University Institute of Engineering

DEPARTMENT OF COMPUTER SCIENCE

& ENGINEERING
Bachelor of Engineering (Computer Science & Engineering)
Subject Name: Software Engineering
Subject Code: 22CST-313
Prepared by:
Er. Puneet Kaur(E6913)

SOFTWARE REQUIREMENT DISCOVER . LEARN . EMPOWER

 Topics covered

• Software requirement Specification

• SRS document

• Functional and non functional requirement

2
SOFTWARE REQUIREMENT SPECIFICATION
• Main aim of requirements specification:
• Systematically organize the requirements arrived during requirements
analysis.
• Document requirements properly.

• The SRS document is useful in various contexts:

• Statement of user needs
• Contract document
• Reference document
• Definition for implementation

3
 SRS DOCUMENT
• The SRS document is known as black-box specification:
• The system is considered as a black box whose internal details are not known.
• Only its visible external (i.e. input/output) behaviour is documented.
• SRS document concentrates on:
• What needs to be done
• Carefully avoids the solution (“how to do”) aspects.
• The SRS document serves as a contract
• Between development team and the customer.
• Should be carefully written

4
SRS Document
• A software requirements specification (SRS) is a document that
captures complete description about how the system is expected to
perform. It is usually signed off at the end of requirements
engineering phase.
• 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.

5
SRS Document
• 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.

6
SRS Document
• 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.

7
 Qualities of SRS
• 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.
• 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.

8
Qualities of SRS
• 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.
• 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.

9
Qualities of SRS
• 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.
• 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.

10
Qualities of SRS
• 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.
• 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.

11
Qualities of SRS
• 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.
• 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 would go wrong and hence, test results may vary.
• 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.
• Freeze requirements: when an ambiguous or incomplete requirement is sent to client to
analyze and team 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.
12
 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.

13
Properties of a good SRS document

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

14
Properties of a good SRS document

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

15
 FUNCTIONAL REQUIREMENTS
• Functional requirements describe:
• A set of high-level requirements
• Each high-level requirement:
• takes in some data from the user
• outputs some data to the user
• Each high-level requirement:
• might consist of a set of identifiable functions
• For each high-level requirement:
• Every function is described in terms of:
• Input data set
• Output data set
• Processing required to obtain the output data set from the input data set.

16
 NON FUNCTIONAL REQUIREMENTS
• Characteristics of the system which can not be expressed as functions:
• Maintainability,
• Portability,
• Usability, etc.
• Non functional requirements include:
• Reliability issues,
• Performance issues:
• Example: How fast the system can produce results
• so that it does not overload another system to which it supplies data, etc.
• Human-computer interface issues,
• Interface with other external systems,
• Security, maintainability, etc.

17
 REFERENCES
Reference Books:
1. Suman Ugrasen, “Software Engineering - Concepts and Practices”, First Edition, Cengage.
2. Mohammad Ali Shaikh, “Software Engineering with UML”, Third Edition, Notion Press.
3. Somerville Ian, “Software Engineering”, Addison Wesley, 8th Edition.
Text Books:
4. Pressman Rogers, “Software Engineering: A Practitioner's Approach”, Sixth edition. Patterson
and Hennessy, “Computer Architecture” , Fifth Edition Morgaon Kauffman.
5. Rajib Mall, “Fundamentals of Software Engineering’’, Fourth Edition, Pearson, PHI.

18
THANK YOU