What is SRS document?

25 April 2017   |   Startup, Blogs
Understanding the meaning of SRS document

IEEE defines software requirements specification as, 'a document that clearly and precisely describes each of the essential requirements (functions, performance, design constraints and quality attributes) of the software and the external interfaces. Each requirement is defined in such a way that its achievement can be objectively verified by a prescribed method, for example, inspection, demonstration, analysis or test.' Note that requirements specification can be in the form of a written document, a mathematical model, a collection of graphical models, a prototype, and so on.

Essentially, what passes from requirements analysis activity to the specification activity is the knowledge acquired about the system. The need for maintaining a requirements document is that the modeling activity essentially focuses on the problem structure and not its structural behavior. While in SRS, performance constraints, design constraints, and standard compliance recovery are clearly specified. This information helps in developing a proper design of the system. Various other purposes served by SRS are listed below.

Feedback: Provides a feedback, which ensures to the user that the organization (which develops the software) understands the issues or problems to be solved and the software behavior necessary to address those problems. Decompose problem into components: Organizes the information and divides the problem into its component parts in an orderly manner.

Validation: Uses validation strategies applied to the requirements to acknowledge that requirements are stated properly.

Input to design: Contains sufficient detail in the functional system requirements to devise a design solution. Basis for agreement between the user and the organization: Provides a complete description of the functions to be performed by the system. In addition, it helps the users to determine whether the specified requirements are accomplished.

Reduce the development effort: Enables developers to consider user requirements before the designing of the system commences. As a result, 'rework' and inconsistencies in the later stages can be reduced.

Estimating costs and schedules: Determines the requirements of the system and thus enables the developer to have a 'rough' estimate of the total cost and schedule of the project. SRS is used by various individuals in the organization. System customers need SRS to specify and verify whether requirements meet the desired needs. In addition, SRS enables the managers to plan for the system development processes. System engineers need a requirements document to understand what system is to be developed. These engineers also require this document to develop validation tests for the required system. Lastly, requirements document is needed by system maintenance engineers to use the requirement and the relationship between its parts.

The requirements document has diverse users. Therefore, along with communicating the requirements to the users it also has to define the requirements in precise detail for developers and testers. In addition it should also include information about possible changes in the system, which can help system designers avoid restricted decisions on design. SRS also helps maintenance engineers to adapt the system to new requirements.

Characteristics of SRS

Software requirements specification should be accurate, complete, efficient, and of high quality, so that it does not affect the entire project plan. An SRS is said to be of high quality when the developer and user easily understand the prepared document. Other characteristics of SRS are discussed below.
1. Correct: SRS is correct when all user requirements are stated in the requirements document. The stated requirements should be according to the desired system. This implies that each requirement is examined to ensure that it (SRS) represents user requirements. Note that there is no specified tool or procedure to assure the correctness of SRS. Correctness ensures that all specified requirements are performed correctly.
2. Unambiguous: SRS is unambiguous when every stated requirement has only one interpretation. This implies that each requirement is uniquely interpreted. In case there is a term used with multiple meanings, the requirements document should specify the meanings in the SRS so that it is clear and easy to understand.
3. Complete: SRS is complete when the requirements clearly define what the software is required to do. This includes all the requirements related to performance, design and functionality.
4. Ranked for importance/stability: All requirements are not equally important, hence each requirement is identified to make differences among other requirements. For this, it is essential to clearly identify each requirement. Stability implies the probability of changes in the requirement in future.
5. Modifiable: The requirements of the user can change, hence requirements document should be created in such a manner that those changes can be modified easily, consistently maintaining the structure and style of the SRS.
6. Traceable: SRS is traceable when the source of each requirement is clear and facilitates the reference of each requirement in future. For this, forward tracing and backward tracing are used. Forward tracing implies that each requirement should be traceable to design and code elements. Backward tracing implies defining each requirement explicitly referencing its source.
7. Verifiable: SRS is verifiable when the specified requirements can be verified with a cost-effective process to check whether the final software meets those requirements. The requirements are verified with the help of reviews. Note that unambiguity is essential for verifiability.
8. Consistent: SRS is consistent when the subsets of individual requirements defined do not conflict with each other. For example, there can be a case when different requirements can use different terms to refer to the same object. There can be logical or temporal conflicts between the specified requirements and some requirements whose logical or temporal characteristics are not satisfied. For instance, a requirement states that an event 'a' is to occur before another event 'b'. But then another set of requirements states (directly or indirectly by transitivity) that event 'b' should occur before event 'a'.

How to write an SRS documentHere are five steps you can follow to write an effective SRS document.

1. Create an outline

Your first step is to create an outline for your software requirements specification. This may be something you create yourself. Or you may use an existing SRS template. If you’re creating this yourself, here’s what your outline might look like:
1. Introduction
   1.1 Purpose
   1.2 Intended Audience
   1.3 Intended Use
   1.4 Scope
   1.5 Definitions and Acronyms
2. Overall Description
   2.1 User Needs
   2.2 Assumptions and Dependencies
3. System Features and Requirements
   3.1 Functional Requirements
   3.2 External Interface Requirements
   3.3 System Features
   3.4 Nonfunctional Requirements
Once you have your basic outline, you’re ready to start filling it out.

2. Start With a Purpose

The introduction to your SRS is very important. It sets the expectation for the product you’re building. So, start by defining the purpose of your product.
Intended Audience and Intended Use
Define who in your organization will have access to the SRS — and how they should use it. This may include developers, testers, and project managers. It could also include stakeholders in other departments, including leadership teams, sales, and marketing.
Product Scope
Describe the software being specified. And include benefits, objectives, and goals. This should relate to overall business goals, especially if teams outside of development will have access to the SRS.
Definitions and Acronyms
It’s smart to include a risk definition. Avoiding risk is top-of-mind for many developers — especially those working on safety-critical development teams.
Here’s an example. If you’re creating a medical device, the risk might be the device fails and causes a fatality. By defining that risk up front, it’s easier to determine the specific requirements you’ll need to mitigate it.

3. Give an Overview of What You’ll Build

Your next step is to give a description of what you’re going to build. Is it an update to an existing product? Is it a new product? Is it an add-on to a product you’ve already created? These are important to describe upfront, so everyone knows what you’re building. You should also describe why you’re building it and who it’s for.
User Needs
User needs — or user classes and characteristics — are critical. You’ll need to define who is going to use the product and how. You’ll have primary and secondary users who will use the product on a regular basis. You may also need to define the needs of a separate buyer of the product (who may not be a primary/secondary user). And, for example, if you’re building a medical device, you’ll need to describe the patient’s needs.
Assumptions and Dependencies
There might be factors that impact your ability to fulfill the requirements outlined in your SRS. What are those factors? Are there any assumptions you’re making with the SRS that could turn out to be false? You should include those here, as well. Finally, you should note if your project is dependent on any external factors. This might include software components you’re reusing from another project.

4. Detail Your Specific Requirements

The next section is key for your development team. This is where you detail the specific requirements for building your product.
Functional Requirements
Functional requirements are essential to building your product.If you’re developing a medical device, these requirements may include infusion and battery. And within these functional requirements, you may have a subset of risks and requirements.
External Interface Requirements
External interface requirements are types of functional requirements. They’re important for embedded systems. And they outline how your product will interface with other components. There are several types of interfaces you may have requirements for, including, user, hardware, software, communications.
System Features
System features are types of functional requirements. These are features that are required in order for a system to function.
Other Nonfunctional Requirements
Nonfunctional requirements can be just as important as functional ones. These include performance, safety, security, quality. The importance of this type of requirement may vary depending on your industry. Safety requirements, for example, will be critical in the medical device industry.

5. Get Approval for the SRS

Once you’ve completed the SRS, you’ll need to get it approved by key stakeholders. And everyone should be reviewing the latest version of the document.