Join Terri Wagner for an in-depth discussion in this video Discovering requirements-analysis techniques, part of Project Management Foundations: Requirements.
- There are a number of different modeling techniques you can use to reflect your project's requirements. Modeling techniques will allow you to simplify and focus on key areas. This helps make complex systems understandable while allowing you to describe different perspectives through use of different model types. Modeling techniques can help facilitate communication with your stakeholders and translate requirements into design solutions.
Let's start with a business-domain model. This is a high-level description of the as-is condition of your scenario. Whether that's the current size of your company with all existing wind turbines or the current capability of your organization's systems that your about to enhance. Then you can provide a high-level description to the proposed to-be solution. The envisioned outcome. The gap between as-is and to-be describes how much change will be needed to achieve the project solution.
This helps define the boundaries of the solution model. I'd recommend this step as a predecessor to detailed analysis. Once you have the big picture, now you can begin the decomposition process. In decomposition, you're breaking high-level goals also known as business requirements into lower-level goals with measurable objectives, thus translating your stakeholders' stated requirements into a solution design.
Selecting the types of analysis models or models you use will be dependent on your organization or client and how they typically use information. Let's look at three of the most popular models. Data and behavior models, process flow models and usage models. Are you data driven? Does the data drive how things work in the output or final solution? Do you have data dictionaries? If data is the most important thing then pick a model that supports that.
Examples include use of business rules and data dictionaries. A process driven model is different. It's really saying over the time sequence of events, what happens inside the solution as we step through and do things. This is more traditional like flow charts and decision flows. In other words, decision-driven from start to finish. If the process and the flow of events is key to your solution, then the process model will work best for your project. Examples include data-flow diagrams and flowcharts.
With usage models, you model the static data and the dynamic process together. Then you document how the user is interacting with the data and the process together. Examples include use cases, prototypes and storyboards. The goal by the time you have everything broken down and analyzed, is to have clearly written, measurable requirements for your project. Let's say you're going to build a garden in your backyard. One of your written requirements states that the garden shall occupy a 25 foot by 40 foot area.
That's a nice clear requirement in terms of size. Added clarity about the exact location would make it a better written requirement. Another requirement states the garden may include a three foot by 10 foot rock wall. Now this requirement needs some improving. Will the wall be three foot high or 10 foot high? Will the wall be included or not? Focus words such as shall and will leave no room for doubt where may leaves room for interpretation.
Better to be crystal clear in your requirements document rather than leaving it to chance. Back on our wind farm, breaking draft requirements on turbine control capabilities into preventive control versus wind turbine control is using functional areas to chunk your requirements from the top down. Be sure to keep in mind with these two areas that there are sure to be overlap and interfaces between the capabilities to be addressed both operationally and technically.
So requirements analysis takes the gathered requirements and groups them into helpful categories. Then through modeling helps us to determine if we have enough detail for all to clearly understand. What's your favorite modeling technique?
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.
- Classifying requirements
- Developing requirements
- Investigating requirements
- Documenting requirements
- Validating requirements
- Managing changing requirements