Poor Requirements – How an RDM tool can help

In the previous blog posts, we discussed what constitutes a poor requirement, what the IT and business impacts from poor requirements are, and then what the causes are for poor requirements and related issues. In this post we'll take a look at the ways a requirements definition and management (RDM) solution can help improve the situation.

Again we extend the diagram that’s been ‘growing’ throughout this blog series. This time we add ‘Solutions’ to the common causes, as shown by the column of green shapes on the right side of the diagram below.

Let’s walk through the list of solutions:

• Generating tests automatically from the requirements is a key way that modern RDM toolsets provide value by dramatically reducing the tedious and error-prone task of ‘crafting’ tests by hand. The more capable toolsets also provide ways to selectively generate tests according to priority criteria, helping focus valuable testing resources on what’s truly important.
• Generating documents automatically is another huge time-saving and quality-improving capability that also transforms document-centric requirements processes to working with requirements online and generating documents instantly when needed.
• Integration with lifecycle tools is essential for an RDM tool in order to reduce the wasted time, inefficiencies, and risks associated with working with disconnected toolsets.
• RDM tool’s ability to adapt to processes used by particular projects prevents the need to ‘work around’ the tool’s shortcomings which can degrade an otherwise well-tuned process.
• Support for reuse of requirements is key to prevent the waste and inefficiency of having to ‘re-invent the wheel’ each time common requirements are needed, and also allows for the enforcement of requirement standardization and consistency.
• Social interaction features integrated with an RDM product help to engage stakeholders, a critical problem for many requirements projects, which has only been compounded with the shift to distributed teams and outsourcing.
• The development of good requirements begins with a complete understanding of the business context, so the requirements can derived from the true business need. RDM solutions need to support this by providing the tools required to model and analyze the business context completely.
• The best RDM tools have a range of formats – both textual and graphical – to express the requirements. It is key that the tool also be able to integrate requirements of these different formats which helps expose missing information, redundancies, and conflicts. Not being able to integrate them means these issues can remain undetected until later in the development cycle.
• How requirements relate to one another is vital information to know when working with requirements and managing change. The RDM tool should expose relationships to ensure users are aware of them no matter when or where the requirements are being viewed or worked with.
• Accessible, easy to use, and managed review and approvals of individual and sets of requirements helps tremendously to ensure that requirements validation is effective and complete.
• Requirements visualization is a proven way to dramatically improve the ability to communicate and understand requirements information. It helps prevent miscommunication and improves stakeholder’s ability to validate requirements.
• There are many kinds of requirements – requirements that deal with process, with data, with rules and conditions, with user interfaces, with states and events, and more. Each has different characteristics and can be best expressed with different formats. RDM tools need to have a broad range of expressions available for users to choose the optimal representation for the kind of requirement being specified.
• Being able to see an overall set of relationships, not just one at a time, is key during analysis and management activities. This is used to ensure that all user requirements have been addressed by lower level technical requirements for example, or that all business objectives are exhaustively mapped to system capabilities that fulfill them, or that all system requirements have associated tests that validate them. A traceability matrix provides this ability to ensure coverage and manage scope.
• A final consideration isn’t concerned with the user features provided by the RDM solution, but rather its administration. The impact of tools that are difficult to administer can be huge, especially on large, distributed, enterprise projects. Cumbersome security, configuration, performance, upgrade, and similar functions can cripple a project. RDM tools designed from the outset with enterprise-scale infrastructure and administration are the best choice.

These tool-focused solutions have been proven in a wide-range of situations to tackle the common causes of poor requirements removing much of their negative impacts on projects.

In the next blog post we will show how Blueprint, an enterprise-class RDM platform, specifically delivers the solutions described above and more.

---

Poor Requirements - What’s the Cause?

In the previous blog posts we discussed what constitutes a poor requirement and what the IT and business impacts are, at a high level. In this post we'll take a look at the classic causes of these issues. The diagram below builds on the diagram shown in the previous blog posts by adding ‘causes’ in a column on the right. 

Poor requirements can stem from a multitude of causes, but some of the most common are listed in the diagram and described here:

• An inability to share Requirements, or reuse requirements, means that all the work that went into defining that requirement in the first place has to be repeated a second time which not only wastes time but introduces the possibility of errors and inconsistency.
• Inadequate stakeholder involvement is one of the most-reported causes of poor requirements from the beginning during requirements elicitation, through validation, and later while the requirements are managed throughout development, test, and delivery. In all these areas of the requirements lifecycle stakeholder involvement in crucial and when it is lacking, requirements quality is at risk.
• When requirements are not aligned with business needs the resulting development and testing effort is not optimal and may be wasted entirely once the misalignment is noticed and rework occurs.
• When requirements are not cross validated with the other requirements there is a huge risk of redundancy and inconsistency among the set.
• Most requirements are dependent to some degree on other requirements which need to be taken into account when working with requirements, implementing changes, and otherwise managing them. When not recorded or simply overlooked, these missed dependencies will result in errors.
• The purpose of validation is to ensure, with stakeholders, that the requirements are complete possess the qualities described in the first blog posting of this series, both individually and as a set. Issues not detected during validation means that poor requirements are being delivered to development and test. Inadequate validation can be due to a number of reasons ranging from inadequate time or involvement, to poor process or tool support.

There are a number of issues that don’t necessarily drive poor requirements, but cause related issues:

• Tedious error-prone test authoring is inefficient and wastes time, and can result in test assets being flawed and having to be reworked. Wasted time and inefficiencies are also caused by poor test prioritization, tedious error-prone document authoring, disconnected toolsets, and tool workarounds when they don’t directly support the process being used.
• Misunderstanding requirements, even when the requirement themselves are of high quality, is yet another source of error that drives incorrect designs and incorrect tests.
• Inadequate coverage and scope control means that there’s no guarantee that all needed features will be built, or that extra features that aren’t needed show up in the finished application.
• And finally, complex tool administration contributes to overall cost of development and maintenance.

As stated multiple times before this is not an exhaustive listing of causes and effects of poor requirements and related issues. It does however capture many of the common ones and can also serve as a brainstorming tool for discovering the specific ones you may be encountering.

Stay tuned for the next blog post in this series which will show proven solutions for these ailments.

---

Poor Requirements – What impact do they have?

In the previous blog post, Poor Requirements - What are they? I discussed at a high level what constitutes poor requirements. In this post I’ll point out the impacts that poor requirements can have, both to the IT group developing the application and to the business side who needs the application.

Poor requirements are a well-known key root-cause for challenged and failed software projects. The figure below illustrates some of the principle impact areas both for the IT group who is developing the application, and for the business whose operation depends on the application. (Note that this is intended to cover the most common impacts and is not an exhaustive list)

IT Pain

Poor requirements have a very real and significant impact on application projects:

Late Product Delivery:

Requirements are the ‘Blueprints’ that virtually everyone on the project works from. When those blueprints are flawed, the work-products of all team members who depend on them suffer. Poor requirements lead to poor designs and tests and depending on when these issues are uncovered, development and testing rework is the result. This, along with the requirements revisions themselves, contribute to late product delivery.

Poor Product Quality:

There is never enough time to completely test every scenario through an application. For this reason, testing must be ruthlessly prioritized to focus on what’s important and must be as efficient as possible to perform the maximum amount of testing. The rework along with resulting wasted test runs severely reduce the overall amount of testing that can be done. Testing priorities are also at risk when requirements and designs are in flux, so not all testing effort is necessarily focused on what’s important. Depending on how poor the requirements are that drive this inefficiency and mis-prioritization, the result can be poor product quality.

Degraded Design and Documentation Integrity:

Great designs are extensible, maintainable, configurable and more, and they consider a wide range of factors, use proven patterns, and involve a high degree of skill and experience on the part of the designer. When requirements are poor a series of changes occur as the flaws are uncovered. This can incrementally degrade the design, chipping away at its integrity with each change, until it has lost much or most of these desirable characteristics. Worse still, this affects not only the design itself but related assets like documentation as well. The net result we call degraded design and documentation integrity.

Invalid Features Delivered:

For those requirements flaws that are not uncovered during development or discovered too late to change end up as invalid features being delivered. These could be features that are out-of-scope or simply incorrect features which must then be handled by workarounds.

Business Pain

As indicated from the diagram, late delivery of the product, poor product quality, degraded design and documentation integrity, and invalid features being delivered, all have direct business impacts. The emphasis and severity of course varies depending on the situation, but none of it is positive and it can be severe. These results impact customers, end users, the business results (e.g. marketshare, profitability, etc.) and business aspects of application development and operation including development costs, maintenance costs, administration costs, related whole-product work, project failure or cancellation, and negative impact on application portfolio backlogs.

As mentioned, this is certainly not an exhaustive list but does capture many of the common impacts and also illustrates the ripple-effect of poor requirements.

Now that we’ve explored the impacts of poor requirements, in the next blog post we’ll look at what causes poor requirements in the first place.

---

Poor Requirements – What Are They?

On application projects requirements are the 'blueprints' for what gets built and tested, so when the blueprints are ‘lacking’the project and the resulting application suffer. We’ve all heard the statistics on software project challenges and failures whose cause can be traced back to poor requirements - but what exactly are ‘poor requirements’?

There are many sources that try to dissect and group requirement faults into convenient categories, but after reading several I would categorize them as ‘missing’, ‘irrelevant’, or ‘bad’ requirements. To help explain I’ll first propose a simple notion of requirements: requirements exist to constrain design choices. With a requirement like ‘build me a vehicle’ pretty much anything from a bicycle to the space shuttle could be delivered and technically would satisfy the requirement. Adding more requirements like “the vehicle should float”, “the vehicle should seat four people”, “the vehicle should have two oars”, “the vehicle’s total length should be between 12 and 14ft long”, “the vehicle should be transportable out of the water using a trailer towed by Honda Civic”, we constrain the possible design choices and are more likely to get what we actually need.

Missing Requirements: Given the large number of requirements you’ll find on a typical software project it’s not surprising that some get overlooked no matter how diligent the team is. Missing a requirement basically means it is left up to the designer to decide on that aspect of the solution. In the example earlier the client neglected to state a requirement that the vehicle needs to support an outboard motor at the rear of the boat. Whether they get this or not is, to a degree, up to chance. It depends on whether someone notices the missing requirement in time, or whether the designer simply makes that design choice based on experience, preference, available components, etc.

Irrelevant Requirements: Irrelevant requirements aren’t ‘wrong’ but are redundant with other requirements or don’t help to further ‘constrain’ the possible design choices. In very simplistic terms it’s like having a requirement in the previous example that states “the vehicle will be able to move”. This is inherent in the definition of what a vehicle is and so is unnecessary. The impact of irrelevant requirements is largely the drag they place on the process by having to be considered, analyzed, managed and dealt with at every step, wasting time and energy.

Bad Requirements: Bad requirements can be at the level of the individual requirement, or the set of requirements as a whole. It means that the requirement (or set) is lacking in one or more of its necessary qualities. Again there are multiple lists of the qualities requirements should have, but I’ll use those promoted by Karl Wiegers [2]. However I will divide them into two sets – those that apply to individual requirements and those that apply to the set of requirements (See Fig2).

For example an individual requirement such as “the vehicle should be able to travel at 70knots” wouldn’t be feasible. An additional requirement saying “the vehicle should allow for three passengers to row simultaneously” would mean the set of requirements is inconsistent because we already have a requirement stating there will only be two oars.

With this description of what poor requirements are, the next blog post will illustrate the impacts that poor requirements have on both technical and business stakeholders.

Key Sources:

1. Evaluating Requirements, Richard Griffiths
2. Writing Quality Requirements, Karl Wiegers
3. Mastering the Requirements Process, Suzanne Robertson, James Robertson

---