UNIT –III

Syllabus:
Software requirement analysis and specification
Value of good SRS, requirement process, Requirement specification, functional specification with use
cases.

Learning Material

Software Requirement Analysis

 IEEE defines a requirement as
 A condition of capability needed by a user to solve a problem or achieve an
objective.
 A condition or a capability that must be met or possessed by a system ... to
satisfy a contract, standard, specification, or other formally imposed
document.
 A software requirement deals with the requirements of the proposed system.
 The goal of the requirements activity is to produce the Software Requirements
Specification (SRS) that describes what the proposed software should do without
describing how the software will do it.
 The basic limitation of SRS is that user needs keep changing as the environment in
which the system is to functions changes with time.

I. Value of a Good SRS (Need for SRS)

 Software system consists of three major parties: the client, the developer, and the
users.
 The problem is that the client usually does not understand software or the software
development process, and the developer often does not understand the client’s
problem and application area.
 This causes a communication gap between the parties involved in the development
project.
 A basic purpose of the SRS is to bridge this communication gap.

Advantages of SRS
 An SRS establishes the basis for agreement between the client and the supplier on
what the software product will do.
 This basis for agreement is frequently formalized into a legal contract between the
client (or the customer) and the developer (the supplier).
  So, through SRS, the client clearly describes what it expects from the supplier, and
the developer clearly understands what capabilities to build in the software.
 An SRS provides a reference for validation of the final product.
 The SRS helps the client determine if the software meets the requirements.
 Without a proper SRS, there is no way a client can determine if the software being
delivered is what was ordered, and there is no way the developer can convince the
client that all the requirements have been fulfilled.
 Providing the basis of agreement and validation should be strong enough reasons for
both the client and the developer to do a thorough and rigorous job of requirement
understanding and specification.
 If we want a high-quality end product that has few errors, we must begin with a high-
quality SRS.
 A high-quality SRS is a prerequisite to high-quality software.
 Finally, the quality of SRS has an impact on cost (and schedule) of the project.
 We know that errors can exist in the SRS. It is also known that the cost of fixing an
error increases almost exponentially as time progresses.
 Hence, by improving the quality of requirements, we can have a huge savings in the
future by having fewer expensive defect removals.
 A high-quality SRS reduces the development cost.
 The quality of the SRS impacts Customer satisfaction , system validation, Quality of
the final software and the software development cost.

Requirement Process
 The requirement process is the sequence of activities that need to be performed in the
requirements phase and that culminate in producing a high-quality document
containing the SRS.
 The requirements process typically consists of three basic tasks:
1. Problem or Requirement Analysis
2. Requirements Specification
3. Requirements Validation.

 Problem analysis often starts with a high-level “problem statement.”

 During Problem Analysis, they have to concentrate to understand system behavior,
constraints on the system, its inputs and outputs, etc.
 The analyst will have a series of meetings with the clients and end users.
 The early meetings, the clients and end users will explain to the analyst about their
work, their environment, and their needs as they perceive them.
 Once the analyst understands the system to some extent, he uses the next few
meetings to seek clarifications of the parts he does not understand.
 In the final few meetings, the analyst essentially explains to the client what he
understands the system should do.
  And uses the meetings as a means of verifying if what he proposes the system should
do is indeed consistent with the objectives of the clients.
 The understanding obtained by problem analysis forms the basis of requirements
specification, in which the focus is on clearly specifying the requirements in a
document.
 Issues such as representation, specification languages, and tools are addressed during
this activity.
 Requirements validation focuses on ensuring that what have been specified in the SRS
are indeed all the requirements of the software and making sure that the SRS is of
good quality.

FIG: Requirement Process

 It is not a linear sequence of activities, from the specification activity we may go back
to the analysis activity.
 The process of specification frequently shows shortcomings in the knowledge of the
problem, thereby necessitating further analysis.
 Once the specification is done, it goes through the validation activity.
 This activity may reveal problems in the specification itself, which requires going
back to the specification step, or may reveal shortcomings in the understanding of the
which requires going back to the analysis activity.

Requirements Specification
 The transition from analysis to specification should also not be expected to be
straightforward, even if some formal modeling is used during analysis.
 A good SRS needs to specify many things, some of which are not satisfactorily
handled during analysis.
 Essentially, what passes from requirements analysis activity to the specification
activity is the knowledge acquired about the system.
 The modeling is essentially a tool to help obtain a thorough and complete knowledge
about the proposed system.
 The SRS is written based on the knowledge acquired during analysis.
  As converting knowledge into a structured document is not straightforward,
specification itself is a major task, which is relatively independent.

Characteristics of an SRS
 An SRS should have certain properties and should contain different types of
requirements.
 These are:
1. Correct
2. Complete
3. Unambiguous
4. Verifiable
5. Consistent
6. Ranked for importance and/or stability
7. Modifiable
8. Traceable

1. Correct:
 An SRS is correct if every requirement included in the SRS represents
something required in the final system.
2. Complete:
 It is complete if everything the software is supposed to do and the responses of
the software to all classes of input data are specified in the SRS.
3. Unambiguous:
 It is unambiguous if and only if every requirement stated has one and only one
interpretation.
 Requirements are often written in natural language, which is inherently
ambiguous.

4. Verifiable:
 only if every stated requirement is verifiable.
 A requirement is verifiable if there exists some cost-effective process that can
check whether the final software meets that requirement.
5. Consistent:
 If there is no requirement that conflicts with another.
 There may be logical or temporal conflict between requirements that causes
inconsistencies.
 This occurs if the SRS contains two or more requirements whose logical or
temporal characteristics cannot be satisfied together by any software system.
6. Ranked for importance and/or stability :
 An SRS is ranked for importance and/or stability if for each requirement the
importance and the stability of the requirement are indicated.
 Stability of a requirement reflects the chances of it changing in the future.
  It can be reflected in terms of the expected change volume.

7. Modifiable
 An SRS is modifiable if its structure and style are such that any necessary
change can be made easily while preserving completeness and consistency.
 Presence of redundancy is a major reason to modifiability, as it can easily lead
to errors.
 For example, assume that a requirement is stated in two places and that the
requirement is later needs to be changed.
 If only one occurrence of the requirement is modified, the resulting SRS will
be inconsistent.
8. Traceable
 An SRS is Traceable if the origin of each of its requirements is clear and if it
facilitates the referencing of each requirement in future development.
 Forward traceability means that each requirement should be traceable to some
design and code elements.
 Backward traceability requires that it be possible to trace design and code
elements to the requirements they support.
 Traceability aids verification and validation.

Components of an SRS
 Completeness of specifications is difficult to achieve and even more difficult toverify.
 The basic issues an SRS must address are:
 Functionality
 Performance
 Design constraints imposed on an implementation
 External interfaces

 Functional requirements specify the expected behavior of the system—which

outputs should be produced from the given inputs.
 They describe the relationship between the input and output of the system.
 For each functional requirement, a detailed description of all the data inputs and their
source, the units of measure, and the range of valid inputs must be specified.
 Functions should include descriptions of the validity checks on the input and output
data, parameters affected by the operation and formulas, and other operations that
must be used to transform the inputs into corresponding outputs.
 Performance requirements part of an SRS specifies the performance constraints on
the software system.
 All the requirements relating to the performance characteristics of the system must be
clearly specified.
 There are two types of performance requirements: static and dynamic.
 Static requirements include number of users, number of terminals are supported and
number of process will system be handle.
 It does not concentrate on the execution characteristics of a system. It is also called
Capacity requirements.
 Dynamic requirements specify constraints on the execution behavior of the system.
 These typically include response time and throughput constraints on the system.
 Response time is the expected time for the completion of an operation under specified
circumstances.
 Throughput is the expected number of operations that can be performed in a unit time.
 There are a number of factors in the client’s environment that may restrict the choices
of a designer leading to design constraints.
 Such factors include standards that must be followed, resource limits, operating
environment, reliability and security requirements, and policies that may have an
impact on the design of the system.
 An SRS should identify and specify all such constraints.
 Some Examples of these are:
 Standards Compliance:
 This specifies the requirements for the standards the system must
follow.
 It includes report formats and logging operations.
 Hardware Limitations:
 The software may have to operate on some existing or predetermined
hardware, thus imposing restrictions on the design.
 It includes the type of machines to be used, operating system available
on the system, languages supported, and limits on primary and
secondary storage.
 Reliability and Fault Tolerance:
 Fault tolerance requirements can place.
 A major constraint on how the system is to be designed, as they make
the system more complex and expensive.
 Recovery requirements are often an integral part here, detailing what
the system should do if some failure occurs to ensure certain
properties.
 Security:
 These requirements place restrictions on the use of certain commands,
control access to data, provide different kinds of access requirements
for different people, require the use of passwords and cryptography
techniques, and maintain a log of activities in the system.
 They may also require proper assessment of security threats, proper
programming techniques, and use of tools to detect flaws like buffer
overflow.
 In the external interface specification part, all the interactions of the software
 With people, hardware, and other software should be clearly specified.
  User interface is becoming increasingly important and must be given proper attention.
 A preliminary user manual should be created with all user commands, screen formats,
an explanation of how the system will appear to the user, and feedback and error
messages.
 So, a statement like “the system should be user friendly” should be avoided and
statements like “commands should be no longer than six characters” or “command
names should reflect the function they perform” used.
 For hardware interface requirements, the SRS should specify the logical
characteristics of each interface between the software product and the hardware
components.
 If the software is to execute on existing hardware or on predetermined hardware, all
the characteristics of the hardware, including memory restrictions, should be
specified.

Structure of a Requirements Document

 Requirements have to be specified using some specification language.
 When formal languages are employed, they are often used to specify particular
properties or for specific parts of the system, as part of the overall SRS.
 All the requirements for a system, stated using a formal notation or natural language,
have to be included in a document that is clear and concise.
 The IEEE standards recognize the fact that different projects may require their
requirements to be organized differently, that is, there is no one method that is
suitable for all projects.
 It provides different ways of structuring the SRS.
 The first two sections of the SRS are the same in all of them.
 The introduction section contains the purpose, scope, overview, etc., of the
requirements document.
 The key aspect here is to clarify the motivation and business objectives that are
driving this project, and the scope of the project.
 The next section gives an overall perspective of the system—how it fits into the larger
system, and an overview of all the requirements of this system.
 A general abstract description of the functions to be performed by the product is
given.
 Schematic diagrams showing a general view of different functions and their
relationships with each other can often be useful.
 FIG: General Structure of SRS
 The detailed requirements section describes the details of the requirements that a
developer needs to know for designing and developing the system.
 These requirements can be organized by the modes of operation, user class, object,
feature, stimulus, or functional hierarchy.
 One method to organize the specific requirements is to first specify the external
interfaces, followed by functional requirements, performance requirements, design
constraints, and system attributes.
 The external interface requirements section specifies all the interfaces of the software:
to people, other software, hardware, and other systems.
 User interfaces can specify each human interface the system plans to have, including
screen formats, contents of menus, and command structure.
 In hardware interfaces, the logical characteristics of each interface between the
software and hardware on which the software can run are specified.
 In the functional requirements section, the functional capabilities of the system are
described.
 For each functional requirement, the required inputs, desired outputs, and processing
requirements will have to be specified.
 The performance section should specify both static and dynamic performance
requirements.
 Any requirement not covered under these is listed under other requirements.
 Design constraints specify all the constraints imposed on design (e.g., security, fault
tolerance, and standards compliance).
 FIG: SRS of an Organization

Functional Specification with Use Cases

 Functional requirements often form the core of a requirements document.
 The traditional approach for specifying functionality is to specify each function that
the system should provide.
 Use cases specify the functionality of a system by specifying the behavior of the
system, captured as interactions of the users with the system.
 Use cases can be used to describe the business processes of the larger business or
organization that deploys the software or it could just describe the behavior of the
software system.
 Use cases are primarily for specifying behavior, they can also be used effectively for
analysis.
 Use cases drew attention after they were used as part of the object-oriented modeling
approach proposed by Jacobson.
 Due to this connection with an object-oriented approach, use cases are sometimes
viewed as part of an object-oriented approach to software development

Basics
 A software system may be used by many users, or by other systems.
 In use case terminology,
 An actor is a person or a system which uses the system for achieving some
goal.
 An actor interacts for achieving some goal, it is a logical entity that represents
a group of users who behave in a similar manner.
  Different actors represent groups with different goals.
 So, it is better to have a “receiver” and a “sender” actor rather than having a
generic “user” actor for a system in which some messages are sent by users
and received by some other users.

FIG: USE CASE Terms

 For example, a use case “Withdraw money from the ATM”
 A customer as its primary actor.
 And will normally describe the entire interaction of the customer with the
ATM.
 However, the bank is also a stakeholder of the ATM system.
 And its goals may include that all steps are logged, money is given only if
there are sufficient funds in the account, and no more than some amount is
given at a time, etc.
 Satisfaction of these goals should also be shown by the use case “Withdraw
money from the ATM.”
 Examples :
 In this system, though we have the same people who might be buying and
selling, we have “buyers” and “sellers” as separate logical actors, as both have
different goals to achieve.
 The name of the use case specifies the goal of the primary actor.
 The primary actor can be a person or a system—for UC1 and UC2, they are
persons but for UC3, it is a system.
 The precondition of a use case specifies what the system will ensure before
allowing the use case to be initiated.
 FIG: Main use cases in an auction system
 Common preconditions are “user is logged in,” “input data exists in files or other data
structures,” etc.
 For an operation like delete it may be that “item exists,” or for a tracking use case it
may be that the “tracking number is valid.”
 For example, the last step in UC2 is to update the bid price of other bidders.
 This action is clearly not needed by the current bidder for his goal.
 Similar is the case with the last item of UC1.
 A use case can employ other use cases to perform some of its work.
 For example, in UC2 actions like “block the necessary funds” or “debit bidder’s
account and credit seller’s” are actions that need to be performed for the use case to
succeed.
  The exception situations are also fairly clear.
 We have listed only the most obvious ones.
 There can be many more, depending on the goals of the organization
 For example, there could be one “user does not complete the transaction, which is a
failure condition that can occur anywhere. What should be done in this case has to
then be specified (e.g., all the records are cleaned).

Extensions
 Besides specifying the primary actor, its goal, and the success and exceptional
scenarios, a use case can also specify a scope.
 If the system being built has many subsystems,sometimes system use cases may
actually be capturing the behavior of some subsystem
 In such a situation it is better to specify the scope of that use case as the subsystem.
 For example, a use case for a system may be log in.
 Even though this is a part of the system, the interaction of the user with the
system described in this use case is limited to the interaction with the “login
and authentication” subsystem
 If “login and authentication” has been identified as a subsystem or a
component, then it is better to specify it as the scope.
 UCs where the scope is the enterprise can often run over a long period of time
(e.g., process an application of a prospective candidate).
 These use cases may require many different systems to perform different tasks
before the UC can be completed.

Developing Use Cases

 UCs not only document requirements, as their form is like storytelling and uses text,
both of which are easy and natural with different stakeholders, they also are a good
medium for discussion and brainstorming.
 Hence, UCs can also be used for requirements elicitation and problem analysis.
 UCs can be evolved in a stepwise refinement manner with each step adding more
details.
 This approach allows UCs to be presented at different levels of abstraction.
 Though any number of levels of abstraction are possible, four natural levels emerge:

Actors and goals

 The actor-goal list enumerates the use cases and specifies the actors for each goal.
 It may be extended by giving a brief description of each of the use cases.
 At this level, the use cases together specify the scope of the system and give an
overall view of what it does.
Main success scenarios
 For each of the use cases, the main success scenarios are provided at this level.
 With the main scenarios, the system behavior for each use case is specified.
 This description can be reviewed to ensure that interests of all the stakeholders are
met and that the use case is delivering the desired behavior.

Failure conditions
 Once the success scenario is listed, all the possible failure conditions can be
identified.
 At this level, for each step in the main success scenario, the different ways in which a
step can fail form the failure conditions.
 Before deciding what should be done in these failure conditions, it is better to
enumerate the failure conditions and review for completeness.

Failure handling
 Often the focus is so much on the main functionality that people do not pay attention
to how failures should be handled.
 Determining what should be the behavior under different failure conditions will often
identify new business rules or new actors.

 And overall functionality or capabilities of the system, actors and goal-level
description is very useful.
 Failure conditions, on the other hand, are very useful for understanding and extracting
detailed requirements and business rules under special cases.
 These four levels can also guide the analysis activity.
 A step-by-step approach for analysis when employing use cases is:
 Step 1:
 Identify the actors and their goals and get an agreement with the
concerned stakeholders as to the goals.
 The actor-goal list will clearly define the scope of the system and will
provide an overall view of what the system capabilities are.
 Step 2:
 Understand and specify the main success scenario for each UC, giving
more details about the main functions of the system.
 Interaction and discussion are the primary means to uncover these
scenarios though modelsmay be built, if required.
 During this step, the analyst may uncover that to complete some use
case some other use cases are needed, which have not been identified.
 In this case, the list of use cases will be expanded.
  Step 3:
 When the main success scenario for a use case is agreed upon and the
main steps in its execution are specified, then the failure conditions can
be examined.
 Enumerating failure conditions is an excellent method of uncovering
special situations that can occur and which must be handled by the
system.
 Step 4:
 Finally, specify what should be done for these failure conditions.
 As details of handling failure scenarios can require a lot of effort and
discussion, it is better to first enumerate the different failure conditions
and then get the details of these scenarios.
 At any step an analyst may have to go back to earlier steps as during some detailed
analysis new actors may emerge or new goals and new use cases may be uncovered.
 For writing use cases, general technical writing rules apply.
 Use simple grammar, clearly specify who is performing the step, and keep the overall
scenario as simple as possible.
 Also, when writing steps, for simplicity, it is better to combine some steps into one
logical step, if it makes sense.
 For example, steps “user enters his name,” “user enters his SSN,” and “user enters his
address” can be easily combined into one step “user enters personal information.”
 Assignment-Cum-Tutorial Questions

A. Questions testing the remembering / understanding level of students

I) Objective Questions

1) What is the final outcome of requirements analysis and specification phase?

[ ]
a) Drawing the data flow diagram b) The SRS document
c) Coding the project d) The user manual
2) Which of the following is not included in SRS document? [ ]
a) Functional requirements b) Non functional requirements
c) Goals of implementation d) User manual
3) Which of the following expects cost estimation from SRS document? [ ]
a) Project manager b) User documentation writer
c) Software developers d) Maintenance engineers

II) Descriptive Questions

1) Explain briefly the value of good SRS and the Requirements Engineering Process.
2) Give the Structure of Software Requirements Document.
3) Describe the Functional Specification Technique with use cases.
4) What is SRS? Discuss the characteristics of SRS.

Previous GATE. Questions:

1) Which one of the following is NOT desired in a good Software Requirement

Specifications (SRS) document? (GATE 2011)
a) Functional Requirements
b) Non-Functional Requirements
c) Goals of Implementation
d) Algorithms for software implementation

2) A Software Requirements Specification (SRS) document should avoid discussing

which one of the following? (GATE 2015)
a) User interface issues
b) Non-functional requirements
c) Design specification
d) Interfaces with third party software