Baby-Stepping Into Requirements
In order to define scope, you must assemble a list of your project’s requirements by getting input from your clients and other stakeholders, and the writers at Bright Hub have covered the topic thoroughly. The first article discusses identifying what your stakeholders want and calculating just what you’re able to deliver. Next, you can read about setting out the elements of a business requirements document through examples, and we have an article that contains the basics if you’re new to the field and provides solid details for seasoned project managers looking for focus.
Then it’s time to dive headlong into learning about the specifics to consider. The article about how much time you should expect to devote is included mostly for its excellent examples of user stories, which can form the basis for project requirements. With that information in hand, you will be able to develop a project charter and learn how to write the project scope. The last piece in this section talks about methods for documenting the requirements list you’re pulling together with several templates available to suit your own style.
Choose Your Method
There are many project management methodologies and the people who work with them have their own favorite ways to proceed. Requirements can be operational or subjectively qualitative, or they can be simply technical.
Whether you work from your own style or have to follow a supervisor’s lead, there is a way to incorporate effective requirements gathering. A huge part of the process involves the input from stakeholders. Here you will learn about getting your stakeholders involved in writing the scope.
Next, we talk about Design for Six Sigma (DFSS); you really depend on the project charter with this method. You can learn about gathering Agile user stories because they are arguably the best way to come up with requirements; and even Scrum has a way of rolling ideas down the field. Extreme Programming might seem beyond the stages of requirements gathering, but integrating iteration planning serves as a great way to develop what you need to know. Last in this section, we focus on brainstorming.
Understanding Work Breakdown Structure
For many, there is no other way to define the technical or qualitative requirements of a program than through the use of a work breakdown structure. A WBS slices and dices your project into easily digestible tidbits so that you can identify the parameters of each step of the project. Once you break the project down into the smallest possible steps, you can identify what you need to accomplish in each step and then you have your requirements documented.
WBS analysis includes familiar techniques such as brainstorming and checklists, and methodologies such as SWOT analysis or SMART lists. We’ve included a simple Excel worksheet that practically leads you by the hand to break down your tasks. Learn about this technique from these articles.
Joint Application Development (JAD) Techniques
Learn more about JAD techniques, which involve workshops or brainstorming sessions among systems analysts, managers, customers and other stakeholders. Here we have tips for conducting a JAD session with specific reference to service requirements.
Next, realizing that JAD sessions facilitate the development of ideas within the boundaries of the project scope, they are also vital for extrapolating concepts for new types of projects or redrawn projects. Often the JAD coordinator leads the group through analysis of past, similar projects. You must be certain to draw the client and additional stakeholders into the process for optimized input.
Analyzing Your Requirements
The sections above discuss exactly how to develop a project scope and methods to gather requirements. The articles here flesh out the information you need: How do you analyze the business requirements you’ve identified? As you learn to define specifications and requirements, you will find the free Word doc template very useful—download it and give it a try; it takes you by the hand through all the details you must list.
You will also find a couple of articles about going through various stages of exploration and learning how to perform a requirements analysis. Finally, in this section you will find an example of a business requirements document, something to guide you as you proceed.
What Works Best for You?
What do you find to be most difficult about gathering requirements? What way is easiest? Many people develop their requirements list before they flesh out a project scope because otherwise they have to issue plan changes even before they get underway. Other people can’t live unless they draw out the plan parameters—the scope—and then figure out from there what they need to get things rolling. We love ideas, because they are the basis of knowledge: Your input is welcome in the comments section below.
Screenshot of scope statement template as created by Eric Stallsworth for Bright Hub
Screenshot of Excel project planning form as created by Linda Richter for Bright Hub
Screenshot of project requirements specification template as created by Sidharth Thakur for Bright Hub