A Thoughtful Approach to Improving Requirement Quality

Have you ever taken a moment to consider the impact that requirements have on the success of a project? The number of projects (and obscene amounts of money) that have been flushed away due to poor requirements is much too high. We’ve all seen the scary figures, quoted time and again. Figures that show the high number of failures. Figures that show the growing cost of a defect as it grows and spreads undetected across teams and deliverables. So, how do we get better?

As they say, there’s no such thing as a silver bullet. However, that doesn’t mean that we give up and throw our hands up in the air! In this article we’ll look at a number of answers, some simple, some a little more complex.

As a starting point, it is good to take a moment and discuss what is not going to help. Wasting time, effort and focus on tools, templates and styles offers no value. Requirements that have traceability links have no increase in quality vs. requirements that are linked. Sure, it’s nice to have that traceability, but links do not do anything for the quality of each of your requirements. Similarly, having a diagram or a mock up, while pretty, do not make for quality requirements. So if the plan was to buy yet another requirements management tool that gives you an editor, traceability and some fancy drawing tools; you’re likely wasting your money. Save some time and money and bring out sticky notes, documents, spreadsheets, wikis and any other tool that is  “good enough”.

In the agile world there’s much discussion about travelling light. Working with purpose and focusing on value. That we should focus on people and process over tools. I’d add that all of these could be summed up as being thoughtful in our efforts.

So you’re probably thinking that the idea of being thoughtful is too simplistic and doesn’t do much to help our requirements. At this point you’re correct. So let’s talk more.

What should we be thoughtful about? To start, we need to get past the notion that all we need is a specific template to follow. Whether the template is for writing a use case, user story or a different form of a requirement. While templates seem to guide the team to consistency, it really is a shallow and ineffective form of consistency. As a matter of fact, simply filling in the blanks tends to put us to sleep and become disengaged. We stop being thoughtful. Our focus goes away as our mind and body disconnect. Our fingers type, type, type away; filling in the blank spaces. Our mind wanders and considers more interesting things.

To increase our thoughtfulness we need knowledge. This knowledge has to help us to understand the different aspects of quality that should be sought in writing requirements. When writing (and reviewing) requirements, we can consider quality from at least 6 different (and complementary) perspectives. These 6 perspectives include: Testability, Readability, Consistency, Completeness, Clarity, and Accuracy.

In the following sections, let’s take a closer look at each of these perspectives. As part of the discussion we’ll elaborate on the definition for the perspective and introduce a number of questions that you can use to guide your efforts.

Testability

Simply put, with Testability we are looking to write requirements that support efforts to confirm that the solution meets the requirements. Poorly written requirements do not support testability. As a result, we have no way to confirm that the solution is correct. As you work with a requirement, imagine yourself as a member of the QA team and ask yourself “How could I test this requirement?

More specifically, you can ask a number of further questions including:

• Does the requirement have any conditions? Are they complete?
• How many imperatives are in each requirement? If there are multiple, consider whether they are concurrent or consecutive.
• Does the requirement suffer from poor wording?
• Is the requirement actually a requirement? Or, is it just speculation?
• Are there continuances? That is, are there references to other supporting documents that are supposed to provide the details? A pitfall in having continuances, such as: see Standard 123 for more details, is that its often unclear whether the reference is to the entire document or just a subsection. This can lead to scope creep.

Readability

To tell if your requirements have readability issues, you can start with the simple question: “Are your requirements read? Or, are they deciphered?” When other people consume your requirements, will they be able to understand what has been written?

To evaluate your requirements for readability, consider the following questions:

• Are the sentences that comprise the requirement unnecessarily long?
• Are the sentences complex? Consider the number of topics discussed, quantifiers, and punctuation.
• Are there unnecessary and redundant words?
• Are there any spelling or grammatical issues?
• Are the requirements written using a passive voice?

Consistency

We talked earlier on about the idea of consistency. More specifically, we talked about how a template is not the answer to consistency. We need to go beyond template thinking. True consistency is reflected in the terms, words and the entire set of requirements. In this set, we need to make sure that we are referring to the same things in the same ways.

Considerations to keep in mind include:

• Are there any duplicate requirements?
• Are there any overlapping or conflicting phrases?
• Is there an alignment between singular and plural references?
• Are we consistent in the units of measure used?
• Are we consistent in terminology?
• Are there variations in grammatical styles?
• Are there interactions between concepts? For instance, functionality vs. security? Optimization vs minimization?

Completeness

Not only do we need a complete set of requirements, we also need for each requirement to be complete in what it is stating. That is, do you have all of the requirements? Have you fully articulate the requirements?

In seeking out completeness, consider the following:

• Are there interfaces between the systems?
• Are there implications related to accessibility?
• Are there potential deadlocks?
• Have safety issues been considered?
• Have you fully articulated the interactions between actors and the system?
• Have you considered the complementary requirements? For instance, if there is already a requirement for downloads, have you considered the requirements for uploads?
• Do the requirements fully realize the vision for the project? Have the fully realized the set of higher level requirements?
• Are all of the important topics covered? Are all of the expected functions discussed? Are there supposed to be sensors or agents? Are they all discussed?
• Review key concepts that appears as plurals. Do they represent a homogenous set? Or is it a heterogeneous set?
• If the system will consume or produce messages, have you considered what happens when messages are delayed? What if only a partial message arrives? What happens in the case of non-delivery?
• Take another look at your boundary conditions. Do any of these boundaries have related hazard, risk or safety issues?

Clarity

Simply put, we want to avoid ambiguous requirements. We want to avoid having concepts, words and phrases that have multiple meanings or that are open to interpretations.

To avoid ambiguity and build clarity into our requirements we want to avoid the use of poor, fuzzy, ambiguous words. Some examples include: mostly, as needed, appropriate, graceful, slowly, clean and stable interface, adequate. While all of these terms are valid words (they are in the dictionary) – in a requirement, they provide little value.

Other considerations:

• Are there any circular references?
• Are there too many conditional clauses?
• When using indefinite pronouns, are all reference clear?
• Is there clear and proper coordinate between verbs and actors?
• Watch for use of and/or.

Accuracy

Accurate requirements are found to be in the state of being correct or precise.

When thinking about accuracy, consider:

• Is there a mix of numbers and words that refer to quantities? Do they align?
• Are there mixed units of measure?
• Does the requirement include the use of “loose” words? For instance: approximately, or so?
• For each unit of measure, do we have correct and accurate values?
• When multiple values are provided, what is required between the values?

With these quality aspects in mind, we can be thoughtful in working on our requirements. Without this thoughtfulness, the path forward is much harder and full of frustration.

Before wrapping up, I’ll add that there’s more to the challenge that just what we’ve touched upon here. We also need to consider scaling, scope creep, timeliness, understanding, communication vectors, cognitive bias, language, standards and managing change. But we’ll leave that for another day.

Today we focus on being thoughtful and using our knowledge about quality to deliver better requirements. Thoughtfulness is critical in delivering better requirements and successful projects.

If you’d like a presentation that further covers these ideas, please visit us at Sirius Requirements This downloadable presentation further details these aspects, related questions and examples. And of course, if you’d like to discuss the challenges of requirement quality or get assistance via services, training or our industry leading product, Requirements Assistant, please contact us at info@sirius-requirements.com.