Software requirement specification(SRS)

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. Also, it comprises user
requirements for a system as well as detailed specifications of the system requirements.
The SRS is a specification for a specific software product, program, or set of applications that
perform particular functions in a specific environment. It serves several goals depending on who is
writing it.
First, the SRS could be written by the client of a system. Second, the SRS could be written by a
developer of the system. The two methods create entirely various situations and establish different
purposes for the document altogether. The first case, SRS, is used to define the needs and expectation
of the users.
The second case, SRS, is written for various purposes and serves as a contract document between
customer and developer.

Characteristics of good SRS

Following are the features of a good SRS document:

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:
(1). All essential requirements, whether relating to functionality, performance, design, constraints,
attributes, or external interfaces.
(2). Definition of their responses of the software to all realizable classes of input data in all available
categories of situations.
Note: It is essential to specify the responses to both valid and invalid values.
(3). Full labels and references to all figures, tables, and diagrams in the SRS and definitions of all
terms and units of measure.
3. Consistency: The SRS is consistent if, and only if, no subset of individual requirements described in
its conflict. There are three types of possible conflict in the SRS:
(1). The specified characteristics of real-world objects may conflicts. For example,
(a) The format of an output report may be described in one requirement as tabular but in another as
textual.
(b) One condition may state that all lights shall be green while another states that all lights shall be
blue.
(2). There may be a reasonable or temporal conflict between the two specified actions. For example,
(a) One requirement may determine that the program will add two inputs, and another may
determine that the program will multiply them.
(b) One condition may state that "A" must always follow "B," while other requires that "A and B" co-
occurs.
(3). Two or more requirements may define the same real-world object but use different terms for that
object. For example, a program's request for user input may be called a "prompt" in one
requirement's and a "cue" in another. The use of standard terminology and descriptions promotes
consistency.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a method used
with multiple definitions, the requirements report should determine the implications in the SRS so
that it is clear and simple to understand.
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. Each element should be identified to make
these differences clear and explicit. Another way to rank requirements is to distinguish classes of
items as essential, conditional, and optional.
6. Modifiability: SRS should be made as modifiable as likely and should be capable of quickly obtain
changes to the system to some extent. Modifications should be perfectly indexed and cross-
referenced.
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. The requirements are verified
with the help of reviews.
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.
There are two types of Traceability:
1. Backward Traceability: This depends upon each requirement explicitly referencing its source in
earlier documents.
2. Forward Traceability: This depends upon each element in the SRS having a unique name or
reference number.
The forward traceability of the SRS is especially crucial when the software product enters the
operation and maintenance phase. As code and design document is modified, it is necessary to be
able to ascertain the complete set of requirements that may be concerned by those modifications.
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. Hence, the purpose of formal notations and symbols
should be avoided too as much extent as possible. 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. Whereas,for a feasibility study, fewer analysis can be used. Hence, the level of
abstraction modifies according to the objective of the SRS.
Properties of a good SRS document
The essential properties of a good SRS document are the following:
Concise: The SRS report should be concise and at the same time, unambiguous, consistent, and
complete. Verbose and irrelevant descriptions decrease readability and also increase error
possibilities.
Structured: It should be well-structured. A well-structured document is simple to understand and
modify. In practice, the SRS document undergoes several revisions to cope up with the user
requirements. Often, user requirements evolve over a period of time. Therefore, to make the
modifications to the SRS document easy, it is vital to make the report well-structured.
Black-box view: It should only define what the system should do and refrain from stating how to do
these. This means that the SRS document should define the external behavior of the system and not
discuss the implementation issues. The SRS report should view the system to be developed as a black
box and should define the externally visible behavior of the system. For this reason, the SRS report is
also known as the black-box specification of a system.
Conceptual integrity: It should show conceptual integrity so that the reader can merely understand
it. Response to undesired events: It should characterize acceptable responses to unwanted events.
These are called system response to exceptional conditions.
Verifiable: All requirements of the system, as documented in the SRS document, should be correct.
This means that it should be possible to decide whether or not requirements have been met in an
implementation.
Why Use an SRS Document? An SRS gives you a complete picture of
your entire project. It provides a single source of truth that every team
involved in development will follow. It is your plan of action and keeps all
your teams — from development and testing to maintenance — on the
same page.
A software requirements specification (SRS) is a document that describes
what the software will do and how it will be expected to perform. It also
describes the functionality the product needs to fulfill the needs of all
stakeholders (business, users).
What Are the Components of a Software Requirement Specification (SRS)?
 Introduction.
 Product Description.
 Software Requirements.
 External Interface Requirements.
 Non-Functional Requirements.
INTRODUCTION
This section presents the purpose of the document, any specific conventions around
language used and definitions of specific terms (such as acronyms or references to
other supporting documents), the document’s intended audience and finally, the
specific scope of the software project.

PRODUCT DESCRIPTION
This section outlines the high-level context that motivates the software product’s
development, including a summary of its main features and functionality. A very
important component of the product description is an explanation of the product’s
intended user, what processes developers will use to accomplish their goal and for
which type of environment this product is most well suited (business, customer,
industry and so forth). The product descriptions will also contain any external
dependency by which the product’s development will be affected.

SOFTWARE REQUIREMENTS
The meat of the document, the software requirements section, describes in detail how
the software will behave and the functionality it offers the user.
For example, a functional requirement may state a user will be able to upload videos
using the user interface.
Detailed requirement information is usually laid out in the document as a written list of
requirements broken down by key topic areas that are specific to the product. For
example, gaming software may have functional requirements specific to players and the
surrounding environment. Otherwise, you might have an external attachment to a
requirements template wherein this template is a simple file that contains a granular
list, or table, of requirements with key information (description of the requirement,
who it’s for, which version of the product it refers to and more).
Both options are a valid way of building out this section.

EXTERNAL INTERFACE REQUIREMENTS

This section contains a description of how the user interacts with the software product
through its interface, as well as a description of the hardware necessary to support that
interface.
In addition, this section usually features a description of how the software will
communicate with other software using the various available communication
standards. For example, you might have descriptions of compatible message formats
(such as audio or visual) as well as standards for the data size the product can send or
receive by way of a specific user action.

UML (Unified Modeling Language) is a standardized, general-

purpose diagraming techniques designed for the field
of Software Engineering. UML contains sets of graphic
notations for modeling object oriented code and databases.
The Unified Modeling Language (UML) is a standard modeling language in
which some of the best object-oriented (OO) modeling experiences are
embedded. In this paper we illustrate the role formal specification
techniques can play in developing a precise semantics for the UML. We
present a precise characterization of requirements-level (problem-oriented)
Class Diagrams and outline how the characterization can be used to
semantically analyze requirements Class Diagrams.
Characteristics of UML
The UML has the following features:
o It is a generalized modeling language.
o It is distinct from other programming languages like C++, Python, etc.
o It is interrelated to object-oriented analysis and design.
o It is used to visualize the workflow of the system.
o It is a pictorial language, used to generate powerful modeling artifacts.
Role of UML in OO design
As the UML is a modeling language used to model software as well as non-software systems, but here
it focuses on modeling OO software applications. It is essential to understand the relation between
the OO design and UML. The OO design can be converted into the UML as and when required. The
OO languages influence the programming world as they model real world objects.
The UML itself is an amalgamation of object-oriented notations like Object-Oriented Design (OOD),
Object Modeling Technique (OMT), and Object-Oriented Software Engineering (OOSE). The strength
of these three approaches is utilized by the UML to represent more consistency.
Audience
This UML tutorial is made for both beginners and professionals, to help them understand the
fundamental concept of UML. After completion of this tutorial, you will find yourself at a moderate
level of expertise from where you take yourself to the next level.
Prerequisites
No particular skills are required as a prerequisite before starting with this tutorial. The learner must be
enthusiastic about gaining knowledge of UML.
Problems
We assure you that you will not find any difficulty in this tutorial. But if there is any query, or you find
any mistake, do let us know by posting it in the contact form so that we can further improve it.
Data Dictionaries in Software Engineering
Data Dictionary is the major component in the structured analysis model of the
system. It lists all the data items appearing in DFD. A data dictionary in Software
Engineering means a file or a set of files that includes a database’s metadata (hold
records about other objects in the database), like data ownership, relationships of the
data to another object, and some other data.
Example a data dictionary entry: GrossPay = regular pay + overtime pay
Case Tools is used to maintain data dictionary as it captures the data items
appearing in a DFD automatically to generate the data dictionary.
Components of Data Dictionary:
In Software Engineering, the data dictionary contains the following information:
 Name of the item: It can be your choice.
 Aliases: It represents another name.
 Description: Description of what the actual text is all about.
 Related data items: with other data items.
 Range of values: It will represent all possible answers.
Features of Data Dictionary :
Here, we will discuss some features of the data dictionary as follows.
 It helps in designing test cases and designing the software.
 It is very important for creating an order list from a subset of the items list.
 It is very important for creating an order list from a complete items list.
 The data dictionary is also important to find the specific data item object from the
list.
Uses of Data Dictionary :
Here, we will discuss some use cases of the data dictionary as follows.
 Used for creating the ordered list of data items
 Used for creating the ordered list of a subset of the data items
 Used for Designing and testing software in Software Engineering
 Used for finding data items from a description in Software Engineering
Importance of Data Dictionary:
 It provides developers with standard terminology for all data.
 It provides developers to use different terms to refer to the same data.
 It provides definitions for different data
 Query handling is facilitated if a data dictionary is used in RDMS.