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 goal of the requirements analysis and specification phase is to clearly understand the
customer requirements and to systematically organise the requirements into a document called the
Software Requirements Specification (SRS) document.
Requirements analysis and specification activity is usually carried out by a few experienced
members of the development team. The engineers who gather and analyse customer requirements
and then write the requirements specification document are known as system analysts. After
understanding the precise user requirements, the analysts analyse the requirements to weed out
inconsistencies, anomalies and incompleteness. They then proceed to write the Software
Requirements Specification (SRS) document. The SRS document is the final outcome of the
requirements analysis and specification phase.
Requirements analysis and specification phase mainly involves carrying out the following two
important activities:
• Requirements gathering and analysis
• Requirements specification

REQUIREMENTS GATHERING AND ANALYSIS

The complete set of requirements is rarely available in the form of a single document from the
customer. The requirements have to be gathered by the analyst from several sources in bits and
pieces which are then analysed to removed several types of problems and inconsistencies.
Requirements gathering and analysis activity into two separate tasks:
• Requirements gathering
• 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.
The important ways in which an experienced analyst gathers requirements are:
• 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 statement of purpose (SoP) document to the developers which discuss issues such as
the context in which the software is required, the basic purpose, the stakeholders, features of
any similar software developed elsewhere, etc.
• 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.
• 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 a software
is also called a task. In this context, 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 realise 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. For different types of
scenarios of a task, the behaviour of the software can be different. For various identified tasks,
the possible scenarios of execution are identified and the details of each scenario is identified in
consultation with the users.
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.
The main purpose of the requirements analysis activity is to analyse the gathered requirements to
remove all ambiguities, incompleteness, and inconsistencies from the gathered customer
requirements and to obtain a clear understanding of the software to be developed.
During requirements analysis, the analyst needs to identify and resolve three main types of
problems in the requirements:
• Anomaly
• Inconsistency
• Incompleteness
Anomaly: An anomaly is an ambiguity in a requirement. When a requirement is anomalous,
several interpretations of that requirement are possible.
Inconsistency: Two requirements are said to be inconsistent, if one of the requirements contradicts
the other.
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.

SOFTWARE REQUIREMENTS SPECIFICATION

The SRS document usually contains all the user requirements in a structured though an informal
form. The production of the requirements stage of the software development process is Software
Requirements Specifications (SRS) (also called a requirements document). This report lays a
foundation for software engineering activities and is constructing when entire requirements are
elicited and analyzed. SRS is a formal report, which acts as a representation of software that
enables the customers to review whether it (SRS) is according to their requirements.
Characteristics of good SRS
1. Correctness: User review is used to provide the accuracy of requirements stated in the SRS. SRS
is said to be perfect if it covers all the needs that are truly expected from the system.
2. Completeness: The SRS is complete if, and only if, it includes the following elements:
I. All essential requirements, whether relating to functionality, performance, design.
II. Definition of their responses of the software
III. Full labels and references to all figures, tables, and diagrams
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements
described in its conflict. Example: One condition may state that all lights shall be green while
another states that all lights shall be blue.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation.
5. Ranking for importance and stability: The SRS is ranked for importance and stability if each
requirement in it has an identifier to indicate either the significance or stability of that particular
requirement. Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly
obtain changes to the system.
7. Verifiability: SRS is correct when the specified requirements can be verified with a cost-
effective system to check whether the final software meets those requirements.
8. Traceability: The SRS is traceable if the origin of each of the requirements is clear and if it
facilitates the referencing of each condition in future development or enhancement
documentation.
9. Design Independence: There should be an option to select from multiple design alternatives for
the final system. More specifically, the SRS should not contain any implementation details.
10. Testability: An SRS should be written in such a method that it is simple to generate test cases
and test plans from the report.
11. Understandable by the customer: An end user may be an expert in his/her explicit domain
but might not be trained in computer science. The language should be kept simple and clear.
12. The right level of abstraction: If the SRS is written for the requirements stage, the details
should be explained explicitly.

Attributes of Bad SRS Documents

SRS documents written by novices frequently suffer from a variety of problems.
Over-specification: It occurs when the analyst tries to address the “how to” aspects in the SRS
document. For example, in the library automation problem, one should not specify whether the
library membership records need to be stored indexed on the member’s first name or on the
library member’s identification (ID) number.
Forward references: One should not refer to aspects that are discussed much later in the SRS
document. Forward referencing seriously reduces readability of the specification.
Wishful thinking: This type of problems concern description of aspects which would be difficult
to implement.
Noise: The term noise refers to presence of material not directly relevant to the software
development process.

Important Categories of Customer Requirements

A good SRS document, should properly categorize and organise the requirements into different
sections.
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. The
functional requirements of the system, should clearly describe each functionality that the system
would support along with the corresponding input and output data set. Each function fi of the
system can be considered as reading certain data and then transforming a set of input data (ii) to
the corresponding set of output data (oi).
Non-functional requirements
The non-functional requirements are non-negotiable obligations that must be supported by the
software. Non-functional requirements usually address aspects concerning external interfaces,
user interfaces, maintainability, portability, usability, maximum number of concurrent users,
timing, and throughput (transactions per second, etc.)
Non-functional requirements can be described under three different sections:
• Design and implementation constraints: Design and implementation constraints describe 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 needs to be honoured; hardware
limitations; interfaces with other applications, 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.
• Other non-functional 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. These are not binding on the developers, and they may
take these suggestions into account if possible. For example, the developers may use these
suggestions while choosing among different design solutions.
A goal, in contrast to the functional and non-functional requirements, is not checked by the
customer for conformance at the time of acceptance testing.

Organisation of the SRS Document

Depending on the type of project being handled, some sections can be omitted, introduced, or
interchanged as may be considered prudent by the analyst. However, organisation of the SRS
document to a large extent depends on the preferences of the system analyst himself, and he is
often guided in this by the policies and standards being followed by the development company.
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.
Description of the user skill-level is important, since the command language design and the
presentation styles of the various documents depend to a large extent on the types of the users it is
targeted for.
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. (For example, the parts of a problem that are being automated and the parts that
would need to be automated during future evolution of the software.)
Environmental characteristics: This section should briefly outline the environment (hardware and
other software) with which the software will interact.
Overall description of organisation 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 systems, or it is new software.
Product features: This section should summarize the major ways in which the software would be
used.
User classes: Various user classes (and their expertise on computer) 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.
Design and implementation constraints: In this section, the different constraints on the design
and implementation are discussed. These might include—corporate or regulatory policies;
hardware limitations (timing requirements, memory requirements); interfaces to other
applications; etc.
User documentation: This section should list out the types of user documentation, such as user
manuals, on-line help, and trouble-shooting manuals.
Functional requirements for organisation of SRS document
This section can classify the functionalities either based on the specific functionalities invoked by
different users, or the functionalities that are available in different modes, etc., depending what
may be appropriate.
1. User class 1
(a) Functional requirement 1.1
(b) Functional requirement 1.2
2. User class 2
(a) Functional req uirement 2.1
(b) Functional requirement 2.2
External interface requirements
User interfaces: This section should describe a high-level description of various interfaces and
various principles to be followed. The user interface description may include sample screen
images, any GUI standards or style guides that are to be followed, screen layout constraints, etc.
Hardware interfaces: This section should describe the interface between the software and the
hardware components of the system.
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 organisation of SRS document
Performance requirements: Aspects such as number of transaction 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 such as recovery after power failure are specified here.
Security requirements: This section should specify any requirements regarding security or
privacy requirements on data used or created by the software.

(Personal library software): It is proposed to develop a software that would be used by

individuals to manage their personal collection of books.
Functional requirements
The software needs to support three categories of functionalities as described below:
1. Manage own books
1.1 Register book
Description: To register a book in the personal library, the details of a book, such as name, year of
publication, date of purchase, price and publisher are entered. This is stored in the database and a
unique serial number is generated.
Input: Book details
Output: Unique serial number
R.1.2: Issue book
Description: A friend can be issued book only if he is registered. The various books outstanding
against him along with the date borrowed are first displayed.
R.1.2.1: Display outstanding books
Description: First a friend’s name and the serial number of the book to be issued are entered. Then
the books outstanding against the friend should be displayed.
Input: Friend name
Output: List of outstanding books along with the date on which each was borrowed.
R.1.2.2: Confirm issue book
If the owner confirms, then the book should be issued to him and the relevant records should be
updated.
Input: Owner confirmation for book issue. Output: Confirmation of book issue.
R.1.3: Query outstanding books
Description: Details of friends who have books outstanding against their name is displayed.
Input: User selection
Output: The display includes the name, address and telephone numbers of each friend against
whom books are outstanding along with the titles of the outstanding books and the date on which
those were issued.
R.1.4: Query book
Description: Any user should be able to query a particular book from anywhere using a web
browser.
Input: Name of the book.
Output: Availability of the book and whether the book is issued out.
R.1.5: Return book
Description: Upon return of a book by a friend, the date of return is stored and the book is removed
from the borrowing list of the concerned friend.
Input: Name of the book.
Output: Confirmation message.
2. Manage friend details
R.2.1: Register friend
Description: A friend must be registered before he can be issued books. After the registration data
is entered correctly, the data should be stored and a confirmation message should be displayed.
Input: Friend details including name of the friend, address, land line number and mobile number.
Output: Confirmation of registration status.
R.2.2: Update friend details
Description: When a friend’s registration information changes, the same must be updated in the
computer.
R.2.2.1: Display current details
Input: Friend name.
Output: Currently stored details.
R2.2.2: Update friend details
Input: Changes needed.
Output: Updated details with confirmation of the changes.
R.3.3: Delete a friend record
Description: Delete records of inactive members.
Input: Friend name.
Output: Confirmation message.
3. Manage borrowed books
R.3.1: Register borrowed books
Description: The books borrowed by the user of the personal library are registered.
Input: Title of the book and the date borrowed.
Output: Confirmation of the registration status.
R.3.2: Deregister borrowed books
Description: A borrowed book is deregistered when it is returned.
Input: Book name.
Output: Confirmation of deregistration.
R.3.3: Display borrowed books
Description: The data about the books borrowed by the owner are displayed.
Input: User selection.
Output: List of books borrowed from other friends.
4. Manage statistics
R.4.1: Display book count
Description: The total number of books in the personal library should be displayed.
Input: User selection.
Output: Count of books.
R4.2: Display amount invested
Description: The total amount invested in the personal library is displayed.
Input: User selection.
Output: Total amount invested.
R.4.2: Display number of transactions
Description: The total numbers of books issued and returned over a specific period by one (or all)
friend(s) is displayed.
Input: Start of period and end of period.
Output: Total number of books issued and total number of books returned.
Non-functional requirements
N.1: Database: A data base management system that is available free of cost in the public domain
should be used.
N.2: Platform: Both Windows and Unix versions of the software need to be developed.
N.3: Web-support: It should be possible to invoke the query book functionality from any place by
using a web browser.
Observation: Since there are many functional requirements, the requirements have been organised
into four sections: Manage own books, manage friends, manage borrowed books, and manage
statistics. Now each section has less than 7 functional requirements. This would not only enhance
the readability of the document, but would also help in design.

FORMAL SYSTEM SPECIFICATION

Formal methods provide tools to precisely describe a system and show that a system is correctly
implemented. We say a system is correctly implemented when it satisfies its given specification.
The specification of a system can be given either as a list of its desirable properties (property-
oriented approach) or as an abstract model of the system (model-oriented approach).
A formal technique is a mathematical method to specify a hardware and/or software system, verify whether a
specification is realisable, verify that an implementation satisfies its specification, prove properties of a
system without necessarily running the system, etc.
A formal specification language consists of two sets—“syn” and “sem”, and a relation “sat”
between them. The set syn is called the syntactic domain, the set sem is called the semantic domain,
and the relation sat is called the satisfaction relation. For a given specification syn, and model of the
system sem, if sat (syn, sem), then syn is said to be the specification of sem, and sem is said to be the
specificand of syn.
In general, formal techniques can be used at every stage of the system development activity to
verify that the output of one stage conforms to the output of the previous stage.
Syntactic domains
The syntactic domain of a formal specification language consists of an alphabet of symbols and a
set of formation rules to construct formulas from the alphabet. The well-formed formulas are used
to specify a system.
Semantic domains
Formal techniques can have considerably different semantic domains. Abstract data type
specification languages are used to specify algebras, theories, and programs. Programming
languages are used to specify functions from input to output values.
Satisfaction relation
Given the model of a system, it is important to determine whether an element of the semantic
domain satisfies the specifications. This satisfaction is determined by using a homomorphism
known as semantic abstraction function. The semantic abstraction function maps the elements of the
semantic domain into equivalent classes.

Operational Semantics
Informally, the operational semantics of a formal method is the way computations are represented.
There are different types of operational semantics according to what is meant by a single run of the
system and how the runs are grouped together to describe the behaviour of the system.
Linear semantics: In this approach, a run o f a system is described by a sequence (possibly infinite)
of events or states. The concurrent activities of the system are represented by non-deterministic
inter leavings of the atomic actions.
Branching semantics: In this approach, the behaviour of a system is represented by a directed
graph. The nodes of the graph represent the possible states in the evolution of a system.
Maximally parallel semantics: In this approach, all the concurrent actions enabled at any state are
assumed to be taken together.
Partial order semantics: Under this view, the semantics described to a system is a structure of states
satisfying a partial order relation among the states (events). The partial order represents a
precedence ordering among events, and constrains some events to occur only after some other events
have occurred.

AXIOMATIC SPECIFICATION
In axiomatic specification of a system, first-order logic is used to write the pre- and post-
conditions to specify the operations of the system in the form of axioms. The pre-conditions
basically capture the conditions that must be satisfied before an operation can successfully be
invoked. The post-conditions are the conditions that are essentially constraints on the results
produced for the function execution to be considered successful.

ALGEBRAIC SPECIFICATION
In the algebraic specification technique, an object class or type is specified in terms of relationships
existing between the operations defined on that type. Algebraic specifications define a system as a
heterogeneous algebra. For example, alphabetic strings S together with operations of concatenation
and length {S, I , con, len}, is not a homogeneous algebra, since the range of the length operation is
the set of integers. Each set of symbols in a heterogeneous algebra is called a sort of the algebra. An
algebraic specification is usually presented in four sections.
Types section: In this section, the sorts (or the data types) being used is specified.
Exception section: This section gives the names of the exceptional conditions that might occur
when different operations are carried out.
Syntax section: This section defines the signatures of the interface procedures. The collection of
sets that form input domain of an operator and the sort where the output is produced are called
the signature of the operator. For example, PUSH takes a stack and an element as its input and
returns a new stack that has been created.
Equations section: This section gives a set of rewrite rules (or equations) defining the meaning of
the interface procedures in terms of each other. In general, this section is allowed to contain
conditional expressions.
Properties of algebraic specifications
Three important properties that every algebraic specification should possess are:
Completeness: This property ensures that using the equations, it should be possible to reduce any
arbitrary sequence of operations on the interface procedures.
Finite termination property: This property essentially addresses the following question: Do
applications of the rewrite rules to arbitrary expressions involving the interface procedures always
terminate? For arbitrary algebraic equations, convergence (finite termination) is undecidable. But,
if the right hand side of each rewrite rule has fewer terms than the left, then the rewrite process
must terminate.
Unique termination property: This property indicates whether application of rewrite rules in
different orders always result in the same answer.

EXECUTABLE SPECIFICATION AND 4GL

When the specification of a system is expressed formally or is described by using a programming
language, then it becomes possible to directly execute the specification without having to design
and write code for implementation. However, executable specifications are usually slow and
inefficient, 4GLs4 (4th Generation Languages) are examples of executable specification languages.
4GLs are successful because there is a lot of large granularity commonality across data processing
applications which have been identified and mapped to program code. 4GLs get their power from
software reuse, where the common abstractions have been identified and parameterized.