What are the most common risks and assumptions in SDLC requirements analysis?

1 Risk: Incomplete or ambiguous requirements

One of the biggest challenges in requirements analysis is to elicit, document, and validate the requirements from the stakeholders, users, and customers. If the requirements are incomplete or ambiguous, they can lead to misunderstandings, conflicts, rework, and delays in the development process. To avoid this risk, use clear and consistent terminology, prioritize and categorize the requirements, involve all the relevant stakeholders, and use various techniques such as interviews, surveys, prototyping, and user stories to collect and verify the requirements.

3 Assumption: Stakeholders know what they want

A common assumption in requirements analysis is that the stakeholders know what they want and can articulate their needs and expectations clearly and accurately. However, this is not always the case, as the stakeholders may have different or conflicting perspectives, hidden agendas, or unrealistic expectations. Use formal and structured methods to elicit and document the requirements, such as use cases, scenarios, and functional specifications.

4 Assumption: Requirements are stable and consistent

Another common assumption in requirements analysis is that the requirements are stable and consistent throughout the project. However, this is not always the case, as the requirements may depend on external factors, such as legal regulations, industry standards, or competitor actions, that can change unpredictably. To avoid this assumption, treat the requirements as not fixed or final, but as dynamic and adaptable, and use techniques such as traceability matrices, impact analysis, and configuration management to track and control the changes.

5 Assumption: Requirements are testable and verifiable

A common assumption in requirements analysis is that the requirements are testable and verifiable, meaning that they can be measured and evaluated against predefined criteria and standards. However, this is not always the case, as some requirements may be vague, subjective, or implicit, such as usability, security, or performance. Don't use ambiguous or general terms; use specific and measurable terms, such as metrics, benchmarks, and acceptance criteria, to define and validate the requirements.

6 Assumption: Requirements are aligned with business goals

A common assumption in requirements analysis is that the requirements are aligned with the business goals and objectives of the project. However, this is not always the case, as some requirements may be irrelevant, redundant, or contradictory to the business goals, such as adding unnecessary features, duplicating existing functionality, or violating business rules. Don't assume that the requirements are self-evident or obvious, but use techniques such as business analysis, stakeholder analysis, and value proposition to justify and prioritize the requirements.

7 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?