ShriShankaracharyaMahavidyalaya, Junwani, Bhilai

Department of Computer Science

Class –BCA III
Subject- Software Engineering
Unit-3

A software requirements specification (SRS) is a detailed description of a software system

to be developed with its functional and non-functional requirements. The SRS is developed
based the agreement between customer and contractors. It may include the use cases of how
user is going to interact with software system. The software requirement specification
document consistent of all necessary requirements required for project development.

To develop the software system we should have clear understanding of Software system. To
achieve this we need to continuous communication with customers to gather all requirements.

A good SRS defines the how Software System will interact with all internal modules,
hardware, communication with other programs and human user interactions with wide range
of real life scenarios. Using the Software requirements specification (SRS) document on QA
lead, managers creates test plan.

It is very important that testers must be cleared with every detail specified in this document in
order to avoid faults in test cases and its expected results.

It is highly recommended to review or test SRS documents before start writing test cases and
making any plan for testing. Let’s see how to test SRS and the important point to keep in
mind while testing it.

1. Correctness of SRS should be checked. Since the whole testing phase is dependent on SRS,
it is very important to check its correctness. There are some standards with which we can
compare and verify.

2. Ambiguity should be avoided. Sometimes in SRS, some words have more than one
meaning and this might confused testers making it difficult to get the exact reference. It is
advisable to check for such ambiguous words and make the meaning clear for better
understanding.

3. Requirements should be complete. When tester writes test cases, what exactly is required
from the application, is the first thing which needs to be clear. For e.g. if application needs to
send the specific data of some specific size then it should be clearly mentioned in SRS that
how much data and what is the size limit to send.

4. Consistent requirements. The SRS should be consistent within itself and consistent to its
reference documents. If you call an input “Start and Stop” in one place, don’t call it
“Start/Stop” in another. This sets the standard and should be followed throughout the testing
phase.

5. Verification of expected result: SRS should not have statements like “Work as expected”,
it should be clearly stated that what is expected since different testers would have different
thinking aspects and may draw different results from this statement.
 6. Testing environment: some applications need specific conditions to test and also a
particular environment for accurate result. SRS should have clear documentation on what
type of environment is needed to set up.

7. Pre-conditions defined clearly: one of the most important part of test cases is pre-
conditions. If they are not met properly then actual result will always be different expected
result. Verify that in SRS, all the pre-conditions are mentioned clearly.

8. Requirements ID: these are the base of test case template. Based on requirement Ids, test
case ids are written. Also, requirements ids make it easy to categorize modules so just by
looking at them, tester will know which module to refer. SRS must have them such as id
defines a particular module.

9. Security and Performance criteria: security is priority when a software is tested

especially when it is built in such a way that it contains some crucial information when
leaked can cause harm to business. Tester should check that all the security related
requirements are properly defined and are clear to him. Also, when we talk about
performance of a software, it plays a very important role in business so all the requirements
related to performance must be clear to the tester and he must also know when and how much
stress or load testing should be done to test the performance.

10. Assumption should be avoided: sometimes when requirement is not cleared to tester, he
tends to make some assumptions related to it, which is not a right way to do testing as
assumptions could go wrong and hence, test results may vary. It is better to avoid
assumptions and ask clients about all the “missing requirements” to have a better
understanding of expected results.

11. Deletion of irrelevant requirements: there are more than one team who work on SRS so
it might be possible that some irrelevant requirements are included in SRS. Based on the
understanding of the software, tester can find out which are these requirements and remove
them to avoid confusions and reduce work load.

12. Freeze requirements: when an ambiguous or incomplete requirement is sent to client to

analyse and tester gets a reply, that requirement result will be updated in the next SRS
version and client will freeze that requirement. Freezing here means that result will not
change again until and unless some major addition or modification is introduced in the
software.

Introduction and needs of SRS

Software requirements specification (SRS) is a detailed description of a software system to

be developed with its functional and non-functional requirements. The SRS is developed
based the agreement between customer and contractors. It may include the use cases of how
user is going to interact with software system. The software requirement specification
document consistent of all necessary requirements required for project development. To
develop the software system we should have clear understanding of Software system. To
achieve this we need to continuous communication with customers to gather all requirements.
An SRS should address, among other things:
 Functionality of the software: What the software will do
 External interfaces: How the given software will interact with hardware, other software(s)
and assumptions on these entities
 Required performance levels: Required performance levels such as response rate, recovery
rate etc. of the software
 Quality attributes: The non-functional factors that are used to evaluate the performance of
the software, such as security, safety, portability etc.
 Design constraints: Any operating system limitations (e.g.: the stock exchange software will
only run on Windows), implementation language etc. that will affect or limit the design of the
software.
Software requirements specification (SRS) is important for developers because
it minimizes the amount of time and effort developers have to expend to achieve desired
software goals. It thus reduces development cost. This also benefits the client company
because the lesser the development cost, the lesser the developers will charge from the client.
And, if composed properly,
Need of SRS
 SRS is used by various individuals in the organization.
 System customers need SRS to specify and verify whether requirements meet the desired
needs.
 In addition, SRS enables the managers to plan for the system development processes.
 System engineers need a requirements document to understand what system is to be
developed.
 These engineers also require this document to develop validation tests for the required
system.
 Requirements document is needed by system maintenance engineers to use the requirement
and the relationship between its parts.

SRS-Users

System
maintainc
e

System
test
engineerin
Software
System requiremen
custom t
er specificatio
n Document System
Engineerin
g
Manager

The requirements document has diverse users. Therefore, along with communicating the
requirements to the users it also has to define the requirements in precise detail for developers
and testers. In addition it should also include information about possible changes in the
system, which can help system designers avoid restricted decisions on design. SRS also helps
maintenance engineers to adapt the system to new requirements.

Structure analysis
 Structured Analysis is a development method that allows the analyst to understand the system
and its activities in a logical way.

It is a systematic approach, which uses graphical tools that analyse and refine the
objectives of an existing system and develop a new system specification which can be
easily understandable by user.

It has following attributes −

 It is graphic which specifies the presentation of application.

 It divides the processes so that it gives a clear picture of system flow.

 It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.

 It is an approach that works from high-level overviews to lower-level details.

Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development.
They are −

 Data Flow Diagrams

 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudocode
 Data Flow Diagrams (DFD) or Bubble Chart
It is a technique developed by Larry Constantine to express the requirements of system in a
graphical form.

 It shows the flow of data between various functions of system and specifies how the current
system is implemented.

 It is an initial stage of design phase that functionally divides the requirement specifications
down to the lowest level of detail.

 Its graphical nature makes it a good communication tool between user and analyst or analyst
and system designer.

 It gives an overview of what data a system processes, what transformations are performed,
what data are stored, what results are produced and where they flow.

Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the
user want a notational language for communication. However, it requires a large number of
iterations for obtaining the most accurate and complete solution.

The following table shows the symbols used in designing a DFD and their significance −

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow

Open Rectangle Data Store

Types of DFD

Data Flow Diagrams are either Logical or Physical.

Logical DFD - This type of DFD concentrates on the system process and flow of data in the
system. For example in a Banking software system, how data is moved between different
entities.

Physical DFD - This type of DFD shows how the data flow is actually implemented in the
system. It is more specific and close to the implementation.

DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points
that differentiate a physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation dependent. It shows It is implementation independent. It focuses

which functions are performed. only on the flow of data between processes.

It provides low level details of hardware, It explains events of systems and data
software, files, and people. required by each event.

It depicts how the current system operates It shows how business operates; not how the
and how a system will be implemented. system can be implemented.
DFD Components

DFD can represent Source, destination, storage and flow of data using the following set of
components -

Entities - Entities are source and destination of information data. Entities are represented by
rectangles with their respective names.

Process - Activities and action taken on the data are represented by Circle or Round-edged
rectangles.

Data Storage - There are two variants of data storage - it can either be represented as a
rectangle with absence of both smaller sides or as an open-sided rectangle with only one side
missing.

Data Flow - Movement of data is shown by pointed arrows. Data movement is shown from
the base of arrow as its source towards head of the arrow as destination.

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

Context Diagram
A context diagram helps in understanding the entire system by one DFD which gives the
overview of a system. It starts with mentioning major processes with little details and then
goes onto giving more details of the processes with the top-down approach.

The context diagram of mess management is shown below.

Data Dictionary
A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data stores,
data stored in data stores, and the processes.

A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard
feature. For example, refer the following table −

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15

Decision Trees
Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.
 Decision trees depict the relationship of each condition and their permissible actions. A
square node indicates an action and a circle indicates a condition. It forces analysts to
consider the sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe
what other combinations of conditions you can take for testing. It is a single representation of
the relationships between conditions and actions.

For example, refer the following decision tree −

Decision Tables
Decision tables are a method of describing the complex logical relationship in a precise
manner which is easily understandable.

 It is useful in situations where the resulting actions depend on the occurrence of one or
several combinations of independent conditions.

 It is a matrix containing row or columns for defining a problem and the actions.

Components of a Decision Table

 Condition Stub − It is in the upper left quadrant which lists all the condition to be checked.

 Action Stub − It is in the lower left quadrant which outlines all the action to be carried out to
meet such condition.

 Condition Entry − It is in upper right quadrant which provides answers to questions asked in
condition stub quadrant.

 Action Entry − It is in lower right quadrant which indicates the appropriate action resulting
from the answers to the conditions in the condition entry quadrant.

The entries in decision table are given by Decision Rules which define the relationships
between combinations of conditions and courses of action. In rules section,

 Y shows the existence of a condition.

 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

Purchase amount = Rs - Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X

Pseudo code
A pseudo code does not conform to any programming language and expresses logic in plain
English.
 It may specify the physical programming logic without actual coding during and after the
physical design.

 It is used in conjunction with structured programming.

 It replaces the flowcharts of a program.