The Requirements Process:
A Best-Practice,
Partnership Path to Development Success
By Diane Pepetone
Requirements
Manager, L'Monte
Like many companies, we ferreted out the best software development
practices the hard way—mostly through trial and error. Over the
past 18 years working with requirements analysis and management,
I've distilled the best industry practices into a four-step partnership
process.
We've found that a partnership-based, requirements approach is
particularly successful on outsourced, offshore projects because
it bridges the knowledge, physical and cultural gaps that often
exist between product experts and the development team.
Our clients have told me that this process does more than keep
their team on track; it makes them better by keeping team members
honest while clarifying the very issues that often cause infighting
and distrust. It's really surprising how much everybody
likes issues being brought into the light and knowing who is responsible
for what.
For those users whose original requests start any development
project, our process eliminates any surprises between what they
were expecting and what the development team actually produces.
But best of all, because it's so practical, our requirements process
results in predictable outcomes and reduced development costs.
And who doesn't love that?
Step 1: Forming the Core Requirements
Team
A project requirements team that works well
together is essential to a successful product launch.
The first step in defining requirements is to form a core project
requirements team. The best teams are comprised of product
experts, market and content experts, the software project manager
and senior architects. We recommend that initial work sessions
define the project's mission, individual team member's roles and
the project's stakeholders.
The core team should address the following relationship responsibilities
and authority questions:
- Who is the project's sponsor? Who has the
fiscal authority to support the project development?
- Who is the project's champion? Who will
promote and sustain the development effort?
- Who is the lead content expert on the project? Who
has final say on accuracy and completeness of requirements?
During these early sessions, the core team also defines their
standard operating procedures for communication, including work
session ground rules, methods of negotiating change, and how to
handle conflicts. The team also develops an initial schedule for
defining requirements. Depending on the size of the project,
it may be necessary to form smaller groups to focus on different
functional aspects of the project.
Best practice: Identify decision making rules for the
core team using a combination of consensus, delegation and decision
leaders to facilitate the decision making process and avoid getting
bogged down in no-win situations.
As the main framework of a project's requirements is delineated
and recorded, each area of functionality is assigned a product
owner and a software team owner. As with the larger team, the success
of individual requirements depends on a collaborative partnership
between its two owners. Together they are responsible for
the requirement throughout its life cycle of defining, designing,
implementing, testing and accepting. Through an iterative
refining process, owners work together to ensure that the final
implementation satisfies the requirement.
Best practice: Identify a software professional on the core team
to act as a requirements representative to the final development
team, sharing with them the project mission and requirements. The
requirements representative has the task of always standing up
for the defined requirements, even when they are unpopular with
the rest of the software team.
Step 2: Distill the Requirements
Until there is no ambiguity in a requirement, it is not ready
to be built.
The core requirements team's first job is to distill the requirements
from initial project materials such as a marketing requirements
document, the project charter or literature describing a competing
product. Working with all team members, we facilitate
high-level definition workshops using interviews to create use
cases, and low-fidelity user interface storyboards. Then the team
performs a series of walkthrough's of the use cases and UI storyboards
until they have distilled functional, testable and complete requirements - in
short, they create a functional specification that is ready to
build. At this point, each requirement's co-owners—the
product owner and software developer owner—are assigned.
Best Practice: Use a project-tracking tool, preferably web
based (to accommodate off site team members), to record requirements,
use cases and acceptance criteria. The tracking tool should be
able to follow each requirement through its entire life cycle—from
definitions, designing, implementing, testing, change requests,
defects and, finally, through acceptance.
The requirements distillation stage is also the time to identify
testable acceptance criteria. Stated requirements and their acceptance
criteria serve as the basis for the agreement between the product
owner and the software team owner of what functionality will be
built.
Step 3: Manage the Requirements
A software development project is a very dynamic living entity
in its own right. You really need to track changes, manage
the process and be able to easily determine what it was the team
originally intended.
It is very common for projects to have up-front specifications
that get overlooked and not revisited until the end. Then, it often
becomes too late or too expensive to incorporate forgotten requirements. Why
does this happen? On most projects the software manager
is fully occupied with managing the software team to produce reliable
software as quickly as possible. Meanwhile, the lead marketer
is busy tracking the market and preparing the product launch. Tending
those two areas is essential, but that leaves no one to monitor
the actual requirements to make sure they mature into successful
features and capabilities. So, in addition to facilitating
on-going project requirements work sessions, it's important to
have someone whose job it is to provide oversight by tracking and
reporting on requirements that might otherwise languish in the
defining stage, or get caught in a non-acceptance loop due to inaccurate
or incomplete definitions. As the person often responsible
for ensuring that essential requirements make it to the finish
line of successful implementation in a timely manner, I can tell
you this: having a good project-tracking tool makes a huge difference
in this phase as well.
Best Practice: Send regular status reports, which identify
requirements still in defining, requirements that have new issues
or risks posted, or requirements coming up for acceptance testing,
to help the core team track progress and target problem requirements
before they become a schedule problem.
Step 4: Acceptance Testing
Don't fear acceptance testing: enjoy it!
After all the effort put into defining, designing and implementing
a feature, the final step comes when the co-owners inspect the
fully functional feature and compare it to the requirement's acceptance
criteria.
All too often this critical stage is overlooked in the rush to
get a commercial product released or because developers and the
user group are afraid of what they will find. This delayed
evaluation can cause a serious hit to the schedule when failures
or omissions are finally discovered after developers have built
on problematic code. And that's when tempers fray, the blame starts
flying and the team falls apart.
Most people fear this step: my clients have grown to love it.
Why? Because of the collaborative co-ownership approach, this becomes
a rewarding time for both the product owner and the software team
owner. Since oversights and defects are discovered well
before the expense of programming has been incurred, they don't
carry the stigma or the emotional wallop of problems discovered
after coding has started. Now testing sessions simply involve putting
a feature through its paces as the acceptance criteria are evaluated.
It may take a few rounds of acceptance testing before the requirement
is fully accepted. If oversights in the definition are discovered,
then change request records are generated. If a failure in functioning
is encountered, then a defect is generated. However, I've
found that when it's co-owned, acceptance testing is usually a
time for celebration.
Best Practice: Make sure that when the status of the requirement
record changes to "ACCEPTED", everyone who worked on it gets an
email announcing the fact. There's nothing like ongoing success
to mitigate the fear of testing.
|
