Achieve Useful Requirements Processes

Aligning IT and business is more than a marketing slogan. Learn best practices that let IT teams share requirements that align IT priorities with business needs more effectively.

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.

Choose elicitation techniques. The methods used for requirements elicitation depends on the extent of stakeholder involvement and how much access one has to those stakeholders. Workshops to explore scenarios and use cases work well when user representatives are available locally. Questionnaires and surveys might be necessary if there are many, geographically distributed stakeholders. Individual interviews with subject matter experts are also useful for capturing information, as are analysis models and building interactive prototypes. These various elicitation techniques are not mutually exclusive, and using multiple communication channels can increase the chance of getting high-quality and complete information.

Explore user scenarios. Discussions that focus on how users interact with a product or system generally yield the best results. Users find it more natural to describe their business tasks and usage goals than to define all of the functionality they expect to see in a product. Use cases, scenarios, and user stories are related terms that are used frequently to describe a system's user requirements. Use cases do not replace the need to define the detailed functional requirements that developers will use to implement the system. However, teams need to explore use cases or user scenarios to help ensure that the requirements their developers implement will allow users to accomplish their goals.

Analyze Requirements
Once requirements are discovered, the next task is to verify that these requirements are complete and achievable. This analysis involves estimating the time and resources needed to achieve the requirements and if necessary prioritizing what can and can't be done.

Create analysis models. Requirements are often full of ambiguities, redundancies, and gaps. Therefore, represent requirements in multiple ways, giving readers a richer, more holistic understanding of them. Analysis models present requirements information visually in graphical diagrams. They allow reviewers to immediately spot missing requirements by examining diagrams.

Build and evaluate prototypes. Prototypes are more tangible than written requirements specifications as they bring use cases to life. When creating a prototype the development team is taking a tentative step into the solution space, which is a valuable way to validate and refine requirements. However, a prototype neither shows the business logic happening behind the scenes nor does it indicate how all exceptions and error conditions are going to be handled. Therefore, it shouldn't be a substitute for documenting detailed functional requirements.

Prioritize requirements. Every organization has limited resources and time. Therefore, every team must determine which of its requirements are most important and most urgent. This determination allows teams to implement the right sets of user functionality in the right sequence. Prioritization must be a collaborative process that involves both a customer and a technical perspective to balance customer value against cost and technical risk.

Specify Requirements
The critical step of specifying requirements fills out the details for each requirement and helps to clarify ambiguities that can result during reworking, during scheduling delays, in budgeting overruns, or in outright project failure.

Look for ambiguities. Requirements, especially those written only in natural language and not represented visually, are fraught with ambiguity. Negative requirements, use of vague and subjective terms, complex logic, omissions, synonyms, and adverbs lead to multiple interpretations by different readers. Teams need to establish an agreed upon lexicon prior to writing requirements.

Store requirements in a database. By storing requirements in a commercial requirements-management tool, teams can overcome many of the limitations imposed by textual documents (see Resources). Requirements management tools make it easy to store additional information—attributes—about different classes of requirements information. They facilitate tracking requirements status, and they provide a mechanism for retaining requirements that have been proposed, rejected or approved, and later deleted from a baseline. The tools also make it easier to work with groups of requirements that are intended for multiple future releases. In addition, organizations that keep requirements in a shared, online database can better facilitate communication and collaboration among distributed teams.

Trace requirements into design, code, and tests. It is valuable to be able to link each functional requirement back to its origin, possibly a use case or business rule. Teams must embrace traceability information that connects functional requirements to associated design elements, code segments, and tests to accelerate debugging and software maintenance. Requirements-management tools are a great aid to managing traceability data.

Validate Requirements
Once requirements are defined, they must be validated with the original stakeholders before development begins. Validation allows the analyst, or whoever is defining the requirements, to review and play back scenarios to ensure requirements in fact map back to user needs.

Review the requirements through a formal peer review. Peer review indicates how well others understand the requirements. Once requirements are well documented, all project stakeholders need to review them to ensure accuracy, completeness, and that the optimal level of detail is there for developers to deliver software that truly meets business needs.

Create test cases from requirements. Have teams begin "testing" as soon as they have some requirements in hand. Deriving test cases directly from use cases and scenarios is a valuable way to find problems in the use cases themselves, or in functional requirements that are derived from use cases.

Manage Requirements
After the requirements are elicited, analyzed, specified, and validated, they are ready to be executed against in the various phases of the development process. Within the management category there are five important best practices for effectively managing requirements throughout the application life cycle.

Manage versions. As requirements evolve during the course of a project, it is important to track the different versions of requirements specification documents. Version tracking helps ensure all team members are working from the most current requirements baseline and documents the evolution of any requirements.

Adopt a change control process. Once baseline requirements have been established, proposed modifications in them should follow an established change control process. This process provides consistency in the way requirement changes are proposed, evaluated, approved or rejected, communicated to stakeholders, and implemented in affected work products. Teams must have formal written change control processes in place before eliciting requirements.

Perform requirements change impact analysis. To help the change control board (CCB) make appropriate business decisions about which proposed changes to approve, developers need to assess the potential impact of each proposed change before committing to implement it.

Store requirements attributes. Requirements attributes provide a richer understanding of each individual requirement. Potential attributes to track include priority, status, author, origin, rationale, validation method, risk, and version number. Teams must store attributes with the requirements to ensure the detail necessary to communicate and prioritize requirements.

Track the status of each requirement. Teams must report on the status of individual functional requirements. There are a number of possible requirements checkpoints, including proposed, approved, implemented, verified, rejected, and deleted. Teams that track the status of each requirement can easily assess the health of the project and avoid unnecessary status meetings.

Besides the obvious cost benefits, improving requirements approaches leads to other valuable, though less tangible, outcomes. Experiencing fewer miscommunications on a software project reduces the overall level of complexity in the IT organization. Less chaos lowers unpaid overtime, increases team morale, boosts employee retention, and improves the team's chances of delivering on time. Best of all, these benefits lead to higher satisfaction for both internal and external customers.

Most   Popular