TMP3413
Software
Engineering Lab
Lecture 06:
Defining the
Requirements
Topics
What are requirements?
Why we need requirements?
Requirement changes
Requirements Elicitation
The Software Requirements
Specification
Requirements Traceability
1.0 What are Requirements?
In requirements the team produces the software
requirements specification (SRS). The SRS should
provide a clear and unambiguous description of
what the product is to be and it should include
precise criteria for evaluating the finished product to
ensure that it does what is supposed to do
For the TSPi course, the team need to provide
feedback to the instructor, who acts as your
customer. Thus the requirements process consists
principally of asking and answering questions. To do
an effective job of developing requirements , we
need the following:
**An initial statement of the customer’s needs.
**Someone who can explain why the product is
wanted. Generally tell what functions the customers
want. In any event, the instructor is the final authority
on requirements questions.
2.0 Why we need Requirements?
(cont)
Because during requirements development,
we review the customer’s needs and
formulate questions about how the product is
to work.
Then, the team need to discuss among them
and decide which ones we understand and
where we need additional information.
Through this process, the team gains a
common understanding of what we plan to
build.
2.0 Why we need Requirements?
SRS document is a necessary part of the
requirement development process, your goal
is to reach the team agreement on what to
build.
A well structures requirements process is
essential that everyone participate in defining
the requirements.
3.0 Requirements Changes (cont…)
Changes in requirements are often a problem
because users generally cannot know precisely what
they need until they try to use the finished product.
The difficult part of the software requirements process
is to learn what the users believe they need and to
help them define their needs in terms of useful
product functions.
The engineers should do this quickly as they can and
make this understanding as specific as possible.
There is no such thing as a free requirements change.
All changes cost time and money.
3.0 Requirements Changes
This raises on key question:
How do you distinguish between requirements
clarifications and significant functional additions?
The only way to do this is to start with a
precise agreement on what is to be in the
product so that you have a mechanism for
settling requirements disagreements.
Best reach this agreement by producing a
clear and precise SRS document.
4.0 Requirements Elicitation
The principal steps of requirements elicitation are
as follows:
Asses system feasibility
Understand the organizational issues
Identify the system stakeholders
Record the requirements sources
Define the system’s operating environment
Asses the business issues
Define the domain constraints
Record the requirements rationale
Prototype poorly understood requirements
Define the usage scenarios
Define the operational processes
5.0 The Software Requirements
Specification (SRS) (cont…)
What you plan to develop and how you intend the
product to perform?
The requirements should not describe or even
imply how to build the product.
That is a design decision and all design issues
should be left for the design phase.
The objective is to produce requirements that
leave you as free as possible to make design
choices.
Focus the SRS on what the product is to do and
avoid specifying how it will be designed and
built.
5.0 The Software Requirements
Specification (SRS)
There are many standards for SRS documents
[Davis, pg 202; Somerville, pg 42; Pressman]
For the TSPi, you will need to on the functional
and operational requirements.
The principal topics to address are;
Functional Req.: inputs, outputs, calculations and use
cases
External Interface Req.: user, hardware, software,
communications
Design Constraint: file formats, languages, standards,
compatibility, etc…
Attributes: availability, security, maintainability,
conversion, etc..
Other requirements: database, installation, etc..
5.0 The Software Requirements Specification
(SRS)
1. Table of contents
Sample SRS contents
2. Introduction
Purpose of the SRS
Problem statement
Team Project Information
3. Statement of functional requirements
Description of the system function requirements
Cycle 1 requirements
Cycle 2 requirements
Top-down structure
4. Definition of rules used in the requirements
5. External Interface requirements
User interface
Screen layouts
6. Design/implementation constraint
Standard compliance
Development constraints
7. Special system requirements
Documentation
Compatibility
8. References and sources of information
5.1 Requirements Traceability
Toensure functional traceability, number the
paragraphs and sections on the SRS so that we
can later identify every requirements item.
Maintain traceability through the SRS and into
design.
5.2 Balancing Workload
SRS produced for a TSPi project is usually only a
few pages long, it should not take very long to
develop.
Divide the writing among team members.
6.0 The TSPi Requirements Scripts
(cont…)
TSPihas two requirements development scripts
REQ1 and REQ2. Shown in Table 6.2 & Table
6.3
REQ1 produces the SRS for the first
development cycle and REQn updates this
SRS for the next subsequent cycles.
7.0 Summary
In the requirement phase, Software
Requirements Specification (SRS) need to be
produced.
It’s purpose is to describe those functions that
you intend the product to perform.
SRS should provide clear and unambiguous
criteria for evaluating the finished product as
well as guidance.
Need functional traceability from the code to
the design and form the design to the SRS
and the need statement.
