2. UNIT II REQUIREMENTS
ANALYSIS AND
SPECIFICATION
Software Requirements: Functional and Non-
Functional, User requirements, System
requirements, Software Requirements
Document – Requirement Engineering
Process: Feasibility Studies, Requirements
elicitation and analysis, requirements
validation, requirements management-
Classical analysis: Structured system Analysis,
Petri Nets- Data Dictionary.
3. Software Requirements
Requirement Engineering:
The process of establishing the services that the
customer requires from a system
the constraints under which it operates and is
developed.
Requirements specify what the system is supposed
to do, but not how the system is to accomplish its
task.
4. Software Requirements
Requirement - It may span a wide range of
statements:
from a high-level abstract statement of a service or
of a system constraint
to a detailed mathematical functional specification
6. Software Requirements
Requirement – User Requirements:
Should describe functional and non-functional
requirements so that they are understandable by
system users who don’t have detailed technical
knowledge
User requirements are defined using natural
language, tables, and diagrams
7. Software Requirements
Requirement – User Requirements:
Problems with natural language
Precision vs. understandability
Functional vs. non-functional requirements
confusion
Requirements mixture
8. Software Requirements
Requirement – User Requirements:
Guidelines:
Prepare a standard format and use it for all requirements.
Apply consistency in the language: ‘shall’ – mandatory
requirements, ‘should’ – desirable requirements.
Avoid the use of computer terminologies. It should be
written in simple language.
9. Software Requirements
Requirement – System Requirements:
More detailed specifications of user requirements
Serve as a basis for designing the system
May be used as part of the system contract
The requirements specify what the system does
and design specifies how it does.
10. Software Requirements
Requirement – System Requirements:
Structured Language Specification:
requirements are written in a standard way.
The requirement become understandable and
expressive.
Uniformity must be maintained.
Graphical model: Sequence Diagram.
12. Software Requirements
Requirement – Domain Requirements:
Requirements that come from the application
domain of the system and that reflect
characteristics of that domain.
These requirements make use of domain
terminologies specific to the specific to the
existing domain concept.
13. Software Requirements
Requirement – Domain Requirements:
These are the specialized requirements and hence
software engineers find it difficult to co-relate the
domain requirements with the system
requirements.
It is important to specify the domain requirements
otherwise the system will not work properly.
14. Functional and non-functional
requirements
Functional requirements
Describe functionality or system services
Statements of services the system should provide,
how the system should react to particular inputs
and how the system should behave in particular
situations.
15. Functional and non-functional
requirements
Functional requirements
It is heavily dependent upon the type of software,
expected users and type of system where the
software is used.
Functional user requirements may be high-level
statements of what the system should do.
Functional system requirements should describe
16. Functional and non-functional
requirements
Functional requirements – Problems:
Requirements imprecision:
Problems arise when functional requirements are
not precisely stated.
Ambiguous requirements may be interpreted in
different ways by developers and users
17. Functional and non-functional
requirements
Functional requirements – Problems:
Requirements completeness and consistency:
Complete : They should include descriptions of all facilities
required.
Consistent: There should be no conflicts or contradictions in the
descriptions of the system facilities
In practice, because of system and environmental complexity, it
is impossible to produce a complete and consistent requirements
document.
18. Functional and non-functional
requirements
Non - Functional requirements:
These define system properties and constraints.
Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
Non-functional requirements may be more critical
than functional requirements. If these are not met,
19. Functional and non-functional
requirements
Non - Functional requirements:
These define system properties and constraints.
Process requirements may also be specified
mandating a particular IDE, programming
language or development method.
Non-functional requirements may be more critical
than functional requirements. If these are not met,
the system may be useless
21. Non-functional requirements -
Types
Product requirements:
Requirements which specify that the delivered product must behave
in a particular way e.g. execution speed, reliability, etc.
Organizational requirements:
Requirements which are a consequence of organizational policies
and procedures e.g. process standards used, implementation
requirements, etc.
22. Non-functional requirements -
Types
External requirements:
Requirements which arise from factors which are external to the
system and its development process e.g. interoperability
requirements, legislative requirements, etc.
23. Non-functional requirements -
Metrics
Reliability: Generate all the updated information in
correct order.
Availability: Any information must be quickly
available from computer to the authorized user.
Security: The application must be password protected.
Maintainability: Any change in requirement occurs
then it should be easily incorporated in an individual
module.
24. Non-functional requirements -
Metrics
Extensibility: Any new requirement occurs then it
should be easily incorporated in an individual module.
Portability: Portable on the desired OS.
Reusability: A segment of source code can be used
again to add new functionalities.
Resource Utilization: Use of resources to its maximum
capability.
25. Non-functional requirements -
Metrics
Property Measure
Speed Processed transactions/second, User/event response time
Screen refresh time
Size Mbytes, Number of ROM chips
Reliability Mean time to failure, Probability of unavailability
Rate of failure occurrence, Availability
Robustness Time to restart after failure, Percentage of events causing
failure, Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems
26. Software Requirements Document
The specification of the system.
It should include both a definition and a specification
of requirements.
It should set of what the system should do rather than
how it should do it.
The SRS is useful in estimating cost, planning team
activities, performing tasks and tracking the team’s
progress.
29. Software Requirements Document
General Description
General functionality of the product: System information,
user characteristics, User objective, general constraints placed
on design team.
The features of the user community, including their expected
expertise with software systems and the application domain.
30. Software Requirements Document
Functional requirements:
It describes the possible effects of a software
system, what the system must accomplish.
Short, imperative sentence stating highest ranked
functional requirements.
31. Software Requirements Document
Functional requirements:
Description: A full description of the requirement.
Criticality: Describes how essential this
requirement is to the overall system.
Technical Issues: Describes any design or
implementation
32. Software Requirements Document
Functional requirements:
Cost and Schedule: Describes the relative or
absolute costs of the system.
Risks: Describes the circumstances under which
this requirement might not able to be satisfied.
Dependencies with other requirements: Describes
interactions with other requirements.
33. Software Requirements Document
Interface requirements:
It describes how the software interfaces with other
software products or users for input or output.
User Interfaces:
GUI: It should include a set of screen dumps user
interface features.
CLI: For each command, a description of all
34. Software Requirements Document
Interface requirements:
Hardware interfaces: interfaces to hardware
devices.
Communication interfaces: Describes network
interfaces.
Software interfaces: Describes the application
programming interfaces not included above.
35. Software Requirements Document
Performance requirements: Specifies speed
and memory requirements.
Design constraints: Specifies any constraints
for the design team such as software or
hardware limitations.
37. Software Requirements Document
Operational Scenarios:
It describes a set of scenarios that illustrate, from
the user’s perspective, what will be experienced
when utilizing the system under various situations.
38. Software Requirements Document
Preliminary Schedule:
It provides an initial version of the project plan,
including the major tasks to be accomplished, their
interdependencies, and their tentative start/stop
dates.
Preliminary Budget:
It provides an initial budget for the project.
39. Software Requirements Document
Appendices:
Definitions, Acronyms, Abbreviations: Provides
definitions terms and acronyms can be provided.
References: It provides complete citations to all
documents and meetings referenced.
40. Characteristics of SRS
Correct: The SRS should be made up to date when
appropriate requirements are identified.
Unambiguous – When the requirements are correctly
understood then only it is possible to write an
unambiguous SRS.
Complete – To make the SRS complete, it should be
specified what a software designer wants to create a
software.
41. Characteristics of SRS
Consistent: It should be consistent with
reference to the functionalities identified.
Specific: The requirements should be
mentioned specifically.
Traceable: What is the need for mentioned
requirement? This should be correctly
identified.
42. Requirement Engineering Process
A Requirement Engineering is a process in
which various activities such as discovery,
analysis and validation of system requirements
are done.
45. Requirement Engineering Process
Functions:
Inception: Specifying the beginning of the
software project. Most of the software projects
get started due to business requirements.
Purpose:
basic understanding of the problem
the people who want a solution and the nature of
46. Requirement Engineering Process
Functions:
Elicitation – Requirements discovery
Difficult to understand customer needs:
Unable to specify the scope of the project.
Difficult to understand the problem and Difficult to communicate with the
system engineer about their needs.
The requirements of the customer changes. This creates a problem of
volatility(Instability).
To overcome these problems, requirements are gathered systematically.
47. Requirement Engineering Process
Functions:
Elicitation – Requirements discovery
Difficult to understand customer needs:
Unable to specify the scope of the project.
Difficult to understand the problem and Difficult to communicate with the
system engineer about their needs.
The requirements of the customer changes. This creates a problem of
volatility(Instability).
To overcome these problems, requirements are gathered systematically.
48. Requirement Engineering Process
Functions:
Elaboration: The information about the
requirements is expanded and refined.
The goal of elaboration activity is to prepare a
technical mode of software functions, features
and constraints.
49. Requirement Engineering Process
Functions:
Negotiation:
Customer may demand for more than that is
achieved .
Customer demands for something which cannot
achieved in limited resources.
50. Requirement Engineering Process
Functions:
Specification - can be any one (or more) of the
following:
A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
51. Requirement Engineering Process
Functions:
Validation—a review mechanism that looks for
errors in content or interpretation
areas where clarification may be required
missing information
inconsistencies (a major problem when large products or
systems are engineered)
conflicting or unrealistic (unachievable) requirements
52. Requirement Engineering Process
Functions:
Requirement Management:
The process of managing changing requirements
during the requirements engineering process and
system development.
54. Feasibility Studies
Focus:
If the system contributes to organizational
objectives;
If the system can be engineered using current
technology and within budget;
If the system can be integrated with other systems
that are used
56. Feasibility Studies
Questions for people in the organisation
What if the system wasn’t implemented?
What are current process problems?
How will the proposed system help?
What will be the integration problems?
Is new technology needed? What skills?
What facilities must be supported by the proposed system?
57. Feasibility Studies
Types:
Technical Feasibility: It is the measure of
technical resources such as hardware
components, software techniques and skilled
persons.
Economical Feasibility: It is the measure
finances or funds are available for proposed
58. Feasibility Studies
Types:
Operational feasibility: It is a measure of how
well the solution of problems or a specific
alternative solution will work in the
organization.
59. Feasibility Studies
Types:
Schedule feasibility: It is the establishment of
time limit for completion of the project. It is
dependent upon available manpower and
economical support for the project.
60. Requirements Elicitation and
Analysis
Sometimes called requirements elicitation or
requirements discovery.
Software engineers communicate with customers
to find out about the application domain, the
services that the system should provide and the
system’s operational constraints.
61. Requirements Elicitation and
Analysis
Stakeholders:
The person(s) who will affected by the system.
Ex: End-user, Managers, System maintenance
engineers, Domain experts and trade union.
62. Requirements Elicitation and
Analysis
Problems of requirements analysis:
Stakeholders don’t know what they really want.
Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting
requirements.
Organisational and political factors may influence the
system requirements.
63. Requirements Elicitation and
Analysis- Process
Requ irem
en ts
class ificatio n an d
org anis ation
Requ irem
en ts
prioritizatio n an d
nego tiation
Requ irem
en ts
do cu m
entation
Requ irem
en ts
dis co very
64. Requirements Elicitation and
Analysis- Process
Requirements discovery:
Interacting with stakeholders to discover their
requirements. Domain requirements are also
discovered at this stage.
Requirements classification and organisation:
Groups related requirements and organizes them
into coherent clusters.
65. Requirements Elicitation and
Analysis- Process
Prioritisation and negotiation:
Prioritising requirements and resolving
requirements conflicts.
If there are some unrealistic requirements then
negotiations are made.
Requirements documentation:
Requirements are documented and input into the
66. Requirements Elicitation and
Analysis- Process
Requirement Discovery:
The process of gathering information about the
proposed and existing systems and distilling the
user and system requirements from this
information.
Sources of information include documentation,
system stakeholders and the specifications of
68. Requirements Elicitation and
Analysis- Methods
Interviewing:
The requirement engineering team communicates
the stakeholders by asking them various questions
about the system and its use.
Types:
Closed interviews where a pre-defined set of
questions are answered
69. Requirements Elicitation and
Analysis- Methods
Interviewing:
Interviews are good for getting an overall
understanding of what stakeholders do and how
they might interact with the system.
70. Requirements Elicitation and
Analysis- Methods
Interviewing - not good for understanding
domain requirements:
Requirements engineers cannot understand specific
domain terminology;
Some domain knowledge is so familiar that people
find it hard to articulate or think that it isn’t worth
articulating.
71. Requirements Elicitation and
Analysis- Methods
Interviewing – Characteristics:
The interviews should be conducted in a free environment
and they should be conducted with open minded approach.
The requirement engineers should listen to stakeholders
with patience.
Interviewee should start the discussion by asking questions
and the requirements should be gathered together.
72. Requirements Elicitation and
Analysis- Methods
Scenario:
The sequence of interactions made by the user
with the software systems.
To formulate actual system requirements.
The interaction sessions.
73. Requirements Elicitation and
Analysis- Methods
Scenario:
A description of the starting situation;
A description of the normal flow of events;
A description of what can go wrong;
Information about other concurrent activities;
A description of the state when the scenario
finishes.
74. Requirements Elicitation and
Analysis- Methods
View point:
Viewpoints are a way of structuring the
requirements to represent the perspectives of
different stakeholders.
Stakeholders may be classified under different
viewpoints.
75. Requirements Elicitation and
Analysis- Methods
View point – Types:
Interactor viewpoints: People or other systems that
interact directly with the system. In an ATM, the
customer’s and the account database are interactor
VPs.
Indirect viewpoints: Stakeholders who do not use the
system themselves but who influence the
requirements. Ex: Security Staff
76. Requirements Elicitation and
Analysis- Methods
View point – Types:
Domain viewpoints: Domain characteristics and
constraints that influence the requirements.
Ex: In Library system, the rules that are to
followed for reserving the book.
77. Requirements Elicitation and
Analysis- Methods
View point – Examples:
Article
providers
Finance
Library
manager
Library
staff
Users
Interactor
Indirect
All VPs
Classification
system
UI
standards
Domain
External
Staff
Students Cataloguers
System
managers
78. Requirements Elicitation and
Analysis- Methods
Use cases:
To identify individual interactions with the
system.
Use cases are extensively used for requirements
elicitation.
79. Requirements Elicitation and
Analysis- Methods
Use Case Diagram:
Use case diagrams describe the functionality of a
system and users of the system. They contain the
following elements:
Actors - users of a system, including human users
and other systems
Use cases - functionality or services provided by a
81. Requirements Elicitation and
Analysis- Methods
Class Diagram: It describes the static structure
of a system, or how it is structured rather than
how it behaves.
Elements:
Classes: Entities with common characteristics or
features. Attributes, Operations, and Associations
Associations: relationships that relate two or more
83. Requirements Elicitation and
Analysis- Methods
Sequence Diagram: Sequence diagrams
typically show the flow of functionality
through a use case, and consist of the
following components:
Actors , involved in the functionality
Objects , that a system needs to provide the
functionality
85. Requirements Elicitation and
Analysis- Methods
Collaboration Diagrams:
The focus of the collaboration diagram is on the
roles of the objects as they interact to realize a
system function.
These links are labeled using appropriate
messages.
Each message is prefixed with a sequence number
87. Requirements Elicitation and
Analysis- Methods
State Diagram:
State transition diagrams provide a way to model
the various states in which an object can exist.
State transition diagrams model the dynamic
behavior of a system in response to external
events.
States - Possible situations in which an object can
89. Requirements Elicitation and
Analysis- Methods
Activity Diagram:
It describes the activities of a class
It describes the behavior/states of a class in
response to internal processing.
90. Requirements Elicitation and
Analysis- Methods
Activity Diagram – Elements:
Swimlanes - delegate specific actions to objects
within an overall activity
Action States - uninterruptible actions of entities, or
steps in the execution of an algorithm
Action Flows - relationships between the different
action states on an entity
92. Requirements Elicitation and
Analysis- Methods
Ethnography:
A technique of observation which is used to
understand social and organizational requirements.
The system analyst imagines himself as a part of
the working environment in which the system will
be used.
The analyst finds the implicit requirements of the
93. Requirements Elicitation and
Analysis- Methods
Ethnography - Types.
Requirements obtained from working style of
people:
Requirements can be identified from the sequence
of actions that user is performing.
Valid card and Valid PIN must be entered for
getting the money from ATM
94. Requirements Elicitation and
Analysis- Methods
Ethnography - Types.
Requirements obtained from inter-activities
performed by the people:
Sometimes for finding the social requirements the
other people’s activities should be known.
Ex: ATM system the operator can not shutdown the
system if some transaction is in processing.
95. Requirements Validation
A process in which it is checked that whether
the gathered requirements represent the same
system that customer really wants.
96. Requirements Validation
Requirement Checking:
Validity. Does the system provide the functions which best
support the customer’s needs?
Consistency. Are there any requirements conflicts?
Completeness. Are all functions required by the customer
included?
Realism. Can the requirements be implemented given available
budget and technology
Verifiability. Can the requirements be checked?
97. Requirements Validation
Techniques:
Requirements reviews - Systematic manual
analysis of the requirements
Regular reviews should be held while the
requirements definition is being formulated.
Both client and contractor staff should be involved
in reviews.
99. Requirements Validation
Techniques:
Test-case generation - Developing tests for
requirements to check testability
Verifiability - Is the requirement realistically
testable?
Comprehensibility - Is the requirement properly
understood?
101. Requirements Management
Requirements are always incomplete and
inconsistent
New requirements emerge during the process
as business needs change and a better
understanding of the system is developed;
Different viewpoints have different
requirements and these are often contradictory.
102. Requirements Management
Enduring and volatile requirements:
Enduring requirements. Stable requirements
derived from the core activity of the customer
organisation. E.g. a hospital will always have
doctors, nurses, etc. May be derived from
domain models
Volatile requirements. Requirements which
103. Requirements Management
Volatile requirements:
Mutable requirements – Change in the environment
Consequential requirements – Changes due to CBS
Emergent requirements – Customer’s understanding
of the system
Compatibility requirements – depend upon the
specific system or business process.
104. Requirements Management
Planning
During the requirements engineering process,
you have to plan:
Requirements identification - How requirements
are individually identified;
A change management process - The process
followed when analysing a requirements change;
105. Requirements Management
Planning
Traceability policies - The amount of
information about requirements relationships
that is maintained;
CASE tool support - The tool support required
to help manage requirements change;
106. Requirements Management
Planning
Traceability policies – Types:
Source Traceability: The links from requirement to
stakeholders who propose these requirements.
Requirement Traceability: The links between
dependent requirements.
Design Traceability: The links from requirements to
design.
110. Requirements Change Management
Problem Analysis and change specification:
To validate the required change.
Change Analysis and costing:
The effect of change using traceability
information.
The cost of such change is estimated
The decision is made on whether to go for
111. Requirements Change Management
Change Implementation
The requirement document has to be modified.
The document has to either re-written or re-
organized.
This can be achieved by making the modularity
112. Structured System Analysis
A technique in which the system requirements
are converted into specifications and then into
computer programs, hardware configurations
and related manual procedures.
113. Structured System Analysis
The system can be modeled using:
Entity Relationship diagram are used to represent
the data model.
Data flow diagram and control flow diagrams are
used to represent the functional model.
114. Structured System Analysis
Designing Data Flow Diagrams:
It is used to model information and function
domain.
Refinement of DFD into greater levels helps the
analyst to perform functional decomposition.
115. Structured System Analysis - Data
Flow Diagrams
Guidelines:
Level 0 DFD. Context level DFD should depict
the system as a single bubble.
Primary input and primary output should be
carefully identified.
While doing the refinement isolate processes, data
objects and data stores to represent the next level.
116. Structured System Analysis - Data
Flow Diagrams
Symbols:
Symbols Description
External Entity: A source of data or a
destination for data.
A process transforms incoming data
flow into outgoing data flow
117. Structured System Analysis - Data
Flow Diagrams
Symbols:
Symbols Description
Data in the system
The flow of information from one
entity to another
118. Structured System Analysis - Data
Flow Diagrams
Rules:
No process can have only outputs or only inputs.
The process must have both outputs and inputs.
The verb phrases in the problem description can
be identified as processes in the system.
There should not be a direct flow between data
stores and external entity. This flow should go
127. Petri Nets
Invented by Carl Adam Petri in 1962
It is used to define the system. It is used for
distributed systems and systems with resource
sharing.
128. Petri Nets
Components:
Places – States of the system
Transitions – Change in the states
Arc – Connects a place with transition
130. Petri Nets
Components:
Set of places P is {p1,p2,p3,p4}
Set of transitions T is {t1,t2}
Input function: I(t1) = {P2,P4}, I(t2) = {P2}
Output function: O(t1) = {P1}, O(t2) = {P3,P3}
131. Petri Nets
A marking of a Petri net is an assignment of
tokens to that Petri net.
.
..
.
P1
P2
P4
P3
t1
t2
132. Petri Nets
Four tokens: one in P1, two in P2, none in P3,
and one in P4.
Represented by the vector (1,2,0,1)
133. Petri Nets
Transition t1 is enabled (ready to fire)
If t1 fires one token is removed from P2, and
one from P4, and one new token is places in
P1
Transition t2 is also enabled.
135. Petri Nets
Transition t1 is enabled (ready to fire)
If t1 fires one token is removed from P2, and
one from P4, and one new token is places in
P1
Transition t2 is also enabled.
137. Data Dictionary
An organized collection of all the data
elements of the system with precise and
rigorous definitions so that user and system
analyst will have a common understanding of
inputs, outputs, components of stores and
intermediate calculations
138. Data Dictionary
Field Name Description
Name Name of the data item.
Aliases Other name of the data item.
Description / Purpose A notation for representing its goal or
context.
Related data item Relevant data item.
Range of value Value between the item.
Data Structure Definition Form of the data item
Where used / How used Input to the process, output from the
process, as a store and external entity
Supplementary information Data types, preset values, restrictions or
limitations.
139. Data Dictionary
Field Name Description
Name Telephone_Number
Aliases Phone_Number, Mobile_Number
Description / Purpose First 2 digit indicates Country Code, Next
4 digits represents district code, Last 6
digit indicates your number, etc.
Where used / How used Address / Visiting Card / Display / read
the Telephone_Number
Format Numeric / Min 6 digit / max 10 digit /
Starts with +, etc..
140. Data Dictionary - Notations
Sl.No. Notation Meaning
1. X = a + b X consists of data elements a & b.
2. X = [a / b] X consists of either data elements a or b.
3. X = a X consists of an optional data element a.
4. X = Y{a} X consists of Y or more occurrence of data
element a.
5. X = {a}z X consists of Z or fever occurrences of data
element a
6. X = y {a} z X consist of some occurrence of data
element a which are between Y and Z.
141. Data Dictionary - Advantages
1. Mechanism for name management. The data
dictionary software can check for name
uniqueness and tell requirements analysts of
name duplications. The names should be used
consisting and should not clash.
2.It serves as a store of organizational
information that can link analysis, design,