Introduction
to Software Engineering
Experiment
7 (Software Requirement Specification: SRS)
Objective
·
Gain
a deeper understanding of the Software Requirement Specification phase and the
Software Requirement Specification (SRS).
·
Learn
how to write requirements and specifications.
Outline
·
Review of the requirements engineering process.
·
Write requirements and specifications.
·
Software Requirement Specification (SRS)
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.
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.
Writing
Requirements
Requirements
always need to be correct, unambiguous, complete, consistent, and testable.
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.
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
are rebuilding very small projects.
·
It
is not cheaper or faster than building the product.
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)
IN-Class Demo
An overview of the
requirements engineering process and writing requirements and specifications.
Exercises
Write SRS for your
project
Deliverables
SRS for your
project
Problem
Description
We need to understand the example
SRS document and apply it on our course projects
Post a Comment