|
Software Requirements Specification |
|
|
It seems obvious that we need to know what software is supposed to do
before we build it. Nevertheless, many projects are delayed (or fail
completely) because development begins before anyone on the project
team really understands how the software should behave. The solution to
this problem is to take the time to gather and verify the software requirements—documentation
that completely describes the behavior that is required of the
software—before the software is designed, built, and tested.
For more information on software requirements, see:
Software Requirements Specification
A software requirements specification (SRS) is a complete description
of the behavior of the software to be developed. It includes a set of
use cases that describe all of the interactions that the users will
have with the software. In addition to use cases, the SRS contains
functional requirements, which define the internal workings of the
software: that is, the calculations, technical details, data
manipulation and processing, and other specific functionality that
shows how the use cases are to be satisfied. It also contains
nonfunctional requirements, which impose constraints on the design or
implementation (such as performance requirements, quality standards or
design constraints).
SRS Outline
The following document contains the outline for a software requirements
specification. It includes templates for use cases, functional requirements and
nonfunctional requirements.
SRS Development Script
Like use cases, the SRS should be developed iteratively. The goal of
the SRS Development Script is to remove as many defects as possible
from the SRS. Many people have trouble figuring out what constitutes a
defect. In this case, a defect is any planned software behavior which a
project team member, user, stakeholder or decision-maker does not agree
with. This means that defects could be caused by any number of problems:
-
Somebody does not believe that the planned behavior will satisfy the users’ or stakeholders’ needs
-
Somebody believes that those needs may be better satisfied with different behavior
-
An inspector does not understand what’s written, or feels that it is ambiguous or confusing
-
A project team member does not believe that the behavior can be implemented as written
-
Two or more requirements contradict each other—an implementation that satisfies one cannot satisfy the others
If there is a requirement in the SRS that has one of these problems, it
must be identified and fixed so that everyone agrees on everything in
the document. There will almost certainly be defects that slip
through—no inspection team is perfect—and each of these will cost much
more time to fix after they have been designed, coded and tested than
it would have if it had been caught using the SRS development script.
The goal is to find as many defects as possible, in order to reduce the
amount of time that the team must spend later on in the project undoing
the few that slipped past.
The following table contains the SRS development script:
|
Name
|
Software Requirements Specification Development Script
|
|
Purpose
|
To elicit software requirements, document them in a
software requirements specification, and verify that it is correct.
|
|
Summary
|
The development of the software requirements specification
should be the most iterative part of the entire project. This is the point
where the behavior of the software to be developed is at its most
malleable—it has only been described in words, and has not yet been realized
in design, architecture, code, test plans or any other work product. The goal
of this script is to ensure that as many defects are found as possible,
because each defect missed at this stage will be much more costly to detect
and fix later on in the project.
|
|
Work Products
|
Output
Software Requirements Specification (SRS)
|
|
Entry Criteria
|
A requirements analyst has a vision and scope document for
a project and has identified a set of users, stakeholders, and other people
who will participate in the elicitation process.
|
|
Basic Course of Events
|
- Elicitation:
The script begins with the elicitation process. The requirements analyst
works with users, stakeholders, and other people to elicit their needs
and any known requirements. If there are outstanding issues or SRS
defects, the analyst resolves them during the elicitation activities.
- Documentation:
The requirements analyst creates or updates the draft of the SRS to
reflect the data elicited in step 1.
- Verification:
A team of reviewers performs a review of the SRS draft. In the first
iteration, a small number of reviewers perform a deskcheck of the draft.
Later reviews will include more people, and may be inspections instead
of deskchecks. Walkthroughs should be conducted for non-technical people
who still need to understand the contents of the SRS. The last iteration
must be an inspection.
|
|
Exit Criteria
|
The script ends after the draft was inspected in step 3
and no defects were found. If defects were found or there was only a
deskcheck performed in step 3 then the script returns to step 1 for the next
iteration.
|
|
