Why Testers Should Get Involved in Requirements Engineering
Testers use requirements as the basis of test cases, review them for testability, and often participate in general requirements reviews or inspections. However, many testers have little knowledge of or skill in requirements engineering.
What level of quality and detail is realistic to expect in requirements documents? What does testability really mean? How can testers help improve requirements? Testers should be able to answer these questions and more.
Five Success Factors
Based on many years of experience in requirements engineering, I would like to point you to five critical success factors I recommend testers start digging into.
1. Requirements attributes
Requirements are much more than just the sentence. Consider documenting rationale, priority, requirements type, related use case or epic, etc. Requirements attributes capture important additional information about a requirement. Usually the requirements attributes evolve into a user story card.
2. Requirements acceptance criteria
Acceptance criteria, or fit criteria, complete the definition of the requirement. We have to be able to tell whether a solution completely satisfies a requirement. These criteria will make requirements measurable. It is often much easier to add concrete acceptance criteria than to write 100 percent unambiguous requirements. Acceptance criteria in some way detail the requirement.
3. Requirements rules
The discussion on what makes good requirements is endless. Of course the answer depends on the context, but most importantly, good requirements need firm decisions. A concrete and usable requirements rule set should be defined that leads to “good enough” requirements based on your context.
Some examples of requirements rules are:
- All requirements shall be unambiguous to the intended readership.
- All requirements shall have a priority indication.
- All requirements shall have a rationale to explain the reason for the requirement.
- All requirements shall be broken up into their most elementary form. (Compound requirements are not allowed.)
4. Requirements templates
Instead of reinventing the wheel, use templates when defining requirements. Templates provide consistency and contribute largely to a higher level of unambiguousness. User stories typically follow this format: “As a <role>, I want <goal/desire> so that <benefit>.” Other common templates include:
- The <stakeholder> shall be able to <capability> (e.g., The order clerk shall be able to raise an invoice).
- The <product> shall be able to <action> <entity> (e.g., The launcher shall be able to launch missiles).
- The <product> shall <function> <object> every <performance> <unit> (e.g., The coffee machine shall produce a hot drink every ten seconds).
5. Requirements reviews
Reviews are by far the most effective and efficient quality assurance measure to find defects. However, this is only true if the reviews are well executed. Start with your objectives and define a review process that matches these objectives.
It is just not good enough anymore to understand testing and hold a certificate. In agile, the tester is more involved in requirements than ever before and contributes to documenting requirements and their acceptance criteria. Having skills in requirements engineering has rapidly become a mandatory part of the tester's skill set.
The five success factors here provide a nice starting point to build knowledge and get involved in a practical, effective, and efficient way.
Erik is leading the tutorial “Requirements Engineering for Testers” at STAREAST 2015.
