How to Write Software Requirement Specifications in Agile

There seems to be an underlying assumption that Agile teams work without a specification as they embrace change and focus on delivering quick turnarounds on the product rather than extensive documentation.

Well, that is not true. Agile projects still require structure, and vague assumptions cannot be used to implement critical functionalities.

This is where SRS comes into play. Software Requirements Specification (SRS) in Agile is a dynamic collection of requirements that evolve with the project. Compared to traditional development methods, it is flexible and iterative.

What is Software Requirements Specification (SRS)?

Software Requirements Specification (SRS) is a document that details the functionality of the software and its expected behavior as well. In essence, it describes how the software will provide value, through its functionality, for all the stakeholders involved.

The SRS document can be said to fulfill four D’s –

• Define what the product’s purpose is
• Describe the product being built
• Detail the system and the user requirements
• Deliver it to stakeholders for their approval

The optimal SRS document seeks to define the entire scope of how the software product interacts with the hardware and other embedded third-party systems/architecture and even take into consideration some amount of real-life human interaction and interaction between users.

What are Agile Software Requirements?

Agile software requirements are the essential requirements or conditions that a product must meet in such a way that supports agile development practices. They are flexible and adaptable, and thus enable iterative updates on feedback.

Why is an SRS important for Agile?

Let’s say an Agile team needs to create a chat application with a defined UI and functionality, catering to enterprises rather than individual customers. 

This can be quite an undertaking, and some of it may have to be outsourced in order to get the product launched in time. Given the increase in remote work and globally dispersed teams, it’s important for all the stakeholders to know exactly what needs to be done so that it can be completed in an optimal time and cost scenario. 

Without sufficient clarity and visibility, people working on individual epics can easily lose track of the bigger picture and things can get out of hand. Every wrong decision ends up causing roadblocks and slows down your entire CI/CD pipeline as people keep reworking on components they thought worked perfectly fine as a unit.

The SRS Document helps put the larger idea on paper and cover all the bases in a language that is understandable by the Business team, the Development team, and the QA team. This also matches the picture the client had in mind and ensures that the Three Amigos work in sync to deliver the exact product required.

Source

The SRS document allows all of these ideas to be committed to paper in great detail and helps empower communication between testers and developers. 

This also helps the clients estimate the overall cost of delivering the work and the entire scope of the project to be covered. 

• For designers, it helps them with insights on how their use cases can match the design outlined in the SRS.
• QA personnel get an understanding of the test suites required to be built in order to ensure that the product satisfies all business requirements.
• The End-user journey is clarified and guideline documentation is created based on the SRS’s description of how the end-users will interact with the product.
• Investors can get an overview of the system features to make informed decisions on further investment avenues.

Thus, a crisp SRS Document can be the single source of information and help manage expectations between all Agile stakeholders.

Components of Software Requirements Specification (SRS)

The SRS should contain enough details for software developers to create the intended finished product described. It should describe the technical composition of the software under development and the purpose of said software and how its performance will impact the stakeholders.

Typically it consists of –

• An outline of the purpose the software is meant to serve.
• A general description of the software itself.
• The details of the functionality of the software are based on the needs of the stakeholders.
• The required performance of the software in a production scenario.
• The non-functional requirements to be covered as part of stakeholder expectations.
• The interaction of the software with external interfaces like hardware and/or third-party systems.
• The limitations of the product are based on the design constraints and the environment that it operates.

How to write Software Requirements Specification (SRS in Agile)

Step 1. Create an Outline

Agile software development methodologies do not stress on heavy documentation. They instead focus on getting “production ready” software delivered as quickly as possible. In such cases, it is imperative to not beat around the bush and settle on an outline that can be acceptable to the entire stakeholder panel. 

Given the closely coupled work culture in Agile teams, the outline should cover all the bases for the stakeholders to be able to come on the same page. 

Generally, there are templates available, but if a team starts from scratch then the following can be used –

• Introduction
• Purpose
• Intended Audience
• Intended Use
• Scope
• Definitions
• Overall Description
• User Needs
• Assumptions and Dependencies
• System Features and Requirements
  • Functional Requirements
  • External Interface Requirements
  • System Features
  • Non-functional Requirements

Step 2. Define the purpose of the document

Agile teams generally work in short sprints of 1-2 weeks. Each sprint has a set number of user stories picked from a set of larger concerns known as epics. 

This language needs to be consistent when describing the purpose of the document. The scope of the project, the value it will deliver, the expected end users, and the value proposition for each of them need to be outlined in these terms.

The more precise this commentary, the easier it is to break up the purpose into achievable tasks and prioritize them.

Step 3. Define the intended audience

The core of any agile project is the User Story. The user story is the smallest item of work in the Agile framework which describes the end goal from a particular user’s perspective. 

Agile believes in putting people first, and the user story allows development to be user-centric. The stories are generally non-technical and they provide a larger context for the Dev and QA teams.

A Shopping Mart app may have different user stories based on the different audience cohorts. For example – a set of stories for online customers, a set for merchandise retailers, and a set for site administrators. 

It’s important to get this context clearly sorted in the SRS for development to take place.

Step 4. Understand the intended use for the audience

A user story is usually documented in terms of “As a [persona], I [want to], [so that].” Once we have defined the different user personas, the SRS needs to make the unique value proposition clear to the engineering team.

Taking the same example of a shopping mart forward, a general online user would want to use it to make purchases, while a retailer would want to showcase their products. Both user personas have different uses for the app and these must be clearly laid out.

Step 5. Scope

Once the user personas and the use of the product for these personas have been defined it is important to understand the scope to which the product satisfies their requirements.

Unlike conventional waterfall models, the agile process hinges on short development sprints and often the end goal is tangibly achieved after several sprints. In such cases, it is important to create User Acceptance Criteria to define the scope of the product.

Dean Leffingwell defines acceptance criteria as the “conditions of satisfaction “ placed on the system. These are written from the standpoint of a user. If all the user acceptance criteria are met for a particular story then it is deemed to have worked as expected.

This is important for shift-left testing as the QA team can create test suites based on this structure and the dev teams can create tasks for these user stories which lead to the satisfaction of the user acceptance criteria.

Step 6. Definitions

Apart from defining commonly used acronyms to prevent widespread confusion, the risks in the project need to be defined as well. It is an important aspect of Test Coverage, known as Risk Coverage and the mitigation policies for these risks need to be put into place as well. The priority, severity, and occurrence probability of these risks need to be considered while writing this section of the SRS.

Step 7. Overall Description

The Agile development methodology uses techniques like Kanban and Scrum to track project progress. Scrum adds user stories to “sprints” and “burn them down” over the duration of the sprint.

Kanban teams assign a certain number of user stories to a “backlog” and then complete them based on prioritization in their workflow. 

This is critical for forecasting project timelines and for sprint planning. 

User Stories are also used as building blocks of larger agile framework elements like epics and initiatives. Epics are larger work items based on a theme, and initiatives are derived from organizational Goals and Objectives.

Step 8. Assumptions and Dependencies

As opposed to conventional methods of development, the ideas obtained from the client are shared to the product owner and the software engineering teams. This requires the entire team to have an understanding of any assumptions made based on any existing systems or limitations of these systems.

Also, any legacy systems or third-party structures required for the project to be completed need to be enlisted in order to better integrate with them and perform better system integration testing. 

Step 9. System Features and Requirements

Once the detailing of the functionalities from the user viewpoint has been completed, it is important to document –

• Functional requirements: Comprising the core functionality of the system in technical terms
• External User Interface requirements: Based on the needs of both front-end and back-end components
• Non-functional requirements: Including performance calibration, safety and security attributes, and other Quality standards needing to be adhered to.

The flexibility of Agile processes allows the scope of the project to be changed mid-development. This prevents a ground-up rework and makes the project more flexible to a shifting landscape. 

Once the product owner understands the user requirements from the client, and the backlog of items has been completed, they are prioritized as per sprint points or models like the RICE or MoSCoW models.

The SRS is fleshed out to the maximum extent that it can at the beginning, based on the information available, and it is modified as the project goes on based on any new developments or changes in scope.

Talk to an Expert

Types of Agile Software Requirements

Here are the key types and characteristics of Agile requirements:

• User Stories: User stories talk about small actionable goals from the user’s perspective.
  Example: The format would be, As a [type of user], I want [action] so that [benefit]. This can translate into – As a user, I want to view product demos so that I can make the right decision.
• Epics: These are high-level requirements that refer to larger features/functionalities. Epics consist of multiple user stories.
  Example: An epic like ‘Purchase’ could include user stories like viewing the cart and adding items.
• Acceptance Criteria: These are conditions that describe when a requirement is considered complete and working as needed.
  Example: One of the acceptance criteria for a login feature can be “user can log in with a password and email.”
• Non-functional Requirements (NFRs): They define how well a solution should run. NFRs are closely associated with quality attributes like performance, scalability and security.
  Example: “The app should support 100 users simultaneously.”
• Technical Requirements: Technical requirements refer to the part of the system that is not visible to the user but are deciding factor when it comes to functionality.
  Example: “ Build a cloud infrastructure to promote scalability”
• Definition of Done (DoD): Agile teams make use of a checklist called Definition of Done to ensure that all quality standards and requirements are fulfilled before marking a feature as complete.

Conclusion

Since an Agile SRS is much more in-line with the “people first” and “Working software is the primary measure of progress” philosophy of Agile it is far more responsive to any required changes and can incorporate those without needing a complete overhaul.

In general Agile development requires teams to test their product thoroughly before closing off every sprint and this involves cross browser testing to ensure that the product works seamlessly across all available options.

BrowserStack leverages a cloud Selenium grid of 3500+ real browsers and devices optimized for automation testing in an Agile scenario. It also allows integrations with most industry-standard CI/CD tools to boost Agile development methods with the streamlining power of DevOps.

Try BrowserStack for Free