Lab 4: Software Requirement Specification (SRS) : Objectives

Software Engineering Lab Manual (14B17CI572)
Lab 4: Software Requirement Specification (SRS)

Objectives
 Gain a deeper understanding of the Software Requirement Specification
phase and the Software Requirement Specification (SRS).
 Learn how to write requirements and specifications.
1. Outline
 Review of the requirements engineering process.
 Write requirements and specifications.
 Software Requirement Specification (SRS).
2. Background
A requirement is a statement of a behavior or attribute that a system must possess for
the system to be acceptable to a stakeholder.
Software Requirement Specification (SRS) is a document that describes the

requirements of a computer system from the user's point of view. An SRS document
specifies:
 The required behavior of a system in terms of: input data, required processing,
output data, operational scenarios and interfaces.
 The attributes of a system including: performance, security, maintainability,
reliability, availability, safety requirements and design constraints.
Requirements management is a systematic approach to eliciting, organizing and

documenting the requirements of a system. It is a process that establishes and
maintains agreement between the customer and the project team on the changing
requirements of a system.
Requirements management is important because, by organizing and tracking the

requirements and managing the requirement changes, you improve the chances of
completing the project on time and under budget. Poor change management is a key
cause of project failure.
2.1 Requirements Engineering Process

Requirements engineering process consists of four phases:
 Requirements elicitation: getting the customers to state exactly what the
requirements are.
 Requirements analysis: making qualitative judgments and checking for
consistency and feasibility of requirements.
 Requirements validation: demonstrating that the requirements define the
system that the customer really wants.
 Requirements management: the process of managing changing requirements
during the requirements engineering process and system development, and
identifying missing and extra requirements.
12
2.2 Writing Requirements

Requirements always need to be correct, unambiguous, complete, consistent, and
testable.
2.2.1 Recommendations When Writing Requirements

 Never assume: others do now know what you have in mind.
 Use meaningful words; avoid words like: process, manage, perform, handle,
and support.
 State requirements not features:
o Feature: general, tested only for existence.
o Requirement: specific, testable, measurable.
 Avoid:
o Conjunctions: ask yourself whether the requirement should it be split
into two requirements.
o Conditionals: if, else, but, except, although.
o Possibilities: may, might, probably, usually.
2.3 Writing Specifications

Specification is a description of operations and attributes of a system. It can be a
document, set of documents, a database of design information, a prototype, diagrams
or any combination of these things.
Specifications are different from requirements: specifications are sufficiently

complete ─ not only what stakeholders say they want; usually, they have no conflicts;
they describe the system as it will be built and resolve any conflicting requirements.
Creating specifications is important. However, you may not create specifications if:
 You are using a very incremental development process (small changes).
 You are building research or proof of concept projects.
 You rebuilding very small projects.
 It is not cheaper or faster than building the product.
2.4 Software Requirement Specification (SRS)

Remember that there is no “Perfect SRS”. However, SRS should be:
 Correct: each requirement represents something required by the target system.
 Unambiguous: every requirement in SRS has only one interpretation
 Complete: everything the target system should do is included in SRS (no
sections are marked TBD-to be determined).
 Verifiable: there exists some finite process with which a person/machine can
check that the actual as-built software product meets the requirements.
 Consistent in behavior and terms.
 Understandable by customers.
 Modifiable: changes can be made easily, completely and consistently.
 Design independent: doesn't imply specific software architecture or algorithm.
 Concise: shorter is better.
 Organized: requirements in SRS are easy to locate; related requirements are
together.
 Traceable: each requirement is able to be referenced for later use (by the using
paragraph numbers, one requirement in each paragraph, or by using
convention for indication requirements)
13
3. Exercise
Are the following requirements vague? If yes, why? Can you fix them?
o The feature is responsible for managing connections.
o The feature allows users to perform administrative functions.
4. Deliverables
 You should submit the solutions for exercise 3.
 Also identify and document various requirements of your term project, in a
manner that they are unambiguous, complete and inconsistent.
14

Lab 4: Software Requirement Specification (SRS) : Objectives

Uploaded by

Copyright:

Available Formats

Lab 4: Software Requirement Specification (SRS) : Objectives

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Lab 4: Software Requirement Specification (SRS) : Objectives

Uploaded by

Copyright:

Available Formats

Software Engineering Lab Manual (14B17CI572)

Lab 4: Software Requirement Specification (SRS)

Software Requirement Specification (SRS) is a document that describes the

Requirements management is a systematic approach to eliciting, organizing and

Requirements management is important because, by organizing and tracking the

2.1 Requirements Engineering Process

2.2 Writing Requirements

2.2.1 Recommendations When Writing Requirements

2.3 Writing Specifications

Specifications are different from requirements: specifications are sufficiently

2.4 Software Requirement Specification (SRS)

You might also like