The document discusses roles and responsibilities in requirements engineering. It defines key roles like clients/customers who provide needs and contractors/suppliers who deliver solutions. Stakeholders are identified who have interests in the system. Requirements engineering tasks include analyzing business processes, identifying and analyzing requirements, ensuring quality of requirements and specifications, creating requirements specifications, and performing risk analysis. Modeling techniques for requirements include context models, functional decomposition, data flow models, state transition models, and Entity Relationship Models.
2. LEARNING TARGET
What basic roles are there in Requirements
Engineering?
What is a stakeholder?
What are the tasks of Requirements
Engineering?
What is the task of a Professional for
Requirements Engineering?
What characterizes a Professional for
Requirements Engineering?
2
3. 4.1 BASIC ROLES
Client (= customer)
a customer is an individual or organization
who derives either direct or indirect benefit
from a product
The client formulates his needs ( Business
Requirement , User Requirement)
Contractor (= supplier)
The contractor delivers solutions (RA)
3
4. STAKEHOLDER
A stakeholder is a person or a role that has
an interest
Stakeholders can be either natural persons,
legal entities or abstract persons
Stakeholders often have conflicts of interest
among each other
Important: Identification of all stakeholders in
order to take adequate consideration of all
perspectives
4
5. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RIGHTS )
To Expect Analysts to Speak Your Language
To Have Analysts Learn About Your Business
and Objectives
To Expect Analysts to Write a Software
Requirements Specification
To Receive Explanations of Requirements
Work Products
To Expect Analysts and Developers to Treat
You with Respect
5
6. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RIGHTS )
To Describe Characteristics That Make the
Product Easy to Use
To Be Given Opportunities to Adjust
Requirements to Permit Reuse
To Receive Good-Faith Estimates of the
Costs of Changes
To Receive a System That Meets Your
Functional and Quality Needs
6
7. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RESPONSIBILITIES )
To Educate Analysts and Developers About
Your Business
To Spend the Time to Provide and Clarify
Requirements
To Be Specific and Precise About
Requirements
To Make Timely Decisions
To Respect a Developer's Assessment of
Cost and Feasibility
7
8. THE CUSTOMER-DEVELOPMENT PARTNERSHIP (
CUSTOMER RESPONSIBILITIES )
To Set Requirement Priorities
To Review Requirements Documents and
Evaluate Prototypes
To Promptly Communicate Changes to the
Requirements
To Follow the Development Organization's
Change Process
To Respect the Requirements Engineering
Processes the Analysts Use
8
9. RA ROLES
Work collaboratively with customers, users,
and system architects and designers to
identify the real requirements for a planned
system or software development effort to
define the problem that needs to be solved.
Identifying the stated needs of customers and
users.
Studying the business objectives
9
10. RA ROLES
Collaborating with customers and users in a joint
or cooperative environment to analyze the stated
requirements, evolve better requirements, and
prioritize them
Involving system architects in requirements
development.
Utilizing an industry-strength automated
requirements tool to support this work.
10
11. RA ROLES
Work effectively with customers and users to
manage new and changed requirements so
that the project stays under control. Install a
mechanism to control changes.
Be alert to new technologies that may help.
Facilitate the project’s reuse of artifacts and
achieving repeatability.
11
12. RA ROLES
Assist the project and its customers in
envisioning a growth path from the first
release or version of a product through a set
of staged releases to the ultimate system or
product.
Advise the project (and customer) of
methods, techniques, and automated tools
that are available to best support
requirements-related project work and
activities. 12
13. RA ROLES
Use metrics to measure, track, and control
requirements-related project work activities
and results.
Be able to facilitate discussions and to
mediate conflicts.
Study the domain of the area in which the
system or software is being used.
13
14. KNOWLEDGE OF A PROFESSIONAL FOR
REQUIREMENTS ENGINEERING:
Skill of moderation
Self-confident manner
Ability to convince
Language skills
Ability to communicate
Precision
Analytical, clear thinking
Ability to act in a structured way
Methodological competence
Stress resistance
14
15. 4.2 TASKS OF REQUIREMENTS ENGINEERING
Analysis of business processes
Identification and analysis of requirements
Quality assurance of requirements and
specifications
Creation of the requirements specification
Risk analysis
The Professional for Requirements Engineering identifies
wishes and aims.
15
16. ANALYSIS OF BUSINESS PROCESSES
Analyze the business context Include the
following tasks:
Analyze the customer organization’s
business enterprise to understand the:
Business model.
Organizational structure and relationships.
Technology currently being used.
Relevant planned improvements.
16
17. ANALYSIS OF BUSINESS PROCESSES
Analyze the competitor organizations that
produce competing systems to:
Identify, profile, analyze, and understand the
competitors.
See how the planned system [upgrade] will
improve the customer organization’s business
enterprise and help it compete.
17
18. ANALYSIS OF BUSINESS PROCESSES
Analyze current and potential/planned
marketplaces
Analyze critical technologies
Analyze current and intended future user
communities (to understand their needs and
desires and determine how the system might
improve their tasks and workflows)
18
19. ANALYSIS OF BUSINESS PROCESSES
Analyze the stakeholders to:
Identify different stakeholder
persons, roles, organizations, and systems.
Profile them including categorizing them into
well-defined and well understood groups.
Understand their
needs, desires, responsibilities, and tasks.
19
20. ANALYSIS OF BUSINESS PROCESSES
Develop a business case to determine
whether the system [enhancement] should
be developed by
Determining is costs and benefits
Comparing its merits relative to those of
competing systems.
20
21. ANALYSIS OF BUSINESS PROCESSES
VISIONING During this task, the main
RE team collaborates with key
stakeholders to produce a vision of the
new system
Define the system’s mission.
Determine the business problems and
opportunities to be solved by the system.
Determine the most important stakeholder
needs to be fulfilled by the system.
21
22. VISIONING
Determine the most important business,
functional, and quality goals of the system.
Determine any major business, technical,
and legal/regulatory constraints on the
system.
Use this information to build a consensus
among key system stakeholders regarding
the vision of the system to lay a foundation
on which the system requirements can be
engineered.
22
23. IDENTIFICATION AND ANALYSIS OF
REQUIREMENTS
Requirement Identification : During this task,
the RE teams identify potential requirements
include:
Identify sources of requirements (e.g.,
stakeholders, documents, legacy systems,
problem reports, etc).
Elicit needs, goals, desires, and requirements
from a representative sample of all major
stakeholder types
23
24. REQUIREMENT IDENTIFICATION
Gather potential requirements from existing
documents describing legacy or competing
systems, problem reports, marketing surveys,
and other sources.
Invent new requirements so that the system will
be truly better than the legacysystems it will
replace and therefore worth building. Invention is
a critically important, though underutilized,
technique for identifying requirements, and is
often the difference between a highly successful
system and a marginally successful system.
24
26. REQUIREMENTS IDENTIFICATION
During this task, the RE teams identify
potential requirements. This task typically
includes the following subtasks:
Identify sources of requirements (e.g.,
takeholders, documents, legacy
systems,problem reports, etc).
Elicit needs, goals, desires, and requirements
from a representative sample of all major
stakeholder types
26
27. REQUIREMENTS IDENTIFICATION
Gather potential requirements from existing
documents describing legacy or competing
systems, problem reports, marketing surveys,
and other sources.
Invent new requirements so that the system will
be truly better than the legacy systems it will
replace and therefore worth building
Transform stakeholder desires, expectations,
and needs into informal, textual, potential
requirements.
27
28. REQUIREMENTS REUSE
During this task, the RE teams reuse all or
part of preexisting requirements work
products. This task typically includes the
following subtasks:
Identify any potentially relevant reusable
requirements work products (e.g., individual
requirements, requirements templates,
requirements diagrams, requirements models,
and requirements specifications
complete work products + parts of work
products 28
29. REQUIREMENTS REUSE
Evaluate the identified reusable requirements
work products for relevancy to the current
endeavor.
Tailor the relevant identified reusable
requirements work products to meet the needs of
the current endeavor.
Reuse the tailored reusable work products by
incorporating them into the current endeavor’s
requirements work products.
29
30. REQUIREMENTS ANALYSIS
During this task, the RE teams analyze the
identified and reused requirements. Include:
Study, categorize, decompose and organize,
model, quantify, refine, prioritize, justify, and
trace each requirement to its source(s).
Transform informal textual requirements into
semiformal or formal requirements (if formal
methods are used).
30
31. REQUIREMENTS ANALYSIS
Negotiate the prioritization of requirements with
the requirements stakeholders, and use the
negotiated prioritization to help schedule the
implementation of the requirements. Note that
this subtask is often performed concurrently with
the requirements validation task.
Verify any related assumptions.
31
32. REQUIREMENTS ANALYSIS
Transform potential raw requirements and
related information into real requirements that
have the necessary quality characteristics such
as clarity (i.e.,lack of
ambiguity), completeness, consistency, correctne
ss, feasibility
(e.g.,technical, financial, schedule, etc.), verifiabil
ity, and understandability.
Ensure that the requirements are sufficiently well
understood that they can be properly specified.
32
33. REQUIREMENTS PROTOTYPING (OPTIONAL)
During this task, the RE teams generate
requirements engineering prototypes. Include
:
Produce one or more requirements prototypes
(e.g., paper or wireframe prototypes of user
interfaces or executable models).
Evaluate these prototypes. This may involve
analysis of static prototypes or execution and
evaluation of dynamic prototypes.
33
34. REQUIREMENTS PROTOTYPING (OPTIONAL)
Use these prototypes to:
Help identify new requirements such as
functional, data, and quality requirements
regarding user interfaces.
Better understand existing requirements.
Identify defects in the existing requirements that
drove the development of these prototypes.
Support the analysis of these requirements.
34
36. 7.2 METHODS AND TECHNIQUES
Different aspects of a system are
represented through different views
Models are developed through suitable
methods of analysis
Differentiation between types of models
Requirements models
Solution models
36
37. DIFFERENT MODELS (STRUCTURED)
Context model
Functional decomposition
Data flow model
State transition model
Petri Net
Entity Relationship Model
37
38. CONTEXT MODEL
Is a diagram that represents the actors
outside a system that could interact with that
system
This diagram is the highest level view of a
system.
SCDs show a system, often software-based,
as a whole and its inputs and outputs from/to
external factors
38
42. DATA FLOW MODEL
DFDs show the flow of data from external
entities into the system, showed how the
data moved from one process to another, as
well as its logical storage
42
44. STATE TRANSITION MODEL
describe the behavior of systems
State diagrams require that the system
described is composed of a finite number of
state
44
47. ENTITY RELATIONSHIP MODEL
is an abstract and conceptual representation
of data. Entity-relationship modeling is a
database modeling method,
used to produce a type of conceptual
schema or semantic data model of a system,
often a rational database, and its
requirements in a top-down fashion
47
49. 7.3 OBJECT-ORIENTED ANALYSIS
UML (Unified Modeling Language)
UML provides diagrams for different views of
the system
Use case diagrams, class diagrams, activity
diagrams, state diagrams, object diagrams,
sequence diagram, component diagrams,
package diagrams, etc.
49
50. USE-CASE DIAGRAM
Use-Case diagrams are probably the
simplest diagramming notation within the
UML
Use-Case diagrams model the operations of
the system as perceived by an outside user
i.e. They model ‘what’ the system does rather
than ‘how’ it does it !
50
51. USE-CASE DIAGRAM
The two primary elements of UC diagrams are Actors
and Use-Cases
Actors - (shown as stick-men on diagrams)
Model the outside users of the system
Actors are not always humans, can be other
computer systems; external devices etc.
A single user may actually be a different actor at the
same time
Many users may be the same actor at the same time
It is actors that initiate a particular use-case
51
52. USE-CASE DIAGRAM
Use-Cases - (shown as an ellipse on diagrams)
A use-case is a unit of an externally visible
operation (i.e. a single use of the system)
Each use-case is orthogonal within the model
(i.e. each use-case can be performed
independently and in any order)
Each use-case can connect to one or more
actors by a solid line, this indicates an
association between an actor and that particular
use of the system
52
54. REFINING USE-CASE DIAGRAMS
Once an initial use-cases have been documented
they can be refined
The refining of a Use-Case diagram can help
simplify and remove unnecessary redundancy
There are three main ways in which refinement can
be performed (usually aided by reading
descriptions, see later)
Identification of shared sequences of operations
Identification of alternative actions within single use-
cases
Identification of common behavior between use-cases
54
55. USING <<INCLUDE>> ASSOCIATIONS
This type of association allows a shared
sequence of operations to be included in several
use-cases
Simplifies a use-case diagram by factoring out
common operations
When a use-case is included within another
use-case the operations are always
incorporated
The operations from the included use-case are
NOT interleaved, they exist as a single block
Including a use-case is similar to calling a sub- 55
57. USING <<EXTEND>> ASSOCIATIONS
This type of association allows a sequence of
operations to be conditionally included in a use-
case
Improves the model by identifying less common
alternatives to operations normally performed
Extensions are typically attached to an
extension-point within the use-case which is
being extended
If a specific condition is true at the extension
point then the extending use-cases operations
are included, otherwise they are not
Similar to an ‘if-then’ construct within a program57
59. USING GENERALIZATION/SPECIALIZATION
This type of association allows common behavior
to be extracted into generalized use-cases
The common behavior is then inherited by
specialized use-cases
Additional steps in the specialized use-cases can
be interleaved with those inherited from the
generalized use-case
A specialized use-case inherits associations from
its generalized use-case, and can be substituted
for its generalized use-case
61. INTERNALS OF USE-CASES
Use-Case diagrams do not show internal
workings of each use-case
These can be documented using other UML
diagrams or natural language
Tend to use natural language during analysis and
UML diagrams later in the lifecycle
Natural language descriptions should be well-
formed and consist of an agreed upon format
within the s/w company
62. A FORMAT DEFINITION FOR TEXTUAL USE-
CASE DESCRIPTIONS
List all pre-conditions
X-reference name of any generalized use-case
List main sequence of operations (numbered)
Show included use-cases as single step, X-ref the name
List alternatives
X-ref the sequence number of extension point
Specify condition for extension to be utilized
X-reference the sequence number of re-entrance point
63. EXAMPLE DOCUMENTATION OF A USE-
CASE
Use-case : debit account
Inherits from : Transfer Funds
pre-condition: account number exists
1. Read amount to be debited
2. Perform check (Check Account
Balance)
3. Deduct amount to be debited
4. Report success code
64. USE-CASE SUMMARY
Accurate requirements are very important to the
success of analysis and design
Use-Case diagrams can be used to model
requirements as seen from an external, or users’
point of view
Actors & Use-Cases are the two primary elements
of a Use-Case diagram
Refinement of a Use-Case diagram helps remove
redundancy
Internals of each use-case can be defined using
other UML diagrams and/or natural language
65. ACTIVITY DIAGRAM
Activity diagram is used to display the
sequence of activities
Activity Diagrams show the workflow from a
start point to the finish point detailing the
many decision paths that exist in the
progression of events contained in the
activity
They may be used to detail situations where
parallel processing may occur in the
execution of some activities
Activity Diagrams are useful for Business
Modeling where they are used for detailing
the processes involved in business activities65
67. ACTIVITY NODE
An activity is the specification of a
parameterized sequence of behavior
An activity is shown as a round-cornered
rectangle enclosing all the actions, control
flows and other elements that make up the
activity
67
68. ACTION NODE
An action represents a single step within an
activity
Actions are denoted by round-cornered
rectangles.
68
69. ACTION CONSTRAINTS
Constraints can be
attached to an
action
This sample shows
an action with local
pre and post-
conditions.
69
70. CONTROL FLOW
A control flow shows the flow of control from
one action to the next one
Its notation is a line with an arrowhead.
70
71. INITIAL NODE
An initial or start node is depicted by a large
black spot, as depicted below
71
72. ACTIVITY FINAL NODE
There are two types of final node
activity final
flow final nodes
The activity final node is depicted as a circle
with a dot inside
72
73. FLOW FINAL NODE
The flow final node is depicted as a circle
with a cross inside
The difference between the two node types
is that the flow final node denotes the end of
a single control flow
The activity final node denotes the end of all
control flows within the activity
73
74. SAMPLES OF ACTIVITY AND FLOW FINAL NODES
A flow dies without ending the whole activity
A flow final node terminates its own path not
the whole activity
It is shown as a circle with an X through it
74
75. BASIC CONTROL FLOWS
Sequential Control Flow
Branch Control Flow
Iteration Control Flow
75
77. BRANCH CONTROL FLOW
Decision nodes and merge nodes have the
same notation - using a diamond shape
They can both be named
The control flows coming away from a
decision node will have guard conditions
which will allow control to flow if the guard
condition is met
77
78. DECISION NODE
Decisions are used when you want to
execute a different sequence of actions
depending on a condition
Decisions are drawn as diamond-shaped
nodes with one incoming edge and multiple
outgoing edges
Each branched edge contains a guard
condition written in brackets
Guard conditions determine which edge is
taken after a decision node
78
80. MERGE NODE
The branched flows join together at a merge
node, which marks the end of the conditional
behavior started at the decision node
Merges are also shown with diamond-
shaped nodes, but they have multiple
incoming edges and one outgoing edge
80
81. USING MERGE NODE IN UML2
In UML 2.0, it's better to be as clear as
possible and to show merge nodes
81
83. ITERATION CONTROL FLOW
A loop is a sequence of activity nodes which
is specified once but which may be carried
out several times in succession
83
84. CONCURRENT ACTIVITIES
Forks and Joins have the same notation –
using either a horizontal or vertical bar
They indicate the start and end of concurrent
threads of control
84
85. CONCURRENT ACTIVITY
When actions occur in parallel, it doesn't
necessarily mean they will finish at the same
time
In fact, one task will most likely finish before
the other
However, the join prevents the flow from
continuing past the join until all incoming
flows are complete
85
89. 7.4 COST ESTIMATES
Cost estimates connect Requirements
Engineering with the project management
Types of estimate
Costs
Time
Requirements
Quality
Cost estimates help to recognize the cost for
change
89
90. ESTIMATION PROCEDURE
Conclusions by analogy
Algorithmic procedure
Function point procedure
bottom-up Approach
Estimation procedures are always based on
historical data and framework conditions
90
91. 7.5 PRIORITIZATION
Why prioritization?
Prioritization is a way to deal with competing
demands for limited resources
A project manager must balance the desired
project scope against the constraints of
schedule, budget, staff, and quality goals.
One way to accomplish this is to drop—or to
defer to a later release—low-priority
91
92. GAMES PEOPLE PLAY WITH PRIORITIES
Customers and developers both should
provide input to requirements prioritization
customers will establish perhaps 85 percent
of the requirements as high priority, 10
percent as medium, and 5 percent as low.
High priority mean high risk.
92
93. ENCOURAGE CUSTOMER TO IDENTIFY LOW
PRIORITY REQUIREMENT
ask questions such as the following:
Is there some other way to satisfy the need that
this requirement addresses?
What would the consequence be of omitting or
deferring this requirement?
What would the impact be on the project's
business objectives if this requirement weren't
implemented immediately?
Why would a user be unhappy if this requirement
were deferred to a later release?
93
94. A PRIORITIZATION SCALE
common prioritization approach groups
requirements into three categories
One way to assess priority is to consider the
two dimensions of importance and urgency
High priority requirements are both important
(the user needs the capability) and urgent (the
user needs it in the next release). Contractual or
legal obligations might dictate that the
requirement must be included, or there might be
compelling business reasons to implement it
promptly.
94
95. A PRIORITIZATION SCALE
Medium priority requirements are important (the
user needs the capability) but not urgent (they
can wait for a later release).
Low priority requirements are not important (the
user can live without the capability if necessary)
and not urgent (the user can wait, perhaps
forever).
Requirements in the fourth quadrant appear to
be urgent but they really aren't important. Don't
waste your time working on these. They don't
add sufficient value to the product.
95
96. Important Not Important
Urgent High
Priority
Low Priority
Not
Urgent
Medium
Priority
Don't do these!
96
REQUIREMENTS PRIORITIZATION BASED
ON IMPORTANCE AND URGENCY
97. PRIORITIZATION BASED ON VALUE, COST, AND
RISK
The typical participants in the prioritization
process include:
The project manager, who leads the process,
arbitrates conflicts, and adjusts input from the
other participants if necessary
Customer representatives, such as product
champions or marketing staff, who supply the
benefit and penalty ratings
Development representatives, such as team
technical leads, who provide the cost and risk
ratings
97
98. STEPS OF THE PRIORITIZATION MODEL
Step 1:
List in the spreadsheet all the features, use
cases, or requirements that you want to
prioritize; All the items must be at the same level
of abstraction—don't mix functional requirements
with product features.
If certain features are logically linked (for
example, you'd implement feature B only if
feature A were included),
list only the driving feature in the analysis.
If you have more items than that, group related
features together to create a manageable initial
list. 98
99. STEPS OF THE PRIORITIZATION MODEL
Have your customer representatives
estimate the relative benefit that each feature
would provide to the customer or to the
business on a scale of 1 to 9. A rating of 1
indicates that no one would find it useful and
9 means it would be extremely valuable.
These benefit ratings indicate alignment of
the features with the product's business
requirements.
99
100. Estimate the relative penalty that the
customer or business would suffer if the
feature were not included. Again, use a scale
of 1 to 9. A rating of 1 means that no one will
be upset if it's excluded; 9 indicates a serious
downside. When assigning penalty ratings,
consider how unhappy the customers will be
if a specific capability isn't included. Ask
yourselves questions such as the following:
100
STEPS OF THE PRIORITIZATION MODEL
101. ESTIMATE THE RELATIVE PENALTY
Would your product suffer in comparison with other
products that do contain that capability?
Would there be any legal or contractual
consequences?
Would you be violating some government or industry
standard?
Would users be unable to perform some necessary
or expected functions?
Would it be a lot harder to add that capability later as
an enhancement?
Would problems arise because marketing has
promised a feature to satisfy some potential
101
102. STEPS OF THE PRIORITIZATION MODEL
By default, benefit and penalty are weighted
equally. As a refinement, you can change the
relative weights for these two factors
102
103. STEPS OF THE PRIORITIZATION MODEL
Have developers estimate the relative cost of
implementing each feature, again on a scale
of 1 (quick and easy) to 9 (time consuming
and expensive). Developers estimate the
cost ratings based on the feature's
complexity, the extent of user interface work
required, the potential ability to reuse existing
code, the amount of testing and
documentation that will be needed, and so
forth.
103
104. STEPS OF THE PRIORITIZATION MODEL
Similarly, have developers rate the relative
degree of technical or other risks associated
with each feature on a scale of 1 to 9.
Technical risk is the probability of not getting
the feature right on the first try. A rating of 1
means that you can program it in your sleep.
A 9 indicates serious concerns about
feasibility, the lack of staff with the necessary
expertise, or the use of unproven or
unfamiliar tools and technologies.
104
105. STEPS OF THE PRIORITIZATION MODEL
Once you've entered all the estimates into
the spreadsheet, it will calculate a priority
value for each feature using the following
formula:
priority = value %
(cost % * cost weight) + (risk % * risk weight)
105
106. SPECIFICATION OF REQUIREMENTS
In the specification, requirements are
specified in a structured way and are
modeled separately.
The specification serves to track and
manage requirements.
106
107. CREATION OF THE REQUIREMENTS
SPECIFICATION
During this task, the RE teams generate and
publish analyzed and/or validated
requirements in paper or electronic
requirements specification documents.
Include:
System, subsystem, software, and hardware
requirements specifications containing the
individual requirements and associated ancillary
information.
107
108. CREATION OF THE REQUIREMENTS
SPECIFICATION
Operational concept documents (OCDs)
containing use cases, misuse or abuse cases,
and usage scenarios.
Glossary and Domain Object Model to properly
define the meaning of the terms used in the
requirements
108
109. CREATION OF THE REQUIREMENTS
SPECIFICATION
Distribute the requirements specifications to their
audiences or make access available to them.
Iterate the requirements specifications as a
result of informal feedback. Note that more
formal feedback will come as part of the
requirements verification subtask of quality
engineering.
109
110. STANDARD CONTENTS OF A REQUIREMENTS
DOCUMENT
Introduction
Secrecy clause
Regulations
Standards
Stakeholder
Purpose of the product
Description of the system
110
111. STANDARD CONTENTS OF A REQUIREMENTS
DOCUMENT
Functional requirements
Non-functional requirements
Assumptions
Dependencies
Risks
Safety requirements
Software Quality Attributes
Acceptance
111
112. LEVEL OF SPECIFICATION
Requirements specifications
Are also called performance specifications
The creation should be the customer's task
Solution specifications
Are also called functional specifications
The basis for the further system development
112
113. SPECIFICATION PROCEDURE
Specification as an activity for formalizing the
results of the requirements analysis
Different degrees of formalization
Non-formal
Semi-formal
Formal
113
114. REQUIREMENTS MANAGEMENT
During this task, the RE teams manage all
requirements, regardless of their status.
Record and store the requirements and their
attributes (i.e., metadata about the requirements)
in an appropriate repository, database, or
requirements management tool.
Control access (e.g., create, read, update,
delete) to the requirements (e.g., based on
metadata such as authorization to
create/read/update/delete requirements by role,
requirement state, requirement ownership,
requirement responsibility, date of last change to
the requirement, etc.).
114
115. REQUIREMENTS MANAGEMENT
Negotiate with the stakeholders to eliminate any
inconsistencies between requirements and their
priorities.
Report the status of the requirements (e.g., the
number, percentage, and state of the
requirements and requirements categories).
Trace the requirements (e.g., to the associated
architecture, design, implementation, and test
work products).
115
116. REQUIREMENTS VALIDATION
During this task, the RE teams validate the
correctness of the analyzed requirements
with their stakeholders and make any
necessary corrections.
This is an ongoing task
116
117. REQUIREMENTS VALIDATION
Identify a representative sample of all major
stakeholder types (e.g., customers, users,
maintainers, operators, subject matter experts,
marketers, and certifiers) to validate the
requirements.
Ensure these stakeholders validate the
correctness of the requirements.
Iterate to fix any requirements problems.
Certify that the requirements are an acceptable
description of the system, software application,
or component to be implemented.
117
118. RELATED TASKS FROM OTHER DISCIPLINES
Scope Management is the management task
that manages requirements changes that
could significantly change the scope of the
endeavor.
Requirements Verification is the quality
engineering task that controls the quality of
the requirements and other requirements
work products such as requirements models
and requirements specifications.
118
119. RELATED TASKS FROM OTHER DISCIPLINES
Requirements Configuration Control is the
configuration management task that
manages and evaluates the impact of
proposed changes to base-lined
requirements and other requirements work
products.
119
120. RELATIONSHIP BETWEEN THESE TASKS
Iterative in the sense that the same tasks will
typically need to be repeated on the same
work products in order to fix defects and
make other improvements.
Incremental in the sense that most systems
are too large and complex to engineer all
requirements in a big-bang waterfall manner
before beginning the tasks of other
disciplines
120
121. RELATIONSHIP BETWEEN THESE TASKS
Concurrent in the sense that:
Requirements engineering tasks are performed
simultaneously with the tasks of many other
disciplines
The requirements engineering teams rapidly
cycle between tasks while different members of
the requirements team concurrently perform
different tasks on different sets of requirements.
121
122. RELATIONSHIP BETWEEN THESE TASKS
When developing large and complex systems,
different requirements engineering teams are
concurrently performing different requirements
engineering tasks on different components of the
system architecture at different levels of the
system architecture.
122
123. REQUIREMENTS TRACKING
Requirements traceability is concerned with
documenting the life of a requirement and to
provide bi-directional traceability between
various associated requirements.
It enables users to find the origin of each
requirement and track every change which
was made to this requirement.
it may be necessary to document every
change made to the requirement
123
124. GOTEL AND FINKELSTEIN DEFINITION
the ability to describe and follow the life of a
requirement, in both a forward and backward
direction (i.e. from its origin, through its
development and specification, to its
subsequent deployment and use, and
through periods of on-going refinement and
iteration in any of these phases)
124
125. 8.1 TRACING WITHIN THE PROJECT
Traceability
Requirements are not stable, but continue to
develop
Reasons for continued development
New insights
New customer needs
Continued work
New connections within the project
125
126. TRACEABILITY AS A SOLUTION:
Provides a check that all important steps of
the development process have been carried
out
Goals:
Impact analysis, coverage analysis, use-of-
potential analysis, proof of implementation, use
of the requirement, etc.
In order to ensure good traceability, it is
important to label the requirements precisely.
126
127. PRE – AND POST- TRACIBILITY
A SRS (software requirements specification)
is traceable if the origin of each of its
requirements is clear and if it facilitates the
referencing of each requirement in future
development and enhancement
documentation
each requirement to be traced to its origin in
other documents and to the software
component( s) satisfying the requirement.
127
129. TYPES OF TRACEABILITY
backward from requirements traceability (pre-
traceability) implies that we know why every
requirement in the SRS (Software
Requirements Specification) exists. It implies
that each requirement explicitly references its
source in previous documents;
forward from requirements traceability (post-
traceability) implies that we understand which
components of the software satisfy each
requirement. It demands that each requirement
in the SRS explicitly references a design
129
130. TYPES OF TRACEABILITY
backward to requirements traceability (pre-
traceability) implies that every software
component explicitly references those
requirements that it helps to satisfy. It implies
that each requirement in the SRS has a unique
name or reference number;
forward to requirements traceability (post-
traceability) implies that documents that
preceded the SRS can reference the SRS. Like
"back to requirements" traceability, this implies
that each requirement in the SRS has a unique
name or reference number;"
130
131. TYPES OF TRACEABILITY
Horizontal tracing
Horizontal traceability ensures that the
requirements are traceable to the test cases.
vertical tracing
Vertical traceability ensures that the requirements are
traceable to the components of the implemented system
and vice versa.
131
133. 8.2 CHANGE MANAGEMENT
Changes of the requirements (Change
Management)
Changes are checked and decided on by a
Change Control Board
Makes decisions regarding change requests
133
134. THE CHANGE CONTROL BOARD
consists of
Project management
Development
Quality assurance
Business management, if applicable
Customer, if applicable
etc.
134
135. THE CHANGE CONTROL
A structured process is necessary for
changes of requirements
The analysis of the meaning of each change
is important. Hasty solutions are problematic.
Large changes of the requirements can be
so serious that they represent a contractual
change.
135
136. 8.3 METRICS
Metrics make it possible to make a
quantifiable statement regarding the project
status and quality
Classification figures must always be
compared to reference data
136
137. METRICS FOR REQUIREMENTS:
Project costs
Project tracking
Project stability
Process improvement
Quality of the specification
Number of errors
Type of error
137
138. MEASUREMENT OF THE REQUIREMENTS
QUALITY
Are the requirements correct?
Are the requirements understandable?
The higher the change rate, the more a
project is at risk
138
139. RISK MANAGEMENT
Project risk management is the art and science
of identifying, analyzing, and responding to risk
throughout the life of a project and in the best
interests of meeting project objectives
Risk management is often overlooked in
projects, but it can help improve project success
by helping select good projects, determining
project scope, and developing realistic
estimates
139
140. 3.2 WHY RISK MANAGEMENT
minimize the impact of project threats
seize the opportunities that occur
deliver your project on time, on budget and
with the quality results your project sponsor
demands
team members will be much happier if they
do not enter a "fire fighting" mode
140
141. RISK MANAGEMENT GOLDEN ROLES
Make Risk Management Part of Your Project
Identify Risks Early in Your Project
Communicate About Risks
Consider Both Threats and Opportunities
Clarify Ownership Issues
Prioritize Risks
Analyze Risks
141
142. RISK MANAGEMENT GOLDEN ROLES
Plan and Implement Risk Responses
Register Project Risks
142
143. REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
Product vision and project scope
Time spent on requirements development (a
rough guideline is to spend about 10 to 15
percent of your project effort on requirements
development activities )
Completeness and correctness of
requirements specifications (apply the use-
case technique to elicit requirements by
focusing on user tasks)
143
144. REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
Requirements for highly innovative
products (Emphasize market research, build
prototypes, and use customer focus groups )
Defining non-functional requirements (Query
customers about quality characteristics )
Customer agreement on product
requirements (Determine who the primary
customers are, Make sure you're relying on
the right people for decision-making authority
on the requirements )
144
145. REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
Unstated requirements (Customers often
hold implicit expectations that are not
communicated or documented )
Existing product used as the requirements
baseline (Document the requirements that
you discover through reverse engineering,
and have customers review those
requirements to ensure that they are correct
and still relevant )
145
147. REQUIREMENTS-RELATED RISKS
REQUIREMENTS ANALYSIS
Requirements prioritization (Ensure that
every functional requirement, feature, or use
case is prioritized and allocated to a specific
system release or iteration )
Technically difficult features (Evaluate the
feasibility of each requirement to identify
those that might take longer than anticipated
to implement )
147
148. REQUIREMENTS-RELATED RISKS
REQUIREMENTS ANALYSIS
Unfamiliar technologies, methods,
languages, tools, or hardware (Don't
underestimate the learning curve of getting
up to speed with new techniques that are
needed to satisfy certain requirements )
148
149. REQUIREMENTS-RELATED RISKS
REQUIREMENTS SPECIFICATION
Requirements understanding (Formal
inspections of requirements documents by
teams that include developers, testers, and
customers , experienced requirements
analysts , Models and prototypes )
Time pressure to proceed despite
TBDs (Record the name of the person
responsible for closing each TBD and the
target date for resolution )
149
150. REQUIREMENTS-RELATED RISKS
REQUIREMENTS SPECIFICATION
Ambiguous terminology (Create a data
dictionary that defines the data items and
structures )
Design included in requirements (Review the
requirements to make sure they emphasize
what needs to be done to solve the business
problem, rather than stating how it will be
solved. )
150
151. REQUIREMENTS-RELATED RISKS
REQUIREMENTS VALIDATION
Invalidated requirements (Gain commitment
from your customer representatives to
participate in requirements inspections )
Inspection proficiency ( Train all team
members , Invite an experienced inspector )
151
152. REQUIREMENTS-RELATED RISKS
REQUIREMENTS MANAGEMENT
Changing requirements ( defer
implementation of those requirements that
are most likely to change, and design the
system for easy modifiability )
Requirements change process (not having a
defined change process, using an ineffective
change mechanism, and incorporating
changes that bypass the process )
152