Join Haydn Thomas for an in-depth discussion in this video Building the requirements plan, part of Business Analysis Foundations.
- How do you get the tune out of one person's head and into another's, and confirm you are all singing the same song, melody and notes. You share the musical score. A requirements plan is what brings all your requirements-gathering elements together to create a package that is understood and delivers the musical magic your stakeholders are requesting. Requirements come from people in departments and organizations that are undertaking the requested changes. And identifying them provides the basis on who you need to engage with.
People in projects can also be classified as input people and output people. We seek the input from people that are requesting and influencing the changes and capture them as requirements. Business analysts then package these requirements into a requirements package, as a way to communicate the input people's needs. A requirements package is used by the output people who take these requirements and turn them into artifacts, services, packages, or systems that meet the input people's requirements.
Following a few guiding principles will make your requirements-gathering journey easier and more efficient. First, we need to understand the definitions of terms and meanings of acronyms by creating and using a glossary of terms within the domains you'll be working. I would encourage you never to use acronyms such as FTE, SRs and NFRs that always spell out what they stand for. Full-Time Equivalent, Stakeholder Requirements, Nonfunctional Requirements. Throughout the project, continue to update the glossary.
This helps both the input people and output people in their understanding. We then need to schedule time with stakeholders to gather their requirements. Sending a detailed purpose and agenda and any supporting documentation ahead of time, prepares the stakeholders on what you were trying to achieve during your time together. Do not underestimate the amount of time wasted in requirements-gathering sessions, when people are not prepared. Next, determine ahead of time how you will capture information from the requirements session.
Asking questions, probing, scribing and maintaining the flow of the meeting is difficult. Capturing notes is very important but capturing accurate information is the aim of the game. This is when you believe you are singing a nursery rhyme, Mary Had a Little Lamb, and you're capturing London Bridge is Falling Down. Similar melody, same beat, different words. As requirements come in differing detail and importance to the project, classifying the requirements will help the output people distinguish between the mandatory, important and nice-to-have requirements.
A requirements package also allows you to distinguish between the differing types of requirements, Business, Stakeholder, Solution, including functional and nonfunctional, and Transition. A good practice to follow is to use consistent language throughout your requirements. Stakeholder Requirements should start with "The user requests..." Functional and Nonfunctional Requirements should start with "The solution shall..." or "The system shall..." As you capture your requirements, validating the requirements and capturing what the stakeholders are really trying to share can be gained through the practicing of a few of these techniques.
Firstly, paraphrasing. "So, what I heard you say" was. When capturing supporting artifacts, documents, specifications, reference material, ask how this requirement will fix an issue or contribute to an opportunity. And finally ask, how does your requirement align to a scope item, deliverable, or objective. As we capture these requirements, we all need to make the requirements traceable, to capture who defined the requirements or made the request, when it was captured, who was the author/analyst and the person or team who wrote the requirement.
This is very important to allow the output people to contact the right resource when seeking any clarification. The deliverable expected from executing the requirements plan is the presentation of the requirements, artifacts, glossary of terms and supporting documentation into a requirements package. The final step is communicating the requirements. After you have verified and validated the requirements with each of the stakeholders, the package is ready for sign-off by the customer and project sponsor.
Once sign-off has been received, they become base-line requirements, and any changes from this point will need to follow the prescribed change management process to understand the impacts of the change within the context of the entire project. The time invested at the start of the project in gathering quality requirements will reduce the amount of time the output people will need in clarifying what the input people are truly requesting. The business analyst's role as the conduit and conductor between these two people will have you making wonderful music that will be enjoyed by all.
Discover where business analysis lives in the project life cycle, how to initiate a project, the best way to gather requirements, and smart strategies to monitor results and test outcomes.
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.
- Understanding what business analysts do
- Defining business opportunities and objectives
- Identifying stakeholders
- Gathering requirements through observation and brainstorming
- Validating requirements
- Developing project acceptance criteria
- Implementing, testing, and closing your project<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.