“The charm as well as the challenge of requirements engineering is that it straddles geek and non-geek territory. Requirements describe how a software project and the system it produces interact with their physical and business environment (non-geek), but must do so with enough rigor and precision to serve as a blueprint for development, verification and maintenance (geek).”
– Meyer B. Handbook of Requirements and Business Analysis, 2022
Requirements change a lot as the project progresses and these changes often introduce contradictions that have to be found and resolved. Managing changing requirements is one of the biggest challenges of Requirements Management. As a business analyst (BA), one of your critical roles is to ensure that the requirements for a project are accurate, complete, and meet the stakeholders’ needs. Books for Analysts (for example, McConnell’s) often advise to test written requirements before moving them to development. Of course, only a few people do it: not everyone knows that it is possible to do this, deadlines are pressing, there is no budget, the complexity of the procurement procedure cancels out the benefits, etc.
Let’s talk about the most important thing first – Requirements Testing means testing of requirements and NOT requirements for testing! Often, these concepts are confused despite the fact that they are very far from each other. The purpose of Requirements Testing is to identify problems and eliminate inconsistencies in requirements before development starts and avoid costly revisions and changes at later stages of projects. Ideally, of course, you should give the requirement to a third-party contractor for testing (especially if the development is not done in-house, but by the contractor), but if you don’t have such an opportunity, an internal tester or business analyst will do.
What is tested during Requirements Testing
Requirements
As part of the testing process, the Business Analyst or Tester should ensure that requirement description is high-quality and well-written. For example, Karl Wiegers in “Software Requirements” book, gives the following criteria for a good requirement:
- Complete. It fully describes the functionality;
- Correct. It accurately describes the functionality;
- Feasible. The requirement can be implemented;
- Necessary. The capability documented must be required;
- Prioritized. The requirement is essential to the system or a particular release;
- Unambiguous. Anyone who reads the requirement should arrive at a single interpretation of it;
- Verifiable. The system can be tested to confirm that it meets the requirement.
In addition to that, you may want requirement to be:
- Atomic. Each requirement cannot be broken down into multiple requirements;
- Unique. Requirements shouldn’t duplicate each other, instead references must be done;
- Compliant with business rules: legislative acts, regulations, standards, rules, described business processes, etc.
Completeness of the requirement description may be decomposed into the following artefacts to be checked:
- List of User Classes and User Roles and their characteristics;
- Requirements for implementation in the system of all possible scenarios of the business process being automated (alternative/exclusive);
- Requirements for checking the correctness of input data (automatic validation);
- Requirements to the system behaviour in case of interruption or change of the process steps execution direction (return to the previous step, window closing, etc.);
- All data entities with indication of the necessary set of attributes for each of them (unique, not empty, other checks);
- All possible states/statuses of data entities and the condition for transition between them;
- Requirements for interaction with lists of data entities;
- Requirements for interaction with other systems.
Requirement Documents
From a single document perspective, the following should be ensured:
- The structure of the document conforms to the approved template;
- Actuality of document attachments and appendices: interface elements, use cases, prototypes/mockups of the system user interface, data models and/or business processes;
- Document follows Document Naming Conventions;
- Document versioning is actual and up-to-date.
Sets of Requirement Documents
Testing the whole set of documents (for example, between BRD, FRD, SRS documents), you may check the following:
- The set of requirements in documents is complete as a whole;
- Each document contains the full set of requirements;
- Every requirement is complete;
- Requirements refer to related requirements in the document;
- Requirements refer to the requirements in other documents as clarifications.
Analysing Use Cases helps validate that the requirements cover all possible scenarios and user interactions. A Traceability Matrix is used to trace requirements back to their source and forward to the deliverables, ensuring that all requirements are accounted for throughout the project lifecycle.
Artefacts of Requirements Testing
As a result of Requirements Testing, you may produce the following artefacts:
- A register of observations containing a list of problems identified in the requirements. For each of them you should specify its unique number, date of detection, author, section of the document where it was detected, the essence of the problem, type of the problem, criticality, etc.
- List of suggestions on how to improve the system under development, if any – e.g., add design requirements, make a prototyping stage, etc.
- List of suggestions to improve the approach to requirements documentation in the company as a whole – e.g. coding, granularity, level of detail, approach to description of NSI, etc.
How to find Contractor for Requirements Testing
Well, for starters – just ask what kind of experience person or company has in this testing industry. In all probability you will be told some vague thing like “yes, we’ve done something similar, I’ll check with my colleagues, we can do it, of course”, which can be interpreted as “no, we don’t know how to do it, but we’ll gladly give it to junior to read, and we’ll charge you as for a team of seniors”. It is better to check Requirements yourself with a glass of wine in the evening then.
If the contractor is not afraid of the question and gives more meaningful answers, then you may want to ask for an example of the Register of Comments and Suggestions and evaluate if it meets your expectations. Often it will be a couple sheets of paper with recommendations like “you should do well and follow Wiegers, but you should not do badly”. Don’t involve yourselves with these people.
But if the Register is full of details and specifics in the recommendations and it was provided you not in a week (giving time to make a document for you), but almost immediately – with this contractor you can try to work. With high probability it will be a very, very, very good contractor with a high level of process organisation (since it has already reached level of Requirements Testing).
It is advised to discuss the possible types of problems that should be identified as a result of Requirements Testing with the contractor in advance so that they can better understand your expectations (for example, sometimes searching for contradictions and errors is priority, in other cases you may want to include searching for typos, getting suggestions for structuring, etc.). Since requirements testing is a rare thing, there are not many formalised approaches to such testing even on the professional QA market, so it’s better to outline everything onshore.
In general, Requirements Testing is a great tool that can save a lot of hours and nerves, the only thing left is to convince the Customer and the Project Sponsor to include this task in the project.