The document discusses roles and responsibilities in requirements engineering. It describes basic roles like clients/customers who define needs and contractors/suppliers who deliver solutions. Stakeholders are identified who have interests in the project. Requirements engineering tasks include analyzing business processes, identifying and analyzing requirements, quality assurance of requirements, creating specifications, and risk analysis. Professionals in this field require skills like moderation, communication, and analytical thinking.

1. SOFTWARE REQUIREMENT ENGINEERING
Prepared By:
Ahmed Alageed
1
4- RESPONSIBILITIES AND ROLES

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

25. REQUIREMENT IDENTIFICATION
 Transform stakeholder
desires, expectations, and needs into
informal, textual, potential requirements.
25

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, correctness, feasibility
(e.g.,technical, financial, schedule, etc.),
verifiability, 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

35. REQUIREMENT ANALYSIS PROCEDURE
1. Analysis of the needs
2. Description of the solution
3. Cost estimate and prioritization
35

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

39. 39

40. FUNCTIONAL DECOMPOSITION
 A Functional Decomposition Diagram
enables you to view your system functions in
an hierarchical structure
40

41. 41

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

43. 43

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

45. 45

46. PETRI NET
 Like the activity diagram
46

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

48. 48

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

53. USE-CASE DIAGRAM EXAMPLE
53
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System

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

56. <<INCLUDE>> EXAMPLE
56
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System
Check
Account
Balance

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

58. <<EXTEND>> EXAMPLE
58
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System
Check
Account
Balance
Reject
Request

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

60. GENERALIZATION/SPECIALIZATION EXAMPLE
Open
Account
Close
Account
Credit
Account
Debit
Account
Print
Statemen
t
Accounts
manager
Teller
ATM
Bank
System
Check
Account
Balance
Transfer
Funds
Reject
Request

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

66. 66

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

76. SEQUENTIAL CONTROL FLOW
 A Sequence of Activities Node
 Unconditional Flow
76

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

79. 79

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

82. EXCLUSIVE GUARDS NEEDED
82

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

86. 86

87. CLASS DIAGRAM
87

88. STATE DIAGRAM
88

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, s
ubject 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

128. 128

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

132. 132

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

146. REQUIREMENTS-RELATED RISKS
REQUIREMENTS ELICITATION
 Solutions presented as needs (The analyst
must drill down to understand the intent
behind a solution the customer has
presented )
146

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

153. REQUIREMENTS-RELATED RISKS
REQUIREMENTS MANAGEMENT
 Unimplemented requirements (The
requirements traceability matrix )
 Expanding project scope ( use incremental
delivery life cycle )
153