Join Haydn Thomas for an in-depth discussion in this video Exploring requirement types, part of Business Analysis Foundations.
- Making a cup of tea or coffee is a relatively easy task, or is it? Let's take my requirements as an example. Haydn requests a hot cup of coffee to be delivered daily at 7:30. This appears to be a simple requirement, though business analysts would need to delve further into the requirement to be able to deliver it. Requirements define what is needed, not the how. Requirements are continually decomposed until such time that you are able to deliver the requirements exactly to what the business or stakeholder requested.
As you delve further into the requirement certain aspects will need to be considered, documented and agreed to to ensure the overall objective of measureable outcome is achieved. The requirements breakdown structure, found in the exercise files, illustrates how the requirements are decomposed. They're always linked back to a higher level requirement. This is a great reference for you to use when gathering the requirements on your project. Business requirements identify very high level business needs to fix issues and support business opportunities.
These are normally defined by executives and senior people in the organization and key decision makers. Business requirements are commonly expressed in terms of measureable objectives and outcomes. Let's start with a sample business requirement that states, make a good cup of coffee to set up my day. We know that Haydn requested the hot cup of coffee. When a user requests something this is referred to as a stakeholder requirement. We'll need to align back to one or more business requirements.
Stakeholder requirements fulfill user needs, fix issues, and provide new capabilities that were not available before, and defined what is needed by the stakeholder. Since stakeholder requirements are often written in the user's own words they may not always follow good requirement writing criteria. This is where all requirements need to be SMART. The acronym spells out Specific, this means the requirement wording is clear, concise, and unambiguous.
Measurable, this means the requirement has a criteria which can be tested. Achievable, this means the requirement can be successfully attained given project environment. Realistic, this means the requirement is appropriate to the project's scope and available resources. Traceable, this means the requirement can be associated with a stakeholder, process, or system, function, model, design element, or test document. To deliver the stakeholder requirement we'll need to detail the solution requirements, and these are split into functional requirements and nonfunctional requirements.
Once the stakeholder requirements are detailed enough we need to understand the actions and activities that are needed to deliver against the stakeholder requirement. These are referred to as functional requirements. The best way to identify the number of functional requirements is to look at the explicit and implied actions required to deliver against the stated stakeholder requirement. Back to the example, we need to make the coffee and we need to deliver the coffee. Functional requirements decompose the stakeholder requirements into actionable detailed specifications.
Certain conditions or capabilities need to be in place to enable the actions and activities to happen. These are referred to as nonfunctional requirements. They enable the functional requirements to happen. They define the parameters, attributes, constraints, or other characteristics the stakeholder and functional requirements must adhere to. To make a cup of coffee we need the measurement for the size of the cup, how hot is hot, what type of coffee, what do you take with your coffee, what procedures must be followed, relevant governance and compliance issues identified, performance, scalability, cleanup, and the list goes on, and that was just making the cup of coffee.
You now need to document the nonfunctional requirements for delivering the cup of coffee. Nonfunctional requirements cover the legislation, regulation, policies, procedures, conditions, and things that need to be in place to deliver the functional requirements. Finally, once you've made and delivered the coffee to Haydn, the next level of requirements are called transition requirements. These requirements document what is needed to confirm acceptance of the stakeholder requirements, and deliver against the higher-level business ones.
In our coffee example, this is where Haydn will now determine whether to accept or reject the cup of coffee based on his specific higher-level requirements. Transition requirements are also determined by documenting the successful completion criteria, where the stakeholder will accept the outcomes from what the project has delivered, and is willing to now live with the new product or service they requested. Ensuring you have captured the above requirements, Haydn should now be happy when he receives his daily hot cup of coffee to his liking. Now that we have listed the requirements, and determined the what, the actions, the conditions, the capabilities, and all things that are needed it's time for Haydn to enjoy his cup of coffee.
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.