Requirements are the basis of any project. When developing products or services, defining requirements is critical to successfully satisfying project needs. To define the project scope and fully build out a Work Breakdown Structure (WBS), you must learn what your stakeholders require. Clearly understanding the project’s objectives is key. Once you know the needs, you can begin to translate them into requirements.
Identifying the correct stakeholders is always the first step of requirements management. There is nothing more frustrating than going into a requirement brainstorming session with a full room containing everyone except the people you really need. Mitigate this issue by identifying appropriate stakeholder engagement at the onset of the project.
Consider asking the following questions:
- Who will be directly responsible for the development of the solution?
- Will they be directly impacted by the results of the project?
- Are they external to the organization?
Answering these questions will save you a lot of headaches later by helping to steer you toward identifying who needs to be involved.
Once the appropriate stakeholders are chosen, you can leverage interviews, surveys, brainstorming sessions, focus groups, and other information gathering tactics to ascertain stakeholder needs. You can then can begin to elicit requirements from your analysis. Elicitation is an iterative process, so it is perfectly acceptable to ask clarifying questions as needed to confirm your understanding. This allows you to draw out information at every level throughout the project, and it’s critical because initially stakeholders may not be able to fully articulate what they need. Asking questions narrows their focus and helps them think outside the box.
When you fully understand stakeholder’s requirements, begin to translate them into clear, concise, and structured requirement statements. These statements will generally begin with “shall” to express a product’s capability and should be understood the same way across multiple stakeholders.
The requirements should be formally documented. An ideal way to document requirements is using an Excel spreadsheet, SharePoint list, or other tool with a configuration management capability to ensure version control. A Requirements Traceability Matrix (RTM) could also be created to trace requirements throughout the project’s lifecycle. This ensures requirements are fulfilled. When the requirements are documented and approved, you can baseline them. Baselining helps manage expectations, so requirement creep does not occur.
Want to learn more about the requirement management process. Please join me for my upcoming three-part series on Project Requirements Management. We’ll dive deeper into successfully gathering and managing solid project requirements!
Part 1: Introduction to Requirements Management: This first session defines different types of requirements and examples for each. I’ll identify where requirements fit within the project lifecycle and how they provide value to project management.
Part 2: Gathering and Writing Requirements: This second session reviews how to implement a structured approach to gathering requirements. Create clear and concise project requirements and review examples of complete, comprehensible, and verifiable requirements.
Part 3: Monitoring and Controlling Requirements: This third session explains the importance of traceability and why it is essential to ensure quality is maintained throughout a project’s lifecycle. Provide examples of tools used to trace requirements.
