13 Examples of Requirements Risk

John Spacey, updated on June 06, 2023

Requirements risk is the potential for losses due to a project's requirements themselves or the requirements management process. Such risks are closely tied to the quality of requirements in that low quality requirements represent a risk to the project. Projects are garbage-in-garbage-out meaning that projects that are based on faulty requirements are likely to face issues and potentially fail. The following are a few common examples of requirements risk.

1. Missing Stakeholders

The requirements management process fails identify or engage all stakeholders. For example, marketing is implementing a new product but sales isn't involved in the project.

2. Wrong Stakeholders

Stakeholders who don't have the requisite knowledge, skills or authority to deliver, validate or sign off on requirements. For example, requirements gathering may be assigned to junior employees who have inadequate access to experts in the organization.

3. Ambiguous Requirements

Requirements that are defined in such a way that they are open to misinterpretation. In some cases, stakeholders may intentionally define open-ended requirements in order to avoid making a decision or to protect themselves politically. In other cases, requirements are simply poorly worded.

The user interface should be streamlined to improve productivity.

4. Incomplete Requirements

Requirements that are incomplete leading to deliverables that are unstable, unusable or are generally unacceptable. For example, requirements for a system that make no mention of a user interface. Incomplete requirements can also refer to a set of requirements that are focused on functional requirements without adequate consideration of business and non-functional requirements.

5. Conflicting Requirements

Requirements are often given by different individuals who each present a wishlist that may conflict in various ways. The owner of the requirements may fail to resolve such conflicts.

Access to the system is restricted to authorized personnel in the HR department.
A user interface allows all employees to enter their hours by activity code.

6. Infeasible Requirements

Requirements that go well beyond the capabilities of the organization or system to which they apply. These risks can be mitigated with a quick feasibility or cost assessment.

The car will go from 0 to 100 mph in 0.00001 seconds.

7. Big Ball Of Mud

Requirements that lack overall consistency resulting in low quality deliverables. This is common when requirements are the result of ideas from many individuals without a strong owner who ensures a consistent high level cohesion. It can also be the result of validating requirements one-by-one without consideration of the requirements as a whole.

8. Unverifiable Requirements

Requirements that have ill defined criteria for verification.

The car will make people happy.

9. Undocumented Assumptions

Requirements that only work given a set of assumptions that are undocumented. For example, the assumption that an organizational change will be in place in time for the project.

10. Invalid Assumptions

Assumptions are often a major source of risk as they may be excessively optimistic or misinformed.

The Hong Kong office will be fully functional by August 1st.

11. Business Requirements As Functional Requirements

A business requirement that is stated as a functional requirement that fails to constrain the deliverables. In other words, a functional requirement that isn't directly actionable by those who are delivering the project.

Sales will improve by 300%

12. Lack of Traceability

Functional requirements that can't be mapped to business requirements, potentially invalidating the business case for the project.

13. Inadequate Validation

Requirements that haven't been validated by the appropriate subject matter experts. For example, non-functional requirements for a new financial system that haven't been reviewed by a security analyst.