Join Haydn Thomas for an in-depth discussion in this video Designing your requirements, part of Business Analysis Foundations.
- Children have a knack of knowing how to play parents off when they want to get their own way. We all heard it, "But Mum said..." Most stakeholders are just grown up kids, and of course, we like to get our own way. In projects stakeholders let you know what they individually want, and will refer to these as requirements. The difficulty comes when a stakeholder asks for something and they believe they are going to get their way. As a business analyst, your role is to ensure you gather these requirements from ALL the stakeholders.
Without a process to manage these requirements, it normally ends in tears. You then need to design or process a framework in which requirements are managed. This could be an iterative process, and appropriate time should be baked into the schedule to allow the process to take place. Let's examine the four main stages to support your requirements life cycle. Firstly you need to ensure you only collect requirements that the project has deemed appropriate, and that deliver the expected results and outcomes. Understanding the scope of the project is paramount, and will ensure you keep your stakeholders focused on what the project is expected to deliver.
Spend some time with your project manager or sponsor to truly understand what the project is and is not expected to deliver. While understanding what is in scope is good, there are always assumptions made if you're not specifically clear on what is also out-of-scope. Out-of-scope items contribute to the number one killer of projects, scope creep. Understanding both in- and out-of-scope provides you with the working boundaries for your requirements collection. You then move onto requirements gathering.
There are many elicitation techniques in gathering requirements from your various stakeholders. A few of these are interviewing, brainstorming sessions, observing a job or a process, surveying, and joint requirement sessions. It's best to practice using more than one elicitation technique, as this provides you the opportunity to verify and compare the results. This could be done by interviewing someone, but then watching them work. As they work, you may realize a few of these nuances of the job they did not share with you during the interview.
The next stage of the requirements life cycle is the process of requirements refinement. Just because the stakeholder has requested a requirement, you need to determine how it fits in the overall context of the project. Business analysts need to ensure the captured requirements reflect the current business strategies, and they still align with initial objectives of the project. Having a stakeholder classify their requirements into categories such as mandatory, important, and nice to have requirements will help you identify the nominative priority, differences, and potential conflicts.
The results from these refinement processes ensure requirements are understood by many, complexities have been identified and clarified, requirements have been prioritized, requirements are necessary for the business, and finally it ensures an understanding of how everything fits together. You should also do verifying of project benefits now to ensure the requirements you have gathered are truly aligned with the desired project benefits. Before you accept the requirements from the stakeholders as gospel, you need to undertake the final process of requirements verification.
Deciding head of time on who should confirm the requirements ensures the collection process does not delve into the dreaded "analysis paralysis" zone. Use popular verification techniques such as peer review, formal inspection, and having meetings where requirements are viewed and discussed with the whole team. Verifying the requirements against process models are also great to safeguard nothing is missed. This is a good time to stop a project if you can't get the business people engaged to define and confirm the requirements.
As requirements are needed to create the deliverables, allowing them to scope items and achieving the project objectives, the verification process will also generate the successful completion criteria for the project. Remember these acceptance criteria need to be specific, measurable, unambiguous, and tied back to the requirements. The requirements are then ready to be signed off by both the customer and the project sponsor, as they are the ultimate decision-makers, and just like the parents, they always get their way.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.