System Requirements Document

What is System Requirements Document?

System Requirements Document is also known as System Requirements Specifications. System requirements document is a set of documentation that describes the behavior and features of a software or system. It comprises of various elements that attempt to characterize the functionality needed by the client to satisfy their users. In other words, the system requirements document (SRD) describes the system-level performance and functional requirements for a system.

System Requirements Document or System Requirements Specification is defined as a document which defines what the software will do and how it will be required to perform, and it also defines the functionality the software needs to satisfy all stakeholders (users, business) requirements.

What is Included in a System Requirement Document?

While the SRD capacities as an outline for dealing with the extent of a project, it eventually characterizes the functional and non-functional requirements of the system. The document doesn't layout design or technology solutions. These decisions will be taken by the developers later.

The well-written system requirement document should:

Split the problem into manageable parts.
Notify design specifications i.e., SRD needs to comprise adequate information on software requirements to present an effective design.
Gives feedback to the customer or client.
For testing and validation, serve as a reference.

According to the IEEE standards, SRDs must cover the following important topics.

Quality
Security/Privacy
Functional capabilities
Safety
Performance levels
Constraints and Limitations
Data Structure/Elements
Reliability
Interfaces

Main Elements of System Requirements Document

Based on the procedure employed (Waterfall vs. agile), the degree of convention and detail in the SRS will differ, however in general, system requirement document or system requirement specification contains a description of the system requirements, functional requirements, technical requirements, acceptance criteria, assumptions and constraints. We have explained each of these in more detail below:

Constraints and Assumption

The constraints and assumption section will underline the lack of any design imposed by the client on the system design, resulting in removing some options from being considered by the developers. This section also comprises assumptions which are made by the team of requirement engineering at the time of requirements gathering and analysis. If there is an incorrect assumption, it is needed to re-evaluate the system requirements specification in order to ensure that the documented requirements are still valid.

Functional and System Requirements

This segment normally comprises a hierarchical arrangement of requirements, with the functional/business requirements at the uppermost level and the detailed system requirements are listed as their child items.

Mostly in the form of statements, the requirements are written like "System requires the capability to do x," with supporting information comprised as required.

Technical Requirements

This part is utilized to list any of the non-functional requirements, which basically personifies the technical environment that the product requires to work in and incorporate the technical limitations that it requires to work under. These technical requirements are important in deciding how high-level functional requirements can decompose into more definite system requirements.

Business Drivers

This part depicts the reasons why the client is hoping to build the system. The new system's rationale is significant because it will manage the choices made by business experts, engineers, and system architects. Another convincing purpose behind recording the business logic and behind the system is that during the project, client can change the staff. Documentation that absolutely recognizes the business explanations for the system will help to continue support the project if the original sponsor proceeds onward.

The drivers may comprise issues as well as opportunities. Generally, a mix of issues and opportunities are required to give inspiration to a new system.

System Qualities

The system qualities are the non-functional requirements which are used to define the system's quality. These qualities are frequently known as "ilities," and the reason behind that is many of these qualities end with "ility". They are comprised of items like availability, maintainability, security, reliability, and scalability.

Unlike functional requirements, the quality of the system generally contains tables of particular metrics that the system should meet to be acknowledged.

Business Models

This part portrays the fundamental business model of the client that the system will require to support. This contains current-state, future-state and organizational context state diagrams, key business functions, business context and process flow diagrams. This part is generally made during the functional analysis phase.

Acceptance Criteria

This part will portray the measures by which the client will "sign-off" the final system. Based on the procedure, this may occur toward the end of the testing and quality assurance stage, or in agile methodology, toward the finish of every iteration.

Usually, this measure refers to the requirement in order to complete all user acceptance tests and fix all bugs/defects which meet a pre-defined priority or severity limits.

Business and System Use Cases

This segment ordinarily comprises a UML use case diagram, which shows the main external entities that will collaborate with the system along with diverse use cases that should be met. There will be a formal definition of the steps for every use case which is required to fulfill the purpose of the business, along with the essential pre-conditions and post-conditions.

Generally, the system use cases are derived from the system requirements and the business use case is derived from the functional requirements. By using the flowchart, the steps of use cases are represented.

Characteristics of a Good System Requirements Document

There are various characteristics of good system requirements:

Completeness
Correctness
Modifiability
Consistency
Testability
Design independence
Understandable by the customer
Traceability
Verifiability
Unambiguousness

1. Completeness

The completeness of the system requirements specification or system requirements document shows each meaning of completion, together with the number of pages, that properly covers all the functional and non-functional requirements as well as resolving parts to the extent possible.

2. Correctness

The reviews of the users are used to make sure the accuracy of the requirements states in the system requirements document. The system requirements document is called true if it contains all the requirements which are really anticipated from the system.

3. Modifiability

The system requirements document should be modified as well as able to adapt changes to the system. Modifications must be appropriately indexed and cross-referenced.

4. Consistency

In the system requirements document, requirements are called consistent if in between any requirements, there is no conflict. Examples of conflicts: logical conflicts such as time period of the report generation, terminologies which are used at separate places, etc.

5. Testability

A system requirement document must be written in a manner which is simple to create test plans and test cases from the document.

6. Design Independence

For the final system, it must be an option to select from the different design alternatives. In particular, the system requirement document should not include any details regarding implementation.

7. Understandable by the Customer

An end-user possibly a specialist in his/her particular domain; however probably won't be a specialist in computer science. Thus, the utilization of formal notations and symbols must be avoided as much as possible. It is must that the language should be simple and clear.

8. Traceability

One must be capable to design a component in a program and then to detect a requirement for a code fragment. Similarly, one needs to be able to detect the need for related test cases.

9. Verifiability

A system requirements document is validated if, in the system requirements document, a particular technique is present in order to quantifiably measure the degree to which the system meets each requirement. For instance, a requirement expressing that the system should be easy to use isn't verifiable and listing such requirements must be dodged.

10. Unambiguousness

If each requirement in the system requirements document has only a single interpretation, then the system requirement document is unambiguous. If we want to avoid unambiguousness, we have to use some modeling techniques such as proper reviews, ER diagrams, buddy checks, etc.

Next TopicATM Abbreviation

← prev next →