Understanding Requirement Specifications

In Scrum, quality is defined as “The ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer”. 

So how can we assure quality so that delivered products meet this definition? Sometimes, testing and quality assurance are used interchangeably so just to be clear, for this blog, by quality assurance I don’t just mean testing. Testing can be part of the QA process but for now I’d like to define quality assurance as a consistent (or at least regular) set of checks that are applied throughout the application lifecycle. There are 2 main parts to it:

1. Process assurance - verifying by reviews, checks and audits that good project processes are being followed.
   
   
2. Product assurance - demonstrating that customers’ requirements are being met as a product is being built. This can be product verification and testing.

If we take it as given that quality assurance assures the quality of delivery, what are the benefits of quality assurance? Put simply, there is a greater chance of a delivering a better-quality product. I believe this is achieved through the prevention and detection of defects as early as possible in the application lifecycle.

One of the principles behind the agile manifesto is: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly."

This means that process assurance is built into the agile process. However, in waterfall I generally find a QA process needs to be injected into the SDLC. In theory, it should be there already but I rarely see it done properly. I firmly believe that if more waterfall projects applied QA throughout the project, there would be many more successful deliveries.

Quality Planning

So, what does it mean to apply QA to requirements definition? The two parts of quality assurance listed above would translate to the processes and artefacts as a part of the requirements definition. These are performed according to good practice and delivered to a high standard. Therefore, translates to getting well defined stories.

Good and high are subjective terms and need to be defined according to an individual organisation’s and project’s desired output. This is best captured during quality planning. I personally believe a documented quality plan is relevant to both agile (including Scrum) and waterfall software delivery.

The mantra of “working software over comprehensive documentation” from the agile manifesto does not mean that all documentation is unnecessary. A quality plan sets out the customer’s quality expectations. It starts with asking some simple questions that if left unasked and ununderstood, will certainly end up with unmet or unmanaged expectations.

Other than by good fortune, how can any other outcome be achieved? It’s like trying to buy your partner a Christmas or birthday present without asking what they want. You might get it right by relying on the hints that you think you’ve picked up over the year but going ‘off list’ is a risky game to play and I’ve learnt the hard way not to play it.

• The key quality requirements which will drive the choice of solution
• Any standards and process that need to be applied
• Any measurements that will determine whether products meet the quality requirements
• What needs to go through a quality check?
• What is the most appropriate way to check the quality?
• Who should be checking and testing?
• When should checking and testing be carried out?

Applying QA to Requirements Definition

“In life, you get what you ask for” and if you don’t articulate what you want then you won’t get much. If the requirements are not well defined and don’t properly describe what the product is supposed to do or do it in enough detail, then there is a high risk that the final product won’t be what your users really need or are expecting.

• Complete
• Clear and lack of ambiguity
• Testable / developable with enough detail
• Consistent (not contradictory or conflicting)
• Cover the full breadth of scope
• Correct with no technical or business process errors
• Traceable with the source of the requirement documented 
• Business value is assessed and documented
• Risk is assessed and documented
• Impact is revised and documented
• Estimates for items exist and are refined
• Acceptance criteria are defined
• Technical specification exists

• Identifying missing user stories
• Identifying what should be in and out of scope
• Identifying dependencies between user stories
• Identifying edge cases
• Generate acceptance criteria
• Identifying gaps in the detailed stories

In Scrum, the refinement process is where we can apply QA and gates to the requirements before sprint planning takes place. Also, there is no formal event that covers the refinement of the product backlog. Instead, the scrum guide states that the "Scrum Team decides how and when refinement is done" and that "refinement usually consumes no more than 10% of the capacity of the Development Team." In my experience, having a planned mid-sprint session that allows for product backlog items that are candidates for the next sprint to be discussed seems to work well.

All members of the Scrum team should be involved in product backlog refinement. This ensures that the whole team understands what is required from each product backlog item that may be taken into a sprint. In addition, you may want to include any UX, UI, DBA, or infrastructure experts who may be involved in the delivery of the product backlog items being refined.

Good QA of the project processes should ensure the refinement process happens on a regular basis, has the right people present and goes to the right level of detail. Just having the event doesn’t ensure the output is good enough. Continuous improvement and learning when looking for development and testing problems. As an indication that the stories at the top of the product backlog, that the team will be pulling into the sprint backlog, are not ready. A checklist to ensure stories are ‘Ready Ready’ is a valuable QA gate.

• Updates to item description (user story) and additional detail
• Updated acceptance criteria
• Test cases 
• "Given, When, Then" statements
• Diagrams (architectural, process flow, UI designs, etc.)
• Example data

All of this is applicable in waterfall delivery but there is typically less structure and complexity in the process. It goes without saying that a good requirements review process can be well defined and implemented, I’m just saying it isn’t common. This is interesting because common wisdom would (incorrectly) say agile development is less process heavy than waterfall.

Why have QA of requirements?

A requirements review process (including Product Backlog refinement) provides value in a number of ways:

• It gives the team an opportunity to look ahead at upcoming requirements, reviewing and revising their content.
• It allows for any queries to be raised and answered at an early stage.
• It removes errors and defects early in the delivery process.
• The additional detail makes development and testing easier.
• It improves the accuracy of estimates.
• Greater velocity.
• It makes planning more accurate and reduce the length of sprint planning sessions.
• Requirements can be deprioritised or removed.

Ultimately, it means we get better quality products and happier customers.
Over the years I’ve seen various QA processes on various projects. At the end of each project, I have invariably felt that better and more detailed requirements/stories would have resulted in a better-quality product being delivered and fewer project issues. I also believe, without a doubt, that more or better QA (or both) of requirements would have resulted in shorter timescales and lower costs.