Join Terri Wagner for an in-depth discussion in this video Investigating requirements analysis, part of Project Management Foundations: Requirements.
- You gathered all this information during elicitation, now we need to do something with it. Let's say on the wind farm project, elicitation results found that the control systems need to monitor the individual turbine performance, as well as the aggregate wind farm performance, and power efficiency. This opens up a lot of questions as we'll need to figure out the capabilities required, the hardware, software, and process capabilities to support this, as well as reporting mechanisms, performance alert levels, and how it's going to interface with the end users who capture, analyze, and act on the control monitoring data in some way.
You'll want to continue asking questions during the analysis process, until you have a clear understanding of all that will be needed at a detailed level, so that your requirements documents can capture all capabilities and how they will be delivered. While you're eliciting the information you'll want to consider what level the information they're providing you is at. Is it high-level concepts, or detailed information, and based on the scope of what you're doing where does this piece or these pieces of information fit in? During the elicitation process you may already have a sense of the buckets or categories you're going to put elicited information in.
These categories may work in the beginning, and then you might decide later that you'd like to restructure the categories differently, and that's okay, that's the nature of progressive elaboration or iteration. In elicitation we're gathering information, and in analysis we're making sense of it. In elicitation we're receiving from the stakeholders the stated requirements, the things they say they need, in analysis we're analyzing and deriving the real requirements for what capabilities we're actually going to implement in our solution.
Those are the two pieces, and it's like a metronome, back and forth, analyze some, do a little modeling, take a look, discover you don't know everything you need, go back for more information, and after doing this for a while you may feel you have enough information to start documenting the requirements into one of your templates. At some point, documenting or specifying the requirements will start to come into the swing of the metronome, when you feel you have enough information to start to write. If you have a strong methodology within your organization, and your templates and processes are well-defined, your templates might help drive the process up front, and guide what information you want to gather, as well as your analysis activities for what you're going to do with that information.
Working from the output template backwards to elicitation and analysis helps drive a pretty consistent high-quality effort, when process or template structure's available within your organization. There's more than one way to go about this process, feel free to try a couple different approaches, and determine for yourself which order works best for you. We have to figure out what's going on with these requirements. They're not just individual statements, but pieces of the big picture, and you need to figure out how all the pieces fit together.
To learn more about the pieces you'll start capturing the requirement's attributes. If you're using some kind of requirements management tool, it's not just asking you for the requirement, it's going to give a unique number, then it's going to ask you for the source, for related requirements, for priority, and for risk. There are lots of attributes and things you can customize in the software, so that as you type of your requirements you can gather and document consistent information about individual requirements, and about common groups of requirements.
There are many requirements management programs out there, some better than others. If a tool hasn't been preselected for you, be sure to research thoroughly before selecting one. That means you have to decide what attributes you're looking for, and which attributes you will document for this project, because if you're going to be looking for a degree of priority from the stakeholders, you'd kind of like to know that before you start asking your questions. Then you can ask them for what's most important while you're in elicitation.
Then you can use the information in analysis and go back, and make sure it makes sense. Even when capturing the output of your analysis in traditional requirements development it isn't done all in text. Some things can just be expressed better in some kind of a table, or matrix, or spreadsheet that allows you to relate information and show how the pieces go together. Then you'll need to figure out what you're going to name your requirements. Are you going to be an IEEE shop, and call them capabilities, conditions, or constraints? Are you going to use old school structure of functional versus nonfunctional approach? Or are you going to be more focused on who's doing what, such as business, user, system, often used in an IT type of project? Assumptions and constraints bound things and help you set the limits of what you'll be doing, and what's outside the scope of this project.
Assumptions are statements you're taking to be true in the absence of knowing for sure. You document in your requirements for all to read, and hope your stakeholders will let you know if they feel that a statement is not true. Constraints are more limits and boundary conditions for your project. These things can be associated with a single requirement, or a whole chunk of the project scope, or the overall project, so a global assumption, or a global constraint. The output from this step is to document the results of your analysis.
Documenting can be done in many ways including text, matrices, diagrams or models. How do you currently name your requirements? Is that the way you do it, or your entire organization? If it's not consistent right now, what might you do to help your organization pick one method for all to start a more consistent approach?
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