<< Back to Requirements Management Home
Requirements Definition and Specification
A System Requirements Specification (SRS) (also known as a Software Requirements Specification) is
a document or set of documentation that describes the features and behavior of a system or software application.
It includes a variety of elements (see below) that attempts to define the intended functionality required by
the customer to satisfy their different users. In addition to specifying how the system should behave, the
specification also defines at a high-level the main business processes that will be supported, what simplifying
assumptions have been made and what key performance parameters will need to be met by the system.
Main Elements
Depending on the methodology employed (agile vs waterfall)
the level of formality and detail in the SRS will vary, but in general an SRS should include a description of the
functional requirements, system requirements, technical requirements, constraints, assumptions and acceptance criteria. Each of these is described in
more detail below:
-
Business Drivers - This section describes the reasons why the customer is looking to
build the system. The rationale for the new system is important as it will guide the decisions
made by the business analysts, system architects and developers. Another compelling reason for
documenting the business rationale behind the system is that the customer may change personnel
during the project. Documentation which clearly identifies the business reasons for the
system will help sustain support for a project if the original sponsor moves on.
The drivers may include both problems (reasons why the current systems/processes are not sufficient)
and opportunities (new business models that the system will make available). Usually a combination
of problems and opportunities are needed to provide motivation for a new system.
-
Business Model - This section describes the underlying business model of the customer
that the system will need to support. This includes such items as the organizational context,
current-state and future-state diagrams, business context, key business functions and
process flow diagrams. This section is usually created during the functional analysis phase.
-
Functional and System Requirements - This section usually consists of a hierarchical
organization of requirements, with the business/functional requirements at the highest-level
and the detailed system requirements listed as their child items. Generally the requirements
are written as statements such as "System needs the ability to do x" with supporting detail
and information included as necessary.
-
Business and System Use Cases - This section usually consists of a UML use case diagram that
illustrates the main external entities that will be interacting with the system together with the different
use cases (objectives) that they will need to carry out. For each use-case there will be formal definition
of the steps that need to be carried out to perform the business objective, together with any necessary
pre-conditions and post-conditions.
The business use cases are usually derived from the functional requirements and the system
use cases are usually derived from the system requirements.
-
Technical Requirements - This section is used to list any of the "non-functional" requirements
that essentially embody the
technical environment that the product needs to operate in, and include the technical constraints that it needs to
operate under. These technical requirements are critical in determining how the higher-level
functional requirements will get decomposed into the more specific system requirements.
-
System Qualities - This section is used to describe the "non-functional" requirements
that define the "quality" of the system. These items are often known as the "-ilities" because
most of them end in "ility". They included such items as: reliability, availability,
serviceability, security, scalability, maintainability. Unlike the functional requirements
(which are usually narrative in form),
the system qualities usually consist of tables of specific metrics that the system must meet to be accepted.
-
Constraints and Assumptions - This section will outline any design constraints that have been
imposed on the design of the system by the customer, thereby removing certain options from being
considered by the developers. Also this section will contain any assumptions that have been made by
the requirements engineering team when gathering and analyzing the requirements. If any of the assumptions
are found to be false, the system requirements specification would need to be re-evaluated to make sure
that the documented requirements are still valid.
-
Acceptance Criteria - This section will describe the criteria by which the customer will "sign-off"
on the final system. Depending on the methodology, this may happen at the end of the testing and quality
assurance phase, or in an agile methodology, at the end of each iteration. The criteria will usually
refer to the need to complete all user acceptance tests and the rectification of all defects/bugs
that meet a pre-determined priority or severity threshold.
Alternatives
In agile methodologies such as extreme programming or scrum
formal, static documentation such as a software requirements specification (SRS) are usually eschewed in favor
of a more lightweight documentation of the requirements, namely by means of user stories and acceptance tests.
This approach requires that the customer is easily accessible to provide clarification on the requirements during development
and also assumes that the team members responsible for writing the user stories with the customer will be the
developers building the system. A more formal approach may be needed if the customer is inaccessible and/or a separate
team of business analysts will be developing the requirements.
In Rapid Application Development (RAD) methodologies such as DSDM
or Unified Process (RUP, AUP) the requirements specification is often kept at a higher-level
with much of the detailed requirements embodied in prototypes and mockups of the planned system. These prototypes
are a more visual way to represent the requirements and help the customer more easily comprehend what is planned
(and therefore provide more timely feedback).