Requirements analysis, also called requirements engineering, is the process of determining user expectations for a new or modified product. These features, called requirements, must be quantifiable, relevant and detailed. In software engineering, such requirements are often called functional specifications. Requirements analysis is an important aspect of project management.

1. Requirements Analysis and
Modeling

2. Requirements Engineering Activities
Requirements
Elicitation
Requirements
Analysis and
Negotiation
Requirements
Specification
Requirements
Validation
User Needs,
Domain Information,
Existing System
Information, Regulations,
Standards, Etc.
Requirements
Document
Agreed
Requirements

3. 3
Requirements Elicitation
• Determining the system requirements
through consultation with stakeholders,
from system documents, domain
knowledge, and market studies
• Requirements acquisition or requirements
discovery

4. 4
Requirements Analysis and Negotiation - 1
• Understanding the relationships among
various customer requirements and shaping
those relationships to achieve a successful
result
• Negotiations among different stakeholders
and requirements engineers
Requirements analysis and negotiation activity is
performed by

5. 5
Requirements Analysis and Negotiation - 2
• Incomplete and inconsistent information needs to be tackled
here
• Some analysis and negotiation needs to be done on account
of budgetary constraints

6. 6
Requirements Specification
• Building a tangible model of requirements
using natural language and diagrams
• Building a representation of requirements
that can be assessed for correctness,
completeness, and consistency
Requirements specification includes

7. 7
Requirements Document
• Detailed descriptions of the required software system
in form of requirements is captured in the
requirements document
• Software designers, developers and testers are the
primary users of the document

8. 8
Requirements Validation
• It involves reviewing the requirements model for consistency and
completeness
• This process is intended to detect problems in the requirements
document, before they are used as a basis for the system
development

9. 9
Requirements Management
• Although, it is not shown as a separate
activity in RE Process, it is performed through
out the requirements engineering activities.
• Requirements management asks to identify,
control and track requirements and the
changes that will be made to them

10. 10
Till-Now
• Requirements engineering is the process by which we can
systematically determine the requirements for a software
product
• It is one of the most critical processes of software life cycle
• If performed correctly, it sets the software project on a track
which results in a successful project

11. Requirement Analysis
• Requirement Analysis bridges the gap b/w
Elicitation and requirement specification
Requirement
Elicitation
Requirement
Analysis
Requirement
Specification

12. Requirements Analysis [1]
• What is it?
 The process by which customer needs are understood and
documented.
 Example 1:
 The system shall allow users to withdraw cash. [What?]
 Example 2:
 A sale item’s name and other attributes will be stored in a hash
table and updated each time any attribute changes. [How?]
 Expresses “what” is to be built and NOT “how” it is to be
built.

13. Iterative Aspects of Elicitation, Analysis, and
Negotiation
Requirements
Elicitation
Requirements
Analysis
Requirements
Problems
Requirements
Negotiation
Requirements
Documents
Draft
Statement of
Requirements

14. 14
Requirements Analysis and Negotiation
• We’ll discuss requirements analysis and negotiation
separately, in order to understand them clearly and to
appreciate that different skills are needed to perform them
• They are inter-leaved activities and join to form a major
activity of the requirements engineering process

15. 15
Requirements Analysis - 1
• The aim of requirements analysis is to discover problems
with the system requirements, especially incompleteness
and inconsistencies
• Some analysis is inter-leaved with requirements elicitation as
problems are sometimes obvious as soon as a requirement is
expressed

16. 16
Requirements Analysis - 2
• Detailed analysis usually takes place after the initial draft of the
requirements document is produced
• Analysis is concerned with incomplete set of requirements, which has
not been discussed by stakeholders

17. Requirements Analysis Process
Necessity
checking
Consistency and
completeness
checking
Feasibility
checking
Unnecessary
requirements
Conflicting and
incomplete
requirements
Infeasible
requirements

18. Necessity Checking
• The need for the requirement is analyzed. In some
cases, requirements may be proposed which don’t
contribute to the business goals of the organization or
to the specific problem to be addressed by the system

19. Consistency and Completeness
Checking
• The requirements are cross-checked for consistency
and completeness. Consistency means that no
requirements should be contradictory; Completeness
means that no services or constraints which are
needed have been missed out

20. Feasibility Checking
• The requirements are checked to ensure that they are
feasible in the context of the budget and schedule
available for the system development

21. 21
Analysis Techniques
• Analysis checklists
• A checklist is a list of questions which analysts may use to assess each
requirement
• Interaction matrices
• Interaction matrices are used to discover interactions between requirements
and to highlight conflicts and overlaps

22. 22
Analysis Checklists - 1
• Each requirement may be assessed against the checklist
• When potential problems are discovered, these should be
noted carefully
• They can be implemented as a spreadsheet, where the rows
are labeled with the requirements identifiers and columns
are the checklist items

23. 23
Analysis Checklists - 2
• The are useful as they provide a reminder of what to look for
and reduce the chances that you will forget some
requirements checks
• They must evolve with the experience of the requirements
analysis process
• The questions should be general, rather than restrictive,
which can be irrelevant for most systems

24. 24
Checklist Items - 1
• Premature design
• Combined requirements
• Unnecessary requirements
• Use of non-standard hardware

25. 25
Checklist Items Description - 1
• Premature design
• Does the requirement include premature design or implementation
information?
• Combined requirements
• Does the description of a requirement describe a single requirement or could
it be broken down into several different requirements?

26. 26
Checklist Items Description - 2
• Unnecessary requirements
• Is the requirement ‘gold plating’? That is, is the requirement a
cosmetic addition to the system which is not really necessary
• Use of non-standard hardware
• Does the requirement mean that non-standard hardware or
software must be used? To make this decision, you need to know
the computer platform requirements

27. 27
Checklist Items - 2
• Conformance with business goals
• Requirements ambiguity
• Requirements realism
• Requirements testability

28. 28
Checklist Items Description - 3
• Conformance with business goals
• Is the requirement consistent with the business goals defined
in the introduction to the requirements document?
• Requirements ambiguity
• Is the requirement ambiguous i.e., could it be read in different
ways by different people? What are the possible
interpretations of the requirement?

29. 29
Checklist Items Description - 4
• Requirements realism
• Is the requirement realistic given the technology which will be
used to implement the system?
• Requirements testability
• Is the requirement testable, that is, is it stated in such a way
that test engineers can derive a test which can show if the
system meets that requirement?

30. 30
Up-till Now
• Discussed requirements analysis, which is an iterative activity
and checks for incomplete and inconsistent requirements
• Studied analysis checklists, and will continue our discussion
of requirements analysis.
• We’ll talk about requirements negotiation.

31. 31
What’s Next
• We’ll spend some time discussing interaction matrices, another
requirements analysis technique
• We’ll talk about requirements negotiation

32. 32
Requirements Interactions - 1
• A very important objective of requirements analysis is to
discover the interactions between requirements and to
highlight requirements conflicts and overlaps
• A requirements interaction matrix shows how requirements
interact with each other, which can be constructed using a
spreadsheet

33. 33
Requirements Interactions - 2
• Each requirement is compared with other requirements, and
the matrix is filled as follows:
• For requirements which conflict, fill in a 1
• For requirements which overlap, fill in a 1000
• For requirements which are independent, fill in a 0
• Consider an example

34. 34
An Interaction Matrix
Requirement R1 R2 R3 R4 R5 R6
R1 0 0 1000 0 1 1
R2 0 0 0 0 0 0
R3 1000 0 0 1000 0 1000
R4 0 0 1000 0 1 1
R5 1 0 0 1 0 0
R6 1 0 1000 1 0 0

35. 35
Comments on Interaction Matrices - 1
• If you can’t decide whether requirements conflict, you should assume
that a conflict exists. If an error is made it is usually fairly cheap to fix;
it can be much more expensive to resolve undetected conflicts

36. 36
Comments on Interaction Matrices - 2
• In the example, we are considering, we can see that R1 overlaps with
R3 and conflicts with R5 and R6
• R2 is an independent requirement
• R3 overlaps with R1, R4, and R6

37. 37
Comments on Interaction Matrices - 3
• The advantage of using numeric values for conflicts and
overlaps is that you can sum each row and column to find
the number of conflicts and the number of overlaps
• Requirements which have high values for one or both of
these figures should be carefully examined

38. 38
Comments on Interaction Matrices - 4
• A large number of conflicts or overlaps means that any
changes to that requirement will probably have a major
impact of the rest of the requirements
• Interaction matrices work only when there is relatively small
number of requirements, as each requirement is compared
with every other requirement

39. 39
Comments on Interaction Matrices - 5
• The upper limit should be about 200 requirements
• These overlaps and conflicts have to be discussed and resolved during
requirements negotiation, which we’ll discuss next

40. 40
Requirements Negotiations

41. 41
Requirements Negotiation - 1
• Disagreements about requirements are inevitable
when a system has many stakeholders. Conflicts
are not ‘failures’ but reflect different stakeholder
needs and priorities
• Requirements negotiation is the process of
discussing requirements conflicts and reaching a
compromise that all stakeholders can agree to

42. 42
Requirements Negotiation - 2
• In planning a requirements engineering process, it is important to
leave enough time for negotiation. Finding an acceptable compromise
can be time-consuming

43. 43
Requirements Negotiation - 3
• The final requirements will always be a compromise which is
governed by the needs of the organization in general, the specific
requirements of different stakeholders, design and implementation
constraints, and the budget and schedule for the system development

44. 44
Requirements Negotiation Stages
• Requirements discussion
• Requirements prioritization
• Requirements agreement

45. 45
Requirements Discussion
• Requirements which have been highlighted as problematic are
discussed and the stakeholders involved present their views about
the requirements

46. 46
Requirements Prioritization
• Disputed requirements are prioritized to identify critical requirements
and to help the decision making process

47. 47
Requirements Agreement
• Solutions to the requirements problems are identified and a
compromised set of requirements are reached. Generally, this will
involve making changes to some of the requirements

48. Requirements Negotiation Process
Requirements
discussion
Requirements
prioritization
Requirements
agreement
Unnecessary
requirements
Conflicting and
incomplete
requirements
Infeasible
requirements

49. 49
Comments on Requirements Negotiation - 1
• In principle, requirements negotiation should be an objective process
• The requirements for the system should be based on technical and
organizational needs

50. 50
Comments on Requirements Negotiation - 2
• Negotiations are rarely conducted using only logical and technical
arguments
• They are influenced by organizational and political considerations,
and the personalities of the people involved

51. 51
Comments on Requirements Negotiation - 3
• A strong personality may force their priorities on other
stakeholders
• Requirements may be accepted or rejected because they
strengthen the political influence in the organization of some
stakeholders
• End-users may be resistant to change and may block
requirements, etc.

52. 52
Comments on Requirements Negotiation - 4
• The majority of time in requirements negotiation is usually spent
resolving requirements conflicts. A requirement conflicts with other
requirements if they ask for different things
• Example of access of data in a distributed system

53. 53
Comments on Requirements Negotiation - 5
• Even after years of experience, many companies do not allow enough
time for resolution of conflicts in requirements
• Conflicts should not be viewed as ‘failures’, they are natural and
inevitable – rather healthy

54. 54
Resolution of Requirements Conflicts
• Meetings are the most effective way to negotiate requirements and
resolve requirements conflicts
• All requirements which are in conflict should be discussed individually
• Negotiation meetings should be conducted in three stages

55. 55
Stages of Negotiation Meetings
• Information stage
• Discussion stage
• Resolution stage

56. 56
Information Stage
• An information stage where the nature of the problems
associated with a requirement is explained

57. 57
Discussion Stage
• A discussion stage where the stakeholders involved discuss
how these problems might be resolved
• All stakeholders with an interest in the requirement should be
given the opportunity to comment. Priorities may be assigned to
requirements at this stage

58. 58
Resolution Stage
• A resolution stage where actions concerning the requirement are
agreed
• These actions might be to delete the requirement, to suggest specific
modifications to the requirement or to elicit further information about the
requirement

59. 59
Up-till Now
• Interaction matrices are very useful for capturing
interactions among requirements
• Requirements negotiation is always necessary to resolve
requirements conflicts and remove requirements overlaps.
Negotiation involves information interchange, discussion and
resolution of disagreements

60. Requirements Analysis [2]
• C- and D-Requirements
 C-: Customer wants and needs; expressed in
language understood by the customer.
 D-: For the developers; may be more formal.

61. Requirements Analysis [3]
Why document requirements?
• Serves as a contract between the customer and the
developer.
• Serves as a source of test plans.
• Serves to specify project goals and plan development
cycles and increments.

62. Requirements Analysis [4]
• Roadmap:
 Identify the customer.
 Write C-requirements, review with customer, and update when
necessary.
 Interview customer representatives.
 Write D-requirements; check to make sure that there is no
inconsistency between the C- and the D-requirements.

63. Requirements Analysis [5]
• C-requirements:
 Use cases expressed individually and with a use case diagram. A use
case specifies a collection of scenarios.
 Sample use case: Process sale.
 Data flow diagram:
 Explains the flow of data items across various functions. Useful for
explaining system functions. [Example on the next slide.]
 State transition diagram:
 Explains the change of system state in response to one or more
operations. [Example two slides later.]
 User interface: Generally not a part of requirements analysis though may
be included.

64. Data Flow Diagram
Get employee
file
Total pay
Deduct
taxes
Net pay
Issue
paycheck
Regular
hours
Overtime
hours
ID
Worker
Check
Company records
Employee Record
Tax rates
Pay rate
Weekly
pay* Pay Overtime
pay
*
Overtime
rate
*

65. State Transition Diagram (STD)
EBOFF (e,f) EBON (e,f)
EBP(e,f)
EBP(e,f)
EBOFF (e,f): Elevator e button OFF at floor f.
EBON (e,f): Elevator e button ON at floor f.
EBP(e,f): Elevator e button f is pressed.
Elevator example (partial):

66. Requirements Analysis [6]
• D-requirements:
 Organize the D-requirements.
 Create sequence diagrams for use cases:
 Obtain D-requirements from C-requirements and
customer.
 Outline test plans
 Inspect
 Validate with customer.
 Release:

67. Requirements Analysis [7]
• Organize the D-requirements:
• Functional requirements
• The blood pressure monitor will measure the blood pressure and
display it on the in-built screen.
• Non-functional requirements
• Performance
• The blood pressure monitor will complete a reading within 10
seconds.
• Reliability
The blood pressure monitor must have a failure probability of less
than 0.01 during the first 500 readings.

68. Requirements Analysis [8]
• Interface requirements: interaction with the users and other
applications
The blood pressure monitor will have a display screen and
push buttons. The display screen will….
 Constraints: timing, accuracy
• The blood pressure monitor will take readings with an
error less than 2%.

69. Requirements Analysis [9]
Properties of D-requirements:
 Traceability:Functional requirements
D-requirement  inspection report  design segment 
code segment  code inspection report  test plan 
test report
 Traceability:Non-Functional requirements
(a) Isolate each non-functional requirement.
(b) Document each class/function with the related non-
functional requirement.

70. Requirements Analysis [10]
• Testability
It must be possible to test each requirement. Example ?
 Categorization and prioritization

71. Prioritizing (Ranking) Use Cases
• Strategy :
• pick the use cases that significantly influence the core
architecture
 pick the use cases that are critical to the success of the
business.
 a useful rule of thumb - pick the use cases that are the highest
risk!!!

72. Requirements Analysis [11]
 Completeness
Self contained, no omissions.
 Error conditions
State what happens in case of an error. How should the
implementation react in case of an error condition?

73. Consistency of Requirements
 Different requirements must be consistent.
R5.4: When the vehicle is cruising at a speed greater
than 300 mph, a special “watchdog” safety
mechanism will be automatically activated.
Example:
R1.2: The speed of the vehicle will never exceed 250 mph.

74. Requirement Analysis Techniques
• Model requirements
• Draw context diagram and detail diagrams
• Create prototypes
• Analyze feasibility
• Prioritize requirements
• Create data dictionary
• Decision Trees and Decision Tables
• Allocate requirements to subsystems
• Analysis checklists
• Requirements Interactions

75. Model requirements
• Data model
• shows relationships among system objects
• Functional model
• description of the functions that enable the
transformations of system objects
• Behavioral model
• manner in which software responds to events from the
outside world

76. Importance of RE Negotiation
• How the requirements were negotiated is far more important
than how the requirements were specified” (Tom DeMarco,
ICSE 96)
• “Negotiation is the best way to avoid “Death March” projects”
(Ed Yourdon,ICSE 97)
• “Problems with reaching agreement were more critical to my
projects’
• Success than such factors as tools, process maturity, and
design methods”(Mark Weiser, ICSE 97)

77. Requirements Negotiation Process
Requirements
discussion
Requirements
prioritization
Requirements
agreement
Requirements Negotiation
Unnecessary
requirements
Conflicting and
incomplete
requirements
Infeasible
requirements

78. Requirement Errors
• Errors of omission
• Domain experts easily forget to convey domain knowledge to
requirements engineers, because they consider that to be
obvious and implicit
• Errors of clarity and ambiguity
• Primarily, because natural languages (like English) are used to
state requirements, while such languages are themselves
ambiguous
• Errors of speed and capacity
• These occur due to conflicting understanding or competing
needs of different stakeholders

79. 79
Addressing Requirements Errors
• Prevention
• Removal

80. 80
Prevention vs. Removal
• For requirements errors, prevention is usually more effective
than removal
• Joint application development (JAD), quality function
deployment (QFD), and prototyping are more effective in
defect prevention
• Requirements inspections and prototyping play an important
role in defect removal

81. 81
Defect Prevention - 1
• Don’t let defects/errors become part of the requirements document
or requirements model in the first place
• How is it possible?
• Understanding application domain and business area is the first step
in defect prevention

82. 82
Defect Prevention - 2
• Training in different requirements engineering activities
(elicitation, analysis and negotiation, specification, and
validation) is also very important for defect prevention
• Allocating enough time to conduct requirements engineering
activities also is very important in this regard

83. 83
Defect Prevention - 3
• Willing and active participation of stakeholders in different activities
of requirements engineering. That is why JAD is very useful in defect
prevention as far as requirements errors are concerned

84. 84
Defect Prevention - 4
• An overall commitment to quality and emphasis on using
documented processes is also a very important
• An overall commitment to process improvement

85. 85
Q.F.D. - 1
• Quality Function Deployment
• Customer’s needs imply technical requirements:
• Normal requirements
(minimal functional & performance).
• Expected requirements
(important implicit requirements, i.e. ease of use).
• Exciting requirements
(may become normal requirements in the future, highly prized & valued).

86. 86
Q.F.D. - 2
• Function Deployment:
• Determines value of required function.
• Information Deployment:
• Focuses on data objects and events produced or consumed by the system.
• Task Deployment:
• product behavior and implied operating environment.

87. 87
Q.F.D. - 3
• Value Analysis makes use of:
• Customer interviews.
• Observations.
• Surveys.
• Historical data.
• to create
• Customer Voice Table
• extract expected requirements
• derive exciting req.

88. 88
Use Cases
• Scenarios that describe how the product will be used in specific situations.
• Written narratives that describe the role of an actor (user or device) as it interacts
with the system.
• Use-cases designed from the actor's point of view.
• Not all actors can be identified during the first iteration of requirements
elicitation, but it is important to identify the primary actors before developing the
use-cases.

89. 89
User Profile - Example
• Full Control (Administrator)
• Read/Write/Modify All (Manager)
• Read/Write/Modify Own (Inspector)
• Read Only (General Public)

90. 90
Use Case Example - 1
• Read Only Users
• The read-only users will only read the database and cannot insert, delete or
modify any records.
• Read/Write/Modify Own Users
• This level of users will be able to insert new inspection details, facility
information and generate letters. They will be also able to modify the entries
they made in the past.

91. 91
Use Case Example - 2
• Read/Write/Modify All Users
• This level of users will be able to do all the record maintenance tasks. They
will be able to modify any records created by any users.
• Full Control Users
• This is the system administrative level which will be able to change any
application settings, as well as maintaining user profiles.

92. 92

93. 93