5 Common Requirements Mistakes to Avoid

This post was inspired by Donald Firesmith’s piece on Requirements Mistakes where he discussed the common mistakes that occur in requirements engineering. Keeping these mistakes in mind can help business analysts (regardless of their domain) develop improved requirements management processes that will ensure the delivery of high quality requirements.

1. Reviewing Requirements Without Sufficient Collaboration

The review of requirements should not be considered an activity to be performed solely by the business analyst - It should be collaborative in the sense that other stakeholders are consulted to validate the quality of the requirements against multiple perspectives or criteria. Dorothy Graham in her article, Requirements and Testing: Seven Missing-Link Myths, explains:

“We don’t need to think about testing yet. Let’s just concentrate on requirements.” This attitude guarantees that you will have a rough time at the end of your project. Of course, getting good requirements is important, but getting testers involved during requirements analysis is one of the best ways to ensure good requirements”.

How does an analyst know that requirements are technically feasible if they have not been discussed with the technical team? This is particularly essential where the analyst does not have much technical experience. Similarly, how can the analyst be certain that the requirements reflect current reality and are accurate if discussions have not been held with the stakeholders from whom the requirements were elicited in the first place? Checking requirements against quality attributes with other stakeholders (not just business users) can help to remove most, if not all the defects that would otherwise have been built into the application.

2. Assuming Use Cases are Always Sufficient

Use cases are one of the most popular means of specifying requirements. They are easy to understand by both technical and business people and focus on system functionality from the user’s perspective. Despite the universal-like acceptance, there are other categories of requirements better depicted using other models. For example, data flow diagrams emphasize the flow of data through the system while an ERD can serve as a foundation for database design.

While use cases can be extremely useful as an identification and analysis technique, most analysts find it difficult to express ALL their requirements as use cases, especially non-functional requirements. Use cases should be combined with other techniques to ensure that the desired solution is specified as completely as possible.

3. Documenting Constraints as Requirements

The fact that there’s a common or preferred approach to implementing a requirement does not imply that there aren’t other approaches. Stating constraints and desires as requirements can happen where stakeholders are caught up in the way things work presently or have a particular vision of how they want a solution to work, causing them to disregard other possibilities. Requirements should be about the “what” and not the “how”. The use of prototypes in particular, has been criticized for causing developers to overlook better solutions and leading to incomplete specifications.

4. Inadequate or Non-existent Requirements Tracing

When changes happen (as they are bound to), requirements can quickly get out of sync, leading to inconsistencies. Tracing should happen all the way from project initiation through design and development to maintenance. Business needs become requirements, which can be traced forward to design, software components, tests and implementation components (user manuals/training guides). Traceability shows how a requirement relates to others and can help to identify the software components that will be affected by certain changes. Business rules should also be linked to the use cases that affect them so that if a business rule changes, the analyst can quickly tell which use cases will be affected.

5. Inadequate Tool Support

Many requirement models are not properly documented to back up actual requirements. The requirements management tool should enable storing of requirements metadata. The tool should also be able to capture diagrams as well as the textual requirements that support those diagrams.

Requirements Management tools are important because they make it easier to create relationships and dependencies between requirements data, thus ensuring that traceability is easier to accomplish. Simple tools like Excel and Word can easily lead to missed and conflicting requirements. They make it hard to collaborate and accomplish versioning. When dealing with a large number of requirements, requirements should be stored in a large database where they are maintained to make sorting and querying easier. All the required metadata about the requirement like the source, priority and status should be stored so that they are easier to manage.

References

Common Requirements Problems, Their Negative Consequences, and the Industry Best Practices to Help Solve Them - Donald Firesmith

Requirements and Testing: Seven Missing-Link Myths - Dorothy Graham