When all members of the IT team speak the same language, the chances of a successful software product rapidly increase. Achieving mutual understanding between QA engineers, project managers, and engineers is possible through the use of BDD practices.
Simple syntax of the Gherkin language is available to all stakeholders, which provides transparency of work with software requirements specifications (SRS, using abbreviation to terminology). In this case, the SRS document has its own characteristics, as there is an emphasis on flexibility and adaptability.
What is SRS in testing, and why is it important for Agile?
Stakeholders with different IT backgrounds are involved in SDLC, so one of the main problems is related to communication. For example, the management team (PM, BA, PO) could not describe the use cases in detail, causing the specialist in software engineering to misunderstand the scope of a feature. Not surprisingly, the result will not meet the expectations of the user.
On this basis, the SRS document in Agile projects is focused on the flexibility of all major and related processes (in contrast to Waterfall, V-Models).
That there is no need for an SRS document in Agile is a misconception. In fact, the methodology does not imply a rejection of documentation but only an emphasis on efficiency, adaptability, and collaborative use. Thus, the documentation created for technical implementers should be understandable to all your team members. The BDD approach provides a mutual understanding between the participants at the expense of Gherkin language. It considers what tasks the end user and representative of the intended audience seek to solve.
What goals SRS document is required for agile projects?
- Definition of the purpose and goal of the software system.
- Description of the product to be developed.
- Specification of the solution and user requirements.
- Clarification of external interface requirements.
- Analysis of constraints, e.g., design constraints.
- Demonstration to stakeholders for approval.
The SRS are able to show the whole picture of the project. It differs from other documents created before the performers start the tasks: the RFP and the brief. In the first case, it is about the plans and ideas to be implemented. Simply put, the management team collects information from the client and makes it the starting point for the work.
The brief is created by the client, providing the performers with essential details, such as priority system features, the estimated cost, and some technical issues for development. Naturally, if an RFP is prepared, there is no need for a brief.
The SRS document is more comprehensive. It contains technical and non-technical details in all areas related to the project. Specific requirements are of importance to specialists in different areas and, in some cases, even to investors.
Requirements specification VS requirements definition
Software requirement specifications are important for:
- Designers: getting an idea of implementing use cases according to the client’s design expectations.
- QA engineers: understanding what test suites and test cases need to be created to test the solution against the original expectations.
- Investors: an opportunity to explore the benefits to decide on the feasibility of investing.
- Developers: they should know what to do.
In addition, it has importance in the construction of the user path. It then serves as the basis for recommendations on how the end user interacts with the product. Thus, the SRS can act as a single source of truth for different parties.
As a rule, it includes 3 types of software requirements, which provide a deeper and more comprehensive understanding of the features.
How are the software requirements collected?
The business analyst and system architects are responsible for collecting, organizing, and analyzing requirements. Specialists constantly communicate with each other and the customer to achieve maximum accuracy of each software requirement specification, thereby facilitating the further construction of an agile project plan.
At the of working out software requirements, the following methods with proven effectiveness are practiced:
- Brainstorming: meetings where each person organizes ideas and selects the best solutions for the software requirements specification.
- User interviews: discussions with the client or potential users to clarify functional priorities and requirements.
- Mind mapping: creating a visual map showing the interaction of key components, considering the hierarchy.
- Document analysis: access to overall business goals and other data for detailed review.
- Mapping: working together with cards to better understand user stories.
- Use cases: thinking about user interactions with a digital product.
- Three Amigo Sessions: project discussion with a product owner, developer, and QA engineer.
The work starts with collecting and comprehending general information about the project and continues with the addition of important details that help specify the software requirements. The resulting data becomes the basis for writing a detailed software requirement specification document.
How to write requirements for software?
When the software requirements have been collected and analyzed, you start creating the document according to the plan. You can create an SRS outline yourself or use a pre-prepared SRS template. Although its structure is not standardized, there are mandatory sections that you should add to the outline and disclose in detail.
As a rule, the SRS template includes:
- Introduction: the essence of the project for all stakeholders.
- Business Objectives: what the project needs to accomplish (e.g., creating an MVP, launching a website, or developing an app).
- Project Scope: the tasks and work that must be done to achieve the goals.
- Intended Use: all possible uses of the product for different user roles.
- Definitions and Acronyms: an explanation of all terms and notations specific to this project.
- Overall Description: the idea of the product and the value from the user’s point of view.
- User Needs: the target audience and their expectations for the digital product.
- Value: the usefulness of the created product, i.e., what audience problems will be solved by the system features.
- Assumptions and Dependencies: constraints related to data exchange standards, business logic, compatibility, etc.
- System Features and Requirements: features of the behavior and operation of the system (discussed in more detail below).
- Functional Requirements: product behavior under certain circumstances or user scenarios.
- External Interface Requirements: interaction of the product with other components, which is especially important for embedded systems.
- Nonfunctional Requirements: operational capabilities of the system and some operational limitations.
Software requirements must be concise, precise, complete, verifiable, and understandable even by non-technical people. Avoid ambiguous language, and ensure that there is no conflict with other requirements. Also, ensure that adjustments can be made at later stages.
The results are coordinated with all stakeholders. Software requirement specifications are approved, and the team begins the development of a clickable prototype. In the future, the scope of work may change, and requirements may be updated and expanded. This means that work with SRS continues throughout the SDLC.
Above we pointed out three types of requirements, but now let’s take a closer look at their levels and the relationships between them, also give examples for a deeper understanding.
Software Requirements Features
Functional software requirements specification
It’s about what needs to be done to make the product the way the customer expects it to be. It describes the product’s functionality, which helps solve the set tasks, and how the solution responds to user actions. Also, here, you can study the business processes, the user input data, and various calculations.
Thus, functional requirements define what the system should do (or not do) in response to input data or under certain conditions.
Example 1:
The user should be able to log in using their username and password.
The function is “login,” and the behavior is “the system should allow the user to log in using the username and login.”
Example 2:
The system sends a successful order confirmation email to the user.
The function is “send the confirmation email,” and the behavior is “the system should send a confirmation email to the user after they have placed the order.”
Scenarios, Examples, or Use Cases are used in BDD. Work with functional requirements begins with creating examples using Given/When/Then, a way of writing for a clear understanding of Context, Tested Action, and Assertions. This is an opportunity to ensure that acceptance tests are independent and understandable.
Example of functional requirements for Scenario BDD:
GIVEN the user is logged in.
WHEN the user adds a promotional item to the cart.
THEN the discount is added to the total cost of the order.Non-functional software requirements specifications
This section of the SRS describes how the system does what it is designed to do. It is not defined by the main functions but by the properties and characteristics. Non-functional software requirements can be related to performance, reliability, adaptability, etc. Also, the implementation constraints that do not affect the system’s behavior are considered.
Examples:
Pages on this website must load within 0.4 seconds.
The software product must be designed following IEC 60601.
A QA expert can perform a unit test through TDD to create a quality technical specification. Reviewing such a test allows each party to learn as much detail about how the solution is structured.
Example for BDD:
Let’s say you have a scenario: a user can update their contact information.
GIVEN the user is on the contact information page.
WHEN the user updates their contact information.
THEN the last contact information entered is displayed.Now suppose the customer wants the whole process to take no more than 5 seconds. The script needs to be rewritten to account for the wait time.
Scenario: the user can quickly update their contact data.
GIVEN the user is on the contact details page.
WHEN the user updates their contact information.
THEN the last contact information entered is displayed,
AND the user does not have to wait longer than the maximum allowed time.External Interface Requirements
These software requirements specifications are linked to:
- UIs (user interaction logic);
- screen layouts;
- buttons;
- functions on each screen;
- hardware interfaces (devices for using software).
SRS documents can also deal with software interfaces, including frontend/backend stack and DB management systems.
Here are a few examples of system requirements
- The software is designed for Windows 7,8,10, Android, and iOS.
- The website must work correctly with all versions of the Opera browser.
- The messenger user can send a file of no more than 16 MB.
- The user can register on the website using their Gmail data.
Access to detailed system requirements is important at every stage: task definition, software engineering, testing, bug fixes, results analysis, and reevaluation of priorities. To achieve a better understanding of the nuances of the work, it is necessary to take seriously the collection of requirements and the generation of a document based on them, as well as the subsequent management of requirements during the SDLC.
Software requirement documents play a significant role in Agile. It visualizes the most important nuances of the project but does not interfere with the creative process. Within BDD, it allows to accelerate knowledge sharing in the team and achieve a deeper understanding of requirements while maintaining the same flexibility.
