Software Requirements Management Processes
If today’s IT industry had a mantra it would probably be “business-IT alignment.” This has become more than just a vendor pitch. This phrase is now being heard and demanded in boardrooms throughout the world as executives realize IT – and particularly software – not only runs their business but can be their biggest competitive weapon.
When it comes to developing and maintaining high-value software, there are a number of processes that lend to business-IT alignment. However, none 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 lifecycle, from design and coding to testing and deployment. And because requirements have such an impact downstream, it’s no surprise that studies cite inaccurate, incomplete and mismanaged requirements as the primary reason for project failure1.
An effective requirements engineering process consists of two major domains – definition and management. It is the definition process that aligns stakeholders with shared goals and expectations, and what 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. Within these two domains are five primary subcomponents – requirements elicitation, analysis, specification, validation and management.
The rest of this article outlines several best practices in each of these categories which can help IT teams to do a better job of understanding and communicating good requirements, and in turn, to more effectively align IT priorities with the needs of the business.
Requirements elicitation
Understanding user or system requirements is more about “discovery” than about “documentation.” Below are five steps 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. This is what draws the boundary between what is in and what is out for a project and what reduces the chance of the dreaded “scope creep.”
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 is 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 locally available. 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 should explore use cases or user scenarios to help ensure that the requirements their developers implement will allow users to accomplish their goals.
Requirements analysis
Once requirements are discovered, the task then falls to verifying that these requirements are complete and achievable. This 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, one should 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 does not show the business logic happening behind the scenes nor does it indicate how all exceptions and error conditions are going to be handled. Therefore, it should not a substitute for documenting detailed functional requirements.
Prioritize requirements.Every organization has limited resources and time. Therefore, every team should determine which of its requirements are most important and most urgent. This allows teams to implement the right sets of user functionality in the right sequence. Prioritization should be a collaborative process that involves both a customer and a technical perspective to balance customer value against cost and technical risk.
Requirements specification
This critical step in the process fills out the details for each requirement and helps to clarify ambiguities that can result in rework, schedule delays, budget overruns or 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 should establish an agreed upon lexicon prior to writing requirements.
Store requirements in a database.By storing requirements in a commercial requirements management tool, such as Borland CaliberRM, teams can overcome many of the limitations imposed by textual documents. Requirements management tools make it easy to store additional information—attributes—about different classes of requirements information. They facilitate tracking requirements status. 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 should 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.
Requirements validation
Once requirements are defined, they must be validated with the original stakeholders before development begins. This 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, they should be reviewed by all project stakeholders 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.Teams should also 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.
Requirements management
Finally, after the requirements are elicited, analyzed, specified and validated, they are ready to be executed against in the various phases of the development process. Below are five important steps for how to effectively manage requirements throughout the application lifecycle.
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 requirements have been baselined, 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 should 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 should 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 should store attributes with the requirements to ensure the detail necessary to communicate and prioritize requirements.
Track the status of each requirement.Teams should 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.
Good requirements practices yield positive results
Besides the obvious cost benefits, improving requirements approaches leads to other valuable—but 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 with both internal and external customers.