Problem Description
| Considerations
| Suggested Questions
|
Lack of clarity
| A common trick that just
about everyone in the information technology industry uses to mask a
lack of understanding is to express themselves in vague terms. This is
probably unconsciously done, but is highly wasteful. Business
requirements that cannot be clearly explained cannot be satisfied.
|
| What are the key objectives of the project? How will we know when we succeed? Who will tell us that we have succeeded?
|
Lack of agreement
| Different stakeholders may have different requirements for the same function. The business sponsor or owner must make the final decisions to ensure that there is agreement on the business requirements.
| Who are the major stakeholders that can provide business requirements? Have there been any arguments or disagreements among the major stakeholders or business owners?
|
Lack of prioritization
| Projects get into trouble when too many requirements have to be met in the same timeframe. Deliver on the requirements that provide the best return. Deliver on the low hanging fruit first.
| What is the single most important requirement for the project? Can we group the business requirements into critical, major, minor, and nice-to-have categories?
|
Contradictory
| Maintaining a requirements document allows contradictory requests to be flagged. The executive sponsor must be prepared to resolve contradictory business requirements (for example, a report cannot be red and green at the same time).
| Are there any requirements that appear contradictory?
|
Ambiguous
| Similar to lack of clarity, ambiguous business requirements can have several different interpretations. Use precise English to describe business requirements. Use words that have one meaning - for example, "18 buttons" instead of "15-18 buttons" or "lots of buttons".
| Which requirements are ambiguous or unclear?
|
Too high level
| A statement of business objectives is very often confused with detailed business requirements. Ensure that the business requirements are described in enough detail for the team members to perform their jobs.
| Is there enough detail in the business requirements for an analyst to write a technical specification?
|
Vague/Incomplete
| Examine the requirements to ensure that there are no missing items. The rescue manager or a designate must understand the details involving different permutations and combinations. For example, if a shipping method is described in detail, it would be useful to point out that a similar level of detail is required for the other shipping methods within the scope of the project.
| What has been done to ensure that the requirements are complete?
|
| Incorrect/Inaccurate | The requirements are documented, but their implications have not been fully fleshed out and could be wrong.
| What has been done to determine the accuracy of the requirements? What is the quality assurance process for the business requirements? How do we know that we are being given reasonable requests?
|
