Before we can start we have to know what we actually need. If the problem we have is “I need to store my lawnmower,” then we can decide on the right type of shed, its size, the interior height, the strength of the floor, where in the garden it is going to be located, and so on. Knowing what we need helps us design a solution to fit the problem. We might not even need a shed. The solution could be to keep the mower in the garage or buy a low-level store rather than a traditional garden shed. It is not just articulation of our problem but also due consideration of it that helps to ensure we don’t buy something we didn’t really need, pay more than we need to for features we’re not going to use, miss out on features that we do need, or buy or build an inappropriate solution.
So, where do we articulate our problem for IT projects? The answer is straightforward enough: in a requirements document or in a requirements management system. It might be sensible to define what is meant by requirements. In Writing Better Requirements, Alexander and Stevens say that a requirement is “a statement of need, something that some class of user or other stakeholder wants.” IEEE standards says it is “a condition or capability needed by a user to solve a problem or achieve an objective that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally-imposed document.” Although this is a much more expansive definition, both agree on a clear meaning: a requirement is something needed by a user or stakeholder. Requirements should not be design or solution – those will be documented elsewhere. Of course, we testers will want to test against the requirements.
Moreover, as testers, we rely on the requirements in order to create tests for scripted testing. If the requirements are wrong and we create tests to match them, they might pass system testing and maybe acceptance testing. But it may only be in live operation that the horrible truth dawns and the cry of “This isn’t what we need!” is heard. We might feel that we’ve done our job but the customer may not be happy with the result. For IT systems, if projects don’t articulate requirements clearly the costs can be very high indeed. Complaints from users, costly rework, damage to the reputation of software suppliers, contractual wrangles, financial penalties, or even abandonment of a system are all examples of what can happen.
The need, then, is for clear and correct requirements – but how do you get them? This is not the responsibility of testers (although we can contribute to it); it is the responsibility of the author of the requirements: the requirements engineer. There are different names for this role, such as business analyst and requirements analyst, but it comes down to much the same work. How does a requirement engineer set about getting clear, correct requirements? A suggested outline for approach is:
Getting the whole picture is the key point here. There is a danger if an incomplete set of stakeholders is identified: vital aspects of the requirements will be omitted, only to rise up later and result in rework. Who are potential stakeholders? Examples of stakeholders could be users, sales teams, marketing department, the organization’s management, support technicians, regulators and legislators, external organizations such as clients and suppliers, and, of course, testers.
This is by no means an exhaustive list as it will depend on the context of the project, but it gives an idea of the wide variety of stakeholders that may need to be considered and consulted. To check understanding, it is a good idea to have a workshop with stakeholders to confirm their role and how they interact with other stakeholders and systems. This could also help identify other unforeseen stakeholders or systems.
There are several approaches that can be used to find out from people what their requirements are: interviews, workshops, working alongside users (as a user), and observing users at work. With all these methods, a “why”-style question or an open question is very useful to ask to get an understanding of what a user does or wants. To be effective, interviews and workshops need two people to work together: the requirements engineer and someone to record the outcome. This is on the basis that it is very difficult for one person to talk, ask, watch people, listen well, interpret results, all while recording everything. Things are likely to be missed. An added advantage is that the outcome can be documented and fed back quickly for confirmation by the stakeholders. Workshops are an invaluable way to solicit and understand requirements, as getting people together is more interactive and gives stakeholders the opportunity to propose, evaluate and agree on requirements. Of course, there are other ways to gather requirements: reading problem reports; meeting the helpdesk and support teams; talking to trainers, consultants and customers; reviewing comparable products and looking at existing designs, specifications and contracts.
Having a good structure to requirements will help us to understand them, while making them more accessible and easier to check. But what structure might be appropriate? A key question to ask is, “What is the system going to achieve for the customers or users?” The answer could be, for example, “to ensure new insurance business is recorded promptly,” or “to ensure that outstanding debt is regularly pursued,” or “to provide a virtual exchange for small businesses.” Each of these statements represents a “goal” that the system needs to support. These are clearly at quite a high level and need to be broken down into lower-level statements of requirement, such as “the customer support operator will capture policyholders’ details over the phone,” “the system will automatically produce a monthly statement of outstanding invoices for all customers with aged debt,” and “the system will route an incoming call to the designated mobile device matching its virtual extension number.” This “decomposition” would then be taken further to provide detailed explanation of the requirements (What are the policyholder’s details? What does aged debt mean? How does a mobile device get designated a virtual extension number – or vice versa?).
By sequencing these statements of requirements, it is possible to build up a scenario of actions necessary to achieving the final goal. Use cases are an example of how this might be documented. For testing, especially in the latter stages of systems test and acceptance test, these scenarios can provide essential input to the design and development of our tests.
Almost every requirement is qualified by context through some sort of constraint (often referred to as, rather confusingly, non-functional requirements). An obvious constraint is that of performance, e.g. 95% of all such routing must occur within a maximum of 5 seconds of the call being received. ISO 9126 (the four-part software quality standard) provides a good reference point for these constraints (the so-called “-ilities”): reliability, usability, maintainability, portability and efficiency.
Where should such requirement constraints be documented? Some constraints are likely to apply to a specific requirement or subset of requirements and thus might be put with those requirements (as in the example above). Other requirements, such as portability, may be at the system level and thus might be better stored entirely separate under their own goals, e.g. all our products must operate on Windows, UNIX, and Linux platforms.
So what actually makes a good written requirement? “Keep it simple” would certainly seem to be a good guideline. Long, wordy and complex requirements are likely to confuse rather than provide clarity. You might like to consider these:
There might be other worthwhile considerations, such as writing in present tense rather than future tense. Future tense feels right for new developments but can be confusing for those maintaining the system once implemented.
You should be on familiar ground here as many testers have done an 8-point check as part of Static Testing. However, some of the points raised above might help you extend the range of checking during Static Testing. However, a key point for the requirements engineer is that the requirements need to be checked before they are passed onto the design and development teams. Often, by the time we do our 8-point check it is after the design and even coding has already been completed, with much money and time having already been spent.
Checking needs to take place immediately after the structure for the requirements has been established so that the sequence and organization of the requirements can be confirmed with the users. Once this is done then the requirements themselves can be checked in detail, individually and as a set. The results of this would then be published to stakeholders who would attend a review meeting to decide what to do with the comments and agree to changes.
Most of these checks (but perhaps not all) should seem familiar:
A very good question! Incremental development methods, such as agile, tend to take the formulation of requirements very strongly down the workshop route, with much interaction and discussion with interested stakeholders taking place on a regular basis. The formulation of good requirements, even (or perhaps especially) in such a dynamic environment, is likely to be key to a successful outcome of the project. The difference will be that the definition of the requirements is itself iterative. I’ll leave that to the agile experts to explain – see Other Sources below.
Alexander, Ian and Stevens, Richard. “Writing Better Requirements.” Addison Wellesley Publishing Company Incorporated, 2002.
Gilb, Tom and Graham, Dorothy. “Software Inspection.” Addison Wellesley Publishing Company Incorporated, 1993.
For requirements management in agile see: https://www.agilemodeling.com/essays
