Unit 2 : Software Engineering

UNIT 2

Contents:
Requirements Analysis and Specification: Requirements Gathering and Analysis, Software
Requirement Specification (SRS): Characteristics of good SRS, Functional Requirements,
Organization of SRS.

Requirements Analysis and Specification

● All plan-driven life cycle models prescribe that before starting to develop a software, the
exact requirements of the customer must be understood and documented.
● Starting development work without properly understanding and documenting the
requirements increases the number of iterative changes in the later life cycle phases, and
thereby alarmingly pushes up the development costs.
● A good requirements document not only helps to form a clear understanding of various
features required from the software, but also serves as the basis for various activities carried
out during later life cycle phases.

Overview of requirements analysis and specification:

● The requirements analysis and specification phase starts after the feasibility study stage is
complete and the project has been found to be financially viable and technically feasible.
● The requirements analysis and specification phase ends when the requirements specification
document has been developed and reviewed.
● The requirements specification document is usually called the software requirements
specification (SRS) document.
● The goal of the requirements analysis and specification phase is to clearly understand the
customer requirements and to systematically organize the requirements into a document
called the Software Requirements Specification (SRS) document.

Who performs requirements analysis

● Requirements analysis and specification activity is usually carried out by a few experienced
members of the development team.
● It normally requires them to spend some time at the customer site.
● The engineers who gather and analyze customer requirements and then write the
requirements specification document are known as system analysts.

Requirements analysis and specification phase mainly involves carrying out the following two
important activities:
● Requirements gathering and analysis.
● Requirements specification.
Unit 2 : Software Engineering

Requirements gathering and analysis:

● The complete set of requirements are almost never available in the form of a single
document from the customer.
● Complete requirements are rarely obtainable from any single customer representative.
● We can conceptually divide the requirements gathering and analysis activity into two
separate tasks: Requirements gathering and Requirements Analysis

Requirements gathering.
● Requirements gathering is also popularly known as requirements elicitation.
● The primary objective of the requirements gathering task is to collect the requirements
from the stakeholders.
● A stakeholder is a source of the requirements and is usually a person, or a group of persons
who either directly or indirectly are concerned with the software.
● It is very difficult to gather all the necessary information from a large number of
stakeholders and from information scattered across several pieces of documents.
● Gathering requirements turns out to be especially challenging if there is no working model
of the software being developed.
● Important ways in which an experienced analyst gathers requirements:
● Studying existing documentation:
○ The analyst usually studies all the available documents regarding the system to be
developed before visiting the customer site.
○ Customers usually provide a statement of purpose (SoP) document to the
developers.
● Interview:
○ Typically, there are many different categories of users of a software.
○ Each category of users typically requires a different set of features from the
software.
○ Therefore, it is important for the analyst to first identify the different categories of
users and then determine the requirements of each.
Refer to: Delphi method
● Task analysis:
○ The users usually have a black-box view of a software and consider the software
as something that provides a set of services (functionalities).
○ A service supported by software is also called a task.
○ The analyst tries to identify and understand the different tasks to be performed by
the software.
○ For each identified task, the analyst tries to formulate the different steps
necessary to realize the required functionality in consultation with the users.
● Scenario analysis:
○ A task can have many scenarios of operation.
○ The different scenarios of a task may take place when the task is invoked under
different situations.
Unit 2 : Software Engineering

○ For different types of scenarios of a task, the behavior of the software can be
different.
● Form analysis:
○ Form analysis is an important and effective requirements gathering activity that is
undertaken by the analyst, when the project involves automating an existing
manual system.
○ In form analysis the existing forms and the formats of the notifications produced
are analyzed to determine the data input to the system and the data that are output
from the system.

Requirements analysis:
● After requirements gathering is complete, the analyst analyses the gathered requirements to
form a clear understanding of the exact customer requirements and to weed out any
problems in the gathered requirements.
● During requirements analysis, the analyst needs to identify and resolve three main types of
problems in the requirements:
○ Anomaly:
■ An anomaly is an ambiguity in a requirement. When a requirement is anomalous,
several interpretations of that requirement are possible.
■ Example: While gathering the requirements for a process control application, the
following requirement was expressed by a certain stakeholder: “When the
temperature becomes high, the heater should be switched off”. Please note that
words such as “high”, “low”, “good”, “bad” etc. are indications of ambiguous
requirements as these lack quantification and can be subjectively interpreted.
○ Inconsistency:
■ Two requirements are said to be inconsistent, if one of the requirements contradicts
the other.
■ Example: Consider the following two requirements that were collected from two
different stakeholders in a process control application development project.
● The furnace should be switched-off when the temperature of the furnace rises
above 500℃.
● When the temperature of the furnace rises above 500℃, the water shower
should be switched-on and the furnace should remain on.
○ Incompleteness:
■ An incomplete set of requirements is one in which some requirements have been
overlooked. The lack of these features would be felt by the customer much later,
possibly while using the software.
■ Example: In a chemical plant automation software, suppose one of the
requirements is that if the internal temperature of the reactor exceeds 200 ℃ then
an alarm bell must be sounded. However, on an examination of all requirements, it
was found that there is no provision for resetting the alarm bell after the
temperature has been brought down in any of the requirements. This is clearly an
incomplete requirement.
Unit 2 : Software Engineering

Software Requirements Specification (SRS):

● After the analyst has gathered all the required information regarding the software to be
developed, and has removed all incompleteness, inconsistencies, and anomalies from the
specification, he starts to systematically organize the requirements in the form of an SRS
document.
● The SRS document usually contains all the user requirements in a structured though an
informal form.SRS document is probably the most important document and is the toughest
to write.
● One reason for this difficulty is that the SRS document is expected to cater to the needs of a
wide variety of audience.
● A well-formulated SRS document finds a variety of usage:
○ Forms an agreement between the customers and the developers.
○ Reduces future reworks.
○ Provides a basis for estimating costs and schedules
○ Provides a baseline for validation and verification
○ Facilitates future extensions

Users of SRS document:

● Users, customers, and marketing personnel:
These stakeholders need to refer to the SRS document to ensure that the system as
described in the document will meet their needs.
● Software developers:
The software developers refer to the SRS document to make sure that they are developing
exactly what is required by the customer.
● Test engineers:
The test engineers use the SRS document to understand the functionalities, and based on
this write the test cases to validate its working.
● User documentation writers:
The user documentation writers need to read the SRS document to ensure that they
understand the features of the product well enough to be able to write the users’ manuals.
● Project managers:
The project managers refer to the SRS document to ensure that they can estimate the cost
of the project easily by referring to the SRS document and that it contains all the
information required to plan the project.
● Maintenance engineers:
The SRS document helps the maintenance engineers to under- stand the functionalities
supported by the system.

Characteristics of a Good SRS Document:

● IEEE Recommended Practice for Software Requirements Specifications describes the
content and qualities of a good software requirements specification (SRS).
● Some of the identified desirable qualities of an SRS document are the following:
○ Concise: The SRS document should be concise and at the same time unambiguous,
consistent, and complete.
Unit 2 : Software Engineering

○ Implementation-independent:
The SRS should be free of design and implementation decisions unless those
decisions reflect actual requirements. It should only specify what the system
should do and refrain from stating how to do these.
○ Traceable:
It should be possible to trace a specific requirement to the design elements that
implement it and vice versa. Similarly, it should be possible to trace a
requirement to the code segments that implement it and the test cases that test this
requirement and vice versa.
○ Modifiable:
Customers frequently change the requirements during the software development
due to a variety of reasons. Therefore, in practice the SRS document undergoes
several revisions during software development. To cope up with the requirements
changes, the SRS document should be easily modifiable. For this, an SRS
document should be well-structured.
○ Identification of response to undesired events:
The SRS document should discuss the system responses to various undesired
events and exceptional conditions that may arise.
○ Verifiable:
All requirements of the system as documented in the SRS document should be
verifiable. This means that it should be possible to design test cases based on the
description of the functionality as to whether or not requirements have been met
in an implementation.

Categories of Customer requirements:

An SRS document should clearly document the following aspects of a software:
● Functional requirements
● Non-functional requirements
○ Design and implementation constraints
○ External interfaces required
○ Other non-functional requirements
● Goals of implementation.

Functional Requirements:
● The functional requirements capture the functionalities required by the users from the
system.
● Consider a software as offering a set of functions {fi} to the user.
● These functions can be considered similar to a mathematical function f : I → O, meaning
that a function transforms an element (ii) in the input domain (I) to a value (oi) in the output
(O).
● In order to document the functional requirements of a system, it is necessary to first learn to
identify the high-level functions of the systems by reading the informal documentation of
the gathered requirements.
● Each high-level function is an instance of use of the system (use case) by the user in some
way.
Unit 2 : Software Engineering

● A high-level function is one using which the user can get some useful piece of work done.
● Each high-level requirement typically involves accepting some data from the user through a
user interface, transforming it to the required response, and then displaying the system
response in proper format.
● A high-level function transforms certain input data to output data.
● Except for very simple high- level functions, a function rarely reads all its required data in
one go and rarely outputs all the results in one shot.
● A high-level function usually involves a series of interactions between the system and one
or more users.
● Functional requirements form the basis for most design and test methodologies.
● Unless the functional requirements are properly identified and documented, the design and
testing activities cannot be carried out satisfactorily.
● Once all the high-level functional requirements have been identified and the requirements
problems have been eliminated, these are documented.
● A function can be documented by identifying the state at which the data is to be input to the
system, its input data domain, the output data domain, and the type of processing to be
carried on the input data to obtain the output data.
● Refer to Withdraw cash from ATM example in text book.

Non-functional Requirements:
● The non-functional requirements are non-negotiable obligations that must be supported by
the software.
● The non-functional requirements capture those requirements of the customer that cannot be
expressed as functions.
● Aspects concerning external interfaces, user interfaces, maintainability, portability,
usability, maximum number of concurrent users, timing, and throughput.
● The non-functional requirements can be critical in the sense that any failure by the
developed software to achieve some minimum defined level in these requirements can be
considered as a failure and make the software unacceptable by the customer.
● Design and implementation constraints:
○ Design and implementation constraints are an important category of non-functional
requirements describing any items or issues that will limit the options available to the
developers.
○ Some of the example constraints can be—corporate or regulatory policies that need to
be honored; hardware limitations; interfaces with other applications; specific
technologies, tools, and databases to be used; specific communications protocols to be
used; security considerations etc.
● External interfaces required:
○ Examples of external interfaces are - hardware, software and communication
interfaces, user interfaces, report formats, etc.
○ To specify the user interfaces, each interface between the software and the users
must be described.
○ One example of a user interface requirement of a software can be that it should be
usable by factory shop floor workers who may not even have a high school degree
Unit 2 : Software Engineering

● Other non-functional requirements:

○ This section contains a description of non- functional requirements that are neither
design constraints nor are external interface requirements.
○ An important example is a performance requirement such as the number of
transactions completed per unit time.

Goals of implementation:
● The ‘goals of implementation’ part of the SRS document offers some general suggestions
regarding the software to be developed.
● A goal, in contrast to the functional and nonfunctional requirements, is not checked by the
customer for conformance at the time of acceptance testing.
● The goals of the implementation section might document issues such as easier revisions to
the system functionalities that may be required in the future, easier support for new devices
to be supported in the future, reusability issues, etc.

Organization of the SRS Document:

● The organization of an SRS document is prescribed by the IEEE 830 standard.
● IEEE 830 standard has been intended to serve only as a guideline for organizing a
requirements specification document into sections and allows the flexibility of tailoring it.
● Depending on the type of project being handled, some sections can be omitted, introduced,
or interchanged.
● The three basic issues that any SRS document should discuss are—functional requirements,
non-functional requirements, and guidelines for system implementation.
● The introduction section should describe the context in which the system is being
developed, and provide an overall description of the system, and the environmental
characteristics.

Various Sections of SRS:

Introduction
● Purpose: This section should describe where the software would be deployed and how the
software would be used.
● Project scope: This section should briefly describe the overall context within which the
software is being developed.
● Environmental characteristics: This section should briefly outline the environment
(hardware and other software) with which the software will interact.
Overall description of organization of SRS document
● Product perspective: This section needs to briefly state as to whether the software is
intended to be a replacement for a certain existing system, or it is a new software.
● Product features: This section should summarize the major ways in which the software
would be used.
● User classes: Various user classes that are expected to use this software are identified and
described here.
● Operating environment: This section should discuss in some detail the hardware platform
on which the software would run, the operating system, and other application software with
which the developed software would interact.
Unit 2 : Software Engineering

● Design and implementation constraints: In this section, the different constraints on the
design and implementation are discussed.
● User documentation: This section should list out the types of user documentation, such as
user manuals, on-line help, and trouble-shooting manuals that will be delivered to the
customer along with the software.

IEEE format for SRS Document

External interface requirements
● User interfaces: This section should describe a high-level description of various interfaces
and various principles to be followed.
● Hardware interfaces: This section should describe the interface between the software and
the hardware components of the system.
 Unit 2 : Software Engineering

● Software interfaces: This section should describe the connections between this software and
other specific software components, including databases, operating systems, tools, libraries,
and integrated commercial components, etc.
● Communications interfaces: This section should describe the requirements associated with
any type of communications required by the software, such as e-mail, web access, network
server communications protocols, etc.
Other non-functional requirements for organization of SRS document
● Performance requirements: Aspects such as number of transactions to be completed per
second should be specified here.
● Safety requirements: Those requirements that are concerned with possible loss or
damage that could result from the use of the software are specified here.
● Security requirements: This section should specify any requirements regarding security or
privacy requirements on data used or created by the software.

FORMAL SPECIFICATION

A formal software specification is a statement expressed in a language whose vocabulary, syntax,

and semantics are formally defined. The need for a formal semantic definition means that the
specification languages cannot be based on natural language; it must be based on mathematics.

The advantages of a formal language are:

 The development of a formal specification provides insights and understanding of the
software requirements and the software design.
 Given a formal system specification and a complete formal programming language
definition, it may be possible to prove that a program conforms to its specifications.
 Formal specification may be automatically processed. Software tools can be built to assist
with their development, understanding, and debugging.
 Depending on the formal specification language being used, it may be possible to animate a
formal system specification to provide a prototype system.
 Formal specifications are mathematical entities and may be studied and analyzed using
mathematical methods.
 Formal specifications may be used as a guide to the tester of a component in identifying
appropriate test cases.

Formal specifications sometimes are not used because:

 Software management is conservative and unwilling to adopt new techniques whose
payoff is not immediately obvious.
 Most software engineers have not been trained in formal specification techniques.
 Some classes of systems are difficult to specify using existing specification techniques.
Interactive and interrupt driven systems might be examples.

SPECIFICATION PRINCIPLES
Principle 1: Separate functionality from implementation.
A specification is a statement of what is desired, not how it is to be realized. Specifications can take
two general forms. The first form is that of mathematical functions: Given some set of inputs,
produce a particular set of outputs. The general form of such specifications is find [a/the/all]
result such that P(input), where P represents an arbitrary predicate. In such specifications, the
 Unit 2 : Software Engineering

result to be obtained has been entirely expressed in a “what”, rather than a “how” form, mainly
because the result is a mathematical function of the input (the operation has well-defined starting
and stopping points) and is unaffected by any surrounding environment.
Principle 2: A process-oriented systems specification language is sometimes required.
If the environment is dynamic and its changes affect the behavior of some entity interacting with
that environment (as in an embedded computer system), its behavior cannot be expressed as a
mathematical function of its input. Rather a process-oriented description must be employed,
in which the “what” specification is achieved by specifying a model of the desired behavior
in terms of functional responses to various stimuli from the environment.
Principle 3: The specification must provide the implementor all of the information he/she needs
to complete the program, and no more.
In particular, no information about the structure of the calling program should be
conveyed.
Principle 4: The specification should be sufficiently formal that it can conceivably be tested for
consistency, correctness, and other desirable properties.
Principle 5: The specification should discuss the program in terms normally used by the user
and implementor alike.

AXIOMATIC SPECIFICATIONS

Use a set of stateless functions; each function has a set of pre- and post-conditions. Pre- and post-
conditions are predicates over the inputs and outputs of a function. A predicate is a Boolean
expression which is true or false and whose variables are the parameters of the function being
specified.
Stages of axiomatic specification of a function:
1. Establish the range of the input parameters over which the function is intended to behave
correctly. Specify the input parameter constraints as a predicate.
2. Specify a predicate defining a condition which must hold on the output of the function if it
behaves correctly.
3. Establish what changes (if any) are made to the function's input/output parameters. (note: in
a purely mathematical function, no parameters would be changed. However, some
programming languages modify parameters through call by name or call by reference.)
4. Combine these into pre- and post-conditions for the function.

Consider a search function that accepts an array of integers and some integer key of its parameters.
The array members are sorted in increasing order. The function returns the array index of the
member of the array whose value is equal to that of the key. The original input is unchanged. If the
key is not matched, return an array index that is one number larger than the array's maximum
index.

Algebraic specification
Algebraic specification is a software engineering technique for formally specifying system
behavior. It was a very active subject of computer science research around 1980.

Algebraic specification seeks to systematically develop more efficient programs by:

1. formally defining types of data, and mathematical operations on those data types
2. abstracting implementation details, such as the size of representations (in memory) and the
Unit 2 : Software Engineering

efficiency of obtaining outcome of computations

3. formalizing the computations and operations on data types

4. allowing for automation by formally restricting operations to this limited set of behaviors and
data types.
An algebraic specification achieves these goals by defining one or more data types, and specifying a
collection of functions that operate on those data types.

These functions can be divided into two classes:

Constructor functions: Functions that create or initialize the data elements, or construct complex
elements from simpler ones. The set of available constructor functions is implied by the
specification's signature. Additionally, a specification can contain equations defining
equivalences between the objects constructed by these functions. Whether the underlying
representation is identical for different but equivalent constructions is implementation-
dependent.
Additional functions: Functions that operate on the data types, and are defined in terms of the
constructor functions.

Executable specification
In software engineering, an executable specification is a set of automated tests
that define the requirements of a system. These tests can be used to verify that
the software works as expected.

How do they work?

 The test title is the requirement, and the steps describe how to test the
requirement.
 A step handler matches the step text to a function that executes the code for
that step.
 When the test is run, it returns a pass or fail result.

Benefits

 Executable specifications can reduce manual testing.

 They can help avoid building software that doesn't work.
 They can provide immediate feedback on new features.
 They can be used as living documentation that updates when the documentation
changes.

How are they written?

 Executable specifications can be written in plain-language formats like Gherkin.

[1]
 They can be described in user-defined formats like spreadsheets, CSV, YAML,
and documents. [4]
 They can also be described in industry standards like IP-XACT, PSS, and System
RDL. [4]
Unit 2 : Software Engineering