Artifacts > Requirements Artifact Set > 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

Input to Activities:
  • Detail a Use-Case






Templates, Case-Study, Report.. To top of page

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 To top of page

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 To top of page

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 To top of page

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 To top of page

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 To top of page

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.

Feedback © 2014 Polytechnique Montreal