Join Terri Wagner for an in-depth discussion in this video Structuring formal requirements documents, part of Project Management Foundations: Requirements.
- Mark Twain once wrote, "I'm sorry this letter is so long, "I didn't have time to write a short one." Writing concisely takes more work and effort than rambling on. To begin writing your requirements you want to start by defining the formality and level of detail of your deliverables. If your organization does not already have a methodology, you'll want to build and use document templates for content and structure. Well written, formally documented user requirements are key to a project success.
Writing with a well understood, clearly documented structure provides the ability to understand large amounts of information, while minimizing the number of requirements. Formal structure also allows you to easily find sets of requirements related to each other, and eliminate conflicts between requirements. Structure can also help you detect duplication, and realize omission before you wrap up the specify or document step. While writing the requirements you want to remember to document assumptions.
There are two types of assumptions commonly found in requirements development activities. First, things that are believed to be true but cannot be confirmed. Second, things that are confirmed to be true at present that would impact the project if they change. Since all readers need to understand the requirements, you want to write the requirements in everyday, understandable language. That may require you to convert technical elements into something everyone can get.
When you first started gathering the requirements, you may have gotten what seemed like random bits that now you want to organize in time order so your document can be read as scenarios. Since the basic sequence of requirements may not show what to do when something goes wrong, you can add a section for each exception, at the place where it could occur in the normal sequence. For ease of reading and comprehension you may also want to start with an overview section to give folks the big picture.
Let's look at some examples from the draft requirements of wind turbine project, for wind turbine control and preventive monitoring, to see how they are structured, and how the two chunks or bits of information now weave together into more understandable requirements. "The installed and operational wind turbines "shall be monitored for control applications "and preventive measures." Control monitoring shall measure turbine rotational speed and generator speed.
In this instance the control monitoring targets help guarantee safe turbine operation, optimized turbine power output, and ensure long structural life of each turbine. A couple of your stated requirements are, the control monitoring application shall calculate the balance between rotational speed and the velocity of wind, to regulate wind turbine performance. Another requirement is the control monitoring system shall keep the available energy above the minimum threshold, to maintain the turbine's structural health.
Another requirement says the control monitoring system shall optimize or limit the following variables: power output, generator speed, blade-angle adjustment, and wind turbine rotation. Another requirement is the control monitoring system shall use electronic converters, coupled to the generator, to optimize turbine power output. Now let's look at a second related category or chunk of requirements, preventive monitoring.
Preventive monitoring shall target extending the turbine life cycle, scheduling turbine maintenance, and predicting future fault conditions. The preventive monitoring system shall use sensors and hardware to acquire physical signals. The physical signals include: vibration in the drive train, oil quality, acoustic emissions, blade-strain monitoring, temperature, and power quality.
The preventive monitoring system shall use software to analyze the physical signals in a meaningful machine condition and predict failure. Preventive monitoring provides predictive maintenance to find and fix small problems before they become progressively worse. Preventive monitoring is used by the control applications to provide warning and safety features. Now you have structured, organized, and related requirements that give a little scenario.
Are you happy with these requirements? Is there any additional information you would want to include if this were your project?
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