10 Requirements Traps to Avoid
Slighting requirements development and management often leads to software projects that struggle or fail. Here are ten common traps projects can encounter if people don’t take requirements seriously. I describe symptoms that might indicate you’re falling victim to each trap, along with some possible solutions. More information about all of these traps can be found in Software Requirements, 3rd Edition by Karl Wiegers and Joy Beatty.
Trap #1: Confusion about What Requirements Are
Symptoms: The word requirements means different things to different people. An executive’s notion of requirements could be a high-level product concept or a business vision. A developer’s requirements might look like user interface designs. Customer-provided requirements often are really solution ideas (see Trap #10).
One warning sign is that stakeholders refer to “the requirements” with no qualifying adjectives. The project participants will have different expectations of how much requirements detail to expect. Another symptom is that users provide “the requirements” but developers still aren’t quite sure what to build. Discussions that focus exclusively on functionality can overlook other important kinds of requirements information.
Solutions: All project participants need to understand key requirements engineering concepts, terminology, and practices. I think in terms of three levels of requirement (Figure 1). Business requirements describe the high-level business objectives of the organization or customer requesting the system or product. They answer the question: Why are we undertaking this project?
Figure 1. Three levels of software requirements
The second level addresses user requirements: what users will be able to do with the product. These can be captured in the form of use cases or user stories. However, use cases alone don’t provide enough detail for developers to know what to build. Therefore, the business analyst (BA) should derive specific software functional requirements from the use cases. Developers don’t directly implement business or user requirements — they implement individual functional requirements.
Other types of requirements knowledge include quality attributes, business rules, design and implementation constraints, and external interface requirements. Explore all of these during elicitation to avoid missing something important. Many of these requirement types typically are collected into a software requirements specification or SRS.
Trap #2: Inadequate Customer Involvement
Symptoms: I once saw customers reject a new information system as unacceptable the first time they viewed it, which was at the initial rollout. This is a powerful — but late and painful — sign of inadequate customer involvement. Users sometimes believe BAs or developers should already know what they need. Some users claim to be too busy to spend time on requirements.
One early indication of inadequate customer involvement is that surrogates for the actual users — managers, marketing staff, or even developers — supply the requirements input. Another clue is that developers are forced to make many requirements decisions without adequate information. If any of the product’s user classes haven’t provided input, someone will be unhappy with the result.
Solutions: Strive to build collaborative relationships among your customer representatives, BA, and development team. Begin by identifying your various user classes. User classes are groups who differ in their frequency of using the product, the features they use, privilege level, or in other ways. Then, identify individual product champions to represent specific user classes. Product champions collect input from other members of their user class, provide user requirements to the BA, and provide input on quality attributes and requirement priorities.
Your user reps also can review written requirements, evaluate prototypes, and provide feedback on incremental releases, as in agile development. Aim for ongoing engagement with users, not just a workshop or two at the beginning of the project.
Trap #3: Vague, Ambiguous, and Incomplete Requirements
Symptoms: You’ve encountered ambiguity if a requirement statement can have several different meanings and you’re not sure which is correct. A more insidious form of ambiguity results when multiple readers interpret a requirement in different ways. Each reader concludes that his interpretation is correct, and the ambiguity remains undetected until later, when it’s more expensive to resolve.
Another sign of vague or incomplete requirements is that the SRS lacks information developers need. For instance, if you can’t think of tests to verify whether each requirement was properly implemented, your requirements are not clearly defined. The ultimate symptom of vague requirements is that developers must ask the BA or customers many questions, or they have to guess at what is really intended.
Solutions: Avoid using intrinsically subjective and ambiguous words when you write requirements. Terms like minimize, maximize, optimize, rapid, user-friendly, intuitive, robust, improved, efficient, and support are particularly weak.
To ferret out ambiguity, have a team that represents diverse perspectives carefully review the requirements. Suitable reviewers include:
- the BA who wrote the requirements and perhaps another experienced BA
- the customer or marketing representative who supplied them
- a developer who must implement them
- a tester who must verify them in the product
Writing conceptual tests against use cases and functional requirements crystallizes your vision of how the software should behave under certain conditions. This can reveal ambiguities and missing information early on.
Prototypes make requirements more tangible. Evaluating a prototype is a great way to clarify gaps in your knowledge and reach a shared understanding. Visual analysis models such as data flow diagrams, entity-relationship diagrams, and state-transition diagrams provide alternative views of requirements that often reveal knowledge gaps.
Identify exceptions the system must handle, as well as discussing things users must be able to do with the system. Good developers spend a lot of time writing code to detect, prevent, and recover from all the things that could go wrong. It helps them — and the users — a lot if the business analyst works with users to identify these error conditions and how to handle them.
Trap #4: Unprioritized Requirements
Symptoms: “We don’t need to prioritize requirements,” said the user representative. “They’re all important, or I wouldn’t have given them to you.” Declaring all requirements to be equally critical doesn’t help the project manager respond to new requirements or to changes in project realities (staff, schedule, quality goals). If it’s not clear which features you could defer during the all-too-common “rapid descoping phase” late in a project, you’re at risk from unprioritized requirements.
Another symptom of this trap is that nearly all of your requirements are deemed high priority. Various stakeholders might interpret “high” priority differently, leading to mismatched expectations about what functionality goes into the next release. Users might hesitate to prioritize because they fear the low priority items will never be implemented. But if you can’t fit every desire into the project box, isn’t it good to know which ones to defer or omit?
Solutions: The relative implementation priority is an important attribute of each use case, user story, feature, or functional requirement. High priority could be based on the anticipated frequency of usage, satisfying your most important user classes, implementing core business processes, or regulatory compliance. Allocate each item in your backlog to a specific release or iteration based on its priority.
Priority encompasses both importance and timing. If you use a three- or four-level priority scale, define the categories clearly to promote consistent classification and common expectations. Here are my definitions:
- High: must be included in the next release or iteration
- Medium: necessary, but could wait for a later release
- Low: we can live without it, forever if necessary
Trap #5: Building Functionality No One Uses
Symptoms: I have sometimes implemented features users swore they needed, but then no one ever used them. This is frustrating. Beware of customers who don’t distinguish glitzy “chrome” from the essential “steel” that must be present for the software to be useful. Watch out for developer gold plating, which adds unnecessary functionality that users might not care about. Some proposed functionality isn’t clearly related to known user tasks or to achieving your business objectives.
Solutions: Trace each functional requirement back to its origin, such as a specific use case, higher-level system requirement, or business rule. Derive functional requirements from use cases to avoid orphan functionality. If you don’t know where a requirement came from, question whether you really need it.
Identify the user class that needs each feature or use case. Writing user stories in the form “As a <type of user>, I want <some goal> so that <some reason>” makes it clear which user class will benefit.
Analytically prioritizing functional requirements, use cases, or features also helps you avoid this trap. Avoid implementing requirements that incur a high cost but provide low business value.
Trap #6: Analysis Paralysis
Symptoms: If requirements development seems to go on forever, you might be a victim of analysis paralysis. New versions of the SRS might appear so frequently that version numbers resemble IP addresses. An overzealous BA might try to model all requirements or prototype the entire system before declaring the requirements ready to be implemented. Perhaps the decision makers never agree on a requirements baseline. Analysis paralysis is the big risk of the pure waterfall approach to software development.
Solutions: Your realistic goal is not a perfect SRS but rather a set of clearly expressed requirements so some portion of development can proceed at acceptable risk. Select a development life cycle that lets you implement portions of the requirements as they become well understood. Incremental development approaches like agile evolved partly to avoid analysis paralysis. Flag knowledge gaps in your requirements with TBD — to be determined — to indicate a higher risk of proceeding. Model and prototype just the complex, novel, or poorly understood parts of the system to clarify the requirements.
Trap #7: Scope Creep
Symptoms: Most projects face the threat of scope creep, as new requirements are continually added during development. Typically, project deadlines don’t change, no more resources are provided, and nothing is deleted to accommodate the new functionality.
Scope creep is most likely when the project scope was never clearly defined in the first place. If new requirements are proposed, then rejected, but resurface later — with ongoing debates about whether they belong in the system — your scope definition is too fuzzy. New requirements that sneak in through the back door, rather than through an effective change process, can lead to schedule overruns.
Solutions: All projects should expect some requirements growth. Your plans should include buffers to accommodate such natural evolution. Whenever someone proposes new functionality, ask: “Is this in scope?” To answer this question, document the product’s vision and scope and use it as the reference for deciding which changes to include.
Scope creep often indicates that requirements were missed initially, so effective requirements elicitation practices are essential. Establish a meaningful process for baselining a set of requirements for the next release or development increment. See my article “Managing Scope Creep: Why, When, and How” for more ideas about handling this trap.
Trap #8: Inadequate Change Process
Symptoms: The most glaring symptom is that your project lacks a defined process for handling changing requirements. New functionality might become evident only during system testing. Some people bypass the process by telling their developer buddies about changes they want. Other clues that your change process is deficient are that it’s not clear who makes decisions about proposed changes, change decisions aren’t communicated to all those affected, and the status of each change request isn’t always clear.
Solutions: Define a practical change control process for your project. You can supplement the process with a problem- or issue-tracking tool to collect, track, and communicate changes. However, a tool is not a substitute for a process. Set up a change control board to consider proposed changes and make binding decisions to accept or reject them. Prioritize each proposed requirement change against the backlog of requirements remaining to be implemented.
Follow your change control process for all changes, recognizing that you might need to renegotiate commitments when you accept new requirements.
Trap #9: Insufficient Change Impact Analysis
Symptoms: BAs, developers, or project managers sometimes agree to make suggested changes without carefully thinking through the implications. The change might be more complex than anticipated, take longer than promised, be technically or economically infeasible, or conflict with other requirements. Another indication of inadequate impact analysis is that developers keep encountering more affected system components as they implement the change.
Solutions: Before saying “Sure, we can do that,” understand the implications of accepting the change, identify the associated work to do, and estimate the effort and schedule impact. Every change will consume resources: change is never free. Use requirements traceability information to help you identify all affected system components. Provide estimates of the costs and benefits of each change proposal to the decision-makers so they can make sensible commitments.
Trap #10: Solutions Presented As Requirements
Symptoms: Many of my consulting clients have told me this trap represents their greatest requirements challenge. Their users often present screen sketches as being their requirements, and elicitation discussions focus on user interface designs, not the underlying needs. The team might expect prototypes to replace written requirements specifications. If you find requirements discussions centering on what the product will look like and its features, rather than what users will be able to do with it, you might be falling into this trap.
Solutions: Before the team dives into screen design and detailed functionality, the BA should lead discussions to elicit user requirements. Focus on the users’ business processes and tasks, the things the system must help them accomplish. From those user requirements, the BA can derive the necessary functional requirements the developers must implement.
The BA needs to listen for cues that indicate users are presenting solutions instead of true requirements. When you hear a solution idea, ask questions to understand the real need behind each proposed solution. Is that solution idea a true constraint the developers must respect? Or is it just one notion the speaker has about how a particular capability could be implemented?
Keys to Excellent Requirements
These ten traps aren’t the only ones lurking in the requirements minefield, but they’re among the most common and the most severe. To control them, try the following approaches.
- Educate developers, managers, and customers about both requirements practices and the application domain.
- Establish a collaborative customer–developer partnership.
- Take an iterative and incremental approach to requirements development.
- Use standard templates for vision and scope, use case, and detailed requirements documents.
- Conduct both informal and formal requirements reviews.
- Write tests against requirements early on.
- Prioritize requirements thoughtfully to yield the maximum business value quickly.
- Instill the discipline to handle changing requirements consistently and effectively.
These practices will help your next project’s requirements provide a solid foundation for efficient construction and a successful rollout. It’s a lot better than just asking some customer “What do you want?” and then doing your best to deliver.
=================
If you’re interested in software requirements, business analysis, project management, software quality, or consulting, Process Impact provides numerous useful publications, downloads, and other resources. Karl’s latest book is The Thoughtless Design of Everyday Things.
