How to develop requirements

- [Voiceover] The project goal, objectives and solution identify what you're trying to achieve, and the general approach for getting there. Requirements provide the details of what the outcome must do, and the features it must have. They describe the specific needs of the project. Getting requirements right is vital, because if you don't identify a project's true requirements, the stakeholders won't be satisfied with the project results, and if you include requirements that aren't really necessary, the project will probably take longer, and cost more than it should.

For the conference center project, one objective is to use state of the art computing and audiovisual equipment. One of the requirements could be to use ultra-high-def monitors in all the presentation rooms. Another requirement could be to offer 802.11n wireless networking throughout the hotel and conference center. These requirements are both necessary and specific, although you can expand them to provide even more detail.

Developing requirements is challenging for several reasons. Stakeholders might describe their requirements incorrectly, or provide inconsistent or contradictory requirements. They might leave out requirements they need, or include nice-to-haves. Sometimes people who aren't stakeholders try to append their requirements on to your to-do list. In addition, stakeholders often balk at committing the time needed to help define requirements.

The first step in developing requirements is to gather information about what is required. There are several techniques for gathering requirements. Interviews are a great way to illicit information about requirements. The key is to pick the right people to interview, and to come prepared with a list of questions. If your project involves several groups, you can use brainstorming sessions, or focus groups with representatives from each group to discuss their requirements for the project.

These meetings may also help you to obtain buy-in from the departments that attend. Another approach is to observe how people work. In other words, watch what people do in their day-to-day activities. To make sure you get the requirements right, write them up, and review them with the workers. Questionnaires and surveys are another way to extract requirements from stakeholders. It's important to build these documents carefully, so you don't influence the answers you get.

If documentation of results already exist, you can obtain requirements by analyzing documents, or reverse engineering products. Once you've collected initial requirements, you need to analyze them to make sure they make sense. Chances are, you'll discover that you don't have all the information you need, or that requirements are inconsistent or duplicated. It takes several rounds to get a project's real requirements.

After you do some analysis, you go back to your stakeholders to ask more questions, and clarify their answers. Eventually the requirements will start to make sense. When that happens, it's time to start documenting those requirements. To ensure that the requirements are correct and everyone understands them, it's important to write them in clear, easy to understand language. Organizing requirements into related categories can help you eliminate duplication and conflicts.

Requirements provide detailed descriptions of what a project is supposed to deliver, so it's important to get them right. To learn more about developing project requirements, check out Terri Wagner's course, Developing Project Requirements.