How to Write Software Requirements Specification (SRS Document)

What is a SRS?

In simple terms, the SRS sets out the requirements that a software application must fulfill. This article aims to demonstrate how to write a software requirements specification. The document sets out the purpose of the application and the features that it should include. The application will precisely do what the project owner wants it to do by meeting all the requirements. No more, no less.  It's important both for internal teams and if the company works with third-party software development companies. Success is predicated on having a complete set of clear, unambiguous, coherent, and correct requirements. The process of producing a software requirements specification will support ensuring these success criteria are met. In some cases, an SRS might be included as part of an RFP to provide more detailed information about the specific requirements for a software product or service. In other cases, the SRS and RFP might be developed and used independently of each other if the RFP is more specific, e.g. ERP RFP - it requires two separate documents. Software requirements specifications can be abbreviated as SRS, but these can be confused with system requirements specifications. The latter defines the requirements for an entire system of which software may be a component part. In this article, we use SRS exclusively to refer to software requirements.

Who uses a SRS?

The SRS document establishes the framework for the software development project that sets out the instructions for all teams involved in the project. This includes:

1. Developers will use the SRS to design and implement software that meets the requirements.
2. Testers will use the requirements to define the testing necessary to verify the software requirements have been implemented and validate that customer requirements have been met.
3. Operations can use the document to establish operating processes and procedures for in-service deployment of the software.
4. Maintainers can use the document to establish maintenance processes and procedures following the in-service deployment of the software.
5. Quality Assurance can use it to validate that quality requirements have been met.
6. Project Management may use the number of requirements to estimate resourcing requirements and development timescales and use metrics of requirements implemented to monitor progress against plans and customer reporting.
7. Sales and Marketing may use the overview to create publicity materials and identify market opportunities. 
8. Senior Management may use the document to attract additional investment.

The software requirements specification document sets out these critical criteria for all teams ensures a consistent understanding and common end goals, vital for project success. This can be challenging when developers use terms that customers, users, or even their own managers cannot understand. Having a document that all stakeholders can comprehend and come away with precisely the same understanding of the requirements is the crucial goal of the SRS.

What should a SRS Include?

The contents of the SRS should comprise the following seven critical elements:

1. A clear definition of the software’s purpose, establishing what the software is intended to do:

• What is the software trying to achieve?
• Who will use the software in terms of demographics and abilities?
• How does the software fit into the broader landscape?
• What is the value proposition?
• What are the success criteria?

2. Unequivocal definitions of all of the product terminology included in product descriptions and requirements. These definitions must clearly and unambiguously characterize all the key terms. There must be a common understanding across the diverse project teams of the wording of the software requirements.

3. A product description defining what functionality is required for each of the interested parties that will interact with the software application. 

These parties typically include:

• Users
• Administrators
• Maintainers
• Third-Party Service Providers

4. A complete list of all the applicable assumptions, dependencies, and prerequisites identified during the discovery process that will constrain or affect the development process.

5. The requirements, the core of the software requirements specification document, broken down into:

• Functional requirements, establishing the required behavior of the software.
• Non-functional requirements, defining technologies, infrastructure, performance, scalability, quality attributes, and other non-behavioral requirements.
• User requirements, use cases establishing how users will interact with the software and intended user interface experience.
• Interface requirements, detailing how the software will interact with any hardware, firmware, or third-party software functions, including temporal constraints.

For more detailed information on requirement types, refer to our blog on functional requirements vs non-functional requirements.

6. Software acceptance conditions, defining how the developed software is required to be validated against its requirements, conscious of the project owner’s goals. For more detailed information, refer to our blog on acceptance criteria.

7. The traceability from each software requirement to its source customer requirement demonstrates all of the customer’s business requirements are represented by one or more software requirements. This also facilitates efficient and effective change management and regression testing analysis if the customer introduces changes to their requirements. Traceability will identify which software functions will be affected, simplify the change process, and accurately estimate the effort required.

Writing a Great SRS

The output of the discovery phase is a set of key deliverables that underpin the development phases. 

A complete and comprehensive collection of project discovery phase deliverables will make development quicker and more straightforward, reducing the risk of show-stopping issues and functionality gaps.

1. The SRS should provide the customer with the assurance that their business needs have been correctly understood. It should be clear that these needs are encompassed in their entirety into the software requirements, and these needs will be addressed.
2. The SRS should be understandable, necessitating the use of natural language in place of any mathematical-based notation. However, the SRS should be precise and unambiguous, which limits how the language is used. Balancing understandability with unambiguity is a challenge.
3. The SRS should decompose complex problems into compartmentalized solutions that can be prioritized and managed using agile development techniques.
4. The SRS should provide a solid foundation for the development lifecycle, supporting the design, test, and assurance processes.

The key characteristics that make an excellent SRS are:

1. Completeness, all requirements have been identified and documented, with every customer requirement being represented by one or more software requirements. All assumptions are defined and validated, all dependencies and prerequisites identified and satisfied.
2. Correctness, all requirements are valid and meet the intent of the overall customer requirements.
3. Coherence, all requirements complement each other with no conflicts caused by contradictions between individual requirements.
4. Unambiguity, all requirements are clearly defined using agreed terminology with no room for misinterpretation.
5. Implementation agnostic, the specification of requirements should not impose architectural or technological solutions or specify a design methodology, development process, or coding language.
6. Maintainability, changes to customer requirements during the development process can be managed in such a manner as to minimize disruption and enable efficient redirection of development activities.
7. Accountability, change control records are kept to monitor why changes are made and who authorized the changes, allowing roll-back in the event of unintended consequences or exploration of alternate solutions.
8. Traceability, a clear relationship from customer requirements through to software requirements, will facilitate validation processes, demonstrate completeness, and support change management processes and regression testing following changes to customer requirements.

Writing Effective Requirements

All requirements must be easy to read and understand to be effective. They must define a subject and include a predicate: a condition, action, or result. For example, “The Software must display Local Time to the User.“ Here the predicate is displaying time. The predicate must be:

• Feasible
• Necessary
• Unambiguous
• Testable

The text used should also define the nature of the predicate, for example:

• Shall, will, and must are mandatory requirements
• May and should are optional requirements

The following are examples of well-written requirements:

“The Software shall allow the User to access their Unread Messages in less than three seconds.”

“The software shall indicate to the user that the transaction was successfully completed.”

• The software is the subject
• The access of unread messages and an indication of successful transactions are the predicates
• Overall, both requirements are testable

By contrast, the following are examples of poorly written variants of these requirements:

“The User may access their Unread Messages quickly using a Smartphone.”

“The user should receive a friendly email or other message types that confirms the transaction.”

• The user is the subject, but requirements cannot be placed on the user, only the software
• Quickly and user-friendly are subjective terms that are untestable
• The references to smartphones and emails are imposing predefined solutions
• The “or other message types” wording is ambiguous and untestable
• The use of “may” and “should” implies that the requirements are not mandatory

Other common problems include multiple conditions in one sentence when a good requirement should contain a single predicate-based statement. The following example comprises numerous requirements that are each too general in nature in that they do not precisely specify what the business need is or what the user requirements are:

“The software shall allow the user to contact a help desk using live chat and contact forms, providing issue tracking and case management functions.”

Each requirement will need to include an indication of its priority to assist development activities. It will also need a unique identifier to support traceability, both upwards to the customer requirements to demonstrate completeness and downwards to design and test documents to support quality control and change management processes.

Approval Process

The completed SRS will drive the development process as well as the verification and validation activities. Any error in the SRS will carry through the development process and into the implemented software. Furthermore, testing activities defined using the SRS and undertaken to verify the software will not identify such errors. Any errors will only be determined when the implemented software is found not to meet the customer’s original requirements at final product acceptance testing. Identifying fundamental mistakes in the validation phase are costly to resolve, effectively requiring entire vertical elements of the development process to be repeated. Therefore, all stakeholders must review the SRS thoroughly as a formal acceptance process before development work commences.

Bottom Line

The SRS is a vital document for the software development process.It underpins the development and provides a shared understanding and route map for all stakeholders. It details precisely what the software should do and determines the point in development when this has been achieved. The requirements must be complete, clear, unambiguous, coherent, and correct. The SRS will facilitate achieving these goals by:

• Providing the development team with a clear understanding of what exactly the customer wants
• Providing the customer with the assurance that the software will do what they want it to do
• Communicating all necessary information relating to the software to all interested stakeholders in terms they understand
• Characterizing users and defining user stories as implementable requirements
• Characterizing the required software behavior under all conditions and environments
• Providing the foundation for software testing activities
• Developing the outputs of the discovery phase and further scrutinizing possible risks

We hope you now know how to write a software requirements specification and appreciate how the effort expended will be rewarded with development process efficiencies, reduced development risks, and improved program success rates. At Enkonix we always provide the best quality and maximum transparency for our customers. Drop us a line and get a free detailed estimation for any of your projects.