Page 126 - Project+

you’re designing a new toaster, a functional requirement might look like this: pushing

the green button will pop the toast out of the toaster, and pushing the red button will
begin the toasting process.

Industry or corporate standards may impact your functional requirements. In our
toaster example, perhaps industry standards state that electric cords on kitchen
appliances must be 20 inches or shorter in length. This requirement needs to be added
to the requirements document. You’ll need to research any industry standards that
may impact your requirements and document them because they may impact activity

duration or cost estimates.

If you work in a regulated industry, make sure you address the question of
whether any specific government or industry-related regulations impact the design
or delivery of your product. Regulatory noncompliance is a serious offense, and
correcting infractions after the fact can be both time-consuming and costly.

Non-functional Requirements

Non-functional requirements describe the characteristics of the functional

requirements. They are not performance or behavioral based. For example, a non-
functional requirement in a toaster example might state that the green button should
be 1.5 inches in diameter and the red button should be 2 inches in diameter.

In my experience, stakeholders are typically more prepared to discuss functional
requirements than non-functional, so come prepared with a list of questions. If all else
fails, asking why and what always works. “Why does the green button stop the toaster
and pop the toast?” And, “What would happen if I pushed the green button and the red

button at the same time?” If your PMO has a requirements template or checklist, use it
in your meetings with the client group.

The Requirements Document

As I mentioned earlier, requirements quantify and prioritize the wants, needs, and
expectations of the project sponsor and stakeholders to achieve the project objectives.

Requirements typically start out high level and are further defined, or progressively
elaborated, as the project progresses. You must be able to track, measure, test, and
trace the requirements of the project. You never want to find yourself at the end of the
project and discover that you have no way to validate the requirements. If you can’t
measure or test whether the requirement satisfies the business need of the project, the
definition of success is left to the subjective opinions of the stakeholders and team
members.

You’ve worked hard to gather and define requirements, and you don’t want all that
effort going to waste. You’ll record everything you’ve learned in a requirements

126