Implementing requirements engineering good practices

High Medium Low

High ■ Define a requirement ■ Train business analysts ■Educate developers about
engineering process ■ Plan requirements approach application domain
■ Base plans on requirements ■ Select product champions ■ Adopt requirement
■ Renegotiate commitments ■ Identify user requirements document templates
■ Hold elicitation interviews ■ Identify user classes
■ Specify nonfunctional ■ Model the application
requirements environment
■ Prioritize requirements ■ Identify requirement origins
■ Define vision and scope ■ Establish baselines and
■ Establish a change control control versions of
process requirements sets
■ Review the requirements ■ Identify requirements
■ Allocate requirements to decision maker
subsystems
■ Use a requirement
management tool
■ Record business rules
Medium ■ Maintain a requirement ■ Educate stakeholders about ■ Create a data dictionary
traceability matrix requirements ■ Observe users performing
■ Hold facilitated elicitation ■ Conduct focus groups their jobs
workshops ■ Create prototypes ■ Test the requirements
■ Estimate requirements ■ Analyze feasibility ■ Track requirements status
effort ■ Define acceptance criteria ■ Perform document analysis
■ Reuse existing ■ Model the requirements ■ Track requirements issues
requirements ■ Analyze interfaces ■ Uniquely label each
■ Perform change requirement
impact analysis ■ Create a glossary
■ Select an appropriate
life cycle
■ Identify system events and
responses
■ Manage requirements risks
■ Review past lessons learned
■ Track requirements effort

Low ■ Distribute questionnaires ■ Examine problem reports

■ Maintain change history
■ Simulate the requirements
Identify Decision Maker
There can be hundreds of decisions to make on software projects; often, they are on the critical
path to being able to move ahead. You might need to resolve some conflict, accept (or reject) a
proposed change, or approve a set of requirements for a specific release. Early in your project,
determine who the requirements decision makers will be and how they will make decisions.
The decision-making group needs to identify its decision leader and to select a decision rule,
which describes how they will arrive at their decisions. There are numerous decision rules to
choose from, including the following:
 The decision leader makes the choice, either with or without discussion with others.
 The group votes and the majority rules.
 The group votes, but the result must be unanimous to approve the decision.
 The group discusses and negotiates to reach a consensus. Everyone can live with the
decision and commits to supporting it.
 The decision leader delegates authority for making the decision to one individual.
 The group reaches a decision, but some individual has veto authority over that decision.
There is no globally correct or appropriate decision rule. A single decision rule won’t work in
every situation, so the group must establish guidelines so they know when to vote, when to
reach consensus, when to delegate, and so on. The people who will be making requirements-
related decisions on each of your projects should choose a decision rule before they confront
their first significant decision.

Reach Agreement
Reaching agreement on the requirements for the product to be built, or for a specific portion of
it, is at the core of the customer-developer partnership. Multiple parties are involved in this
agreement:
 Customers agree that the requirements address their needs.
 Developers agree that they understand the requirements and that they are feasible.
 Testers agree that the requirements are verifiable.
 Management agrees that the requirements will achieve their business objectives.
Many organizations use the act of “signing off” on the requirements as the mark of stakeholder
approval. All participants in the requirements approval process should know exactly what sign-
off means or problems could ensue. One such problem is the customer representative or
manager who regards signing off on the requirements as a meaningless ritual.
Equally problematic is the development manager who views sign-off as a way to freeze the
requirements. Whenever a change request comes along he can protest, “But you signed off on
these requirements, so that’s what we’re building. If you wanted something else, you should
have said so.” Both of these attitudes ignore the reality that it’s impossible to know all the
requirements early in the project and that requirements will undoubtedly change over time.
Approving a set of requirements is an appropriate action that brings closure to some stage of
requirements development. However, the participants have to agree on precisely what they’re
saying with their signatures.

What if you don’t reach agreement?

It can be hard to achieve sign-off from all the relevant stakeholders. Barriers include logistics,
busy schedules, and people who are reluctant to commit and be held accountable later. If
stakeholders are afraid they won’t be able to make changes after they approve the
requirements, they might drag their feet on the approval. This contributes to the dreaded trap
of analysis paralysis. Many teams have tried sending out an email message that says, “If you
don’t reply by next Friday with your changes and/or sign-off, I’m going to assume you are
agreeing to these requirements.” That’s one option, but really it equates to not reaching
agreement. It also risks straining the relationship with those stakeholders for whom you’ve just
assumed a tacit approval. Try to understand why they didn’t feel comfortable with a sign-off
and address that directly.
In such a situation, you’re better off moving forward—cautiously—with the assumption that
you don’t have approval from the recalcitrant stakeholders. Document the fact that certain
stakeholders didn’t sign off on the requirements in your risk list, along with the likely impact of
some of the requirements being missing or wrong. Follow up with these people as part of risk
management. In a positive manner, mention that you recognize that they have not yet
approved the requirements but that the project is still moving forward with those requirements
as a baseline so as to not impede progress. Let them know that, if they want to change things,
there’s a process in place to do that. Basically, you’re acting as though the stakeholder did
indeed agree to the requirements, but you’re managing the communications closely.

Requirement Baseline
More important than the sign-off ritual is the concept of establishing a baseline of the
requirements agreement, a snapshot of it at a point in time. A requirements baseline is a set of
requirements that has been reviewed and agreed upon and serves as the basis for further
development.
A shared understanding along these lines helps reduce the friction that can arise as
requirements oversights are revealed or marketplace and business demands evolve over the
course of the project. A meaningful baselining process gives all the major stakeholders
confidence in the following ways:
 Customer management or marketing is confident that the project scope won’t explode
out of control, because customers manage the scope change decisions.
  User representatives have confidence that the development team will work with them
to deliver the right solution, even if they didn’t think of every requirement before
construction began.
 Development management has confidence because the development team has a
business partner who will keep the project focused on achieving its objectives and will
work with development to balance schedule, cost, functionality, and quality.
 Business analysts and project managers are confident that they can manage changes to
the project in a way that will keep chaos to a minimum.
 Quality assurance and test teams can confidently develop their test scripts and be fully
prepared for their project activities.
After the decision makers define a baseline, the BA should place the requirements under
change control. This allows the team to modify scope when necessary in a controlled way that
includes analyzing the impact of each proposed change on the schedule and other success
factors. Sealing the initial requirements development activities with an explicit agreement helps
forge a collaborative customer-development partnership on the way to project success.