5 Validating and Controlling Your Requirements During Project

Execution

5.1 Verifying your requirements

So let's say I just took your order for your favorite drink at your local coffee shop and I say, "Let me
repeat that back to you. "You ordered the decaf vanilla low-fat latte "with a twist of hazelnut in a large
cup." Ordering a beverage is never easy, and if the person capturing the order has not verified your
requirements, you may end up with a light mocha with a French vanilla twist three hours after you
expected it.

Enjoying the benefits of your favorite beverage can be challenging if verification is not undertaken
appropriately. There are a number of verification pitfalls that I want you to be aware of. First is limiting
the validation to quality assurance personnel or testers only. Next is analysis paralysis, frustrating
personnel who contribute to the requirements. Another pitfall is not taking a holistic point of view.
And finally, considering verification as a one-time event.

The verification of requirements gathered from your stakeholders is imperative in successfully

ensuring the expected results meet the needs. The validation and verification process is to be
performed at varying stages throughout the project life cycle. Deciding ahead of time who and how
you should be confirming requirements should always be in the business analyst's mindset. Business
analysts capturing the requirements with the stakeholders are close enough to understanding the
context of the business and understanding the organization's drivers and needs.

The verification process may include multiple people and require meetings where requirements are
reviewed and discussed to ultimately obtain sign off of the requirements from the customer and the
sponsor. You can commence the verification process at the early stages where you replay or repeat
the requirement back to the stakeholder to seek clarification that you captured the requirement
correctly.

This can be undertaken in several ways.

 The first is through paraphrasing, where you replay what you hear back to the stakeholder,
who then verifies what was said.
 Next is capturing the requirements in a written format and sending it back to the stakeholder
to verify or update.
 The final way is through capturing the agreement from the stakeholder and possibly their
manager.
Requirements are captured and then classified into business, stakeholder, functional, and
nonfunctional, and finally, transitional requirements. This is known as the requirements breakdown
structure and captures how the low-level requirements align to meet the high-level business and
stakeholder requirements. This also ensures the requirements complexities have been identified and
clarified within the context of the entire scope of the project.

The next stage of the project life cycle is to ensure that each and every requirement will deliver against
a scope item to create a deliverable. And that deliverable will achieve one or many measurable project
objectives. The next stage is to establish the priority of the requirements and how it best aligns to the

32 | P a g e
achievement of the project objectives, expected outcomes, resolving the stated issues and problems,
or delivering against the new opportunities.

These requirements can then be captured in three categories: mandatory, important, or nice to have.
Categorizing your requirements into these three categories will help you figure out which ones are
most important. Making sure that your requirements are necessary for the organization is the essence
of this stage of the verification process.

The final stage of the verification process is to ensure the requirements pass the SMART Test. Are they
specific, measurable, achievable, realistic, and traceable, and written in a language that ensures
understanding by many. Ensure the requirements gathered align with the initial objectives of the
project by analyzing each item and considering where the priority of your project lies in the project
portfolio, focusing on the synergies and conflicts between business and user needs, and finally,
analyzing any off-task requests for their true motivation. Failure to capture the essence and specifics
of any requirements in isolation may not cause any major impact.

Though when these requirements are collated, validated, verified, aligned, and agreed to, they
represent the true needs of the project. It is only then that the requirements package is ready for final
sign off by the sponsor and customer. You can then relax in the knowledge that you have done your
utmost to deliver the decaf vanilla low-fat latte with the twist of hazelnut in a large cup, and your
stakeholder appreciates your efforts to make it happen.

5.2 Exploring requirement-verification techniques

During the Christmas season, children write out their letters to Santa, with their lists, and we know
Santa is then always checking the lists and then checking them twice.

If this is the only verification technique business analysts undertake, this may lead to an
underwhelming present called a failed project. As with the Santa list, the more specific and
measurable the list is, the greater chance of waking up at the end of your project, and having happy
stakeholders, customers and sponsors. Requirements change over time and the diligent business
analyst will need to add these verification techniques to their toolkit.

First up, we have two techniques surrounding documentation inspection approaches: peer review and
formal inspection.

 The Peer Review Verification Technique is a less formal approach. Start by identifying a skilled
resource, someone who has not been involved in the requirements gathering, to comment on
their understanding of what the requirements are trying to convey. This is best performed by
simply circling words that do not make sense or require clarification. This is given back to the
business analyst to rectify with the stakeholder, so to achieve the goal of the requirement
standing on its own and being easily understood by many. The aim here, really, is to identify
improvements rather than a rigorous confirmation.
 The Formal Inspection Technique is completed after the requirements package has been
collated and passed through the first round of Peer Review. Formal inspection is a disciplined
approach, including subject matter experts, a moderator, note takers and requirements
collectors. These parties are needed as paragraph-by-paragraph you review the entire
documentation, confirming each requirement will achieve a project objective, has a specific
exit criteria, and the document is ready to proceed to the next technique: the capturing of the
acceptance criteria. Acceptance Criteria is the technique to determine Are we done yet? and

33 | P a g e
 How will we know? The more specific requirements are, the greater the option in
predetermining the measurable success criteria. Undertaking the acceptance criteria
technique is valid when: The completion criteria is tied back to the high-level business
requirements; The requirements are quantifiable and clear; The traceability matrix has been
applied as to who has asked for the requirement and when; And finally, you have completion
criteria signed off by the sponsor and customers. You know when this is done when the
requirements you have gathered will achieve the overall project objectives. You won't know
the answer for this, for certain, until the detailed design begins in the construction phase.
With Santa only arriving once a year, you will know when to stop gathering requirements when the
current state and future state is documented, you have used at least two different techniques to
gather requirements, iterated through the gathering process to at least twice, for each major business
area, and have used independent reviewers.

As you undertake these informal and formal reviews, ensure you have a process to manage verification
findings, such as, change requests and issues management. Other supporting processes you will need
to define and manage include, labeling severity codes and prioritize resolution accordingly. Derive
processes to revisit requirements as needed, and finally, confirm the issues do not reach the project
deliverables.

The aim all along is to have the requirements package documented, verified, with predefined success
criteria and signed off by both the sponsor and the customer. This makes for a far easier transition
into the design and construction teams who are charged to transform the requirements into project
deliverables.

Santa's elves are always a lot happier preparing all the gifts when they know Santa has undertaken his
appropriate due diligence and analysis. The elves' understanding of the importance of the list, as
delivering against the kids' expectations, is what will put a smile on the kids' faces when they wake up
on Christmas Day.

5.3 Creating procedure manuals and documentation

Creating documentation is your chance to leave a legacy. Good documentation enables people to
perform their job properly and efficiently. On the flip side, lack of documentation or poorly written
documentation can create havoc within a business unit.

Let's begin with the procedure manuals. The purpose of procedure manual is to explain how a process
is intended to function. Who does what, when, in what sequence, and to what governing standard. It
becomes the single source of truth on how the new processes will deliver the ongoing benefits and
outcomes. Keep in mind, the procedures manual could be used in many different locations and the
manual enables processes to be used consistently across the company, maybe even worldwide.
Procedure manuals should be easy to read, with plenty of white space, provide details, but not be
complicated, use a combination of text and diagrams and provide complete end-to-end information
for a given procedure.

When writing or updating a procedure manual, refer to the original requirements to ensure
consistency with the intent of the solution. But keep in mind, there may be very important processes
that occur offline which need to be identified and documented. Your future state process maps should
contain some of this information but you'll need to expand on the level of detail to be included in your
procedure manual. You will likely need to hold workshops with key stakeholders to obtain the
necessary information to populate the procedure manual. A procedures manual will be more detailed

34 | P a g e
compared to any other documentation. With that being said, you need to write it generically, so that
the manual is usable for all intended users. Expect to write several drafts prior to final management
approval.

Another key set of documentation to be produced is the training materials. The training materials
typically focus on how the user will interact with the new prodcut. However, training materials will
also be required for new business processes or supporting the introduction of a new project product.
How the materials are organized is important as you want the user to be able to quickly absorb the
information being presented. The training materials should be based on the requirements. The
training materials will need to be reviewed for content, accuracy and easy-to-follow instructions.
Training materials should be easy to read with plenty of white space, be engaging maybe a few
demonstrations or sample outputs, provide enough detail and context, use a combination of text and
diagrams with specific examples, and finally, detail where additional support can be sourced.

So I guess you're wondering, "What's the difference between training materials and a procedure
manual?" Training materials are designed to teach readers something new. They may be self-paced.
Readers do the tutorial at their own rate. Or they may be designed for use with a training course. They
seldom try to teach everything but provide a basic foundation upon which readers can build their
knowledge. Once the products or procedures are learned, the procedure manual is typically used. The
key to good training is providing a variety of different ways for the audience to learn. For example,
have them complete pop quizzes to see what information they have retained, create a role play
situation, provide a combination of individual and group activities. Have them do something versus
just read. Good training materials enable the trainer to engage actively with the audience and enable
more information to be retained.

As a business analyst, you provide a pivotal role in creating the transition material from the project
team owning the product to the business. The documentation you produce enables the business to
take ownership of the project products going forward.

You will know when you've done an awesome job when, one day, when they enhance what you have
created, a fellow project professional walks up to you and says,"Thank you for the legacy documents
you created." There is no better sense of satisfaction than that.

5.4 Measuring verification activities

I am fond of the color blue while my wife is more partial to purple. It is interesting how two people
can see the same thing and have widely differing views as to how desirable it may be.

Unfortunately that can be the case with requirements you collect. Sound verification techniques with
appropriate metrics to measure your success can help you overcome changing colors when what you
started with would work all along. Here are approaches you can use to ensure you are appropriately
verifying your requirements.

 First ensure aligned understanding. On occasion different people will interpret something
you've written differently from others. While often unavoidable that does not necessarily
mean you should change your requirements. If multiple people interpret what you have
written in the same way differently from what you meant, that is an indication that you need
to clarify what you have written. A rule of thumb here. If nine out of 10 people have a common
understanding of what you are trying to convey, you have likely written a valid requirement.

35 | P a g e
  Second, watch for differences of opinion. Any differences should be explored to see if you can
find common ground. Seek to understand the concern, focusing on the perceived business
impact. Try to resolve the differences if you can. If the issue is simply a concern about change
itself it's probably okay to move forward, even if some conflict exists. Rule of thumb here. If
75% of the people you talk to believe the requirements or approach will bring business value,
you are likely okay to move forward.
 Third item, watch for missing or invalid requirements. 90% or more of the people you use to
validate your requirements should believe the requirements are complete for the intended
scope of your project. If that is the case you are likely in good shape to move forward. That
being said, in the event someone says that something is missing, it is a good idea to capture
that idea and share it with others. In a case where someone says the requirement is invalid
try to understand exactly how the requirement is inaccurate in business process terms. The
idea here is to sort out actual business problems from personal items that present
uncomfortable change. Actual business process issues should be investigated further through
interviewing with other stakeholders.
 Fourth, look for alignment between managers and workers who are executing processes.
Management goals often will differ from perceptions and opinions of their team members.
Management might be looking for process effciencies and greater throughput that will make
their teams wary. This is not unusual and it will likely not vary your requirements. However at
times team members will convey more detailed knowledge of processes than their managers
possess, and that knowledge should cause you to refine your stated requirement. There is no
metric rule of thumb for this area. If you find a process detail that puts the validity of
requirements at risk you should refine that requirement or drop it altogether and review your
changes and rationale with management.
 Lastly, ensure personnel understand how your requirements will achieve project goals. While
some people have a very narrow focus and will not be able to tie specific changes in their
business area to overall goals, most people actually do if your requirements and goals are
clear. If 80% of people feel business objectives can be achieved by what you are proposing
you are likely in good shape to proceed.
So that's it, your validation measurement palette to make sure your project stays green instead of red,
no matter what your favorite color is.

5.5 Developing project acceptance criteria

Can you imagine running in a race without a finish line? I would think that that would be a very
harrowing experience. You would not know how to pace yourself or when you might need to get food
and water to ensure you have enough energy to finish.

Acceptance criteria are like the finish line for your project. They define the point when you can declare
success and work on making sure your business fully embraces the products of your project. Of course,
this needs to be done within defined funding and resource limits, kind of like the food and water for
the race. Your acceptance criteria should be developed in conjunction with your key stakeholders. And
they should be specific so you can clearly determine when you have achieved business objectives.

In addition viable completion criteria also have following characteristics.

36 | P a g e
First, they reflect specific business outcomes, determined early in the project. Sound acceptance
criteria are part of a good traceability matrix I discussed earlier in the course. They are traceable from
the initial desired outcome through the requirements, to how they'll be tested. Acceptance criteria at
the heart of determining testing validity, which I will discuss in the next chapter. Acceptance criteria
define a fixed finish line for all to see and strive for.

The second characteristic of good acceptance criteria is they reflect the desires and expectations of
your stakeholders. This is not a point in time exercise. As a business analyst, you should be in constant
contact with key stakeholders, conveying progress towards achieving project outcomes. Acceptance
criteria can be drafted early, but should be constantly revisited and refined as the project progresses.
By doing so and discussing the costs and risks associated with greater or lesser project acceptance
criteria, you take on a no surprises approach and help ensure your project will be perceived as
successful.

The third characteristic of sound acceptance criteria is that they set or reinforce project priorities.
Most projects are designed to achieve multiple business outcomes, however these outcomes are
really prioritized. For instance if increasing your customer base and controlling costs are project
objectives, will it be okay if you increase your customers base by 50%, but spend 20% more on
marketing to achieve that goal? Good acceptance criteria put multiple project objectives in balance,
and help the project team create processes and tools that meet the holistic objectives of all your
stakeholders and the sponsor.

The last characteristic of sound acceptance criteria is they include specifics on how they'll be
measured. You, your project managers, and your team will not know where the finish line is to this
race if you do not know the means of measurement. Is it 10 miles, or 10 kilometers? Is it measured by
the distance traveled on the road or as the crow flies? The answer to these questions can change the
criteria greatly. Making an assumption that all stakeholders will embrace the same measurement
approach is a very dangerous thing to do. Your effective acceptance criteria should include the exact
processes by which success will be measured, what business processes will be measured, what unit of
measure will be used, and what the specific target is to be achieved.

One more tip about acceptance criteria, they can change as business pressures and strategies change.
So, on longer projects, make sure you validate the acceptance criteria periodically. That way you can
help ensure you are always on the right road, heading to the proper finish line.

37 | P a g e