Author: Karl Wiegers

Karl Wiegers is Principal Consultant with Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of 14 books, including Software Requirements Essentials, Software Requirements, More About Software Requirements, Successful Business Analysis Consulting, Software Development Pearls, The Thoughtless Design of Everyday Things, and a forensic mystery novel titled The Reconstruction. Karl also has written many articles on software development, design, project management, chemistry, military history, and consulting, as well as 18 songs. You can reach him at ProcessImpact.com or KarlWiegers.com.

Requirements for Implementing Packaged Solutions

Written by Karl Wiegers on August 4, 2014. Posted in Articles.

Many organizations acquire and adapt purchased packaged solutions (also called commercial off-the-shelf, or COTS, products) to meet their software needs, instead of building new systems from scratch. Software as a service (SaaS), or cloud, solutions are becoming increasingly available to meet software needs as well. Whether you’re using a package as part or all of the solution for a new project or implementing a solution in the cloud, you still need requirements. Requirements let you evaluate solution candidates so that you can select the most appropriate package, and then they let you adapt the package to meet your needs. This article describes several ways to approach requirements definition when you plan to acquire a commercial package to meet your needs.

Figure 1 shows that the spectrum of effort required to make a packaged solution useful ranges from using the package as is, right out of the box, to performing considerable requirements specification and software development for extensions.

Table 1 describes these four types of COTS package implementations, which are not mutually exclusive. Any of these implementations might also require making infrastructure changes in the operating environment, such as upgrading operating systems or other software components that interact with the package.

Figure 1. A spectrum of implementation effort for packaged solutions.

Table 1. COTS package implementation approaches.

One advantage of purchasing a COTS solution is that it might provide useful capabilities that you hadn’t originally sought. You typically select the package based on what you know you need. However, during implementation, you might discover valuable features that you hadn’t even thought of. This can change the amount of work needed to install the package to exploit the additional features.

Configuration Requirements

Sometimes you can use a package just as it comes from the vendor. More often, you’ll need to adjust various configuration parameters in the package to better meet your needs. Configuration requirements are essential to most successful COTS implementations. One approach is to define configuration requirements for one process flow, use case, or user story at a time, which could work well when deploying a COTS solution using an agile approach. Walk through user manuals for the purchased system to learn how to execute a specific task, looking for settings that need to be configured to suit your environment. Consider the full set of business rules when you are configuring the system, not just those you examined during the selection process. It might be helpful to create decision tables and decision trees to model these requirements. Many COTS solutions come with predefined mechanisms to specify roles and permissions. Use a roles and permissions matrix to define which roles to create and what permissions those roles should have.

Integration Requirements

Unless the packaged solution is used in a standalone mode, you’ll need to integrate it into your application environment. This integration involves understanding the external interfaces the package will present to each of the other applications with which it must interact. Precisely specify the requirements for interchanging data and services between the package and other components in your environment. You will likely have to create some custom code to make all the parts fit together, and new code demands requirements. This code could take the form of:

Adapters that modify interfaces or add missing functionality.
Firewalls that isolate the COTS software from other parts of the enterprise.
Wrappers that intercept inputs to and outputs from the package and modify the data as necessary to be used on the other side of the interface.

Extension Requirements

One common goal of COTS implementations is to minimize customizations to the solution. Otherwise, you should just custom-build the application yourself. In most COTS projects, though, there will be gaps between what the organization needs and what the package delivers. For each such gap, decide whether to ignore it (remove the requirement and just live with the tool); change how you do something outside the solution (modify the business process); or build something to bridge the gap (extend the solution). If you are extending the COTS solution, you’ll need to fully specify the requirements for those new capabilities just as you would for any new product development effort. While analyzing the requirements for any components to be added, assess whether they could negatively affect any existing elements or workflows in the package.

Data Requirements

Begin with the data requirements used in the selection process. Map data entities and attributes from your existing data dictionary to the COTS entities and attributes. There will likely be areas where the solution doesn’t handle some of your existing data entities or attributes. As with functional gaps, you’ll need to decide how to handle data gaps, typically by adding attributes or repurposing an existing data structure in the COTS solution. Otherwise, when you convert data from any existing systems into the COTS solution, you will likely lose any data that was not properly mapped. Use report tables to specify requirements for deploying existing or new reports (see Chapter 13 of Software Requirements, 3rd Edition).

Many COTS packages will provide some standard report templates to start with.

Business Process Changes

COTS packages are usually selected because implementing and maintaining them is expected to be less expensive than building custom software. Organizations need to be prepared to adapt their business processes to the package’s workflow capabilities and limitations. This is different from most development projects where the software is designed specifically to accommodate existing or planned processes. In fact, a COTS solution that can be fully configured to meet your existing processes is likely to be expensive and complex. The more buttons and knobs you can adjust, the harder it is to configure. You need to strike a balance between implementing all of the desired user functionality and only what the COTS product offers out of the box.

Start with the user requirements identified during the selection process. Develop use cases or swimlane diagrams to understand how the tasks will change when users execute their tasks in the COTS solution. Users might resist the new packaged solution because it looks or behaves differently than their existing systems, so involve them early in this process. Users are more willing to accept the new solution if they contributed to shaping the necessary changes in their business processes.

Buy or Build: An Eternal Question

Buying, configuring, and extending a commercial software package often is a sensible business alternative to building a custom solution. Packages can provide a lot of flexibility, but at the same time they come with built-in limitations and constraints. You don’t want to pay for a lot of features that your organization doesn’t need. Nor do you want to build a fragile structure of extensions and integrations that might break when the vendor releases the next version of the package. A careful package selection and implementation process will help you find the optimum balance of capability, usability, extensibility, and maintainability in a commercial packaged software solution.

Don`t forget to leave your comments below.

About the Writers:

Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the recent award-winning book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Exploring Quality Attribute Requirements

Written by Karl Wiegers on July 7, 2014. Posted in Articles.

In an ideal universe, every product would exhibit the maximum value for all quality attributes. The system would always be available, would never fail, would instantly supply results that are always correct, would block all unauthorized accesses, and would never confuse a user. In reality, trade-offs and conflicts between certain attributes make it impossible to simultaneously optimize all of them. You have to determine which attributes are most important to your project’s success and state specific objectives for them so designers can make appropriate choices. This article describes an approach for identifying and specifying the most important quality attributes for your project, adapted from Jim Brosseau’s method (“Software Quality Attributes: Following All the Steps,” 2010, www.clarrus.com/resources/articles/software-quality-attributes).

Step 1: Start with a broad taxonomy

Begin with a rich set of quality attributes to consider, such as those listed in Table 1. This broad starting point reduces the likelihood of overlooking an important quality dimension.
Table 1. Some external and internal software quality attributes

External Quality	Brief Description
Availability Installability Integrity Interoperability Performance Reliability Robustness Safety Security Usability	The extent to which the system’s services are available when and where they are needed How easy it is to correctly install, uninstall, and reinstall the application The extent to which the system protects against data inaccuracy and loss How easily the system can interconnect and exchange data with other systems or components How quickly and predictably the system responds to user inputs or other events How long the system runs before experiencing a failure How well the system responds to unexpected operating conditions How well the system protects against injury or damage How well the system protects against unauthorized access to the application and its data How easy it is for people to learn, remember, and use the system
Internal Quality	Brief Description
Efficiency Modifiability Portability Reusability Scalability Verifiability	How efficiently the system uses computer resources How easy it is to maintain, change, enhance, and restructure the system How easily the system can be made to work in other operating environments To what extent components can be used in other systems How easily the system can grow to handle more users, transactions, servers, or other extensions How readily developers and testers can confirm that the software was implemented correctly

Step 2: Reduce the list

Engage a cross-section of stakeholders to assess which of the attributes are likely to be important to the product. For instance, an airport check-in kiosk for travelers must emphasize usability (because most users will encounter it infrequently) and security (because it has to handle payments). Attributes that don’t have much impact on your project’s success need not be considered further.

Step 3: Prioritize the attributes

Prioritizing the pertinent attributes sets the focus for future elicitation discussions. Pairwise ranking comparisons can work efficiently with a small list of items like this. Figure 1 illustrates how to use Jim Brosseau’s spreadsheet (at www.clarrus.com/resources/articles/software-quality-attributes) to assess the quality attributes for an airport check-in kiosk. For each cell at the intersection of two attributes, ask yourself, “If I could have only one of these attributes, which would I take?” Entering a less-than sign (<) in the cell indicates that the attribute in the row is more important; a caret symbol (^) points to the attribute at the top of the column as being more important. For instance, comparing availability and integrity, I conclude that integrity is more important. The passenger can always check in with the desk agent if the kiosk isn’t operational, but passengers will be very unhappy if the kiosk doesn’t show the correct data. So I put a caret in the cell at the intersection of availability and integrity, pointing up to integrity as being the more important.

Figure1. Sample quality attribute prioritization for an airport check-in kiosk.

The spreadsheet calculates a relative score for each attribute, shown in the second column. In this illustration, security is most important (with a score of 7), closely followed by integrity (6) and usability (5). Though the other factors do indeed contribute to success—it’s not good if the kiosk crashes halfway through check-in—the fact is that not all quality attributes can have top priority.

Prioritization helps you focus elicitation efforts on the key attributes and helps you know how to respond when you encounter conflicting requirements. In this example, elicitation would reveal a desire to achieve specific performance goals, as well as some specific security goals. These two attributes can clash because adding security layers can slow down transactions. Because the prioritization revealed that security is more important (with a score of 7) than performance (with a score of 4), you should bias the resolution of any such conflicts in favor of security.

Step 4: Elicit specific expectations for each attribute

Users won’t know how to answer questions such as “What are your interoperability requirements?” or “How reliable does the software have to be?” The business analyst must ask questions that explore the users’ expectations and lead to specific quality requirements that help developers create a delightful product. For instance, following are a few questions a BA might ask to understand user expectations about the performance of an information system that manages patent applications that inventors have submitted:

What would be a reasonable response time for retrieval of a typical patent application in response to a query?
What would users consider an unacceptable response time for a typical query?
How many simultaneous users do you expect on average?
What’s the maximum number of simultaneous users that you would anticipate?
What times of the day, week, month, or year have much heavier usage than usual?

Consider asking users what would constitute unacceptable performance, security, or reliability. That is, specify system properties that would violate the user’s quality expectations, such as allowing an unauthorized user to modify a file. Defining unacceptable characteristics lets you devise tests that try to force the system to demonstrate those characteristics. If you can’t force them, you’ve probably achieved your quality goals.

Step 5: Specify well-structured quality requirements

Simplistic quality requirements such as “The system shall be user-friendly” or “The system shall be available 24×7” aren’t useful. The former is far too subjective and vague; the latter is rarely realistic or necessary. Neither is measurable. So the final step is to craft specific and verifiable requirements from the information that was elicited regarding each quality attribute. When writing quality requirements, keep in mind the SMART mnemonic—make them Specific, Measurable, Attainable, Relevant, and Time-sensitive. If a quality requirement isn’t measurable, you’ll never be able to determine if you’ve achieved it. The notation called Planguage (described in Chapter 14 of Software Requirements, 3rd Edition) facilitates precise specification of quality attribute requirements.

Satisfying the user’s quality expectations is a powerful contributor to software project success. A wise BA will systematically explore quality attributes as diligently as she elicits the system’s functional requirements.

Don’t forget to leave your comments below.

========================================
About the Authors:
Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com. Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the recent award-winning book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Requirements Review Challenges

Written by Karl Wiegers on August 13, 2013. Posted in Articles.

Any time someone other than the author of a work product examines the product for problems, a peer review is taking place. Reviewing requirements is a powerful technique for identifying ambiguous or unverifiable requirements, requirements that aren’t defined clearly enough for design to begin, conflicting requirements, and other problems. The most effective type of peer review is a structured and systematic examination called an inspection. Inspection of requirements documents is one of the highest-leverage software quality techniques available. Several companies have avoided as many as 10 hours of labor for every hour they invested in inspecting requirements documents and other software deliverables. A 1,000 percent return on investment is not to be sneezed at.

A peer review is both a technical activity and a social activity. Asking some colleagues to tell you what’s wrong with your work is a learned—not instinctive—behavior. It takes time for a software organization to instill peer reviews into its culture. This article points out some common challenges that organizations face regarding requirements reviews, with suggestions for how to address each one.

Large requirements documents. The prospect of thoroughly examining a several-hundred-page requirements document is daunting. You might be tempted to skip the review entirely and just proceed with construction—not a wise choice. Even given a document of moderate size, all reviewers might carefully examine the first part and a few stalwarts will study the middle, but it’s unlikely that anyone will look at the last part.

To avoid overwhelming the review team, perform incremental reviews throughout requirements development. Use inspections to take a close look at high-risk areas, and use informal reviews for less risky material. Ask particular reviewers to start at different locations in the document to make certain that fresh eyes have looked at every page. To judge whether you really need to inspect the entire specification, examine a representative sample. The number and types of errors you find will help you determine whether investing in a full inspection is likely to pay off.

Large inspection teams. Many project participants and customers hold a stake in the requirements, so you might have a long list of potential participants for requirements inspections. However, large review teams increase the cost of the review, make it hard to schedule meetings, and have difficulty reaching agreement on issues. I once participated in a meeting with 13 other inspectors. Fourteen people cannot agree to leave a burning room, let alone agree on whether a particular requirement is correct. Try the following approaches to deal with a potentially large inspection team:

Make sure every participant is there to find defects, not to be educated or to protect a position.
Understand which perspective (such as customer, developer, or tester) each inspector represents. Several people who represent the same community can pool their input and send just one representative to the inspection meeting.
Establish several small teams to inspect the requirements in parallel and combine their defect lists, removing any duplicates. Several studies have shown that multiple inspection teams find more requirements defects than does a single large group. The results of parallel inspections are primarily additive rather than redundant.

Geographically separated reviewers. Organizations often build products through the collaboration of geographically dispersed teams. This makes reviews more challenging. Teleconferencing doesn’t reveal the body language and expressions of other reviewers like a face-to-face meeting does, but videoconferencing can be an effective solution. Web conferencing tools allow reviewers to ensure that they are all looking at the same material during the discussion.

Reviews of an electronic document placed in a shared network repository provide an alternative to a traditional review meeting. In this approach, reviewers use word-processor features to insert their comments into the text. (This is how we reviewed each other’s work as we were writing our book) Each comment is labeled with the reviewer’s initials, and each reviewer can see what previous reviewers had to say. Web-based collaboration tools also can help. Some requirements management tools include components to facilitate distributed asynchronous reviews that do not involve live meetings. If you choose not to hold a meeting, recognize that this can reduce a review’s effectiveness, but it’s certainly better than not performing the review at all.

Unprepared reviewers. One of the prerequisites to a formal review meeting is that the participants have examined the material being reviewed ahead of time, individually identifying their initial sets of issues. Without this preparation, you risk people spending the meeting time doing all of their thinking on the spot and likely missing many important issues. In fact, if you are invited to participate in a requirements review and do not have adequate time to go over the material in advance on your own, don’t even bother to go to the meeting. It’s a waste of everyone’s time.

One project had a 50-page SRS to be reviewed by 15 people (far too large to be effective and efficient). Everyone had one week to review the document on their own and send issues back to the author. Not surprisingly, most people didn’t look at it at all. So the lead BA scheduled a mandatory meeting for the inspectors to review the document together. He projected the SRS on the screen, dimmed the lights, and began reading through the requirements one by one. (The room had one very bright light shining down in the middle, directly on the lead BA—talk about being in the spotlight!) A couple of hours into the review meeting, the participants were yawning, their attention fading. Not surprisingly, the rate of issue detection decreased. Everyone longed for the meeting to end. This BA let the participants leave, suggesting they review the document on their own time to speed up the next review meeting. Sure enough, being bored during the meeting triggered them to do their prep work.

Reviewing a requirements document is not everyone’s idea of a fun time. Peer reviews can be tedious and time consuming. Nonetheless, if you’re serious about maximizing the quality of your software, your teams will review all of their requirements, using inspections to carefully examine the most critical or error-prone portions. The teams I know that have adopted requirements inspections agree that every minute they spent was worthwhile. Keep the suggestions in this article in mind to help you maximize the return on investment you make in requirements reviews.

Don’t forget to leave your comments below.

Author Bios:

Joy Beatty is a Vice President at Seilevel. Karl Wiegers is Principal Consultant at Process Impact. Karl and Joy are co-authors of the new book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Creating a Culture That Respects Requirements

Written by Karl Wiegers on July 9, 2013. Posted in Articles.

The leader of a corporate requirements organization once posed a problem. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?” In another organization, a BA experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked.

These questions exemplify the challenges that can arise when trying to engage BAs, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that he’ll get what he needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as you are; if they were, they’d probably all become business analysts!

Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.

It’s possible that the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. That would leave anyone feeling frustrated. Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.

If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves. Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers often aren’t aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive—and expensive—course corrections.

Even if you don’t have data available to quantify the costs of requirements problems, every organization has an anecdotal legacy of project failures. People remember systems that were dead on arrival, rejected by users as unacceptable. Isn’t it strange how project teams never feel that they have the time to devote to getting the requirements right, and yet they always find the time, staff, and money to fix systems that were deeply flawed because of requirements errors? Use such stories from the corporate folklore to help steer the culture to a recognition that, without solid requirements, failure is highly likely.

Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity. You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.

Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.

Management plays a powerful role— often the dominant role—in shaping the culture of an organization. The organization’s leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Though project-specific and localized grassroots efforts are important, without management commitment, the improvements and benefits likely won’t be sustained after the project ends or after a reorganization. It doesn’t help if your senior people say they “support” the improvements but then revert to the same old processes the minute there is a fire.

Behaviors—not pronouncements—constitute evidence of commitment to quality. Figure 1 lists ten signs that your organization’s management is truly committed to excellent requirements processes.

Figure 1. Some behaviors that indicate management’s commitment to excellent requirements processes.

Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with facts, reassurance, clarification, and education. Show people how their constructive participation in the requirements process not only is in their personal best interest but also will lead to collectively better results.

========================================
Author Bios:

Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com.

Joy Beatty is a Vice President at Seilevel, www.seilevel.com.

Karl and Joy are co-authors of the new book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.

Cosmic Truths about Software Requirements, Part 3

Written by Karl Wiegers on June 4, 2013. Posted in Articles. 1 Comment on Cosmic Truths about Software Requirements, Part 3

In the previous two articles in this series I have shared some “cosmic truths” about requirements concepts in general and about how requirements affect the project stakeholders. This closing article in the series, adapted from my book More about Software Requirements, presents four more universal truths regarding requirements specifications.

Cosmic Truth #7: The first question a business analyst should ask about a proposed new requirement is, “Is this requirement in scope?”

Anyone who’s been in IT for long has worked on a project that has suffered from scope creep. It is normal and often beneficial for requirements to grow over the course of a project. Scope creep, though, refers to the uncontrolled and continuous increase in requirements that makes it impossible to deliver a product on schedule.

To control scope creep, the project stakeholders must first agree on a scope definition, a boundary between the desired capabilities that lie within the scope for a given product release and those that do not. Then, whenever some stakeholder proposes a new functional requirement, feature, or use case, the BA can ask, “Is this in scope?” To help answer this question, some project teams write their scope definition on a large piece of cardstock, laminate it, and bring it to their requirements elicitation discussions.

If a specific requirement is deemed out of scope one week, in scope the next, then out of scope again later, the project’s scope boundary is not clearly defined. And that’s an open invitation to scope creep.

Cosmic Truth #8: Even the best requirements document cannot—and should not—replace human dialog.

Even an excellent requirements specification won’t contain every bit of information that developers and testers need to do their jobs. There will always be tacit knowledge that the stakeholders assume—rightly or wrongly—that other participants already know, along with the explicit knowledge that must be documented in the requirements specification. BAs and developers will always need to talk with knowledgeable users and subject matter experts to refine details, clarify ambiguities, and fill in the blanks. This is the rationale behind having some key customers, such as product champions, work intimately with the BA and developers throughout the project. The person performing the role of BA (even if this is one of the developers) should coordinate these discussions to make sure that all the participants reach the same understanding so the pieces all fit together properly. A set of written requirements—whether stored in a document, a requirements management tool, or some other form—is still valuable and necessary, though. A documented record of what stakeholders agreed to at a point in time—a “group memory”—is more reliable than human memories.

You need to include more detail in the requirements specifications if you aren’t going to have opportunities for frequent conversations with user representatives and other decision makers. A good example of this is when you’re outsourcing the implementation of a requirements specification your team created. Expect to spend considerable time on review cycles to clarify and agree on what the requirements mean. Also expect delays in getting questions answered and decisions made, which can slow down the entire project.

This very issue was a major contributing factor in a lawsuit I know of between a software package vendor and a customer. The vendor allowed no time in the schedule for review following some requirements elicitation workshops, planning to begin construction immediately. Months later, numerous key requirements issues had not yet been resolved and the project status didn’t remotely resemble the project plan.

Cosmic Truth #9: The requirements might be vague, but the product will be specific.

Specifying requirements precisely is hard! You’re inventing something new, and no one is exactly sure what the product should be and do. People sometimes are comfortable with vague requirements. Customers might like them because it means they can redefine those requirements later on to mean whatever they want them to mean. Developers sometimes favor vague requirements because they allow the developers to build whatever they want to build. This is all great fun, but it doesn’t lead to high-quality software.

Ultimately, you are building only one product, and someone needs to decide just what that product will be. If customers and BAs don’t make the decisions, the developers will be forced to. This is a sign that the key stakeholders are abdicating their responsibility to make requirements-level decisions, leaving those decisions to people who might know far less about the problem or the business.

Don’t use uncertainty as an excuse for lack of precision. Acknowledge the uncertainty and find ways to address it, such as through prototyping. A valuable adjunct to simply specifying each requirement is to define fit criteria that a user or tester could employ to judge whether the requirement was implemented correctly and as intended. Attempting to write such fit criteria will quickly reveal whether a requirement is stated precisely enough to be verifiable. See Suzanne Robertson and James Robertson, Mastering the Requirements Process, Third Edition (Addison-Wesley, 2013) for more information about fit criteria.

Cosmic Truth #10: You’re never going to have perfect requirements.

Requirements are rarely finished or complete. There is no way to know for certain that you haven’t overlooked some requirement, and there will always be some requirements that the BA won’t feel are necessary to record. Rather than declaring the requirements “done” at some point, define a baseline, a snapshot in time that defines an agreed-upon foundation for subsequent work and modifications. Once you’ve established a baseline, follow your change control process to modify the requirements, recognizing the implications of making changes. It’s folly to think you can freeze the requirements and allow no changes after some initial elicitation activities.

Striving for perfection can lead to analysis paralysis. Analysis paralysis, in turn, can have a backlash effect. Stakeholders who have been burned once by a project that got mired in requirements issues sometimes are reluctant to invest in requirements development at all on their next project. This is an even quicker path to failure.

You don’t succeed in business by writing a perfect specification. From a pragmatic perspective, strive to develop a set of requirements that are good enough to allow the team to proceed with design, construction, and testing at an acceptable level of risk. The risk is the threat of having to do expensive and unnecessary rework. Have team members who will need to base their own work on the requirements review them to judge whether they provide a suitably solid foundation for that subsequent work. Keep this practical goal of “good enough” in mind as you pursue your quest for quality requirements.

Don’t forget to leave your comments below.