Strategic Partners
About Us
News & Events
Contact Us
Sustainable Energy
Requirements Engineering Requirements Management Custom Development

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.

Commons License
This work is licensed under a Creative Commons License.