UNIT-2

Software Requirements Specification:

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.

Structure of SRS:

1. Introduction:

1.1 Purpose

1.2 Intended Audience

1.3 Scope

1.4 Definitions

1.5 References

2. Overall Description:

2.1 User Interface

2.2 System Interface

2.3 Constraints, Assumptions, Dependencies.

2.4 User Characteristics

3. System features and Requirements:

 3.1 Functional Requirements

3.2 Use cases

3.3 External Interface

3.4 Logical database Requirements

3.5 Non Functional Requirements

4. Deliver for Approval.

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:

(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.

(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.

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.
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.

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:

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.

Requirements Analysis:

Requirement analysis is significant and essential activity after elicitation. We analyze, refine, and
scrutinize the gathered requirements to make consistent and unambiguous requirements. This
activity reviews all requirements and may provide a graphical view of the entire system. After
the completion of the analysis, it is expected that the understandability of the project may
improve significantly. Here, we may also use the interaction with the customer to clarify points
of confusion and to understand which requirements are more important than others.

The various steps of requirement analysis are shown in fig:

COMPONENTS OF THE SRS:

1. Functional Requirements
Functional requirements specify what output should be produced from the given inputs. So they
basically describe the connectivity between the input and output of the system. For each
functional requirement:

1. A detailed description of all the data inputs and their sources, the units of measure, and the
range of valid inputs be specified:

2. All the operations to be performed on the input data obtain the output should be specified,
and

3. Care must be taken not to specify any algorithms that are not parts of the system but that may
be needed to implement the system.

4. It must clearly state what the system should do if system behaves abnormally when any
invalid input is given or due to some error during computation. Specifically, it should specify
the behaviour of the system for invalid inputs and invalid outputs.

2. Performance Requirements (Speed Requirements)

This part of an SRS specifies the performance constraints on the software system. All the
requirements related to the performance characteristics of the system must be clearly specified.
Performance requirements are typically expressed as processed transaction s per second or
response time from the system for a user event or screen refresh time or a combination of these.
It is a good idea to pin down performance requirements for the most used or critical transactions,
user events and screens.

2. Design Constraints

The client environment may restrict the designer to include some design constraints that must be
followed. The various design constraints are standard compliance, 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.

Standard Compliance: It specifies the requirements for the standard the system must follow.
The standards may include the report format and according procedures.

Hardware Limitations: The software needs some existing or predetermined hardware to

operate, thus imposing restrictions on the design. Hardware limitations can includes the types of
machines to be used operating system availability memory space etc.

Fault Tolerance: Fault tolerance requirements can place a major constraint on how the system
is to be designed. Fault tolerance requirements often make the system more complex and
expensive, so they should be minimized.
Security: Currently security requirements have become essential and major for all types of
systems. Security requirements place restriction s on the use of certain commands control access
to database, 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.

4. External Interface Requirements

For each external interface requirements:

1. All the possible interactions of the software with people hardware and other software should
be clearly specified,

2. The characteristics of each user interface of the software product should be specified and

3. The SRS should specify the logical characteristics of each interface between the software
product and the hardware components for hardware interfacing.

Data Flow Diagrams:

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows
within a system. A neat and clear DFD can depict the right amount of the system requirement
graphically. It can be manual, automated, or a combination of both.

It shows how data enter and leaves the system, what changes the information, and where data is
stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be
used as a communication tool between a system analyst and any person who plays a part in the
order that acts as a starting point for redesigning a system. The DFD is also called as a data flow
graph or bubble chart.
Rules of DFD:
1. Each process should have at least one input and one output.
2. Each data store should have at least one data flow in and data flow out.
3. A system’s stored data must go through a process.
4. All processes in a DFD must link to another process or data store.

Levels in Data Flow Diagrams (DFD):

The DFD may be used to perform a system or software at any level of abstraction. Infact, DFDs
may be partitioned into levels that represent increasing information flow and functional detail.
Levels in DFD are numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in the
data flow diagram, which are: 0-level DFD, 1-level DFD, and 2-level DFD.

 Level 0 - Highest abstraction level DFD is known as Level 0 DFD, which depicts the
entire information system as one diagram concealing all the underlying details. Level 0
DFDs are also known as context level DFDs.

 Level 1 - The Level 0 DFD is broken down into more specific, Level 1 DFD. Level 1
DFD depicts basic modules in the system and flow of data among various modules. Level
1 DFD also mentions basic processes and sources of information.
  Level 2 - At this level, DFD shows how data flows inside the modules mentioned in Level
1.
Higher level DFDs can be transformed into more specific lower level DFDs with deeper
level of understanding unless the desired level of specification is achieved.

Entity-Relationship Diagrams

ER-modeling is a data modeling method used in software engineering to produce a conceptual

data model of an information system. Diagrams created using this ER-modeling method are
called Entity-Relationship Diagrams or ER diagrams or ERDs.

Components of an ER Diagrams

1. Entity

An entity can be a real-world object, either animate or inanimate, that can be merely identifiable.
An entity is denoted as a rectangle in an ER diagram. For example, in a school database,
students, teachers, classes, and courses offered can be treated as entities. All these entities have
some attributes or properties that give them their identity.
2. Attributes

Entities are denoted utilizing their properties, known as attributes. All attributes have values. For
example, a student entity may have name, class, and age as attributes.

There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.

3. Relationships

The association among entities is known as relationship. Relationships are represented by the
diamond-shaped box. For example, an employee works_at a department, a student enrolls in a
course. Here, Works_at and Enrolls are called relationships.