Artifact:
Software Requirements Specification
Software
Requirements
Specification
|
The Software
Requirements Specification (SRS) captures the complete software requirements
for the system, or a portion of the system. When using use-case modeling,
this artifact consists of a package containing
use cases
of the
use-case model
and applicable
Supplementary
Specifications
.
|
Role:
|
Analyst
|
More
Information:
|
-
Checkpoints:Software Requirements Specification
-
Concepts: Requirements
-
Guidelines: SRS/Non-Functional Requirements
|
|
Templates, Case-Study, Report..
The Word template can be bought through a template package. Case studies and reports are freely available in the table below.
Word
Template
|
Case
Study
|
Report
|
|
|
---
|
Purpose
The Software Requirements Specification (SRS) focuses on the collection and
organization of all requirements surrounding your project.
Since you might find yourself with several different tools for collecting
these requirements, it is important to realize that the collection of
requirements may be found in several different artifacts and tools. For example,
you might find it appropriate to collect textual requirements such as
non-functional requirements, Design Constraints, etc, with a text documenting
tool in
Supplementary Specifications
. On the other
hand, you might find it useful to collect some (or all) of the functional
requirements in the
use cases
and you might find it
handy to use a tool appropriate to the needs of defining the
use-case
model
. For this reason, we will collect the requirements for our SRS in a
package which may be a single document or a collection of various artifacts that
describe the requirements. (See:
Guidelines:
Software Requirements Specification
)
The SRS package controls the evolution of the system throughout the
development phase of the project, as new features are added or modified to the
Vision document, they are elaborated within the SRS Package. The following
people use the Software Requirements Specification:
-
The
Analyst
creates and
maintains the
Vision
and
Supplementary
Specifications
, which serve as input to the SRS and are the
communication medium between the system analyst, the customer, and other
implementers. He also creates and maintains the individual
use case
and other
components of the SRS package
-
Designers
use the SRS Package as a
reference when defining responsibilities, operations, and attributes on
classes, and when adjusting classes to the implementation environment.
-
Implementers
refer to the SRS
Package for input when implementing classes.
-
The
Project Manager
refers to the
SRS Package for input when planning iterations.
Brief Outline
The Software Requirements Specification (SRS) captures
the complete software requirements for the system, or a portion of the system.
Following is a typical SRS outline for a project
using use-case modeling
.
This artifact consists of a package containing
use cases
of the
use-case model
and applicable
Supplementary
Specifications
and other supporting information.
Many different arrangements of an SRS are possible. Refer
to [IEEE830-1998] for further elaboration of these explanations, as well as
other options for SRS organization.
Timing
Software Requirements Specifications go hand-in-hand with the
use
cases
and
Supplementary Specifications
, implying
that:
-
They are initially considered in the
inception
phase, as a complement to defining the scope of the system.
-
They are refined in an incremental fashion during the
elaboration
and
construction
phases.
Responsibility
An
Analyst
is responsible for
producing the Software Requirements Specification (SRS), which is an
important complement to the use-case model. The SRS Package collects applicable
Supplementary
Specifications
and
use cases
of the
use-case
model
which together capture a complete set of requirements on the system or
a defined subsystem.
Tailoring
Many different arrangements of an SRS are possible. Refer to [IEEE93] for
further elaboration of these explanations, as well as other options for SRS
organization.
|