business requirements Archives

Tag Archive for: business requirements

One of the most common types of requirements problem is missing information. Either entire requirements could be absent—which are hard to spot, being invisible—or individual requirements are missing information that help make them fully comprehensible. In this article I’ll present some examples of both kinds of problems, along with some recommended solutions.

Omissions

When requirements lack important bits of information, it’s hard for all readers to interpret them in the same way unless they make precisely the same assumptions. For instance, a functional requirement might describe a behavior without identifying the triggering cause that leads to that behavior:

The system shall generate an error report and forward it to the user.

This requirement doesn’t identify the stimulus that leads the system to produce the error report. Another common mistake involves missing descriptions of how possible exceptions should be handled. In the previous example, what should happen if no errors occur during the processing being described? It’s unspecified, thereby leaving it up to the developer to decide what to do. Options include:

Do nothing (an assumed default perhaps).
Present a “Congratulations! No errors found.” message but do not generate a report.
Generate an empty report and forward it to the user.
Generate a report stating that no errors were found and forward it to the user.

Perhaps we add the following requirement to address the case in which no errors are encountered:

If parsing is successful, the system shall not generate an error report.

This is another description of the system doing nothing, though, as I discussed under “Negative Requirements” in a earlier article in this series. It would be better to state what the system will do if no error is encountered, even if it is to simply continue the processing.

Another kind of incompleteness occurs when requirements describe system behaviors that involve some type of symmetry. Suppose you’re specifying the functional requirements for a bookmark feature in a Web browser. You might say:

The system shall display the user’s defined bookmarks in a collapsible hierarchical tree structure.

So, the user can collapse the bookmark tree, but what if he wants to expand it again? It’s easy to overlook that sort of symmetrical or reverse operation. To remedy this, either you could add a second requirement stating that the tree can be expanded, or you could alter this requirement to say “…in a collapsible and expandable hierarchical tree structure.”

If you omit the reverse operation, the customer and the BA might assume that the missing portion of the symmetrical requirement is implied. If you request an undo capability, of course you want a redo capability as well, right? But implicit requirements make me nervous. They involve too many assumptions about the knowledge and thought processes that other stakeholders must have to ensure that we all get what we expect in the final product. I know of a organization that developed its own tool for editing and storing source code in a database, with no written requirements. Unfortunately, they forgot to include the ability to print the contents of the database. The team members no doubt assumed that a printing function would be included so didn’t even think to mention it. They didn’t mention it, and they didn’t get it.

Boundaries

Boundary values in numerical ranges provide additional opportunities for creating ambiguity, as well as being places to look for missing requirements. Suppose you’re writing software for a point-of-sale system and you need to comply with a business rule that states, “Only supervisors may issue cash refunds greater than $50.” An analyst might derive several functional requirements from that business rule, such as the following:

If the amount of the cash refund is less than $50, the system shall open the cash register drawer.
If the amount of the cash refund is more than $50 and the user is a supervisor, the system shall open the cash register drawer. If the user is not a supervisor, the system shall display a message: “Call a supervisor for this transaction.”

But what if the amount of the cash refund is exactly $50? Is this a third, unspecified case? Or is it one of the two cases already described? If so, which one? Such ambiguity forces the developer either to make his best guess or to track down someone who can answer the question definitively. This is an example of the BA generating an inconsistency between a higher-level piece of information—the business rule—and the functional requirements derived from it.

You can resolve boundary ambiguities in one of two ways. The previous requirement #1 could be rewritten as, “If the amount of the cash refund is less than or equal to $50, the system shall open the cash register drawer.” This preserves the original intent of the business rule and eliminates the ambiguity.

Alternatively, you could use the words inclusive and exclusive to explicitly indicate whether the endpoints of a numerical range are considered to lie within the range or outside the range. To illustrate with a different example, you might say, “The system shall calculate a 20% discount on orders of 6 to 10 units, inclusive.” This wording makes it perfectly clear that both endpoints of the range, 6 and 10, lie within the range subject to the 20-percent price discount. You still need to review a set of similar requirements to make sure the range endpoints don’t overlap, though. For example, note the inconsistency between the following two requirements:

The system shall calculate a 20% discount on orders of 6 to 10 units, inclusive.
The system shall calculate a 30% discount on orders of 10 to 20 units, inclusive.

The boundary value of 10 is incorrectly included in both ranges. Using a table to show this sort of information is more concise and makes these kinds of errors more evident:

Units Purchased	Discount Percentage
1–5	0
6–10	20
11–20	30
21+	40

Also read Elements of Requirements Style, Part 1

Also read Elements of Requirements Style, Part 2

Also read Elements of Requirements Style, Part 4

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.

Parent and Child Requirements

When writing requirements in a hierarchical fashion, the BA records a parent requirement and one or more child requirements. The parent requirement is satisfied by implementing all of its children. Here’s an illustration of a hierarchical requirement with some problems: 3.4 The requester shall enter a charge number for each chemical ordered. 3.4.1 The system shall validate charge numbers against the master corporate charge number list. If the charge number is invalid, the system shall notify the requester and shall not accept the order. 3.4.2 The charge number entered shall apply to an entire order, not to individual line items in the order. Notice that this parent requirement, 3.4, is written in the form of a functional requirement. It’s not entirely clear how many requirements are represented here: two or three? Also notice that there is a conflict between the parent requirement and one of its child requirements, 3.4.2. If each ordered chemical is a line item, exactly how many charge numbers is the requester supposed to enter? These sorts of problems disappear if the parent requirement is written in the form of a heading or title instead of in the form of a functional requirement. Consider using this style whenever you have a set of child requirements that, in the aggregate, constitute a parent requirement. Following is an improved version of the preceding example: 3.4 Charge Numbers 3.4.1 The requester shall enter a charge number for each chemical in an order. 3.4.2 The system shall validate charge numbers against the master corporate charge number list. If the charge number is not found on this list, the system shall notify the requester and shall not accept the order.

What Was That Again?

Ambiguity is the great bugaboo of software requirements. Ambiguity shows up in two forms. One form I can catch myself. I read a requirement and realize that I can interpret it in more than one way. I don’t know which interpretation is correct, but at least I caught the ambiguity. The other type of ambiguity is much harder to spot. Suppose the BA gives the requirements specification to several reviewers. The reviewers encounter an ambiguous requirement that makes sense to each of them but means something different to each of them. The reviewers all report back, “These requirements are fine.” They didn’t find the ambiguity because each reviewer knows only his own interpretation of that requirement. Let’s see some sources of ambiguity to watch for and some suggestions about how to write less ambiguous requirements.

Complex Logic

Complex Boolean logic offers many opportunities for ambiguities and missing requirements. Consider the following paragraph: If an order is placed for a chemical to a vendor, the system shall check to see if there are any other pending orders for that chemical. If there are, the system shall display the vendor name, vendor catalog number, and the name of the person who placed each previous order. If the user wishes to contact any person who placed a previous order, the system shall allow the user to send that person an e-mail message. This long requirement is difficult to read and contains multiple functionality descriptions that should be split into separate requirements. Plus, it has some gaps. Writing requirements in this style makes it difficult to see whether the outcomes of all the if/then branches are specified. “Else” conditions are often overlooked with this sort of textual representation. Nested “or”, “and”, and “not” clauses are better represented using a decision table or decision tree. A decision tree such as that shown in Figure 1 would immediately reveal that the system’s behavior is not specified if there are no pending orders for that particular chemical. Other false outcomes from the decisions are also unspecified. Implicitly, perhaps the reader will conclude that the system should do nothing if the various “if” conditions described here are false, but that’s an assumption forced by the incompleteness.

Figure 1. Sample decision tree for complex logic.

Expressions involving compound operators—such as “IF this AND (that OR the other)”—are even more confusing: If the amount of the cash refund is less than $50 or the amount of the cash refund is $50 or greater and the current user is a supervisor, then the system shall open the cash register drawer. Making this requirement understandable and unambiguous requires either parentheses (awkward) or splitting into multiple requirements (better).

Negative Requirements

Negative (or inverse) requirements are another source of confusion. Try to recast inverse requirements in a positive sense, to state what the system will do under certain circumstances. Table 1 states several functional requirements, all drawn from actual projects, that contain negation, along with possible ways to rewrite them in a positive sense. I’ve also restated these passive-voice requirements into the less ambiguous active voice, which clearly shows what entity is taking each action. Note that changing a negative requirement into a positive one often requires inserting the word only to identify the conditions that permit the system action being described to take place. In the third example, note also the ambiguity between cannot (as in “not able to”) and may not (as in “not permitted to”). Table 1. Removing Negation from Functional Requirements

Before	After
All users with three or more accounts should not be migrated.	The system shall migrate only users having fewer than three accounts.
The registration process will default to International English and will not present a localized experience until country and language are selected.	The registration process shall default to International English. After the user selects the country and language, the registration process shall present a localized experience.
A domain name cannot be transferred to another registrar during the registration grace period.	The domain administrator may transfer a domain name to another registrar only after the registration grace period.
The PC administrator will not have the ability to change the FZL-Web user.	Only the system administrator shall be able to change the FZL-Web user.

Avoid double and triple negatives in all circumstances. Consider this example: Training rewards and points will not be visible to users who cannot participate in training rewards. We can rephrase this double negative into a positive statement that’s easier to understand: The system shall display training rewards and points only to users who are permitted to participate in training rewards. Following is another illustration of recasting a double negative into a positive using an “only” constraint. The original requirement said: Users who are delivered service without being authenticated should not generate accounting records. Let’s state it as a positive action that the developer can actually implement: The system shall generate accounting records only for users who are delivered service after being authenticated. Multiple negations can lead to ambiguous requirements, as illustrated here: Records, however, should not fail validation if these attributes are not present at all. Does this mean that the records should fail validation if the attributes are present? Probably not. The context might make the meaning of this requirement clearer, but as it’s written, it raises a question in my mind. The main message here is to think positive when writing requirements!

Also read Elements of Requirements Style, Part 1
Also read Elements of Requirements Style, Part 3
Also read Elements of Requirements Style, Part 4

Writing requirements is hard! There is no simple, formulaic approach to software specification. High-quality requirements begin with proper grammar, accurate spelling, well-constructed sentences, and a logical organization. This series of four articles, adapted from my book More about Software Requirements (Microsoft Press, 2006), presents numerous style guidelines to keep in mind when writing functional requirements.

I’m not a fan of arbitrary rules about writing requirements. Some I’ve heard are:

A requirement may not contain the word and. An “and” indicates the presence of two requirements, which must be separated.
A requirement may not contain more than one sentence.
A requirement may not contain more than 22 words.

These sorts of simplistic rules are intended to help analysts write good requirements, but there are too many cases in which they don’t constitute good advice. As you develop your requirements specifications, remember your key objective: clear and effective communication among the project stakeholders.

I Shall Call This a Requirement

Shall is the traditional keyword for identifying a functional requirement. Functional requirements describe behaviors the system shall exhibit under certain circumstances or actions the system shall let the user take. Some people object to the use of shall because it feels stilted. It’s not the way people normally talk, at least not outside English period-piece movies. True—but so what? In fact, this is a plus. Using a distinctive word sharply separates a requirement from other information in a specification document. Shall serves as a symbol that signals the presence of a discrete requirement.

Too many requirements specifications use a random mix of different verbs: shall, must, should, could, would, is recommended, is desirable, is requested, will, can, may, and might. Many of these words are used interchangeably in casual conversation, but this can become confusing in a written specification. The reader is left to wonder whether there’s a subtle but important distinction between these various keywords. Does must have some different connotation than can? Does might (which conveys a sense of possibility in normal dialog) mean the same thing as may (which conveys a sense of permission)? I’ve also heard of conventions in which shall identifies a requirement, but will indicates a design statement and must signifies a constraint. Oh, my.

Some organizations follow a convention I find risky. In this scheme, shall indicates a function that is required, should means that the function is desired, and may indicates that the function being described is optional. This raises two problems. First, two concepts are being combined: the statement of intended functionality and the relative priority of that functionality. The second problem is that the priority information is being communicated using words that have similar meanings in everyday conversation.

My preference is to use the keyword shall to identify functional requirements whenever possible. Avoid should, may, might, and similar words that don’t make it clear whether the statement is a requirement. My colleague Brian Lawrence suggests that you replace should with probably won’t and see if that would be all right with the customer. It probably won’t.

A requirement in the form, “The system should do X” can be restated in the form, “When Y happens, the system shall do X.” And instead of using the shall–should–may convention to communicate priority, I’d rather see requirements written as follows:

“The system shall … [Priority = High].”
“The system shall … [Priority = Medium].”
“The system shall … [Priority = Low].”

The goal of clear and unambiguous communication is more elusive when requirements writers use a mix of nearly synonymous verbs and expect all readers to reach the same conclusions about what they’re trying to say. Frankly, I don’t understand the objection to shall. But if you don’t like it, pick an alternative word—such as must—and use it consistently.

System Perspective or User Perspective?

Various conventions for writing functional requirements exist. Some people believe that requirements should describe only the system’s behavior, because “the system” is what you create by implementing all the functional requirements. However, I think it’s appropriate to write functional requirements from either the system’s perspective or the user’s perspective. Use whichever structure offers the clearest communication in a given situation.

Requirements written from the system’s perspective conform to the following general structure:

Conditions: “When [some conditions are true]…”

Result: “… the system shall [do something]”

Qualifier “…[response time goal or quality objective].”

The “conditions” part of the requirement could reflect an event that triggers the system to respond in some way. Here’s a simple example, from an information system for ordering meals on-line from a company cafeteria:

“When the patron indicates that he does not wish to order any more food items, the system shall display all food items ordered, the individual food item prices, and the total payment amount within 1 second.”

This requirement describes an event that the system can detect, followed by the action the system takes in response to that event. This requirement also includes a performance goal, the 1-second response time. This element constitutes a nonfunctional requirement associated with this specific bit of system functionality.

When stating such performance goals, it’s important to make clear whether they are critical values or merely desirable targets. Is the system acceptable if it takes 1.2 seconds to display the order details? How about 10 seconds? Precise response times are more critical for hard real-time systems than for information systems.

In some cases, it makes more sense to describe actions that the system will let the user take under particular circumstances. When writing functional requirements from the user’s perspective, keep the following general structure in mind:

User type: “The [user class or actor name]…”

Result type: “… shall be able to [do something]…”

Object: “… [to something].

Qualifier: [response time goal or quality objective]

It’s more meaningful to refer to the affected user class by name, rather just saying user. Here’s an illustration of a functional requirement written from the user’s perspective:

“The patron shall be able to reorder any meal he had ordered within the previous six months, provided that all food items in that order are available on the menu for the meal date.”

Note that these examples are written in the active voice. They explicitly identify the entity—the system or a specific user type—that takes each action. Most of the functional requirements I read are written in passive voice:

Passive: “When the output state changes, it is logged in the event log.”

Whenever you can, recast such requirements in the much clearer active voice:

Active: “When the output state changes, the system shall record the new state and the time of the state change in the event log.”

With active voice, the reader doesn’t have to deduce which entity is doing what. The more explicit and precise you can make the requirements, the easier it will be for the readers to understand them and use them to guide the project work they do.

This is the first of a four-part series. Check back soon for Elements of Requirements Style, Parts 2, 3 and 4.

Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry we don’t do a great job of estimation. In this article I offer several safety tips to keep in mind as you prepare estimates for your project and for your individual work.

Tip #1: A goal is not an estimate.

A management- or marketing-imposed delivery date is not an estimate—it is a goal. A team of a certain size and productivity level can produce only so much high-quality functionality in a given time. Estimation tutorials typically are presented as though the body of work to be done is precisely defined and the purpose of estimation is to determine the corresponding effort, cost, and time needed. Sometimes, though, estimation works another way. If the product absolutely must be delivered by a particular date, then the relevant estimation parameter determines how much functionality of given quality will fit into that time box. Commitments should be based on plausible estimates, not just desired targets. A piece of work should not be considered overdue if there was never any likelihood of completing it by the dictated target date.

Tip #2: The estimate you produce should be unrelated to what you think the requester wants to hear.

If your estimate and the requester’s expectation are too far apart, then of course you must negotiate to reach some agreement. But don’t change your estimate simply because someone doesn’t care for it. Suppose your manager requests a time estimate for some piece of work and you reply, “Two months.” “Two months?” exclaims your manager. “My grandmother could do that in three weeks with one hand tied behind her back!” So you try again: “Okay, how about one month?” What changed in those few seconds? Nothing! The task didn’t shrink, and you didn’t magically become more productive. Your manager just didn’t like your first answer so you offered an alternative that might go over better.

There’s no reason to reduce a thoughtfully crafted estimate simply because someone isn’t happy with it. We don’t expect a rainy day to brighten up just because we feel like going on a picnic (especially in Portland, where I live). Nor does it make sense to alter your own prediction of the future, barring a change in factors that affect how you think that future will turn out.

Tip #3: The correct answer to any request for an estimate is “Let me get back to you on that.”

Avoid the temptation to give someone a quick estimate off the top of your head if you haven’t thought carefully about the problem yet. You haven’t really generated an estimate; you just pulled a guess out of thin air. Unfortunately these casual guesses often sound like commitments to coworkers. Before you provide an estimate, think through what is being requested. Then assess how much time and effort it realistically would take to deliver on that request.

This is a particularly common problem when processing requested requirements changes. A little impact analysis often reveals that the real request is substantially bigger than you might have thought based on the initial information you had available. So before you say, “Sure, no problem,” make sure you know what you’re getting into. Sometimes, providing a more realistic estimate leads the requester to drop the whole thing because it’s just not worth the cost or time required. It’s better to know that before you begin devoting effort on the activity, instead of getting halfway done and throwing out what you’ve already invested.

Tip #4: Avoid giving single-point estimates.

Estimates contain uncertainty; that’s why they aren’t called predictions. When you provide an estimate, also state your confidence in the estimate. Are you ten, fifty, or ninety percent confident that you’ll be finished within the estimated time? We usually don’t even think about that, let alone express it aloud. The person who receives the estimate probably assumes that you’re ninety percent confident in the estimate, even if you’re offering a best-case scenario. This mismatch can lead to unpleasant surprises when the estimate turns out to be vastly overoptimistic.

Alternatively, present an estimate as a range instead of a single value. Identify the minimum possible duration (or whatever measurable factor) for the work, the most likely or expected value, and the maximum expected duration barring some catastrophic event. You can calculate a single, nominal-value estimate by summing the minimum possible value, four times the most likely value, and your maximum estimate for that work, and then dividing the total by six. This results in a weighted average that reflects the probability distribution.

Unfortunately, the people to whom you present a range of estimates might select the lowest value of the range as the one they want to hear. A manager who goes with the minimum estimate has chosen to manage his project at a low confidence level, with only a small likelihood of delivering on project commitments. There’s no defense against unreasonable people who reject thoughtful estimates, but at least get into the habit of acknowledging the intrinsic uncertainty associated with all prognostications.

Tip #5: Incorporate contingency buffers into estimates.

Nothing goes exactly as planned. Therefore, build some contingency time into the estimate for each chunk of work you do. These contingencies will help you accommodate any unplanned tasks that may arise, and they’ll compensate for estimates that turn out to be too low. Contingency buffers also help you cope with risks that materialize into problems. If you don’t leave any slack in your schedule, the first unexpected situation you encounter will demolish your plans. Work to meet the nominal estimates, but commit externally to the estimates and the contingencies.

Contingency buffers are sometimes viewed as simply padding, a fudge factor to protect yourself in case you’re not very good at making estimates. Managers sometimes want to yank out the contingency buffer, assuming that this will somehow shorten the project. A manager who discards thoughtfully planned contingency buffers is making several assumptions:

• All estimates are perfect.

• No risks will materialize into problems.

• There will be no growth in the requirements.

• Nothing unexpected will happen.

Anyone who has ever worked on a software project knows that these are not very realistic assumptions. To help a manager avoid these terrible assumptions, you should point out some unexpected experiences from previous projects. Ask the manager if there is any reason to believe that the new project will be different and that none of those unpleasant experiences will be repeated. If no reason can be provided, then the contingency buffers should stay.

These five safety tips might not help you generate estimates that all of your managers, customers, and coworkers will dance to, but they will help you and your team at least hear the same music.

Software projects can derail in many ways. You can avoid making many classic mistakes if you study the many books and articles available on software engineering and project management, as well as the lessons your own teams have learned on previous projects. Sure, everyone’s very busy when you’re launching a new project, and taking the time to study existing bodies of knowledge doesn’t seem like real work. However, “doing nothing” while you examine the lessons of the past is a high-yield investment in your own future. An overconfident project manager, in contrast, will rely solely on personal experience, memories, and the team members’ intelligence and experience to weather any crisis and master any challenge. Hubris, arrogance, and cockiness aren’t a solid foundation for project success.

Best Practices

People have been developing software for more than fifty years. During that time, a number of software development and management techniques have emerged as strong contributors to project success. These are known as best practices. It behooves all project managers, business analysts, and other practitioners to become familiar with the established best practices in their domain. Selectively applying appropriate industry and local best practices is a way to benefit from the lessons learned on thousands of previous projects.

Some people don’t care for the term “best practices.” They protest that it implies a global or absolute standard of excellence. Certainly, practices are context-dependent. Few techniques can be stated universally to be superior in every situation. In fact, I prefer the term “good practices” to “best practices.” Nonetheless, there are indeed patterns of practices and techniques that consistently give better results than do others, when thoughtfully applied in appropriate situations.

Some best practices are collected by industry gurus and consultants who examine many projects for patterns that correlate with success and failure. Other collections of best practices come from authors who glean and synthesize insights from the vast body of software engineering literature. One such author is Steve McConnell, whose classic book Rapid Development (Microsoft Press, 1996) describes thirty-five software best practices. McConnell presents the potential benefits from each practice, the effects on project schedule and risk, improvement in progress visibility, and the chances of both initial and long-term success. He also describes how to apply each best practice and the risks associated with each one.

You do need to watch out for the trap of mindlessly following an approach that someone dubbed a “best practice” without considering whether it applies to the culture, technology, size, and nature of your project and organization. However, you ignore the collected wisdom of those who have gone before at your peril. Don’t assume that your project (or team, or product, or organization) is so different that none of the learnings from other projects apply to your situation. Sure, all projects have their unique aspects, but there are enough commonalities that you can save a lot of time and anguish by applying the lessons that others have accumulated.

Lessons Learned

In addition to published reports of best practices, we all have our own collections of lessons learned from our personal experiences or those of our colleagues. Cancelled projects or those that struggled to deliver a product provide a rich source of insights that can save your team grief on the next project—if you take the time to glean and apply those lessons. The most effective way to reap this harvest of knowledge is through a retrospective. A retrospective is a structured activity in which project participants reflect on the experiences of the previous project, phase, or iteration. Some of these reflections will lead to lessons regarding different approaches to try the next time around. Successful projects are even more valuable, identifying effective solutions to common problems and suggesting actions to repeat on future projects. Two excellent resources for performing retrospectives are Norman L. Kerth’s classic Project Retrospectives (Dorset House Publishing, 2001) and Agile Retrospectives by Esther Derby and Diana Larsen (The Pragmatic Bookshelf, 2006).

Don’t expect all project managers and team members to read the complete report from every retrospective and draw their own conclusions. For the maximum organizational leverage, accumulate and share lessons learned from your retrospectives, from process appraisals, and from your experiences in identifying and managing project risks. Organize the lessons-learned repository to make it easy for future project managers and practitioners to find what they’re looking for. The time you spend accumulating lessons and studying that collection will be amply repaid on every project that finds effective shortcuts and avoids repeating past problems.

I like to write lessons in a neutral style. That way it isn’t obvious whether we learned each one because we did something brilliantly or because we made a foolish mistake. The knowledge itself is more important than how we acquired the knowledge. Don’t use a lessons-learned analysis to try to blame anyone for why a project didn’t turn out the way you hoped.

The template in Figure 1 provides a simple structure for collecting lessons from multiple projects within your organization. Table 1 describes the information that should go into each lesson-learned record. Accumulating insights from multiple projects in a structure like this (or, even better, in a searchable database) facilitates sharing these lessons across all projects and teams. Building a lessons-learned collection is not free. However, it takes far less time to record knowledge than to acquire that knowledge. You can always add more information to the repository, such as searchable keywords, but the information in Table 1 will get you started.

Figure 1. Lessons learned template.

ID	Date	Project	Description	Activity	Contact	Recommendations

Table 1. Lesson Learned Data Field Descriptions

Column	Description
ID	A unique identifier for each lesson. This could be a simple sequence number but a more meaningful label or tag is better.
Date	The date the lesson was entered into the repository.
Project	The name of the project that contributed this lesson.
Description	Description of the lesson learned, including the risks of ignoring the lesson.
Activity	The project life cycle activity, work product, or other subject category to which this lesson applies. Some possible choices are: Concept Proposal, Requirements, Architecture, Prototyping, Hardware, Design, Construction, Unit Testing, Integration, System Testing, User Acceptance Testing, Certification, Installation, Maintenance, Process, Planning, Estimation, Tracking, Management.
Contact	The name of a person the reader could contact to learn more about this lesson.
Recommendations	Suggestions for implementing the lesson on a future project or for taking process improvement actions based on the lesson.

Following are a few simple examples of lessons you might learn on a project. Grow your own list of lessons and pass them along to anyone who might benefit from your own experience. And be sure to refresh your own memory when you dive into the next project. You don’t have time to relearn these lessons the hard way on every project.

Requirements specifications that are going to be outsourced for implementation must be more detailed and clearly written than those that will be implemented locally because you’ll have fewer opportunities for informal interactions to resolve ambiguities and answer questions.
Inspectors need to be trained before you can expect them to be highly effective at finding defects and to participate constructively in a positive inspection experience.
It will take twice as long for new team members to get up to speed and become fully productive as you think it will.
Plan more time than usual for review cycles when the review participants are geographically separated.

You might or might not arrive at these same conclusions when you reflect on your own organization’s project experiences. The exact lessons you learn from each project are less important than the fact that you develop a cultural imperative in the organization of continuous improvement based on continuous reflection and learning. That habit will pay off both for you personally and for your team forever.

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.

Requirements will change and grow over the course of any software project. This is a natural aspect of software development. In fact, if a project doesn’t experience some requirements evolution, the team likely is ignoring reality and risks releasing an irrelevant product. The prudent project manager anticipates and plans to accommodate some requirements growth.

Scope creep (also known as feature creep, requirements creep, featuritis, and creeping featurism), however, refers to the uncontrolled growth of functionality that the team attempts to stuff into an already-full project box. It doesn’t all fit. The continuing churn and expansion of the requirements, coupled with inadequate prioritization, makes it difficult to deliver the most important functionality on schedule. This demand for ever-increasing functionality leads to delays, quality problems, and misdirected energy.

Scope creep is one of the most pervasive challenges of software development. The techniques I described in the first two articles in this series (adapted from my book More about Software Requirements) provide several ways to define a project’s scope. In this final article in this series, I’ll give you some suggestions about how to manage the insidious scope creep.

The first step in controlling scope creep is to document a clearly stated and agreed upon scope for the project. Without a scope definition, how can you even tell if you’re experiencing scope creep? Project teams following an agile development life cycle should write a brief scope statement for each iteration. This helps make sure that everyone understands the goal of the iteration and what functionality the team will—and won’t—implement during that iteration.

An ill-defined scope boundary can have serious consequences. In one situation I know of, a customer had hired a package-solution vendor to migrate three sets of existing data into the new package. Partway through the project, the customer concluded that six additional data conversions were required. The customer felt that this additional work fell within the agreed-upon scope, but the vendor maintained that it was out of scope and demanded additional payment. This scope ambiguity, and the resulting conflict, was one factor that led to the project being cancelled and a lawsuit being filed. Not the desired outcome.

The second step for managing scope creep is for the business analyst or project manager to ask “Is this in scope?” whenever someone proposes some additional product capability. This could be a new or extended use case, a set of functional requirements, another user story, or a new feature or report. Note that the project scope could also encompass activities and deliverables besides the software products themselves. Perhaps your customers suddenly decide they want an online tutorial to help users learn the new system. This doesn’t change the software deliverables, but it certainly expands the scope of the overall project.

There are three possible answers to the question, “Is this in scope?” If the new capability is clearly in scope for the next release, the team needs to address it. If it’s clearly out of scope, the team does not need to address it, at least not now. They might schedule the new capability for a later release.

Sometimes, though, the requested functionality lies outside the scope as it’s currently defined, but it’s such a good idea that the management sponsor should expand the project scope to accommodate it. Less frequently, a proposed change could even modify the strategic product vision in some fundamental way. The question to consider is whether the proposal to expand the scope of the current release will significantly enhance the success of that release.

Electing to increase project scope is a business decision. When weighing whether to increase project scope, the key stakeholders need to consider cost, risk, schedule, and market or business implications. This demands negotiation between the project manager, management sponsor, and other key stakeholders to determine how best to handle the scope alteration. Referring to my three-level model of business, user, and functional requirements, the stakeholders must decide whether proposed changes in user or functional requirements will become the project manager’s responsibility through a scope expansion (Figure 1).

Following are some possible strategies for accommodating a scope increase:

Defer some lower-priority or less time-critical functionality that was planned for the current release or iteration to make room for the proposed scope additions.
Obtain additional development staff to handle the additional work.
Obtain additional funding, perhaps to pay overtime (OK, this is just a little joke), outsource some work, or leverage productivity tools.
Extend the schedule for the current release to accommodate the extra functionality. (This is not a joke.)
Compromise on quality by doing a hasty job that you’ll need to repair later on (not your best option).

Increasing the project’s scope—or, even more profoundly, the product vision—always has a price. The people who are paying for the project must make a considered decision as to which scope management strategy is most appropriate in each situation. The objective is always to deliver the maximum customer value as soon as possible, while achieving the defined business objectives and success criteria, within the existing constraints.

There’s no point in pretending the project team can implement an ever-increasing quantity of functionality without paying a price. In addition, it’s always prudent to anticipate a certain amount of scope growth over the course of the project. A savvy project manager will incorporate contingency buffers into project plans so the team can accommodate some scope growth without demolishing its schedule commitments. This isn’t simply padding or a fudge factor. Thoughtful contingency buffers are simply a sensible way to deal with the reality that things change and projects grow.

Effective scope management requires several conditions be met:

The requirements must be prioritized so that the decision makers can agree upon the capabilities to include in each release or iteration, and so they can evaluate change requests against the priorities of unimplemented requirements in the backlog.
The size of the requirements must be evaluated so that the team has an approximate idea of how much effort it will take to implement them.
The team must know its average productivity (or velocity, in agile terms) so it can judge how many requirements or user stories it can implement and verify per unit time.
The team must assess the impact of change requests they have a good understanding of what it will cost to implement each one.
The decision makers need to be identified and their decision-making process established so they can efficiently decide to modify the scope when appropriate.

Don’t be victimized by the specter of creeping scope or attempt in vain to suppress change. Instead, establish a clear scope definition early in the project and use a practical change control process to cope with the inevitable—and often beneficial—requirements evolution.

Check out Part 1, Defining Project Scope: Context and Use Case Diagrams

Check out Part 2, Defining Project Scope: Feature Levels and System Events

Learn how product development teams can leverage analytics to improve efficiency and quality in “The Essential Guide to Software Development Team Metrics.”

In part 1 of this three-part series, adapted from my book More about Software Requirements, I described the importance of documenting the scope of each software development project or iteration. The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.

Feature Levels

Customers, marketers, and developers often talk about product features, but the software industry doesn’t have a standard definition of this term. I define a feature as: “A set of logically related functional requirements that provides a capability to the user and enables the satisfaction of a business objective.” Features are product capabilities that a user can recognize, as opposed to capabilities that the product needs to have “under the hood” but aren’t visible to end users. Marketing materials often state the features that the new (or improved) product will offer to the customer. Therefore, feature lists help customers make purchase decisions. You can think of each product feature as having a series of levels that represent increasing degrees of capability or feature enrichment. Each iteration or product release implements a certain set of new features and perhaps enhances certain features that were partially implemented in earlier releases. One way to describe the scope of a particular product release, then, is to identify the specific levels for each feature that the team will implement in that release. A sequence of releases represents increasing levels of capability—and hence user value—delivered over a period of time. During requirements analysis, the analyst determines just which functional requirements must be implemented in a particular release to deliver the planned feature levels, beginning with the top-priority or foundational levels of the top-priority features. To illustrate this approach to scope definition, consider the following set of features from our hypothetical cafeteria ordering system: FE-1: Create and modify cafeteria menus FE-2: Order meals from the cafeteria menu to be picked up or delivered FE-3: Order meals from local restaurants to be delivered FE-4: Register for meal payment options FE-5: Request meal delivery FE-6: Establish, modify, and cancel meal service subscriptions FE-7: Produce recipes and ingredient lists for custom meals from the cafeteria Table 1 illustrates a feature roadmap, which depicts the various levels for each of these features that are planned for implementation in forthcoming releases. FE-2 and FE-5 in Table 1 represent features that each have three enrichment levels, but there’s nothing special about three levels. Some product features may have four or five levels of increasing functionality enrichment. Others might just have a single level that’s implemented all at once, such as FE-1, Create and modify cafeteria menus, which the team will fully implement in the first release. The full functionality for each of these features is delivered incrementally across the three planned releases. The analyst can also indicate dependencies between features or feature levels. As an illustration, the level of FE-2 scheduled for release 1 will let users pay for meals by payroll deduction. Therefore, the capability of FE-4 that lets users register for payroll deduction payments cannot be deferred to a later release, because the first level of FE-2 depends on the first feature level of FE-4. Understanding these dependencies is essential for effective release planning. Notice that this sample feature roadmap indicates that the team won’t work on feature FE-3 at all until the third planned release. Also, feature FE-6 is of lower priority than the others. We’d like to get it out in the first release if we can, but it’s okay to defer it to release 2 if necessary. Table 1: A Sample Feature Roadmap

Feature	Release 1	Release 2	Release 3
FE-1	Fully implemented
FE-2	Standard individual meals from lunch menu only; delivery orders may be paid for only by payroll deduction (depends on FE-4)	Accept orders for breakfasts and dinners, in addition to lunches; accept credit and debit card payments	Accept group meal orders for meetings and events
FE-3	Not implemented	Not implemented	Fully implemented
FE-4	Register for payroll deduction payments only	Register for credit card and debit card payments
FE-5	Meals will be delivered only to company campus sites	Add delivery from cafeteria to selected off-site locations	Add delivery from restaurants to all current delivery locations
FE-6	Implemented if time permits	Fully implemented
FE-7	Not implemented	Not implemented	Fully implemented

The feature level approach is the most descriptive of the four techniques I’m presenting for defining the project scope. The farther into the future you look, the less certain the scope plans become and the more you can expect to adjust the scope as project and business realities change. Nonetheless, defining the product vision and project scope lays a solid foundation for the rest of the project work. This helps keep the team on track toward maximizing stakeholder satisfaction.

System Events

The final scoping technique I’m going to describe focuses on external events the system must detect. Each event causes the system to produce a particular response. There are three types of system events to consider:

Business events, which are user actions that cause the system to respond in some way. The trigger that initiates the execution of a use case typically is a business event.
Temporal or time-based events, such as scheduled program executions. Examples are automatically producing a database extract at the same time every night or having an antivirus program check for virus signature updates once an hour.
Signal events, which could be input signals received from sensors or switches in a system that contains both software and hardware components.

Event analysis works well for real-time systems. Consider a complex highway intersection. It might include road sensors and cameras to detect vehicles (though sometimes they don’t seem to spot me when I’m on my motorcycle), traffic lights, buttons pedestrians can press to cross the street, pedestrian walk signals, and so forth. This system has to deal with a variety of events, including these:

A sensor detects a car approaching in one of the through lanes.
A camera detects a car approaching in a left-turn lane.
A pedestrian presses a button to request to cross a street.
One of several timers counts down to zero.

At the scope level, you can just list the external events to which the system must respond without worrying about additional details. For an iterative development approach, you can allocate the handling of specific events to different iterations or releases. This initial events list also leads nicely into more detailed functional requirements specifications, expressed in the form of an event–response table. Exactly what the system does in response to an external event depends on the state of the system at the time it detects the event. Table 2 presents a fragment of what an event–response table might look like for such a system. This sort of layout is an effective alternative to the traditional list of natural-language functional requirements, which can be tedious to read and review. Table 2: Partial Event-Response Table for a Highway Intersection

Event	SystemState	Response
Road sensor detects vehicle entering left-turn lane.	Left-turn signal is red. Cross-traffic signal is green.	Start green-to-amber countdown timer for cross-traffic signal.
Road sensor detects vehicle entering left-turn lane.	Left-turn signal is green.	Do nothing.
Green-to-amber countdown timer reaches zero.	Cross-traffic signal is green.	Turn cross-traffic signal amber. Start amber-to-red countdown timer.
Amber-to-red countdown timer reaches zero.	Cross-traffic signal is amber.	Turn cross-traffic signal red. Wait 1 second. Turn left-turn signal green. Start left-turn-signal countdown timer.

Now that we’ve seen several methods for representing a project’s scope, in the final article in this series I’ll offer some suggestions about how to effectively manage the dreaded specter of scope creep. Check out Part 1, Defining Project Scope: Context and Use Case Diagrams Check out Part 3, Defining Project Scope: Managing Scope Creep 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.

Perhaps you’ve seen a sign at a car repair shop that asked, “What do you want: good, fast, or cheap? Pick two.” While humorous, the sign is also wise: it acknowledges the reality of tradeoffs. You generally cannot optimize every desired outcome of a given situation.

People often apply this so-called “iron triangle” or “triple constraint” to software projects. The problem is that I have seen numerous representations of the triangle with various parameters on the triangle’s vertices—size, cost, time, or scope—and various assumptions made about what is being held constant, such as quality or functionality. I’ve also seen diagrams that show four project dimensions. So, in my view, the “triple constraint” is wrong, although the concept is valid.

The Five Dimensions

I think in terms of five dimensions we have to manage on a software project (Figure 1, adapted from my book Creating a Software Engineering Culture). First, of course, there are the features (aka scope), which itemize the product’s functional capabilities. But it’s important to distinguish quality from scope. I can write software very fast if it doesn’t have to work correctly. The other three dimensions are the time we have available before delivery (schedule), the budget for the project (cost), and the staff available to work on the project. We shouldn’t lump staff and budget together and just call the combination “resources” as is often done. Most of the project cost is indeed staff salaries. I’ve seen situations, though, where a team had adequate funding but could not hire additional staff. In this case, perhaps the project manager can use the available money in different ways, such as outsourcing some work, buying automated test tools, or bringing in consultants.

Figure 1. The five dimensions of a software project.

For each project, we need to decide which dimensions are most critical and how to balance the others so we can achieve the key project objectives. The tradeoffs among these five dimensions are not simple or linear. For example, if you add staff, the schedule might be shortened (although not necessarily) and the cost could well increase. A common, but unfortunate, tradeoff is to shorten the schedule or add features while sacrificing quality. Anyone who has been the victim of buggy software questions these kinds of tradeoff decisions, but they do take place.

Each of these five dimensions can take one of three roles on any given project: a constraint, a driver, or a degree of freedom. Constraints define restrictions within which the project manager must operate. The project manager has no flexibility around a constraint dimension. If a team of immutably fixed size is assigned to a project, staff becomes a constraint. Cost is a constraint on a project being done under a fixed-price contract (at least from the client’s perspective). Quality will be a constraint for a project that develops software for a medical device. Y2K projects were schedule-constrained.

A driver is a key objective or success criterion for the project. For a product with a desired marketing window of opportunity, schedule is a driver. Commercial desktop applications often have features as a driver. The project manager has a little flexibility around the drivers. A specified feature set might be the primary driver of the project, but features are a constraint if the feature set is not negotiable.

Any project dimension that is neither a driver nor a constraint is a degree of freedom. This is a factor that the project manager can adjust within certain limits. The manager’s challenge, then, is to adjust the degrees of freedom to make the project succeed in meeting its success drivers within the limits imposed by the constraints. Suppose that on some corporate information system project the drivers are features and quality and staff is a constraint, so the degrees of freedom become schedule and cost. The implication for this profile is that the features demanded by the customers will all be included, but the delivery time for the product may be later than desirable and the project might cost more than planned.

Here’s a little safety tip: all five dimensions can’t be constraints and they can’t all be drivers! Something has to give to be able to meet the key objectives. If the project is over-constrained, with no degrees of freedom, then you will almost certainly fail. The first added requirement, the first team member who gets the flu, the first risk that materializes will trash the schedule because the project manager has no flexibility to respond to these changes. A student in a project management class I taught once said, “Our project has a fixed budget, we can’t add any people, all of the features are critical, there can’t be any defects, and we have to finish on time.” This project isn’t likely to succeed.

Negotiating Priorities

An important aspect of this model is not which of the five dimensions turn out to be drivers or constraints on any given project, but that the relative priorities of the dimensions be negotiated in advance by the project team, the customers, and management. This negotiation process helps to define the rules and bounds of the project. For instance, schedule is often presented as a constraint when in fact it is a driver. The way to tell the difference is to ask, “Okay, you want this delivered on June 30. What happens if it’s not delivered until, say, July 14?” If the answer is to forget the whole thing because it won’t be useful to us or we’ll be socked with penalties from the government or our client then, yes, schedule truly is a constraint. But if the answer is, “Well, we’d sure like it by June 30, but I guess we’ll live if it’s not available for two more weeks,” then schedule is a driver. If there is some flexibility around a dimension, then it is not a constraint. A little bit of flexibility makes it a driver, and a lot of flexibility makes it a degree of freedom.

Let me illustrate how this five-dimension idea works in practice. Once I heard a discussion between a senior manager and a project manager about a new project. The senior manager asked, “How long will this take?” The project manager replied, “Two years.” “That’s too long,” said the senior manager. “I need it in six months.” So what did the project manager say? He said, “Okay.” Now what changed in those few seconds? Nothing at all! The project didn’t shrink by a factor of four, the team didn’t get four times bigger, and the team didn’t magically become four times as productive. The project manager simply said what the senior manager wanted to hear. (The project took more than two years to complete, incidentally.)

What are some other ways the project manager could have responded instead of simply saying okay? Let’s look at the five dimensions. Maybe he could have asked what portion of the product absolutely must be available within six months. That is, can we cut back on the features intended for the initial release? The project manager could question the schedule, asking, “What’s so vital about six months?” Perhaps this system is replacing a legacy system that runs on an antique computer and they’re removing that computer from the building in six months. Okay, that’s a good reason. Or maybe there’s nothing magic about six months, but we understand there’s a strong desire to get the system operational quickly. In that case the target date of six months is a driver, not a constraint.

You can continue this analysis down the list of the five attributes. Can I get more people or more money? Does the software have to work? Some organizations deliver something on the scheduled release date, but it is severely crippled in functionality and full of bugs. Nonetheless, they declare victory and claim they shipped on schedule, even if what they shipped wasn’t useful. It’s just a little game they play.

Contemplating these five dimensions is a better way to understand your project priorities instead of just assuming that every aspect of the project is both critical and non-negotiable. In part two of this series, I’ll describe two ways to represent the information about a project’s constraints, drivers and degrees of freedom and show you some examples.

Also read The Five Dimensions of a Software Project, Part 2

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.

In the first article in this series I described five dimensions of a software project: features, quality, schedule, staff, and cost. Each of these dimensions can be a project constraint, a driver, or a degree of freedom. A way to classify each dimension into one of the three categories is to think of the amount of flexibility the project leader has with respect to that dimension. A constraint gives the project leader virtually no flexibility, a driver has low flexibility, and a degree of freedom provides wider latitude to balance that dimension against the other four.

Flexibility Diagrams

A graphical way to depict the degree of flexibility is with a Kiviat diagram, also called a radar chart or a spider chart (Figure 1). In a Kiviat diagram, you show the five dimensions around a circle and draw a separate axis for each dimension coming out from a common origin point in the center. All the axes are the same length and they are normalized to the same scale. Each axis represents how much flexibility the project manager has in the corresponding dimension, so I call these pictures “flexibility diagrams.” I use a relative scale from zero to ten for flexibility. Zero is not shown at the exact center of the origin just for convenience in drawing the plot.

Figure 1. Flexibility diagram for a corporate information system.

Plotting a point at zero indicates that the dimension for that axis is a constraint with no flexibility. If you plot a point fairly low on the axis, between zero and two or thereabouts, that represents a driver. It shows that the project manager has a small amount of flexibility in that dimension. Any dimension plotted at a higher level on its axis represents a degree of freedom having more latitude for adjustment. If you connect the five points for the five dimensions that you plotted, you get an irregularly shaped pentagon that visualizes one profile of the project’s characteristics.

Figure 1 shows the flexibility diagram for an information system my team once developed. This project was constrained to a fixed staff size, so the value plotted on the staff axis is zero. The project was aiming for a desired, but not critical, delivery date, so the point on the schedule axis also has a low value. The project had varying amounts of flexibility around the features that would be incorporated into the initial release, the product quality, and the latitude for cost overruns. Therefore, the values for these degrees of freedom are plotted higher on their axes.

Note that this is not a high-resolution or quantitative tool. We’re not going to calculate the area of the pentagon or anything like that. But the size of the pentagon does provide a rough indication of how much flexibility the project manager has to work with. If the pentagon is small, that means that you have numerous constraints or drivers, which will make it more difficult for the project manager to steer a path to success.

Different types of projects will lead to flexibility diagrams having very different shapes. Figure 2 illustrates a flexibility diagram for a hypothetical project for which quality is a driver and the schedule shows the greatest latitude. This is what you might see for a product intended for use in a higher-risk environment. Note that this diagram does not show any constraints; none of the axes are plotted at the zero value. That’s fine. In contrast, the profile for a commercial software product in a highly competitive environment might look like Figure 3, in which a specified feature set must be included (a constraint), the schedule is constrained to a specified ship date, and the quality is just whatever it turns out to be.

Figure 2. Flexibility diagram for a quality driven application.

Figure 3. Flexibility diagram for a competitive commercial application.

The shapes of the pentagons in these examples visually indicate the important aspects of each project. If you push the point on one of the axes inward to reduce the amount of latitude the project leader has in one dimension, you’ll generally have to adjust the other dimensions to compensate. You can use this sort of analysis to make management aware of the tradeoffs and decisions they must make to meet a project’s key objectives, and to negotiate realistically achievable commitments on each project.

Flexibility Table

You can also document your project priorities in the form of a flexibility table, as illustrated in Figure 4. This example is simplified just to give you a flavor of how this works. For each project constraint, state the limits the project manager must work within. For each success driver, described the goal you’re intending to achieve. For each degree of freedom, describe the tolerance or latitude that the project manager has available.

Figure 4. Sample flexibility table.

Dimension	Constraint (State Limits)	Driver (State Objectives)	Degree of Freedom (State Range)
Cost			Up to 20% overrun from initial estimate is acceptable
Features			At least 80% of priority 1 features must be in release 1.0
Quality			Release 1.0 can contain up to 4 known noncritical defects
Schedule		Release 1.0 should be delivered within 4-5 months
Staff	5 full-time staff available for duration of the project

The table in Figure 4 is for the project whose flexibility diagram appears in Figure 1. Recall that staff was a constraint. We had just five full-time team members available for the duration of this project. Schedule was a driver. We wanted to have the first release delivered within four to five months, but there was no fixed delivery date. The other three dimensions had more flexibility. Because the project was essential, the project manager could overrun the initial budget by a reasonable margin before anyone would get upset. We did have a core set of high priority features that we needed to have delivered in the first release, but other than that, we could defer some requirements if necessary.

Note that each of the five dimensions takes on only one characteristic. For example, schedule is either a constraint, a driver, or a degree of freedom, not two of these or all three. You wouldn’t have entries for the same dimension in more than one column in a flexibility table.

Applying the Five Dimensions

The point of this analysis is to help the project manager make decisions as to how to respond to changing conditions or realities on the project. You can use the five-dimension model to renegotiate when the world changes. Suppose staff is constrained as it is in Figure 1. If new requirements come along that simply must be included, the only parameters that can change are quality, cost, or schedule. Nothing is free. Ask management which dimensions to adjust to accommodate this request. The specific answer is less important than the discussion that is triggered when project managers react to unexpected changes in any of these five dimensions. Customers and managers have to understand the impact of such changes on the other project dimensions so they can make the right decisions.

One characteristic of a healthy software engineering culture is that project expectations and commitments are established through negotiation. To avoid unpleasant surprises late in a project’s life cycle, the stakeholders all have to understand and agree on their objectives and priorities. Not everyone might be happy with the outcome of the negotiations, but people can commit to realistic schedules and deliverables only if all the parameters are discussed honestly. A group with a culture in which people are afraid to say no or to discuss problem areas openly will always fall short of expectations. Tools like the flexibility diagram can facilitate these frank, and often difficult, negotiations.

Also read The Five Dimensions of a Software Project, Part 1

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.

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.

Figure 1. Checklist of possible implications of a proposed change.

Figure 2. 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.

Figure 3. 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.

Figure 4. 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.