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.