Join Haydn Thomas for an in-depth discussion in this video Creating a requirements package, part of Business Analysis Foundations.
- Picture yourself buying a new car. You go to the car dealer and you take a look around the lot. You might've done some research ahead of time and know the features that are available and what you want in your shiny, new vehicle. You find what you're interested in and go for a test drive. Ultimately, what will likely get you to purchase the vehicle is how it looks and how it fits you personally, assuming the performance of your car does not discourage you during your test drive. Your requirements package is a lot like a car. There are pieces that must work well. Like the engine in a car, the requirements you capture must be complete and accurate.
However, the whole package, like the car's body type, color, and comfort of the interior will make or break whether you buy the vehicle. Like the car, there are a number of elements that must come together in your requirements package for people to buy. To ensure your sales record is sound, you need to ensure the inputs are aligned, the data you have collected are sound, and the setting, like the body of your car, is suitable as well. Let's first talk about the input. The project charter must set the stage for your requirements. The sponsor of your project will have specific expectations about what business outcomes that will be realized.
The requirements package must fire a crisp introduction of the intended business improvements and how they'll be realized, support the intent communicated in the project charter. Next, the providers of requirements input should be conveyed clearly. Most senior leaders will have a very distinct idea about who the experts are in their organization. In the introduction to the requirements package, ensure that you talk about the key stakeholders that provide a requirement input. After the input, the requirements data needs to be solid, but also represented in various formats to appeal to those who want to read the detail as well as those who are more visual and need to absorb information via graphics.
So first, ensure you have the requirement details laid out in an easy to find manner. Use tables of contents that sort the requirements in ways that people will quickly understand, like via the organizational chart or the products you business. Second, ensure you are using clear graphics that are easy to absorb. Context diagrams and flow charts are great and commonly used. However, ensure the text that outlines the steps is easy to see. Don't try to put too much detail in the boxes in your graphs.
Ensure the high-level and detailed requirements and proposed improvements are included in the requirements package. As your requirements packages are likely to be viewed by different audiences, having different levels of detail with both text and graphics is important to avoid unnecessary revisions requested by stakeholders who cannot find what they are seeking. Lastly, you should include any constraints, assumptions, and dependencies you had to consider when collecting requirements. These will likely have altered your approach or the areas your business that were included in your requirements collection exercises.
Including these elements in your requirements package are like adding a great body style or color to a car. They are likely to seal the deal and ensure that your requirements package sells the project and the great work you put into collecting requirements effectively.
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.