What are System Requirements?

First, let’s start with the basics. System requirements are the minimum and/or maximum hardware and software specifications that a system or application must meet in order to function properly. In order to determine the system requirements for a particular system or application, it’s important to carefully analyze the functional and non-functional requirements of the system or application, and to identify any constraints or other factors that may affect its performance.

What is SRS?

When it comes to applying this to software development, we get SRS. System Requirements Specification (SRS), also known as Software Requirements Specification, is a document or set of documentation that describes the features and behavior of a software application. It includes a variety of elements (see below) that attempt 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.

Why use SRS documents?

The importance of SRS documents lies in their impact on the planning stages of software development. The primary reasons for their use are:

• Clearly and accurately define the requirements for a system or application.

  System requirement documents provide a detailed description of what the system or application should do, how it should behave, and the constraints and other factors that it must satisfy. This helps to ensure that the system or application is developed to meet the needs of the user or client.

• Serve as a reference point throughout the development process.

  This documentation also provides a detailed description of the requirements for a system or application, which can be used as a reference point throughout the development process

  to verify that the system or application is being built according to the planned requirements.

• Facilitate communication and collaboration among team members.

  SRS documents provide a common language and set of terms that can be used by all team members to discuss and agree on the requirements for a system or application. This can help to improve communication and collaboration among team members, and to avoid misunderstandings or disagreements.

• Help ensure that the system or application is developed in a cost-effective manner.

  SRS documents provide a detailed description of the requirements for a system or application, which can help to identify potential challenges or problems early in the development process. This improves initial planning, particularly around making sure that the system or application is developed in a cost-effective manner, which will reduce the risk of costly reworks or changes later on.

Overall, SRS documents are an important tool for defining and documenting the requirements for a system or application, as well as confirming that the system or application is developed to meet the needs of the user or client.

How to Write a System Requirements Document

A system requirements document (SRD) is a record that outlines the functional and non-functional requirements required for a system. This is used to provide a clear and detailed description of the system, and is an important tool for affirming that the system meets the needs of all stakeholders.

The main steps in writing an SRD for your project should follow:

• Identify the purpose of the system and the stakeholders who will be using it.

  This will help you understand the goals and needs of the system, and it will ensure that the

  requirements you include in the SRD are relevant to the stakeholders

  .

• Create a list of functional requirements for the system.

  These are the specific actions or capabilities that the system must be able to perform. For example, if the system is a website, the functional requirements might include the ability to create an account, log in, and search for products.

• Create a list of non-functional requirements for the system.

  These are the requirements that define the quality or performance of the system, rather than its specific capabilities. For example, the non-functional requirements for a website might include response time, uptime, and security.

• Organize the requirements

  into categories or sections

  , and provide a detailed description of each requirement. This will keep the SRD organized and easy to read for anyone involved in the project.

• Review the SRD with the stakeholders

  to confirm that it accurately reflects their needs and that all of the requirements are clearly defined.

• Update the SRD as needed throughout the development process

  to reflect any changes or additions to the requirements.

Main Elements

• Depending on the

  methodology employed

  (

  agile

  vs.

  traditional waterfall

  ), the level of formality and detail in the SRS will vary. However, 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

These 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 is needed to provide motivation for a new system.

Business Model

The next 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

Moving on, the functional and system requirements part of the SRD usually consists of a hierarchical organization of requirements. This is organized 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

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:

Technical Requirements

Following that, this portion of the SRD is used to list any of the non-functional requirements that embody the technical environment that the product needs to operate in. This also includes 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, and 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

Relatively self-explanatory, here you 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. This section will also 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

One of the final sections of the document, here is where the criteria by which the customer will “sign off” on the final system are described. 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 these software requirements specifications are usually eschewed in favor of 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. In addition, it assumes that the team members responsible for writing the user stories with the customer will also 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).

Improve Your SRS Process Today

Inflectra offers software that can streamline your entire development process, including the requirement specifications stage. Not only does it help you identify requirements and organize them, but requirements traceability features allow you to stay on top of any that might have fallen through the cracks. For a comprehensive, out-of-the-box solution for all of your software development, testing, and lifecycle management needs, try a free 30-day trial of SpiraTeam below!