As Karl Wiegers accurately states in his paper on writing better requirements, “quality is in the eye of the reader … No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.”
Avoiding ambiguity when writing requirements is essential to building the product you want built. In our recent post, “Five Ways Ambiguous Language Will Ruin Your Requirements,” we shared examples of ambiguity in requirements writing and gave expert tips to help clarify.
Here are four more sources of ambiguity, plus additional best practices to save your requirements — and your product.
Negative Requirements
Negative or inverse requirements create a lot of unnecessary ambiguity. Positive requirements in active voice are much easier to understand. Here are some before and after examples of increased clarity when moving from negative to positive.
Abbreviations i.e. and e.g.
Some readers might misconstrue the use of i.e. and e.g. The abbreviation i.e. stands for the Latin phrase id est, which means “that is.” The abbreviation e.g. stands for the Latin phrase exempli gratia, which means “for example.”
These two abbreviations are so commonly confused — either on the part of the writer or the reader — that they are best avoided altogether in favor of explicitly saying what you mean.
A/B Construct
Some requirements writers use the A/B construct, as in, “data should be recorded in an audit/history table.” This construct is rarely used in formal writing because it is so vague it could be interpreted in a variety of ways. Some examples include:
A is the same as B. In this case, they are synonyms and you should stick to one term consistently.
Both A and B. In this case, use the explicit conjunction “and.”
A or B. In this case, use the explicit conjunction “or.”
Adverbs
Words that end in -ly often are ambiguous. They might describe some desirable property of the product, but exactly what is desired is left to each reader’s interpretation. Here are a few examples:
“Allows the user to edit his interests and possibly search results …” Should the user be able edit the search results or not?
“Optimize upload and download to perform quickly.” Is five seconds considered quick?
“Offer significantly better download times.” State exactly how much better or give a range for precisely what the download time should be.
“Subscribers who are changing content selection (effectively a subset of the currently subscribed subscribers) …” Are they a subset or not?
“Exposing information appropriately …” What’s considered appropriate?
Be specific when describing the intended product’s characteristics so all readers share a common vision of the desired result when they’re done.
When a requirement can be interpreted in more than one way, problems ensue. In his paper, “Writing High-Quality Requirements,” expert Karl Wiegers gives examples of ambiguity issues in requirements and best practices to successfully clarify them. Here are five sources of ambiguity and tips to overcome.
Complex Logic
Boolean logic offers many opportunities for ambiguities and missing requirements. Try using a decision tree to reveal gaps and ensure clarity.
Omissions
When requirements lack important pieces of information, it’s unlikely that all readers will interpret them in the same way unless they make precisely the same assumptions. Be sure to include trigger causes that lead to the behavior and indicate what is required to happen because of or after the behavior. Further, specify the action as well as the reverse operation as part of the requirement. For example:
“The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.”
Changes to:
“The system shall display the user’s defined bookmarks in a collapsible and expandable hierarchical tree structure.”
Boundaries
Boundary values in numerical ranges are common sources of ambiguity, and they are a good place to look for missing requirements. One easy way to resolve boundary confusion is to show the information in a table. If you see a number represented in two ranges, you know something needs fixing. Conversely, if there is no value in one of the table’s cells, you can quickly identify the missing requirement.
Synonyms
Using synonyms to describe the same thing across different requirements unnecessarily introduces ambiguity. Will the reader automatically know you mean the same thing or might they assume them to be different? If they are truly identical, use the same word consistently. If there are differences, even subtle ones, place such definitions in a shared glossary so team members understand the terms and use them consistently.
Pronouns
Pronouns can be a source of headaches in a requirements specification. Be certain that the antecedent is crystal clear whenever you employ a pronoun. If you use a word such as this or that, there should be no confusion in the reader’s mind about what you’re referring to.
Learn more requirements best practices from expert Karl Wiegers. In his paper, “Writing High-Quality Requirements,” he explains they begin with proper grammar, well-constructed sentences and a logical organization.
In the product development process, requirements are the foundation to success. They define what a company is trying to build. And they identify what a product needs to do and what it should look like. As the number and complexity of products increases, so do the requirements to support them. Today’s sophisticated products and software applications often take hundreds or thousands of requirements to define their scope so exercising successful requirements management is more important than ever.
It takes an entire team to define and track product requirements. A product manager, for example, will request a feature that describes how the product will solve a problem. A designer will write requirements to illustrate how the product should look or perform from a usability or user interface standpoint. A business analyst will want to make sure the product is built to specific technical or organizational constraints.
Mismanagement of stakeholder needs results in drawn out project timelines and increased costs. According to Carnegie Mellon Software Engineering Institute, 60 percent to 80 percent of the cost of software development is in rework. Development teams can end up wasting their budgets on efforts they didn’t do right the first time. In fact, it can cost up to 100 times more to correct a defect later in the development process, after it’s been coded, than when it’s still in written form, according to Borland Software Corporation.
On the other hand, successful requirements management can eliminate 50 percent to 80 percent of project defects. The entire team can work seamlessly together because everyone is aware of the goals, feedback and decisions. And that increases the likelihood of completing the product on time and within budget.
To effectively manage requirements, it’s important to understand the ins and outs of these four primary principles:
Using stakeholder, system, hardware and software requirements to build a professional wireless microphone.
In the post below—the last of three transcribed from his Writing Good Requirements workshop, with notes and slides from his presentation deck included—Jama Consultant Adrian Rolufs explains common problems teams go through, and how to avoid them. (See Part II here.)
==Start Part III==
Let’s look at an example product using my audio background. I’m going to take a circuit that goes into a professional wireless microphone—the kind of high-performance microphone you’d see someone on a stage, like a MC or a musician, use.
It’s got to be able to handle a wide, dynamic range, meaning it has to be able to record very loud signals and very quiet signals, all with very high quality, and it’s got to be powered off of a battery so that it can he handheld, meaning the connection to the system will be wireless.
So we’re going to talk about some of the requirements that go into the chip; one of the main chips that goes into a solution like this.
First we’ll start at the market or stakeholder requirements level. Often, they’re called stakeholder requirements because stakeholders can be more than just customers.
In most product development organizations customers have requirements, but internal teams also have requirements.
So if I’m building a chip, for example, I have quality requirements that my quality department is going to dictate, but will also be influenced by the customer’s requirements.
And I probably have a production test organization that has to test every one of these devices as they go out the assembly line.
These devices are going to have requirements concerning what kind of access they need to internal circuits, and what kinds of circuits they need to enable them to test in a timely manner—things like that.
The development team might also have requirements; for example, they need to be able to reuse certain amounts of existing circuitry to stay on schedule, or requirements around data costs.
The point is that what we call stakeholder requirements is really a broad category. It could be anybody who has an influence on the product development.
Let’s look at some examples—these would most likely come from customers—which would be focused on the functionality and performance of the device. I’ve got three examples here: One is good and recommended; two are not.
We’ll start with the first one. Say we need a product that can input a microphone signal, convert a signal with two digital audio signals, have two different gain stages and consume less than 20mA while operating.
This is the sort of thing you’d likely hear directly from the customer but not necessarily the sort of thing I’d want to write down as requirements.
This brings up a couple of issues.
First, I’ve got a bunch of requirements mixed together, so it would be easy to miss something, and also it presupposes a certain solution.
It could be this is the right solution, but it assumes certain solutions, so it’s talking about internal details that are over‑constraining the design team.
The team can come up with a different gain structure that works and achieves the results, but doesn’t use 20dB and 0dB of gain. What’s wrong with that? Why do I need to over‑constrain them?
So those are some of the problems with the first one.
Second, customer X needs a 140dB microphone amplifier with a digital output for less than 50 cents. The microphone amplifier shall be low power.
This is the sort of thing marketing might write, because it’s focused on the customer’s request: They need it at a certain cost and everything should always be low power.
It’s very difficult to actually meet these kinds of requirements.
140dB—well, what is that? That’s just a ratio number; I don’t know what that actually is a measurement of. I need some more specificity around that.
As for 50 cents, you have no idea what the solution is yet so 50 cents may or may not be achievable, but it’s good to know.
And then the last one, low power; that can mean almost anything. Low power in one industry could be high power in another, so specificity around what low power means would be beneficial.
So in that case, the first example is more specific and has more detail—although both of the first two are not very atomic so it would be easy to miss things.
The last example talks about two things.
The first one has a problem statement. I love problem statements because they really tie back to the value the solution can offer. It’s giving me some context around what’s in the market today and what the problem is.
It’s saying in the market there are high dynamic range microphones which transmit digitally, and it requires circuitry that’s expensive and large or high power to obtain the necessary performance.
And from that I know that a solution is out there, but that solution is difficult, hard to use or hard to implement, and it can be expensive and it may or may not provide the necessary performance.
You can see how this helps outline the idea of what kinds of problems I need to solve and where the most value is in design.
So based on this, I would know that hitting the audio performance is important, and getting a small solution size that’s low power is also important; those are the key constraints.
To make that have a specific power consumption, say the solution shall consume less than 75mW while in operation.
Now, the other benefit here is 75mW; it’s an actual power number, whereas in the first example I had a current but without knowing the voltage I don’t what the power consumption is, so that’s also not a great example.
So in this case, the last one is the one I would recommend; it has more constraints and a good set of stakeholder requirements. With that, the design team has a good idea of what their goals are, but they’re not over‑constrained.
Now for the next level of detail: Once we have a set of stakeholder requirements, or at least a draft, we can start looking at system requirements. The system requirements are what we’re actually going to build a product against.
We’re not going to build a product directly against the stakeholder requirements because we could have multiple stakeholders and we need to consolidate their requirements into one set.
Or, certain stakeholders may ask for things that we actually end up not satisfying, but we still know that we can build a successful product.
So that translation from stakeholder requirements to system requirements provides the clarity and explicit decisions around what we’re going to do, what we’re not going to do, and what the actual requirements are for this project.
Now, one of my favorite examples of system requirements is the first one—absolutely nothing—and I see this time and time again.
I can’t count the number of times where I see people skipping the system requirements when they’re building a system.
If you’re an engineer responsible for low-level details, how do you know if those low-level details are the right details? Well, you need system requirements first, so we definitely don’t want to skip this level.
Now, the next one: The solution shall have two differential inputs using instrumentation amplifiers. The instrumentation amplifiers shall be followed by sigma‑delta ADCs. These are really low-level component requirements.
We’ve already jumped to the conclusion that we’re going to have a specific architecture in the hardware. What if part of the solution needs to be software? We haven’t said anything about that and we could already be over‑constraining the design team when some other architecture would be more appropriate.
It could be an instrumentation amplifier is not the best choice. We don’t need to constrain that at this level. So the last example here is really a better example of system requirements.
What about power consumption? It’s going to 20mA while in operation. I said before, current on its own is not necessarily the best example. With this you would typically provide a supply voltage range so then it would become clear.
What about the signal levels? Stating what the signal range needs to be provides a lot of detail around what the architecture of the design needs to be, without over‑constraining it.
And then, the overall end‑to‑end, signal‑to‑noise ratio: 140dB A‑weighted gives me a very clear statement of the overall performance, again without over‑constraining.
So for system requirements I like that last one.
These system requirements are all focused on the performance of the signal path. There should also be some system requirements here that talk about constraints on size, constraints on packaging and things like that.
Now we know we need to build something that consumes relatively low power, takes in a very wide dynamic range signal and maintains the quality of that. So we can start talking about architectures in response to these system requirements.
Let’s say we use a hardware device that has analog to digital conversion with two signal paths, both of which have medium performance but which we can combine together to obtain high performance, and that’s actually the common solution in the application.
And then we use a software algorithm to combine those signals, so we’re going to need a DSP to run the software algorithm and process the signal to output this resulting signal of 140dB A‑weighted signal noise ratio.
Based on that, we can now talk about the hardware‑specific requirements.
Here are some examples of different possibilities. The first one is a block diagram of the architecture.
I’m visual; I love block diagrams. I love schematics because they’re very intuitive. I can relate to them very well. They don’t make good requirements, unfortunately. It’s very difficult to test a diagram. It’s very difficult to make sure you didn’t miss anything in a diagram. So having a diagram on its own is not sufficient.
A really good solution is a diagram complemented by a set of requirements that attach to every important detail of that diagram.
That way, visual people have something to see, but we also have atomic requirements that we can test against and trace to make sure we didn’t miss anything, and also so we can manage changes.
If I make changes to this diagram based on changes to the architecture or customer requirements, it might be hard to actually know what those changes were, whereas if I have individual requirements I can track, I can easily know.
The second example is just a description of functionality, a response to the requirements. This is saying what the signal path of the device is; the architecture is describing a specific part number. This is down in the design descriptions where this belongs. It’s not hardware requirements.
So the last example is one I like for hardware requirements. We’re talking power consumption; we’re getting more specific.
We know that I’m building a chip, the power consumption is going to vary and I want to know what it’s typically at and what its maximum can be, so we’re specifying that.
Again, we’re repeating the input signal level because that input signal level was a requirement on the system that’s also a requirement on the hardware.
There is some duplication, but it’s there to explicitly say that this is a requirement on the hardware. I won’t see a requirement for 17uV RMS to 1V RMS on the software, because the software is never going to know about volts; it’s going to know about digital signals.
So even though there is duplication it’s done to make the decisions and the traceability explicit. So then I have requirements on the specific architecture.
Now that we’re down at the low-level and component requirements, the hardware requirements, we can start talking about specific solutions. We’ve got to get into the details of what the solution is actually going to be.
So in this case, in the hardware requirements, you’ll likely see requirements that dictate a certain solution, but that’s okay because it’s quite likely that the design team is the one writing these requirements, so they’re the right ones to make that decision.
As you probably have guessed by now, the last one is my recommendation for well‑written hardware requirements.
The last example is software requirements.
I see a lot of teams that just skip software requirements entirely and go straight to writing code. It’s really fun to write code, really satisfying, but if you don’t have any requirements, you’re starting without clear directions. We need some requirements.
The second example, some descriptions of functionality, is written as a shall statement. It sounds like a requirement but I’ve got a bunch of stuff mixed together.
I’m talking about two signals. I’m talking about what their performance is. I’m talking about the output. There is too much stuff mixed together here, so the third one is the recommendation: talking about specifics.
I am going to develop this software for a specific DSP, the Tenscilica HiFi 3. It’s going to perform a specific function. It’s going to take two audio signals and it’s going to combine those into one.
(Note: I’d probably need more detail around this. This is probably not enough by itself but I didn’t want to fill the screen with the requirements.)
And then, what’s the sample rate going to be? This algorithm is going to be designed for a specific sample rate or multiple sample rates. It’s an important characteristic of the algorithm. Let’s make sure that’s captured in requirements.
So that is exactly what I would recommend, and in each of these there are a lot more requirements that go along with this. These are just a couple of examples in each category.
Many teams mix up requirements and specifications. It’s very common.
You need to make sure you have a clear understanding of each of them and when to use them. It’s not always easy to decide which one is which, so it’s absolutely critical to have that discussion with your team.
What I see a lot of teams doing is skipping levels of hierarchy, jumping straight from high-level customer requirements down to detailed requirements or detailed specifications. Do that and you’ll have a very difficult time proving that you built the right thing.
It could be you’re operating fast and loose and you’re okay with that. Maybe that’s okay for a very small team in a very small organization. But in every other situation, it’s unlikely that you’d be building something so uncomplicated that you could get away with it. It’s high-risk.
So make sure that you have at least stakeholder requirements, client requirements and some kind of detailed specifications.
That’s the bare, bare minimum for any kind of product. More likely you need more.
What I recommend:Make sure you have a clearly defined process with clear levels of your requirements. If you don’t think you have that, discuss it with your team. What levels do you need? Which one of those diagrams [more in posts Part I and Part II] would be appropriate for your project?
And then there’s the scary question: Do you even use requirements?
Some teams plow ahead without requirements. Think about what kind of problems that can cause:
Maybe you’ve built products that have not been successful, that maybe needed a late change or maybe even failed, and you had to develop a new product in order to be successful.
Perhaps you’ve been in a situation where you later learned you missed some important details along the way and realized that you barely got away with it. That’s high-risk too.
When you start with an understanding of the roles different levels of requirements perform, you’re less likely to invite risk and add complications during development, and are much more likely to build the right product.
==End Part III==
Key differences between requirements and specifications, why different levels of requirements are important, and how to establish a clear requirements hierarchy you can use and change to suit any product, version or variant you build.
In the post below—the second of three transcribed from his Writing Good Requirements workshop, with notes and slides from his presentation deck included—Jama Consultant Adrian Rolufs explains common problems teams go through, and how to avoid them. (See Part I here.)
==Start Part II==
These days, products are so complicated they can only be used in specific scenarios and for specific applications, which means that if you don’t build a product right, chances are there’s no home for it.
Potentially millions of dollars of development efforts, not to mention sales, are lost if you’re unable to thoroughly keep track of the requirements all the way through.
So we’re going to talk today about some ways to avoid those problems and really set yourself up for success.
What’s most important is having a systematic process to follow; you want a logical progression that takes you from the high-level to the low-level details in a structured way, because that leads to the best results.
It’s actually more important than how you write the requirements.
So the first key point I want to make concerns differentiating between requirements and specifications, and here the word “specifications” is a nebulous term. It’s used differently in different industries.
In many, “specifications” means a document that contains something, a requirement specification, a verification specification or a list of verification test cases.
By the way, I’m using the term “specification” here as the semiconductor industry does. The specification is a list of the performance, the functionality and the features of the solution; it’s the end result. It documents what you actually produce.
In many cases, there is a document called a datasheet that’s the customer facing version of this. So if you’re familiar with datasheets, think of the specification as the datasheet.
For the purposes of this discussion, here are the differences between requirements and specifications:
Requirements
Requirements reveal what the product needs to do
The tool we use to identify the right product to build and to ensure we’re building it right
The tool we use to communicate internally about what the product needs to do and how it needs to work
Specifications
Specifications detail what the product actually does
Specifications are not useful to identify the right product to build
The tool we use to communicate externally about what the product is and how it works
Typically, requirements are a little higher-level and a less explicit than specifications.
But when you combine the two, what you get is a clear statement of a need and a clear statement of what you’re going to do to satisfy that need.
In doing so, you document exactly what you’re doing and why, and this helps capture the decisions that are made along the way and why they’re made.
However, what I typically see is a document that has intermixed requirements and specifications.
It’s an easy and logical way to write, but it’s very difficult to refer back to afterward for facts and analysis.
So what you end up finding out is, although what you did made sense at the time, you missed some things along the way. There were some high-level requirements that you’d forgotten about.
For example, I was recently working on a product that had only 30 requirements, but discovered that when I wrote the documentation and the specification, I missed one, even though I had written the requirements and solution myself on the same day.
It’s very easy to miss things without a systematic approach in place.
I found what I’d missed only because I’d built the traceability from my specification back to the requirements. I had to prove that I’d met every single requirement and that every one of my specifications was there because of a requirement.
By doing that, it reminded me of something that I missed, so it really saved me some trouble.
This oversight may have come up at some point during reviews, but maybe not, because it’s impossible for anybody to remember every single detail.
Having the requirements separate from the specifications and traceability links between them is critical for making sure you don’t miss anything or end up with features that you don’t need, which add cost or schedules to the product.
Separating the two is difficult if you’re not used to writing that way. Often, I will write, or other people will write, in a traditional kind of document style, and then extract from that what the requirements and the specifications of the solution are.
In other words, you can take an iterative approach to this, and that’s totally valid.
Now, the next question is, how do we get to the right solution? The answer is, by having a clear hierarchy.
So what I’m showing here is a basic hierarchy with market requirements and product requirements. It’s probably the simplest level of requirements you can possibly have in any product development.
The market requirements capture what the customer needs and what the market as a whole needs, and the product requirements say what the requirements are, for the product that we’ve agreed to build.
We can trace back to those customer requirements in such a way that we can prove that the product we’re building is going to satisfy the market requirements, and that we don’t build anything extra.
This is the basic minimum.
You can think of each as a documentation task, but they also follow the phases of your project. When you’re capturing marketing requirements you’re also thinking about what possible solutions you could be developing to satisfy those market requirements.
You’ll likely come up with product concepts, or maybe just one product concept, depending on the situation. And so you would capture, in addition to the requirements, some architectures or concepts that go along with that; that’s the “black box” for all the market requirements.
Same for the product requirements. Once you have them—or while you’re writing them—you’re thinking about the architecture of your solution and the trade-offs you might need to make.
This informs what requirements you can satisfy and which ones you can’t.
By writing the requirements in conjunction with coming up with a design, when you’re done, you have a clear statement of requirements and a solution that can meet them.
Before I came to Jama I was an engineer, coming up with new products, and I sometimes focused only on the product concept and the product design, and skipped a lot of the requirements.
It’s easy to fall into that trap. Engineers love solving problems. We don’t love writing down the requirements for solving those problems. But without those requirements we don’t know whether our solution is the right solution.
Some teams might have, say, only market requirements and no product requirements, or vice versa.
But what they don’t have is a clear distinction between what the customer asked for, or what the market needs and what the team is doing to address both.
As a result, it’s difficult to know whether they’re building the right thing or not.
Now, if your product is complicated you add hierarchy to this model.
Let’s say, for example, I’m doing chip development and my chip has a whole bunch of different internal blocks that are all each fairly complicated in of themselves.
Well, then I can add another level of hierarchy, which I’ll call block-level requirements.
A block requirement would be probably something specific to a chip, or a system where you have a hardware device and it’s made up of sub-circuits.
For example, say I have a digital chip that’s a microcontroller. One block might be a digital interface. Another might be the memory. Another block might be the analog interface.
Or, say I’m building a bigger system, and Engine Control Unit, or ECU, for a car. The ECU is my system. And that ECU is made up of a microcontroller and interfaces; they are components of the system.
Whatever you’re building, you want to break it up into logical pieces; those are your components—which you’ll be wanting to write component requirements for.
So product requirements would describe what is needed from this whole chip overall, and that chip, for the purposes of the requirements, is really best thought of as a “black box.”
But then the block-level requirements say, now that we have a product architecture in mind, what the requirements are for the individual pieces. The designers are going to go and design against those block-level requirements.
For example, product architecture says we’re going to have an ADC, an Analog Digital Converter.
We would then need block-level requirements to say what the performance for this ADC is: What does the power consumption need to be? What does the size need to be it needs to fit into a certain space? What kind of input signals and outputs signals does it need to have?
Things like that.
And then the block design would tell me how this ADC is architecture. What’s the topology? What circuit components are coming together to satisfy those requirements?
Again, having both of those pieces of information is critical.
In this example, what sometimes happens is the product requirements section gets skipped. People already know the architecture, to a certain degree, and so they jump right to the block-level requirements.
The problem with that is market requirements are very high-level and block level requirements are very detailed, so skipping requirements means teams can’t forget a single thing during building.
But the most serious problem is having no traceability back to product requirements; without it, teams can’t confirm the connection between block-level requirements and market requirements.
Without traceability, it’s difficult to know for certain if this block-level requirement traces to that particular market requirement.
You end up missing things, so each of those levels is important.
Now, it could be you are building something even more complicated, so you need to add levels of hierarchy.
Basically,the more complex your build, the more hierarchical structure you want in place.
Here’s a system example; in this case we have both hardware and software, so we have system requirements that describe the overall needs of the system, and then we have an architecture that says, what’s going to happen in hardware, and what’s going to happen in software.
And based on that architecture, we can then write requirements for the hardware and for the software.
We can architect the hardware and the software, and then we can again write low-level requirements for the individual pieces of hardware and the individual pieces of software, and then write the design details that go along with each of those blocks.
So again, you take a systematic approach going from high-level customer needs all the way down to design, and you just adjust this based on the levels of complexity of your product.
And as your products get more complicated, it’s entirely possible that you start off with something simple and you add complexity to the next generation, and maybe you add even more complexity in the next generation, so you have to adjust the model based on your product complexity.
But it’s very unlikely you’ll use the same model forever.
When I was an engineer, we were really more focused on market requirements, product requirements and the block requirements model. Recently I’ve seen a lot more of the system requirements, especially in the chip industry.
Many of the products coming out of chip companies these days are more like systems than ever, so this model ends up being a good place to start.
You can cut out pieces out that you don’t need, but make sure you have accounted for all the pieces that you do need. Having that discussion with your team is really critical to setting up the right model.
==End Part II==
[raw]
To read the updated version of this article, visit www.jamasoftware.com/blog/defining-project-scope-context-use-case-diagrams/.
[/raw]
Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles, adapted from my book More about Software Requirements (Microsoft Press, 2006). I’ll present some definitions, describe four techniques for defining project scope, and offer some tips for managing scope creep.
Vision and Scope
I regard the vision and scope document is a key software project deliverable. You can find a suggested template for this document at http://www.processimpact.com/goodies.shtml. Other terms for this type of guiding document are a project charter, market (or marketing) requirements document, and business case. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the software requirements specification.
Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment. Chapter 5 of my book Software Requirements, 2nd Edition describes how to write a concise vision statement using a simple keyword template.
I’ll define project scope as: “The portion of the ultimate product vision that the current project or iteration will address. The scope draws the boundary between what’s in and what’s out for the project.” The second part of the project scope definition is most important. The scope identifies what the product is and is not, what it will and won’t do, what it will and won’t contain.
A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. In essence, the scope statement defines the boundary of the project manager’s responsibilities.
Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release:
There will be no virtual or fantasy games via the Web.
There will be no ticketing facilities on the site.
There will be no betting facilities available.
The demographic details for newsletters will not be collected.
Message boards are out of scope for phase 1.
Some stakeholders involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success.
The rest of this article describes two techniques I’ve found useful for depicting project scope, the context diagram and the use case diagram. In part 2 of the series, I’ll describe two additional techniques, feature levels and system events.
Context Diagram
The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system. The context diagram shows the name of the system or product of interest in a circle. The circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software systems to which this one connects, or hardware devices that interface to the system.
The interfaces between the system and these external entities are shown with labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow.
The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. The business analyst can decompose these data flows into individual data elements in the project’s data dictionary or data model. Corresponding data inputs and outputs imply the types of operations the system will perform, but these aren’t shown explicitly in the context diagram.
Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary. A BA in a requirements class I once taught showed me a context diagram for her current project. She had shown this diagram to the project manager. The manager had pointed out that one of the external entities shown on the context diagram, another information system, was now going to be part of the new system. With respect to Figure 1, this would be like moving the Payroll System inside the project circle. That is, the scope of the project just got larger than the BA expected. She had expected that external system to be someone else’s responsibility, but now it was her problem.
Use Case Diagram
Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagram for our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box representactors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram.
Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction.
The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. Some analysts simply draw lines instead of arrows on the use case diagram to avoid any confusion with data flow. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases.
The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizeable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams.
Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events.
The need for performing impact analysis is obvious for major enhancements. However, unexpected complications can work below the surface of even minor change requests. A consulting client of mine once had to change the text of a single error message in its product. What could be simpler? The product was available in both English and German language versions. There were no problems in English, but in German the new message exceeded the maximum character length allocated for error message displays in both the message box and a database. Coping with this apparently simple change request turned out to be much more work than the developer had anticipated when he promised a quick turnaround.
Impact analysis is a key aspect of responsible requirements management. It provides accurate understanding of the implications of a proposed change, which helps the team make informed business decisions about which proposals to approve. The analysis examines the proposed change to identify components that might have to be created, modified, or discarded and to estimate the effort associated with implementing the change. Skipping impact analysis doesn’t change the size of the task. It just turns the size into a surprise. Software surprises are rarely good news. Before a developer says, “Sure, no problem” in response to a change request, he or she should spend a little time on impact analysis. This article, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003), describes how the impact analysis activities might work.
Impact Analysis Procedure
The chairperson of the change control board will typically ask a knowledgeable developer to perform the impact analysis for a specific change proposal. Impact analysis has three aspects:
Understand the possible implications of making the change. Change often produces a large ripple effect. Stuffing too much functionality into a product can reduce its performance to unacceptable levels, as when a system that runs daily requires more than 24 hours to complete a single execution.
Identify all the files, models, and documents that might have to be modified if the team incorporates the requested change.
Identify the tasks required to implement the change, and estimate the effort needed to complete those tasks.
Figure 1 presents a checklist of questions designed to help the impact analyst understand the implications of accepting a proposed change. (You can download the checklists and templates described in this article from http://www.processimpact.com/goodies.shtml.) The checklist in Figure 2 contains prompting questions to help identify all of the software elements that the change might affect. Traceability data that links the affected requirement to other downstream deliverables helps greatly with impact analysis. As you gain experience using these checklists, modify them to suit your own projects.
Checklist of possible implications of a proposed change.
Checklist of possible software elements affected by a proposed change.
Following is a simple procedure for evaluating the impact of a proposed requirement change. Many estimation problems arise because the estimator doesn’t think of all the work required to complete an activity. Therefore, this impact analysis approach emphasizes comprehensive task identification. For substantial changes, use a small team—not just one developer—to do the analysis and effort estimation to avoid overlooking important tasks.
Work through the checklist in Figure 1.
Work through the checklist in Figure 2, using available traceability information. Some requirements management tools include an impact analysis report that follows traceability links and finds the system elements that depend on the requirements affected by a change proposal.
Use the worksheet in Figure 3 to estimate the effort required for the anticipated tasks. Most change requests will require only a portion of the tasks on the worksheet, but some could involve additional tasks.
Total the effort estimates.
Identify the sequence in which the tasks must be performed and how they can be interleaved with currently planned tasks.
Determine whether the change is on the project’s critical path. If a task on the critical path slips, the project’s completion date will slip. Every change consumes resources, but if you can plan a change to avoid affecting tasks that are currently on the critical path, the change won’t cause the entire project to slip.
Estimate the impact of the proposed change on the project’s schedule and cost.
Evaluate the change’s priority by estimating the relative benefit, penalty, cost, and technical risk compared to other discretionary requirements.
Report the impact analysis results to the CCB so that they can use the information to help them decide whether to approve or reject the change request.
In most cases, this procedure shouldn’t take more than a couple of hours to complete. This may seem like a lot of time to a busy developer, but it’s a small investment in making sure the project wisely invests its limited resources. If you can adequately assess the impact of a change without such a systematic evaluation, go right ahead; just make sure you aren’t stepping into quicksand. To improve your ability to estimate the impacts of future changes, compare the actual effort needed to implement each change with the estimated effort. Understand the reasons for any differences, and modify the impact estimation checklists and worksheet accordingly.
Estimating effort for a requirement change.
Money Down the Drain
Here’s a true story about what can happen if you don’t take the time to perform impact analysis before diving into implementing a significant change request. Two developers at the A. Datum Corporation estimated that it would take four weeks to add an enhancement to one of their information systems. The customer approved the estimate, and the developers set to work. After two months, the enhancement was only about half done and the customer lost patience: “If I’d known how long this was really going to take and how much it was going to cost, I wouldn’t have approved it. Let’s forget the whole thing.” In the rush to gain approval and begin implementation, the developers didn’t do enough impact analysis to develop a reliable estimate that would let the customer make an appropriate business decision. Consequently, the A. Datum Corporation wasted several hundred hours of work that could have been avoided by spending a few hours on an up-front impact analysis.
Impact Analysis Report Template
Figure 4 suggests a template for reporting the results from analyzing the potential impact of each requirement change. Using a standard template makes it easier for the CCB members to find the information they need to make good decisions. The people who will implement the change will need the analysis details and the effort planning worksheet, but the CCB needs only the summary of analysis results. As with all templates, try it and then adjust it to meet your project needs.
Impact analysis report template
Requirements change is a reality for all software projects, but disciplined change-management practices can reduce the disruption that changes can cause. Improved requirements elicitation techniques can reduce the number of requirements changes, and effective requirements management will improve your ability to deliver on project commitments.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
Track the status of each requirement over time to monitor overall project status, perhaps defining a requirement attribute to store this information. Status tracking can help you avoid the pervasive “ninety percent done” problem of software project tracking. Each requirement will have one of the following statuses at any time.
Proposed (someone suggested it)
Approved (it was allocated to a baseline)
Implemented (the code was designed, written, and unit tested)
Verified (the requirement passed its tests after integration into the product)
Deferred (the requirement will be implemented in a future release)
Deleted (you decided not to implement it at all)
Rejected (the idea was never approved)
Other status options are possible, of course. Some organizations use a status of “Reviewed” because they want to confirm that a requirement is of high quality before allocating it to a baseline. Other organizations use “Delivered to Customer” to indicate that a requirement has actually been released.
When you ask a developer how he is coming along, he might say, “Of the eighty-seven requirements allocated to this subsystem, sixty-one of them are verified, nine are implemented but not yet verified, and seventeen aren’t yet completely implemented.” There’s a good chance that not all these requirements are the same size, will consume the same amount of implementation effort, or will deliver the same customer value. If I were a project manager, though, I’d feel that we had a good handle on the size of that subsystem and how close we were to completion. This is far more informative than, “I’m about ninety percent done. Lookin’ good!”
Requests for Changes
Much of requirements management involves handling requirement additions, modifications, and deletions. Therefore, track the status and impact of your requirements change requests. The data you collect should let your team answer questions such as the following:
How many change requests were submitted in a given time period?
How many of these requests are open, and how many are closed?
How many requests were approved, and how many were rejected?
How much effort did the team spend implementing each approved change?
How long have the requests been open on average?
On average, how many individual requirements or other artifacts are affected by each submitted change request?
Monitor how many changes are incorporated throughout development after you baselined the requirements for a specific release. Note that a single change request potentially can affect multiple requirements of different levels and types (user requirements, functional requirements, nonfunctional requirements). To calculate requirements volatility over a given time period, divide the number of changes by the total number of requirements at the beginning of the period (for example, at the time a baseline was defined):
The intent is not to try to eliminate requirements volatility. There are often good reasons to change requirements. However, we need to ensure that the project can manage the degree of requirements changes and still meet its commitments. Changes become more expensive as the product nears completion, and a sustained high level of approved change requests makes it difficult to know when you can ship the product. Most projects should become more resistant to making changes as development progresses, meaning the trend of accepted changes should approach zero as you near the planned completion date for a given release. An iterative development approach gives the team multiple opportunities to incorporate changes into subsequent iterations, while still keeping each iteration on schedule.
If you receive many change requests, that suggests that elicitation overlooked many requirements or that new ideas keep coming in as the project drags along month after month. Record where the change requests come from: marketing, users, sales, management, developers, and so on. The change request origins will tell you who to work with to reduce the number of overlooked, modified, and misunderstood requirements.
Change requests that remain unresolved for a long time suggest that your change management process isn’t working well. I once visited a company where a manager wryly admitted that they had enhancement requests that were several years old and still pending. This team should allocate certain of their open requests to specific planned maintenance releases and convert other long-term deferred change requests to a status of rejected. This would help the project manager focus the team’s energy on the most important and most urgent items in the change backlog.
Effort
Finally, I recommend that you record the time your team spends on requirements engineering activities. These activities include both requirements development (getting and writing good requirements) and requirements management (dealing with change, tracking status, recording traceability data, and so on).
I’m frequently asked how much time and effort a project should allocate to these functions. The answer depends enormously on the type and size of project, the developing team and organization, and the application domain. If you track your own team’s investment in these critical project activities, you can better estimate how much effort to plan for future projects.
Suppose that on one previous project, your team expended ten percent of its effort on requirements activities. In retrospect, you conclude that the requirements were too poorly defined and the project would have benefited from additional investment in developing quality requirements. The next time your team tackles a similar project, the project manager would be wise to allocate more than ten percent of the total project effort to the requirements work.
As you accumulate data, correlate the project development effort with some measure of product size. The documented requirements should give you an indication of size. You could correlate effort with the count of individually testable requirements, use case points, function points, or something else that is proportional to product size. As Figure 1 illustrates, such correlations provide a measure of your development team’s productivity, which will help you estimate and scope individual release contents. If you collect some product size data and track the corresponding implementation effort, you’ll be in a better position to create meaningful estimates for similar projects in the future.
Some people are afraid that launching a software measurement effort will consume too much time, time they feel should be spent doing “real work.” My experience, though, is that a sensible and focused metrics program doesn’t take much time or effort at all. It’s mostly a matter of developing a simple infrastructure for collecting and analyzing the data, and getting team members in the habit of recording some key bits of data about their work. Once you’ve developed a measurement culture in your organization, you’ll be surprised how much you can learn from the data.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
Anyone who works closely with software engineers understands it takes a big brain to do what they do, even if it’s never really understood exactly what they do or how they do it. But just because you spend the bulk of your time in an obscure world of ones and zeroes, it doesn’t mean you don’t love being empowered to discover uniquely creative ways of solving complex problems.
You simply want a firm grasp on the problems you’re tasked with solving and to be allowed to solve them your way.
But when your team is mired in a poor product delivery system, you and your team likely spend too much of your limited bandwidth deciphering unclear requirements or seeking further explanation of insufficiently described problem statements.
In today’s increasingly complex product delivery workflows, smoothly handing-off work from one life cycle stage to the next requires clear cross-team communication. But handoff difficulties too often become bottlenecks that stall your productivity, especially within delivery environments where teams are siloed and communication lacks efficiency and transparency.
You need complete visibility into the requirements document as it shifts and into every phase of the product roadmap, as well as real-time insight into the related activities of all delivery team members. When that’s the reality, you become a creative problem solver, empowered not only to develop innovative solutions to the challenges your product’s tasked with overcoming, but also to feel passionate about your work while doing it.
Although the challenges mentioned thus far relate specifically to just a few of the many tasks typically required of a software engineer, together they speak in broader terms about a fundamentally flawed product delivery system.
Fixing it requires an entirely new mode of communication, which demands a comprehensive solution to some of the most common challenges:
A “Task” Mindset With No Context
When problem statements fail to provide a thorough description of what needs to be solved, you become a taskmaster. All too often, you’re “tasked” with a specific request, such as “Change this drop-down menu to a list with radio buttons.” Of course, you can handle that, but why are you being asked to do so? What’s the larger problem? By providing the proper context, such as “The drop-down menu makes the user experience too cumbersome,” you’re enabled to creatively address the bigger picture instead of simply completing a task that’s really just a Band- Aid. To address the challenge, you need complete visibility into what is being built from Day One.
Endless Rework
Poorly defined requirements lead to incomplete solutions—a situation that results in unnecessarily reworking the same requirements, definitely not the best use of your time and talent. What you need is a proactive, inclusive system of collaboration that lets you weigh in on the requirements early in the product delivery life cycle.
Legacy Code
Today it’s very rare for a development team to work on a greenfield project. Given the reality that virtually every new software release must be developed to operate harmoniously with legacy code, you’re routinely presented with unique challenges—which become major process hindrances when you lack sufficiently supportive documentation. The solution hinges on having access to a central information repository that provides comprehensive insight into what has been documented and decided upon.
Shifting To An “Embrace Change” Mentality
Why do defects continue to be added to the backlog every time a test fails? Because when you’re focused on immediate tasks, with deadlines looming, issues that should be addressed as part of the current iteration get bumped down the priority list. Or requirements change and you (and other engineers whose work is impacted) aren’t made aware. Fixing the situation means implementing a system that not only ensures you’re informed when requirements change, but that also tracks cross-project relationships and displays how new information impacts the entire product team.
The major consequence of requirements problems is rework—doing over something that you thought was already done. Rework can consume 30 to 50 percent of your total development cost, and requirements errors account for 70 to 85 percent of the rework cost. The data from Hewlett-Packard in Figure 1 shows that it costs far more to correct a defect that’s found late in the project than to fix it early on. Preventing requirements errors and catching them early therefore has a huge leveraging effect on reducing rework. Imagine how different your life would be if you could cut your rework effort in half! You could build products faster, build more and better products in the same amount of time, and perhaps even go home occasionally.
Figure 1. The relative cost to correct a requirement defect depends on when it’s discovered
Shortcomings in requirements practices pose many risks to project success. I describe some of the most common requirements risks in this post.
Insufficient User Involvement
Customers often don’t understand why it is so essential to work hard on gathering requirements and assuring their quality. Developers might not emphasize user involvement, either because working with users isn’t as much fun as writing code or because they think they already know what the users need. In some cases, it’s difficult to gain access to people who will actually use the product, and user surrogates don’t always understand what users really need. Insufficient user involvement leads to late-breaking requirements that delay project completion. There’s no substitute for having the development team work directly with actual users throughout the project.
Creeping Requirements
As requirements evolve and grow during development, projects often exceed their planned schedules and budgets. Such plans aren’t always based on realistic understandings of the size and complexity of the requirements; constant requirements modifications make the problem worse. The problem lies partly in the users’ frequent requests for changes in the requirements and partly in the way that developers respond to these requests.
To manage scope creep, begin with a clear statement of the project’s business objectives, strategic vision, scope, and success criteria. Evaluate proposed new requirements or changes against this reference. An effective change process that includes impact analysis will help the stakeholders make informed business decisions about which changes to accept and the associated cost. Change is often necessary, but change always has a price. To minimize quality degradation, flow requirements changes through the architecture and design rather than implementing them directly into code.
Ambiguous Requirements
One symptom of ambiguity is that a reader can interpret a requirement statement in several ways. Another sign is that multiple readers of a requirement arrive at different understandings of what it means. Ambiguity also results from imprecise and insufficiently detailed requirements that force developers to fill in the blanks. Ambiguous requirements result in wasted time when developers implement a solution for the wrong problem. Testers who expect the product to behave differently from what the developers intended waste time resolving the differences.
One way to ferret out ambiguity is to have people who represent different perspectives formally review the requirements. Simply passing around the requirements document for comments isn’t sufficient to reveal ambiguities. Suppose different reviewers interpret a requirement in different ways but it makes sense to each of them. That doesn’t reveal the ambiguity! Writing test cases against the requirements and building prototypes are other ways to discover ambiguities.
Gold Plating
Gold plating takes place when a developer adds new functionality that he believes “the users are just going to love.” Often, users don’t care about that functionality, and the time spent implementing it is wasted. Rather than simply inserting new features, developers and analysts should present the customers with creative ideas and alternatives for their consideration. Developers should strive for leanness and simplicity, not for going beyond what the customer requests without customer approval.
Customers sometimes request features or elaborate user interfaces that look cool but add little value to the product. Everything you build costs time and money, so you need to maximize the delivered value. To reduce the threat of gold plating, trace each bit of functionality back to its origin so that you know why it’s included.
Minimal Specification
Sometimes marketing staff or managers are tempted to create a limited specification, perhaps just a product concept sketched on a napkin. They expect the developers to flesh out the spec as the project progresses. This approach can work with a tightly integrated, agile team that’s building an application incrementally, on exploratory or research projects, or when the requirements truly are flexible. In other cases, though, it frustrates the developers (who might be operating under incorrect assumptions and with limited direction) and disappoints the customers (who don’t get the product they envisioned).
Overlooked User Classes
Most products have several groups of users who might use different subsets of features, have different frequencies of use, or have varying experience levels. If you don’t identify the important user classes for your product early on, some user needs won’t be met. After identifying all user classes, make sure that each has a voice, some person who will work with the business analyst to elicit the needs of a specific user class.
Inaccurate Planning
“Here’s my idea for a new product; when will you be done?” Don’t answer this question until you know more about the problem being discussed. Vague, poorly understood requirements lead to overly optimistic estimates, which come back to haunt us when the inevitable overruns occur. An estimator’s off-the- cuff guess sounds a lot like a commitment to the listener. The top contributors to poor software cost estimation are frequent requirements changes, missing requirements, insufficient communication with users, poor specification of requirements, and insufficient requirements analysis.
Benefits from a High-Quality Requirements Process
A great reward from effective requirements processes comes from reducing unnecessary rework during development and throughout the lengthy operational period. Many people mistakenly believe that time spent discussing requirements simply delays delivery by the same duration. A holistic cost-of-quality perspective, though, reveals the value of emphasizing early-stage quality practices. Sound requirements processes emphasize a collaborative approach to product development that involves multiple stakeholders in a partnership throughout the project. Collecting requirements lets the development team better understand its users or market.
Engaging users in the requirements-gathering process generates enthusiasm for the product and builds customer loyalty. By emphasizing user tasks instead of superficially attractive features, the team can avoid writing code that won’t ever be used. Customer involvement reduces the expectation gap between what the user needs and what the developer delivers. You’re going to get the customer feedback eventually. Try to get it early rather than late, perhaps with the help of prototypes that stimulate user feedback. This is far cheaper than correcting a lot of problems in beta testing or after release. Documented, unambiguous requirements greatly facilitate system testing, which in turn increases your chances of delivering high-quality products that satisfy all stakeholders.
No one can promise a specific return on investment from an improved requirements process. You can go through an analytical thought process to imagine how better requirements could help you, though. First, consider the cost of investing in a better process. This includes the cost of assessing your current practices, developing new procedures and document templates, training the team, buying books and tools, and perhaps using outside consultants.
Your greatest investment is the time your teams spend gathering, documenting, reviewing, and managing their requirements. Next, think about the possible benefits you might enjoy and how much time or money they could save you. You can’t quantify all the following benefits, but they’re real:
• Fewer requirements defects • Reduced development rework • Fewer unnecessary features • Lower enhancement costs • Faster development • Fewer miscommunications • Reduced scope creep • Reduced project chaos • Higher customer and team member satisfaction
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
![change-impact-analysis-01[1]](https://static.jamasoftware.com/www/imports/2014/02/change-impact-analysis-011.png)
