Every project needs clear requirements. No exceptions.
Without them, a project turns into a group of people standing around, unsure of what to do, essentially making things up as they go. This scenario may sound familiar to anyone who has been involved in disorganized projects.
What are requirements?
According to the Association for Project Management (APM), “Requirements are the wants and needs of stakeholders clearly defined with acceptance criteria.”
Requirements engineering is the process for managing the entire lifecycle of these needs and involves five key stages:
- Elicitation – Gathering the wants and needs of users and stakeholders.
- Analysis – Ensuring that requirements are comprehensive, viable, prioritized, and consistent.
- Documentation – Organizing and recording requirements for clear communication.
- Validation – Confirming that the requirements accurately represent the users’ needs and the solution being built.
- Management – Maintaining and controlling the requirements, especially as they evolve over time.
Let’s dive deeper into these stages:
1. Requirements Elicitation
Sometimes, the term “requirements capture” is used, as if stakeholders’ needs are floating around, waiting to be caught. However, requirements are not passively waiting; they must be actively elicited.
Elicitation Methods:
- Brainstorming: Promotes creative problem-solving with group discussions.
- Card Sorting: Helps understand how users perceive information structures.
- Document Analysis: Reviews existing materials to gain knowledge on demographics or objectives.
- Focus Groups: Small groups of people discuss useful features and solutions.
- Interviews: One-on-one sessions with users to uncover their goals and frustrations.
- Observation: Watching users perform tasks to understand their workflows.
- Prototyping: Creating early product models to test with users.
- Surveys: Gathering quantitative data for analysis.
- User Personas: Creating profiles to empathize with specific user needs.
Eliciting requirements involves interpreting genuine needs, not just compiling a wish list of requested features.
2. Requirements Analysis
Once you’ve gathered a set of requirements, it’s time for analysis to ensure they are comprehensive, feasible, and aligned with the project’s objectives.
This phase is crucial because 80% of project errors occur during the requirements phase, yet it often receives less than 20% of a project’s time.
Key steps include:
- Categorization: Label requirements as either functional (what the system does) or non-functional (how the system works).
- Prioritization: Using methods like MoSCoW to categorize needs by their importance:
- Must have
- Should have
- Could have
- Won’t have
- Filtering: Ensure requirements avoid problems like duplication or ambiguity and align with quality standards such as completeness, feasibility, and measurability.
3. Requirements Documentation
After analyzing requirements, document them clearly to communicate with stakeholders and developers.
A good requirements document typically includes:
- An introduction to the project.
- Relevant models (e.g., functional, data).
- A glossary.
- Detailed requirements with sufficient context.
One popular method for documenting requirements is through user stories, which frame requirements from the user’s perspective:
- As a… [user type],
- I need… [specific feature],
- So that… [desired outcome].
User stories focus on meeting user needs rather than prescribing technical specifications.
4. Requirements Validation
The next step is validating your documented requirements. This ensures they accurately represent what users and stakeholders need.
Validation methods include:
- Reviews: Examining requirements for errors or inconsistencies.
- Prototypes: Testing early versions of the product to see if it meets user needs.
- Test Cases: Writing tests to ensure the requirements can be implemented.
Validation is essential to ensure requirements are complete, realistic, and verifiable.
5. Requirements Management
The final phase involves tracking and managing changes to requirements throughout the project.
Key Concepts:
- Traceability: Being able to trace requirements back to their origins and forward to their resolution. This is critical for managing changes and ensuring alignment with business goals.
- Linear vs. Iterative: Different methodologies handle requirements management differently. For example, linear approaches (like Waterfall) are more rigid, while iterative approaches (like Agile) are more flexible.
- Configuration Management: Controlling changes and ensuring quality across the scope of requirements.
Agile frameworks often rely on iterative approaches, where product owners manage changes during sprint reviews and retrospectives.
Summary
Requirements engineering consists of five interdependent stages: elicitation, analysis, documentation, validation, and management. While these concepts may seem detailed, they offer a structured framework that’s essential for delivering high-quality solutions. By following this approach, even smaller, lower-risk digital projects can benefit from clear and actionable requirements.
Expanding its reach beyond CRM, Salesforce.com has launched a new service called AppExchange OEM Edition, aimed at non-CRM service providers. Read more
In Marc Benioff's own words How did salesforce.com grow from a start up in a rented apartment into the world's Read more
Salesforce.com, a prominent figure in cloud computing, has finalized a deal to acquire Jigsaw, a wiki-style business contact database, for Read more
Following swiftly after last week's successful launch of Financial Services Cloud, Salesforce has announced the second installment in its series Read more
