What is a System Requirements Specification (SRS)?
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.
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
- Business Model
- Functional and System Requirements
- Business and System Use Cases
- Technical Requirements
- System Qualities
- Constraints and Assumptions
- Acceptance Criteria
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.
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.
The use cases steps can also be represented as a flowchart diagram:
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.
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.
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.
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).