How to Write a Software Requirements Specification (SRS) Doc

Learn and understand What software requirements specifications are, their importance, and How to Write a Software Requirements Specification (SRS) Doc:

Software development teams are often enamored by the technical implementation details and managers by process implementation/maturity. Unless the team pays particular attention to understanding what we are building, who it is for, in what steps to achieve a certain goal, etc.

Before we start building the software, the sophisticated technology and/or process cannot rescue the software from its inadequacies.

Software Requirements Specification (SRS) Doc

Example situation: One evening an employee of a company calls asking why her insurance policy could not include her adopted son.

After several emails and frenzied phone calls, the realization hits that when the requirement was created the only life changes that caused adding or removing family members to the employee’s insurance policy were marriage, birth, death, employment/unemployment, and minor dependents becoming majors.

Adoption as a life event causing insurance changes was overlooked as a requirement, hence was not a feature of the insurance software. It’s not hard to imagine the employee’s reaction and the company’s frustration and feeling of inadequacy that followed.

If only, Software Requirement Specifications included this scenario, the fiasco could have been completely avoided.

What is a Software Requirement

A software requirement is a description of software behavior from a user’s perspective. It should be noted that the user may not always be the customer. Although most requirements are from a user’s point of view. Some are technical while others could be compliance oriented(for banking and other government systems.)

Formally, Software Requirements are defined as follows by Ian Sommerville and Pete Sawyer in their book Requirements Engineering: A Good Practice Guide, “Requirements are a specification of what should be implemented.

They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.

Types of Software Requirements

There are 4 main types of software requirements:

1. Functional
2. Business
3. User
4. Non-Functional

The book “Software Requirements” by Karl Wieger defines these requirements and their relationships(image) as follows:

1. Functional Requirement: A description of behavior that a system will exhibit under specific conditions.
2. Business Requirement: A high-level business objective of the organization that builds a product or of a customer who procures it.
3. User Requirement: A goal or task that specific classes of users must be able to perform with a system, or a desired product attribute.
4. Non-Functional Requirement: A description of a property or characteristic that a system must exhibit or a constraint that it must respect.

What is a Software Requirement Specification Document

A Software Requirement Specifications(SRS) document is an important project artefact that describes all the requirements (Functional, business, user, and nonfunctional) in detail so that they are clearly defined for further development, review, acceptance, and revision(if need be) by all the stakeholders of the software project.

Most waterfall projects have a dedicated phase during the software development life cycle to gather, analyze, prioritize, and finalize requirements. Agile projects too have a requirement-gathering phase; since the scope of each sprint is short, all the requirements to be implemented in a sprint are gathered and analyzed during the planning phase.

=> Click here to see how requirement gathering is carried out in SDLC.

Who Writes Software Requirements Specifications Documents

Business Analysts document software requirements after they gather the system inputs from all the stakeholders involved including the customers/users. They are usually proficient with how to write requirements for the software.

The SRS document is an important input for software development, technical architecture design, Software testing, project management, training, user manuals writing, etc.

For a quick glance at how the QA utilises SRS to devise test cases, check these articles:

• Writing Test Cases from SRS Document 
• Review SRS Document And Create Test Scenarios

The level of detail depends on the:

• The complexity of the system
• Available time and resources
• Involvement of stakeholders

If need be, there can be several different types of requirement documents created.

=> Click here to see a comprehensive list.

5 Characteristics of Good Software Requirements Specifications

Many aspects go into good system requirements specifications documents. Some of them are:

#1) Requirements have to be correct: It goes without saying that if we do not have correct requirements, we are going to build an incorrect product.

#2) Requirements have to be complete: Incomplete requirements waste time, create functionality gaps, and cause grave customer dissatisfaction.

#3) Requirements have to be feasible: We cannot expect a car to fly(as of 2023) so a requirement has to be assessed for feasibility irrespective of its originating source.

#4) Requirements have to be unambiguous: Clearer requirements mean clean objectives and a smooth sail when it comes to further development and design steps. Avoid and/or such as: enable search by name and/or DOB.

#5) Requirements have to be necessary: We can be ambitious but the software has to do things that are absolutely essential for the user and the business.

How to Write a Software Requirements Specification Document

When writing software requirements specifications document a keen focus on business, end users, and the technical implementation has to be kept in mind. Firstly, a series of interviews and Q&A sessions are held with all the stakeholders involved to understand the current state of the business and the expectations from the final software product.

Based on the outcome of this step, the requirements undergo further analysis. Secondly, the requirements are assessed to understand accuracy, feasibility, and priority among other things. Finally, the requirements undergo a review process with the stakeholder to ensure that all the stakeholders are on the same page.

The review can be a casual walkthrough or a more formal step-by-step evaluation. The outcome of this review can be that some requirements might be:

• Ranked so that the team can decide what areas to focus the team’s energies on
• Eliminated because they are not accepted as necessary, collectively
• “How-to” steps for different features might need to be changed and finalized
• Finalized requirements are approved for further stages
• For tougher requirements, a minimal POC might be decided to be carried out and validated

Most projects and teams may not go to this level of detail but all of the teams undergo this process in some capacity.

Their lifecycle might look something like this:

[image source]

A generic template for a requirement written from the system’s perspective is (Mavin et al. 2009):

[optional user] [optional precondition] [optional trigger event] the system shall [expected system response].

Software Requirement Specification Examples

The following are some samples of software requirement specifications. These are examples of what goes into section 3.X of the template provided in the next section:

• The system must permit search by a Purchase order number, bill number, and customer order number.
• If the Buyer’s payment card on file has expired, the system shall allow the customer to either update the current credit card information or enter a new credit card for payment.
• When a manager logs into the leave approval system, they shall see the leave requests submitted by their reportees on the home page dashboard.

Software Requirement Specifications Template

A comprehensive SRS document contains the following sections. Depending on the context, sections could be added or removed but generally speaking this is the outline followed by most software teams.

#1) Introduction

1.1 Purpose
1.2 Document conventions
1.3 Project scope – short description of the software being specified and its purpose.
1.4 References

Introduction section usually sets the context for the software project and/or the SRS document. The purpose of the document, the level of detail, the short forms and abbreviations that are going to be used, the outline, etc. are defined.

The project scope outlines what the project is about, who is going to use it, what problem it is going to solve, what is not in scope, the risks involved, etc.

#2) Overall description- a high-level overview of the product

2.1 Product Description and Goals
2.2 User Classes and Characteristics
2.3 Operating Environment: Describe the environment in which the system will operate
2.4 Design and Implementation Constraints: Programming language, cloud architecture to be used, etc.
2.5 Assumptions and Dependencies

This section goes into greater detail about the project features and its goals. At this stage, detailed goals are formulated. At this point, the requirements are from a business perspective. For example, it can list a requirement/goal as “the system shall provide controlled and secure access to all its users.” It does not go into system-level details.

For example, it does not talk about whether the secure access is going to be implemented using a simple login or multi-factor authentication or in some other way.

Also, the user level and the user-facing functionality and its elaboration using use cases is carried out in this step. For a quick look at what a use case might look like.

Please note this image is a screen capture from the very well-written SRS example document.

Some of the design and implementation details are also documented in this stage. Also important is to list out the assumptions and constraints so there is no ambiguity.

#3) System Features

3.x System feature X Name of the feature
3.x.1 Description
3.x.2 Functional requirements

We have already seen examples of how system features are documented in the section: Software Requirement Specification Examples:

#4) Data Requirements

4.1 Logical data model
4.2 Data dictionary
4.3 Reports
4.4 Data Acquisition, Integrity, Retention, and Disposal

The most important outcome of this step is designing the data. Consider an example feature, ‘The system shall provide a registration option for new users.’ This step will decide what data should be used using registration.

This is a super small scale and only gives you an idea, but this step takes considerable thought and effort.

#5) External Interface Requirements

5.1 User interfaces
5.2 Software interfaces
5.3 Hardware interfaces :
5.4 Communications interfaces

Look and feel, fonts to use, language, etc. are outlined in this section. Wireframes can be used to mock future pages. Sometimes a separate document outlining the colors, themes, and formats to be used is maintained depending on the need.

Other features such as interactions with other software systems, software components, tools, operations systems, etc. Interaction with hardware devices such as POS systems, barcode scanners, etc., and communication functions the product will use, including email, web browser, network protocols, and electronic forms are all listed and explained in this section.

#6) Quality Attributes: Record Nonfunctional Requirements

6.1 Usability Requirements
6.2 Performance Requirements
6.3 Security Requirements
6.4 Safety Requirements
6.5 Internationalisation and localization requirements
6.x [Others]

While there is no standard format or template for non-functional requirements, they can either be expressed as use cases in section 2 or system requirements listed in section 3.

• Performance requirements can look like this, “The system shall support up to 500 internal users at a given time while maintaining a 10-second response time to retrieve an artefact.”
• Example Usability requirements, the website will be both mobile and desktop compatible.
• Security requirements might look like this, “The system shall restrict registration with phone numbers without the United States country code.”

#7) [Other requirements]: Other requirements that are not covered elsewhere in the SRS. Examples are legal, regulatory, or financial compliance and standards requirements; etc.

To reiterate, a very well-written SRS example is here: https://www.cse.msu.edu/~cse435/Handouts/SRSExample-webapp.doc

Now that we know what software requirements are, how they are collected, the requirements lifecycle, and how to write a software requirements specification document, let’s look at some tips that can make your SRS document stand out.

Tips for an Effective Software Requirements Specification Document

• Don’t duplicate information.
• Use images when outlining complex business/user cases- flowcharts, use cases, context diagrams, mind maps, etc.
• Provide secure access to the document- read-only access vs. edit access.
• Use proper version control to track review and change history.
• Provide a glossary for abbreviations and other technical terminology used.
• For Agile projects or if you also use a requirement management tool such as JIRA, Micro Focus ALM, etc. provide hyperlinks to work items created.

Software Requirements Specification/Management Tools

Smaller scale teams might use MS Excel sheets, Google Sheets, or SmartSheet applications. However, with larger projects/teams they may need dedicated requirements management software. A simple spreadsheet used for requirements management can look like this:

Here are the three requirement management tools:

#1) Micro Focus ALM: One of the most prominent of the licensed enterprise requirements and test management tools out there. It has several important features like requirement definition, assignment, status tracking, and traceability features.

#2) JIRA: Atlassian JIRA is almost always part of most Agile teams and plays an important role in keeping all requirements/stories in a centralized place. Scrum/Kanban boards show an accurate status depiction, whereas integration with GitHub and Bitbucket lets you see the ensuing code changes/commits that originated from the requirement.

#3) Jama Software: Rated as the top ALM tool in 2019, Jama is a notable name in the world of requirements management. Support for requirement traceability with tests and risks is Jama’s key strength and is highly valued by many businesses and teams.

Other popular tools are:

• Visure
• SpiraTeam by Inflectra
• ReqSuite® RM
• Xebrio
• Process Street
• Visual Trace Spec
• IBM Rational DOORS
• Accompa
• Case Complete
• Katalon TestOps

=> Click here for more information on the most commonly used requirement management tools, their key features, and quick comparison.

Risks of Incomplete, Undefined, and Undocumented Requirements

The example in the introduction is just a needle in a haystack. Not taking time to properly gather, clearly define and document requirements is a recipe for disaster.

Cutting corners during the requirements gathering phase might seem like you are saving time and avoiding deeper effort, but the risks can be:

• Bugs later in the development process.
• All implementations are open for interpretation- developers will build the system based on their understanding, testers will create test cases based on their deciphering, etc.
• If working with implementation partners the agreement on terms of delivery and acceptance criteria becomes ambiguous.
• Schedule risks are huge too because UAT/Acceptance validation might fail due to the final product not behaving as expected.
• Team morale and working towards a common goal is jeopardized because each team in the SDLC has a different idea about what the ultimate goal is.

How to Measure Functional SRS Documents

Well, we need to define some standard tests to measure the requirements. Once each requirement is passed through these tests, you can evaluate and freeze the functional requirements.

Let’s take an example, you are working on a web-based application. The requirement is as follows: “Web application should be able to serve the user queries as early as possible”

How will you freeze the Requirement in this case?

What will be your Requirement Satisfaction criteria? To get the answer, ask this question to the stakeholders: How much response time is ok for you? If they say that they will accept the response if it’s within 2 seconds, then this is your requirement measure. Freeze this requirement and carry the same procedure for the next requirement too.

We just learned how to measure the requirements and freeze those in the Design, Implementation, and Testing phases.

Now let’s take another example: I was working on a Web-Based project. The client (stakeholders) specified the project requirements during the initial phase of the project development. My manager circulated all the requirements to the team for review. When we started the discussion on these requirements, we were just shocked!

Everyone was having his or her own conception of the requirements. We found a lot of ambiguities in the “terms” specified in the requirement documents, which later on were sent to the client for review/clarification.

The client used many ambiguous terms, which had many different meanings, thereby making it difficult for us to analyze the exact meaning. The next version of the requirement doc from the client was clear enough to freeze for the design phase.

From this example, we learned that the “Requirements should be clear and consistent”

The next criteria for testing the requirements specification is to “Discover missing requirements”, let’s take a look at it.

Discover Missing Requirements

Many times the project designers don’t get a clear idea about each specific module and they simply assume some requirements in the design phase. None of the requirements should be based on assumptions. Requirements should be complete, covering each and every aspect of the system under development.

Specifications should state both the types of requirements i.e., what the system should do and what it should not.

Generally, I use my own method to uncover unspecified requirements. When I read the Software Requirements Specification document (SRS), I note down my own understanding of the requirements that are specified, plus other requirements that the SRS document is supposed to cover.

This will help ask questions about the unspecified requirements thereby making it clearer.

To check the completeness of the requirements, divide the requirements into three sections: ‘Must implement’ requirements, requirements that are not specified but are ‘assumed’ and the third type is ‘imagination’ type of requirements. Check if all types of requirements are addressed before the software design phase.

Check if the Requirements are related to the Project goal

Sometimes stakeholders have their own expertise, which they expect to come into the system under development. They don’t even think about whether that requirement would be relevant to the project at hand. Make sure to identify such requirements.

Try avoiding all irrelevant requirements during the first phase of the project development cycle.

If not possible, then ask questions to stakeholders like why do you want to implement this specific requirement? This will describe that particular requirement in detail, thereby making it easier to design the system considering the future scope.

But how to decide whether the requirements are relevant or not?

The answer is simple. Set the project goal and ask this question: If not implementing this requirement will cause any problems in achieving our specified goal? If not, then this is an irrelevant requirement. Ask the stakeholders if they really want to implement these types of requirements.

In short, the Requirements Specification (SRS) doc should address the following:

• Project functionality (what should be done and what should not be done).
• Software & Hardware interfaces and the user interface.
• System Correctness, Security, and performance criteria.
• Implementation issues (risks) if any.

Conclusion

We hope this article provides you with an overall overview of what software requirements specifications are, their importance, and how to write good software requirements specifications documents.

“Requirements should be clear and specific with no uncertainty, requirements should be measurable in terms of specific values, requirements should be testable having some evaluation criteria for each requirement, and requirements should be complete, without any contradictions”

Testing should start during the requirement phase to avoid further requirement-related bugs. Communicate more and more with your stakeholders to clarify all the requirements before starting the project design and implementation.

This article borrows a lot of its ideas and concepts from these two books. Please read them if you would like to deepen your knowledge.

• “Software Requirements” by Karl Wieger
• “Requirements Engineering: A Good Practice Guide” by Ian Sommerville and Pete Sawyer

Finally, if you have any questions, feedback, and comments, please share them below with us.