email article printer friendly more resources

Achieve Useful Requirements Processes
Learn best practices to help your team better understand and communicate requirements that align your IT priorities with your business needs.
by Matt Klassen

June 1, 2006

When it comes to developing and maintaining high-value software, there are a number of processes that lend themselves to aligning business and IT. However, no process is more fundamental than the process of defining and managing business and technical requirements for both new and existing applications. These requirements impact every single step of the application life cycle, from design and coding to testing and deployment. Because requirements have such an impact downstream, it's no surprise that studies (such as the Standish Group's 2004 CHAOS report) cite inaccurate, incomplete, and mismanaged requirements as the primary reason for project failure.

An effective requirements-engineering process consists of two major domains: definition and management. The definition process aligns stakeholders with shared goals and expectations and helps bridge the significant communication gap between IT and the business. The management process enables an organization to respond quickly to change and to ensure the resulting application effectively meets customer needs (see the sidebar, "Software Requirements Truths"). Within these two domains are five primary subcomponents for requirements: elicitation, analysis, specification, validation, and management (see Figure 1).

Let's take a look at best practices in each of these categories that can help IT teams to do a better job of understanding and communicating good requirements, and to more effectively align IT priorities with the needs of the business.

Elicit Requirements
Understanding user or system requirements is more about discovery than it is about documentation. Within the elicitation category are five best practices that can help effectively discover an accurate and complete set of requirements.

Define the vision and project scope. A vision is the long-term strategic concept underlying the ultimate purpose and form of the new system or application. It could do such things as describe the system's place among its competition or in a specific operating environment. Project scope is what the specific project in question will address and is what draws the boundary between what is in and what is out for a project. It also addresses what reduces the chance of the dreaded scope creep, (also called requirement creep), which refers to uncontrolled changes in a project's scope that often occur when the scope of a project is defined, documented, and controlled improperly. The scope increase typically consists of either new products or new features for already approved products, which can lead the project team to drift from its original purpose and overrun original budgets and schedules.

Identify the appropriate stakeholders. Every software project should identify the key stakeholders early on to ensure that the right people can make important and timely decisions. The customer perspective is required in all aspects of the process when making change decisions, assessing the impact of changes, and adjusting requirement priorities.

Select champions. Teams must determine who will serve as the literal voice of the customer for each type of user who might touch the system or application. These representatives are called champions. When engaging champions, it's important to agree on the level of involvement. It's one thing to participate in a workshop or two, but sustained engagement with frequent contact points adds far more value. The best champions are collaborative partners who communicate with other members of the team for input, feedback, and conflict resolution.