Chapter 3

Software Requirement Analysis and

Specification
What is a requirement?
• It may range from a high-level abstract statement of a service
• System constraint to a detailed mathematical functional specification.
• This is unavoidable as requirements may serve a dual function
• May be the basis for a bid for a contract - therefore must be open to
interpretation
• May be the basis for the contract itself - therefore must be defined in detail;
• Both these statements may be called requirements.

30/10/2014 Chapter 4 Requirements Engineering 2

 Types of requirement

• User requirements
• Statements in natural language plus diagrams of the services the system
provides and its operational constraints. Written for customers.
• System requirements
• A structured document setting out detailed descriptions of the system’s
functions, services and operational constraints. Defines what should be
implemented so may be part of a contract between client and contractor.

30/10/2014 Chapter 4 Requirements Engineering 3

System stakeholders
• Any person or organization who is affected by the system in some way
and so who has a legitimate interest
• Stakeholder types
• End users
• System managers
• System owners
• External stakeholders

30/10/2014 Chapter 4 Requirements Engineering 4

 Functional and non-functional
requirements

30/10/2014 Chapter 4 Requirements Engineering 5

 Functional and non-functional
requirements
• Functional requirements
• Statements of services the system should provide, how the system
should react to particular inputs and how the system should behave in
particular situations.
• May state what the system should not do.
• Non-functional requirements
• Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards,
etc.
• Often apply to the system as a whole rather than individual
features or services.
• Domain requirements
• Constraints on the system from the domain of operation
30/10/2014 Chapter 4 Requirements Engineering 6
Functional requirements
• Describe functionality or system services.
• Depend on the type of software, expected users and the 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 the system services
in detail.

30/10/2014 Chapter 4 Requirements Engineering 7

Requirements imprecision
• Problems arise when functional requirements are not precisely
stated.
• Ambiguous requirements may be interpreted in different ways by
developers and users.
• Consider the term ‘search’ in requirement 1
• User intention – search for a patient name across all appointments in all
clinics;
• Developer interpretation – search for a patient name in an individual clinic.
User chooses clinic then search.

30/10/2014 Chapter 4 Requirements Engineering 8

Requirements completeness and
consistency
• In principle, requirements should be both complete and consistent.
• 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.

30/10/2014 Chapter 4 Requirements Engineering 9

Non-functional requirements
• These define system properties and constraints e.g. reliability,
response time and storage requirements. Constraints are I/O device
capability, system representations, etc.
• 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.

30/10/2014 Chapter 4 Requirements Engineering 10

Non-functional requirements
implementation
• Non-functional requirements may affect the overall architecture of a
system rather than the individual components.
• For example, to ensure that performance requirements are met, you may
have to organize the system to minimize communications between
components.
• A single non-functional requirement, such as a security requirement,
may generate a number of related functional requirements that
define system services that are required.
• It may also generate requirements that restrict existing requirements.

30/10/2014 Chapter 4 Requirements Engineering 11

Non-functional classifications
• Product requirements
• Requirements which specify that the delivered product must behave in a particular way e.g.
execution speed, reliability, etc.
• Organisational requirements
• Requirements which are a consequence of organisational policies and procedures e.g.
process standards used, implementation requirements, etc.
• External requirements
• Requirements which arise from factors which are external to the system and its development
process e.g. interoperability requirements, legislative requirements, etc.

30/10/2014 Chapter 4 Requirements Engineering 12

Goals and requirements
• Non-functional requirements may be very difficult to state precisely and
imprecise requirements may be difficult to verify.
• Goal
• A general intention of the user such as ease of use.
• Verifiable non-functional requirement
• A statement using some measure that can be objectively tested.
• Goals are helpful to developers as they convey the intentions of the system users.

30/10/2014 Chapter 4 Requirements Engineering 13

Usability requirements
• The system should be easy to use by medical staff and should be
organized in such a way that user errors are minimized. (Goal)
• Medical staff shall be able to use all the system functions after four
hours of training. After this training, the average number of errors
made by experienced users shall not exceed two per hour of system
use. (Testable non-functional requirement)

30/10/2014 Chapter 4 Requirements Engineering 14

Metrics for specifying nonfunctional
requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
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

30/10/2014 Chapter 4 Requirements Engineering 15

 Requirements engineering processes

30/10/2014 Chapter 4 Requirements Engineering 16

Requirements engineering processes
• The processes used for RE vary widely depending on the application domain,
the people involved and the organisation developing the requirements.
• However, there are a number of generic activities common to all processes
A. Feasibility Study
B. Requirements elicitation
C. Requirements analysis
D. Requirements validation
E. Requirements management.
• In practice, RE is an iterative activity in which these processes are
interleaved.

30/10/2014 Chapter 4 Requirements Engineering 17

A. Feasibility Study

• A feasibility Study in Software Engineering is a study to evaluate the

feasibility of a proposed project or system.
• A feasibility study is one of stage among important stages of the
Software Project Management Process.
• It is a measure of the software product in terms of how beneficial
product development will be for the organization from a practical
point of view.
• A feasibility study is carried out based on many purposes to analyze
whether the software product will be right in terms of development,
implantation, the contribution of the project to the organization etc.
A. Feasibility Study

1.Technical Feasibility
• Current resources hardware or software
• Technical skills and capabilities
2.Economic Feasibility
• Cost incurred on software development
• Cost of hardware ,software, development team, and training.
3. Operational Feasibility
Depends on human resource and whether software will operate after it
is developed.
B. Requirement Elicitation
• Requirements are Discovered , Articulated and Revealed from stake
holders
• It is perhaps the most difficult, most error-prone and most
communication intensive aspect of software development.
• It can be successful only through an effective customer-developer
partnership.
• It is needed to know what the users really need.
Requirements elicitation Activities:
1. Knowledge of the overall area where the systems is applied.
2. The details of the precise customer problem where the system are
going to be applied must be understood.
3. Interaction of system with external requirements.
4. Detailed investigation of user needs.
5. Define the constraints for system development.
Requirements elicitation Methods:
1. Interviews
2. Brainstorming Sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
The success of an elicitation technique used depends on the maturity
of the analyst, developers, users, and the customer involved.
1. Interviews:
• Objective of conducting an interview is to understand the customer’s
expectations from the software.
• It is impossible to interview every stakeholder hence representatives
from groups are selected based on their expertise and credibility.
• Interviews maybe be open-ended or structured.
• In open-ended interviews there is no pre-set agenda.
• Context free questions may be asked to understand the problem.
• In structured interview, agenda of fairly open questions is prepared.
Sometimes a proper questionnaire is designed for the interview.
2. Brainstorming Sessions:

• It is a group technique used to understand the requirement.

• It promotes creative thinking, generates new ideas and provide
platform to share views and difficulties of implementations.
• A highly trained facilitator is required to handle group bias and group
conflicts.
• Every idea is documented so that everyone can see it.
• Finally, a document is prepared which consists of the list of
requirements and their priority if possible.
3. Facilitated Application Specification
Technique(FAST):
• It’s objective is to bridge the expectation gap – difference between what the developers
think they are supposed to build and what customers think they are going to get.
• A team-oriented approach is developed for requirements gathering.
Each attendee is asked to make a list of objects ,functions and constraints.
• List of object consist of objects used in the system, object that are produced by system and
the object that surround the system.
• List of service consist of all the required functionalities that manipulate or interact with the
object.
• List of constraint consist of all the constraint of the system such as cost, rules, memory
requirements, speed, accuracy etc.
• Each participant prepares his/her list, different lists are then combined, redundant entries
are eliminated, team is divided into smaller sub-teams to develop mini-specifications and
finally a draft of specifications is written down using all the inputs from the meeting.
4. Quality Function Deployment
In this technique customer satisfaction is of prime concern, hence it emphasizes on the requirements
which are valuable to the customer.
Three types of requirements are identified –
1. Normal requirements
In this the objective and goals of the proposed software are discussed with the customer.
Example – normal requirements for a result management system may be entry of marks, calculation
of results, etc
2. Expected requirements
These requirements are so obvious that the customer need not explicitly state them.
Example – protection from unauthorized access.
3. Exciting requirements
It includes features that are beyond customer’s expectations and prove to be very satisfying when
present.
Example – when unauthorized access is detected, it should backup and shutdown all processes.
 5. Use Case Approach:
• This technique combines text and pictures to provide a better understanding
of the requirements.
• The use cases describe the ‘what’, of a system and not ‘how’. Hence, they
only give a functional view of the system.
The components of the use case design includes three major things – Actor,
Use cases, use case diagram.
1. Actor
It is the external agent that lies outside the system but interacts with it in some
way. An actor maybe a person, machine etc. It is represented as a stick figure.
Actors can be primary actors or secondary actors.
• Primary actors – It requires assistance from the system to achieve a goal.
• Secondary actor – It is an actor from which the system needs assistance.
 5. Use Case Approach:

2. Use cases –
They describe the sequence of interactions between actors and the system.
They capture who(actors) do what(interaction) with the system. A complete
set of use cases specifies all possible ways to use the system.
3. A use case diagram
Graphically represents what happens when an actor interacts with a system. It
captures the functional aspect of the system.
 A stick figure is used to represent an actor.
 An oval is used to represent a use case.
 A line is used to represent a relationship between an actor and a use case.
Use Case Diagram
C. Requirement analysis
• Requirement analysis is significant and essential activity after
elicitation.
• Analyze, refine, and scrutinize the gathered requirements to make
consistent and unambiguous requirements.
• Provide a graphical view of the entire system.
• After the completion of the analysis, it is expected that the
understandability of the project may improve significantly.
• Here, we may also use the interaction with the customer to clarify
points of confusion and to understand which requirements are more
important than others.
C. Requirement analysis
i) Draw the context diagram:
The context diagram is a simple model that defines the boundaries and interfaces of the proposed
systems with the external world.
It identifies the entities outside the proposed system that interact with the system.
The context diagram of student result management system is given below:
(ii) Development of a Prototype (optional):
• One effective way to find out what the customer wants is to construct
a prototype, something that looks and preferably acts as part of the
system they say they want.
• We can use their feedback to modify the prototype until the customer
is satisfied continuously. Hence, the prototype helps the client to
visualize the proposed system and increase the understanding of the
requirements. When developers and users are not sure about some of
the elements, a prototype may help both the parties to take a final
decision.
(iii) Model the requirements:
• This process usually consists of various graphical representations of
the functions, data entities, external entities, and the relationships
between them.
• The graphical view may help to find incorrect, inconsistent, missing,
and superfluous requirements.
• Such models include the Data Flow diagram, Entity-Relationship
diagram, Data Dictionaries, State-transition diagrams, etc.
(iv) Finalize the requirements:
• After modeling the requirements, we will have a better understanding
of the system behavior.
• The inconsistencies and ambiguities have been identified and
corrected.
• The flow of data amongst various modules has been analyzed.
Elicitation and analyze activities have provided better insight into the
system.
• Now we finalize the analyzed requirements, and the next step is to
document these requirements in a prescribed format.
D. Requirements verification and
validation:
Verification: It refers to the set of tasks that ensures that the software
correctly implements a specific function.

Validation: It refers to a different set of tasks that ensures that the

software that has been built is traceable to customer requirements.

If requirements are not validated, errors in the requirement definitions

would propagate to the successive stages resulting in a lot of
modification and rework.
Conti..
The main steps for this process include:
• The requirements should be consistent with all the other
requirements i.e no two requirements should conflict with each other.
• The requirements should be complete in every sense.
• The requirements should be practically achievable.
Requirements 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?
Requirements validation Techniques:
1. Plan Review
2. Distribute SRS Document
3. Read SRS Document
4. Organize Review meeting
5. Follow-up action
6. Revise SRS Documents
Requirements reviews
• Regular reviews should be held while the requirements definition is
being formulated.
• Both client and contractor staff should be involved in reviews.
• Reviews may be formal (with completed documents) or informal.
Good communications between developers, customers and users can
resolve problems at an early stage.
Review checks
• Verifiability
Is the requirement realistically testable?
• Comprehensibility
Is the requirement properly understood?
• Traceability
Is the origin of the requirement clearly stated?
• Adaptability
Can the requirement be changed without a large impact on other
requirements?
E. Requirements management:
• Requirements management is the process of managing changing
requirements during the requirements engineering process and
system development.
• New requirements emerge as a system is being developed and after it
has gone into use.
• Need to keep track of individual requirements and maintain links
between dependent requirements so that you can assess the impact
of requirements changes.
• Establish a formal process for making change proposals and linking
these to system requirements.
Requirements management planning
• Establishes the level of requirements management detail that is
required.
• Requirements management decisions:
Requirements identification Each requirement must be uniquely identified so
that it can be cross-referenced with other requirements.
A change management process This is the set of activities that assess the
impact and cost of changes..
Traceability policies These policies define the relationships between each
requirement and the system design that should be recorded.
Tool support Tools that may be used range from specialist requirements
management systems to spreadsheets and simple database systems
SRS Document
What is SRS?
• A software requirements specification (SRS) is a description of a software system to
be developed.
• It lays out functional and non-functional requirements and may include a set of use
cases that describe user interactions that the software must provide.
Why SRS?
• In order to fully understand one’s project, it is very important that they come up with
an SRS listing out their requirements, how are they going to meet them and how will
they complete the project.
• It helps the team to save upon their time as they are able to comprehend how are
going to go about the project.
• Doing this also enables the team to find out about the limitations and risks early on.
Quality Characteristics of a good SRS

• Correctness:
User review is used to ensure the correctness of requirements stated in the SRS.
SRS is said to be correct if it covers all the requirements that are actually expected
from the system.
• Completeness:
Completeness of SRS indicates every sense of completion including the numbering
of all the pages, resolving the to be determined parts to as much extent as possible
as well as covering all the functional and non-functional requirements properly.
• Consistency:
Requirements in SRS are said to be consistent if there are no conflicts between any
set of requirements. Examples of conflict include differences in terminologies used
at separate places, logical conflicts like time period of report generation, etc.
Quality Characteristics of a good SRS

• Unambiguousness:
A SRS is said to be unambiguous if all the requirements stated have only 1
interpretation. Some of the ways to prevent unambiguousness include the use of
modelling techniques like ER diagrams, proper reviews and buddy checks, etc.
• Ranking for importance and stability:
There should a criterion to classify the requirements as less or more important
or more specifically as desirable or essential. An identifier mark can be used with
every requirement to indicate its rank or stability.
• Modifiability:
SRS should be made as modifiable as possible and should be capable of easily
accepting changes to the system to some extent. Modifications should be
properly indexed and cross-referenced.
Quality Characteristics of a good SRS

• Verifiability:
An SRS is verifiable if there exists a specific technique to quantifiably measure the
extent to which every requirement is met by the system. For example, a
requirement starting that the system must be user-friendly is not verifiable and
listing such requirements should be avoided.
• Traceability:
One should be able to trace a requirement to design component and then to code
segment in the program. Similarly, one should be able to trace a requirement to the
corresponding test cases.
• Design Independence:
There should be an option to choose from multiple design alternatives for the final
system. More specifically, the SRS should not include any implementation details.