Tag Archive for: karl wiegers Page 4

Tag Archive for: karl wiegers

Automated tools can help your change control process operate more efficiently. Many teams use commercial problem- or issue-tracking tools to collect, store, and manage requirements changes. A list of recently submitted change proposals generated from the tool can serve as the agenda for a change control board meeting. Problem-tracking tools can also report on the number of requests in each status category at any given time, the origins of the change requests, and other parameters that can give you insight into the change activity on your projects.

Because the available tools, vendors, and features frequently change, I won’t provide specific tool recommendations here. Instead, I’ll provide some general guidance about how to effectively incorporate such tools into your software development process and how to use the tool’s reporting capabilities to get a handle on the project’s change activity. Look for the following features in a tool to support your requirements change activities:

  • Lets you define the data items included in a change request.
  • Lets you define a state-transition model for the change-request life cycle.
  • Enforces the state-transition model so that only authorized users can make the permitted status changes.
  • Records the date of every status change and the identity of the person who made it.
  • Lets you define who receives automatic email notification when an originator submits a new request or when a request’s status is updated.
  • Produces both standard and custom reports and charts.

Some commercial requirements management tools have a simple change-proposal system built in. These systems can link a proposed change to a specific requirement so that the individual responsible for each requirement is notified by email whenever someone submits a pertinent change request.

Tooling Up a Process

When I worked in a Web development team for a large corporation, one of our first process improvements was to implement a change control process to manage our huge backlog of change requests. We began with a process similar to the one described in the previous article in this series on change control. We piloted it for a few weeks by using paper forms while I evaluated several issue-tracking tools. During the pilot process we found several ways to improve the process. We also discovered several additional data items that should be included in the change requests. We selected a highly configurable issue-tracking tool and tailored it to match our process.

The team used this process and tool to handle requirements changes in systems under development, defect reports and suggested enhancements in production systems, updates to Web site content, and requests for new development projects. Change control was one of our most successful process improvement initiatives. Our process and tool really helped this extremely busy team manage its dynamic backlog of requests effectively.

Status Overkill

It’s easy for people to get carried away with all the options they have available with a change control tool. I saw a good example of this once when I was visiting a client site. That very day, someone was configuring the team’s new change control tool. He was planning to set up no fewer than fifteen unique statuses for change requests. While I can imagine that these statuses all made some sense, the fact is that no one is going to use them all in practice. Some of them were transient statuses, through which a change request might pass just briefly on its way from one status to another. In reality, no one is going to update the contents of the change-request database frequently enough for these short-lived status changes to be useful.

Be sure to take a pragmatic approach to the tools and processes you use. If the process and tool are overly complex and do not add evident value to the organization, team members will find ways to bypass the process or revert to handling things manually instead of through the tool. This undermines the effort and gives the whole concept of process a bad reputation.

Measuring Change Activity

Software measurements provide insights into your projects, products, and processes that are more accurate than subjective impressions or vague recollections of what happened in the past. The measurements you select should be motivated by the questions you or your managers are trying to answer and the goals you’re trying to achieve. Measuring change activity is a way to assess the stability of the requirements. It also reveals opportunities for process improvement that might lead to fewer change requests in the future. Consider tracking the following aspects of your requirements change activity:

  • The number of change requests received, currently open, and closed.
  • The cumulative number of changes made, including added, deleted, and modified requirements (You can also express this as a percentage of the total number of requirements in the baseline.)
  • The number of change requests that originated from each source.
  • The number of changes proposed and made in each requirement since it was baselined.
  • The total effort devoted to processing and implementing change requests.
  • The number of cycles through the change process that it took to correctly implement each approved change (Sometimes changes are implemented improperly or cause other errors that need to be corrected.)

You don’t necessarily need to monitor your requirements change activities to this degree. As with all software metrics activities, understand your goals and how you’ll use the data before you decide what to measure. Start with simple measurements to begin establishing a measurement culture in your organization and to collect the key data you need to manage your projects effectively. As you gain experience, make your measurements as sophisticated as necessary to help your projects succeed.

Figure 1 illustrates a way to track the number of requirements changes your project experiences during development. This chart tracks the rate at which requests for new requirement changes arrive. You can track the number of approved change requests similarly. Don’t count changes made before baselining; you know the requirements are still evolving prior to establishing the baseline. Once you’ve baselined the requirements, though, all proposed changes should follow your change control process. At that point you should also begin to track the frequency of change (also called requirements volatility) that Figure 1 illustrates. This change-frequency chart should trend toward zero as the project approaches its ship date. A sustained high frequency of changes implies a risk of failing to meet your schedule commitments. It probably also indicates that the original baselined requirements were incomplete, suggesting that improving your requirements elicitation practices might be a good idea.

Figure 1. Sample chart of requirements change activity.

A project manager who’s concerned that frequent changes might prevent the project from finishing on schedule can gain further insight by tracking the requirements change origins. Figure 2 shows a way to represent the number of change requests that came from different sources. The project manager could discuss a chart like this with the marketing manager and point out that marketing has requested the most requirements changes. This might lead to a fruitful discussion about what actions the team could take to reduce the number of post-baselining changes received from marketing in the future. Using data as a starting point for such discussions is more constructive than holding a confrontational meeting stimulated by frustration.

Figure 2. Sample chart of requirements change origins.

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.

Whether you like it or not, requests to modify the requirements are going to come your way on a software project. To keep the inevitable changes from throwing your project into chaos, someone has to make the decisions about which changes to accept and which to reject. The industry-standard term for these decision makers is the change control board, and every project needs one.

The change control board (sometimes known as the configuration control board) has been identified as a best practice for software development. The CCB is the body of people, be it one individual or a diverse group, who decides which proposed requirement changes and newly suggested features to accept for inclusion in the product. The CCB also decides which reported defects to correct and when to correct them. Most projects already have some de facto group that makes change decisions; establishing a CCB formalizes this group’s composition and authority and defines its operating procedures.

A CCB reviews and approves changes to any baselined work product on a project, of which the requirements documents are only one example. Some CCBs are empowered to make decisions and simply inform management about them, whereas others can only make recommendations for management decision. On a small project it makes sense to have only one or two people make the change decisions. At the other extreme, very large projects or programs might use several levels of CCBs. Some are responsible for business decisions, such as requirement changes, and some for technical decisions. A higher-level CCB has authority to approve changes that have a greater impact on the project. For instance, a large program that encompasses multiple projects would establish a program-level CCB and an individual CCB for each project. Each project CCB resolves issues and changes that affect only that project. Issues that affect other projects and changes that exceed a specified cost or schedule impact are escalated to the program-level CCB.

To some people, the term “change control board” conjures an image of wasteful bureaucratic overhead. Instead, think of the CCB as providing a valuable structure to help manage even a small project. This structure doesn’t have to be time-consuming or cumbersome—just effective. An effective CCB will consider all proposed changes promptly and will make timely decisions based on analysis of the potential impacts and benefits of each proposal. The CCB should be no larger and no more formal than necessary to ensure that the right people make good business decisions about every requested modification.

CCB Composition

The CCB membership should represent all groups who need to participate in making decisions within the scope of that CCB’s authority. Sometimes a single individual can make decisions from all these perspectives, but more frequently you’ll need a multifunctional team. Consider selecting representatives from the following areas:

  • Project or program management
  • Product management or business analyst
  • Development
  • Testing or quality assurance
  • Marketing or customer representatives
  • User documentation
  • Technical support or help desk
  • Configuration management

The CCB for a project that has both software and hardware components might also include representatives from hardware engineering, system engineering, manufacturing, or perhaps hardware quality assurance and configuration management. Only a subset of these people actually need to participate in making the change decisions, although all must be informed of decisions that affect their work.

Keep the CCB as small as possible so that the group can respond promptly and efficiently to change requests. As we’ve all discovered, large groups have difficulty even scheduling meetings, let alone making decisions. Make sure that the CCB members understand their responsibilities and take them seriously. To ensure that the CCB has adequate technical and business information, invite other individuals to a CCB meeting when specific proposals are being discussed that relate to those individuals’ expertise.

CCB Charter

A charter describes the CCB’s purpose, scope of authority, membership, operating procedures, and decision-making process. You can download a suggested template for a CCB charter from http://www.processimpact.com/goodies.shtml. The charter should state the frequency of regularly scheduled CCB meetings and the conditions that trigger a special meeting. The scope of the CCB’s authority indicates which decisions it can make and which ones it must pass on to a higher-level CCB or a manager.

Making Decisions

As with all decision-making bodies, each CCB needs to select an appropriate decision rule and process. The decision-making process description should indicate the following:

  • The number of CCB members or the key roles that constitutes a quorum for making decisions.
  • Whether voting, consensus, consultative decision making, or some other decision rule is used.
  • Whether the CCB Chair may overrule the CCB’s collective decision.
  • Whether a higher level of CCB or someone else must ratify the decision.

The CCB balances the anticipated benefits against the estimated impact of accepting a proposed change. Benefits from improving the product include financial savings, increased revenue, higher customer satisfaction, and competitive advantage. The impact indicates the adverse effects that accepting the proposal could have on the product or project. Possible impacts include increased development and support costs, delayed delivery, degraded product quality, reduced functionality, and user dissatisfaction. If the estimated cost or schedule impact exceeds the established thresholds for this level of CCB, refer the change to management or to a higher-level CCB. Otherwise, use the CCB’s decision-making process to approve or reject the proposed change.

Communicating Status

Once the CCB makes its decision, a designated individual updates the request’s status in the change database. Some tools automatically generate email messages to communicate the new status to the originator who proposed the change and to others affected by the change. If email is not generated automatically, inform the affected people expeditiously so they can properly process the change.

Renegotiating Commitments

It’s not realistic to assume that stakeholders can stuff more and more functionality into a project that has schedule, staff, budget, and quality constraints and still succeed. Before accepting a significant requirement change, renegotiate commitments with management and customers to accommodate the change. You might negotiate for more time or staff or ask to defer pending requirements of lower priority. If you don’t obtain some commitment adjustments, document the threats to success in your project’s risk list so that people aren’t surprised if the project doesn’t fully achieve the desired outcomes.

Establishing a small and well-functioning change control board early in a project is an effective way to make sensible business and technical decisions so the project can deliver the maximum benefit with the minimum effort. Someone’s going to make all those decisions anyway. I think it’s best to thoughtfully identify those key players, then give them the charter and the tools to do their job efficiently.

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.

I admit it: I’m a process kind of guy. My opinion is that any time we have a relatively complex activity that needs to be performed numerous times and involves multiple people, it’s a good idea to write down the steps in that activity. It’s also a good idea to train people so they know how to perform the activity effectively. Even a simple documented process description (and simple is nearly always better than complex) helps ensure that we succeed in our mission each time we perform the activity.

Managing changes is one of those activities that every software organization must perform in largely the same fashion. This article, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003), describes a typical change control process that can be used, with minor adaptation, by just about any development organization. You can download a sample change control process description from http://www.processimpact.com/goodies.shtml.

Figure 1 illustrates a proposed template for a change control process description to handle requirements modifications and other project changes. The discussion in this article pertains primarily to how the process would handle changes proposed in requirements. I find it helpful to include the following four components in all procedures and process descriptions:

  • Entry criteria—the conditions that must be satisfied before executing the process or procedure.
  • The various tasks involved in the process or procedure, the project role responsible for each task, and other participants in the task.
  • Steps to verify that the tasks were completed correctly.
  • Exit criteria—the conditions that indicate when the process or procedure is successfully completed.

You’ll find these elements in steps 4, 5, 6, and 7 of Figure 1. Now let’s look at what you might put into each section of this template.

Figure 1. Sample template for a change control process description.

 

1. Introduction

The introduction describes the purpose of this process and identifies the organizational scope to which it applies. If this process covers changes only in certain work products, identify them here. Also indicate whether any specific kinds of changes are exempted, such as changes in interim or temporary work products created during the course of a project. Define any terms that are necessary for understanding the rest of the document in section 1.3.

2. Roles and Responsibilities

List the project team members—by role, not by name—who participate in the change-control activities and describe their responsibilities. Table 1 suggests some pertinent roles; adapt these to each project situation. Different individuals need not fill each role. For example, the CCB Chair might also receive submitted change requests. Several—perhaps all—roles can be filled by the same person on a small project.

Table 1. Possible Project Roles in Change-Management Activities

 

3. Change-Request Status

A change request passes through a defined life cycle, having a different status at each stage in its life. You can represent these status changes by using a state-transition diagram, as illustrated in Figure 2. Update a request’s status only when the specified criteria are met.

Figure 2. State-transition diagram for a change request.

4. Entry Criteria

The basic entry criterion for your change control process is that a valid change request has been received through an approved channel. All potential originators should know how to submit a change request, whether it’s by completing a paper or Web-based form, sending an email message, or entering the information into a change-control tool. Assign a unique identification tag to every change request, and route them all to a single point of contact, the Request Receiver.

5. Tasks

The next step is to evaluate the request for technical feasibility, cost, and alignment with the project’s business requirements and resource constraints. The change control board (CCB) Chair might assign an evaluator to perform an impact analysis, risk analysis, hazard analysis, or other assessments. This analysis ensures that the potential consequences of accepting the change are well understood. The evaluator and the CCB should also consider the business and technical implications of rejecting the change.

The appropriate decision makers, chartered as the CCB, then elect whether to approve or reject the requested change. The CCB gives each approved change a priority level or target implementation date, or it allocates the change to a specific build or release number. The CCB communicates the decision by updating the request’s status and notifying all team members who might have to modify work products. Affected work products could include the requirements documentation, design descriptions and models, user interface components, code, test documentation, help screens, and user manuals. The modifier(s) update the affected work products as necessary.

6. Verification

Requirements changes are typically verified through a peer review to ensure that modified specifications, use cases, and models correctly reflect all aspects of the change. Use traceability information to find all the parts of the system that the change touched and that therefore must be verified. Multiple team members might verify the changes made in downstream work products through testing or review. Following verification, the modifier installs the updated work products to make them available to the rest of the team and redefines the base¬line to reflect the changes.

7. Exit Criteria

All of the following exit criteria must be satisfied to properly complete an execution of your change control process:

 The status of the request is Rejected, Closed, or Canceled.

 All modified work products are installed into the correct locations.

 The originator, CCB Chair, project manager, and other relevant project participants have been notified of the change details and the current status of the change request.

 If you have requirements traceability matrix for your project, it has been updated.

8. Change-Control Status Reporting

Identify the charts and reports you’ll use to summarize the contents of the change control database. These charts typically show the number of change requests in each status category as a function of time. Describe the procedures for producing the charts and reports. The project manager uses these reports when tracking the project’s status.

Appendix: Data Items Stored for Each Request

Table 2 lists some data items to consider storing for each change request. When you define your own list, indicate which items are required and which are optional. Also, indicate whether the value for each item is set automatically by your change-control tool or manually by one of the participants in the change-management process.

The next article in this series describes the composition and responsibilities of the CCB, the change control board.

Table 2. Suggested Change-Request Data Items

 

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.

One of the few constants about software development is that change happens. I doubt any project has ever delivered a product that exactly matched its original specifications. Software change isn’t a bad thing. It’s virtually impossible to define all of a product’s requirements up front, and the world changes as development progresses. An effective software team can nimbly respond to necessary changes so that the product they build provides timely customer value. This series of five articles, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003) addresses many aspects of handling requirement changes effectively.

The change process is fraught with problems. Most developers have encountered an apparently simple change request that turned out to be far more complicated than expected. Developers sometimes don’t—or can’t— produce realistic estimates of the cost and other ramifications of a proposed software change. And, when developers who want to be accommodating agree to add enhancements that a user requests, requirements changes slip in through the back door instead of being approved by the right stakeholders. Such uncontrolled change is a common source of project chaos, schedule slips, and quality problems. An organization that’s serious about managing its software projects must ensure that:

  • Proposed requirements changes are carefully evaluated before being committed to.
  • The appropriate individuals make informed business decisions about requested changes.
  • Approved changes are communicated to all affected participants.
  • The project incorporates requirements changes in a consistent fashion.

But change always has a price. Revising a simple Web page might be quick and easy; modifying an integrated chip design can cost tens of thousands of dollars. Even a rejected change request consumes the resources needed to submit, evaluate, and decide to reject it. Unless project stakeholders manage changes during development, they won’t really know what will be delivered, which ultimately leads to an expectation gap. The closer you get to the release date or the end of a development iteration, the more you should resist changing that release because the consequences of making changes become more severe.

The business analyst should incorporate approved changes into the project’s requirements documentation. Your philosophy should be that the requirements documentation will accurately describe the delivered product. If you don’t keep the software requirements specification (SRS) current as the product evolves, its value will decrease and the team might function as though it doesn’t even have an SRS. And requirements documentation that doesn’t match the reality of the product is practically useless as a maintenance aid.

When you need to make a change, start at the highest level of abstraction that the change touches and cascade the impact of the change through related system components. For example, a proposed change might affect a use case and its functional requirements but not any business objectives. A modified high-level system requirement could have an impact on multiple software requirements. Some changes pertain only to system internals, such as the way a communications layer is implemented. These are not user-visible requirements changes but rather design or code changes.

Several problems can arise if a developer implements a requirement change directly in the code without flowing it through the requirements and design descriptions. The description of what the product does, as embodied in the requirements specification, becomes less accurate because the code is the ultimate software reality. The code can become brittle and fragile if changes are made without respecting the program’s architecture and design structure. On one project, developers introduced new and modified functionality that the rest of the team didn’t discover until system testing. This required unplanned rework of test procedures and user documentation. Consistent change control practices help prevent such problems and the associated frustration, development rework, and wasted testing time.

The Change Control Process

While performing a software process assessment once, I asked the project team how they incorporated changes in the product’s requirements. After an awkward silence, one person said, “Whenever the marketing rep wants to make a change, he asks Bruce or Sandy because they always say ‘yes’ and the rest of us give marketing a hard time about changes.” This didn’t strike me as a great change process.

A rational change control process lets the project’s leaders make informed business decisions that will provide the greatest customer and business value while controlling the product’s life cycle costs. The process lets you track the status of all proposed changes, and it helps ensure that suggested changes aren’t lost or overlooked. Once you’ve baselined a set of requirements, follow this process for all proposed changes to that baseline.

Customers and other stakeholders sometimes balk at being asked to follow a new process, but a change control process is not intended to be an obstacle to making necessary modifications. It’s a funneling and filtering mechanism to ensure that the project incorporates the most appropriate changes. If a proposed change isn’t important enough for a stakeholder to take just a couple of minutes to submit it through a standard, simple channel, then it’s not worth considering for inclusion. Your change process should be well documented, as simple as possible, and—above all—effective. If you ask your stakeholders to follow a new change control process that’s ineffective, cumbersome, or too complicated, people will find ways to bypass the process—and perhaps they should.

Managing changes in requirements is similar to the process for collecting and making decisions about defect reports. The same tools can support both activities. Remember, though: a tool is not a substitute for a process. Using a commercial problem-tracking tool to manage proposed modifications to requirements doesn’t replace a written process that describes the contents and processing of a change request.

Change Control Policies

Management should clearly communicate a policy that states its expectations of how project teams will handle proposed requirements changes. Policies are meaningful only if they are realistic, add value, and are enforced. I’ve found the following change control policy principles to be helpful:

  • All requirements changes shall follow the process. If a change request is not submitted in accordance with this process, it won’t be considered.
  • No design or implementation work other than feasibility exploration shall be performed on unapproved changes.
  • Simply requesting a change doesn’t guarantee that it will be made. The project’s change control board (CCB) will decide which changes to implement. A later article in this series discusses the change control board.
  • The contents of the change database shall be visible to all project stakeholders.
  • The original text of a change request shall not be modified or deleted.
  • Impact analysis shall be performed for every change.
  • Every incorporated requirement change shall be traceable to an approved change request.
  • The rationale behind every approval or rejection of a change request shall be recorded.

Of course, tiny changes will hardly affect the project and big changes will have a significant impact. In principle, you’ll handle all of these through your change control process. In practice, you might elect to leave certain detailed requirements decisions to the developers’ discretion, but no change affecting more than one individual’s work should bypass your change control process. However, your process should include a “fast path” to expedite low-risk, low-investment change requests in a compressed decision cycle.

The sweet spot is to establish a set of change control policies and practices that facilitate making good, timely change decisions, without misusing the process as a barrier to halt any changes. Change is inevitable—deal with it. The remaining articles in this series will look at the change control process in some detail, the change control board, change control tools, and performing impact analysis for proposed changes.

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 previous article in this series, I described several conditions in which writing less detailed requirements is appropriate. However, there are several situations in which recording only high-level requirements information increases the project’s risk. When you encounter situations such as the ones described in this article (adapted from my book More about Software Requirements), expect to spend more time than average developing detailed requirements specifications.

Development will be outsourced

Anytime you outsource software construction rather than performing it in house, your project will benefit from comprehensive requirements documentation. When the developers are a continent or an ocean away, you don’t have the opportunity for the day-to-day interactions needed to flesh out the details, answer questions, and resolve ambiguities. In certain cultures, software developers will implement precisely what the client specified, even if it’s not complete or sensible. Without having many opportunities for clarification, you have no choice but to supply all the necessary information in the form of written specifications and acceptance tests. Do your best to remove uncertainties before sending the specification out for implementation.

Project team members are geographically dispersed

It takes surprisingly little separation between project participants to inhibit communication. I learned this long ago when I was writing programs for a research scientist who sat just a few feet from my desk. One day John moved to a new office about a hundred feet away. My productivity dropped immediately. It now took longer to get my questions answered. I had to set up a meeting with John, phone him, or walk down the hall and hope to catch him, whereas previously I just had to call out my question to get an immediate response. It was an eye-opener for me to see the impact that even a small distance between developer and customer had on my productivity. If you’re concerned about having customer representatives available to supply the missing details during design and construction, you’d better produce that information during requirements development.

On another project, the three of us collaborating on a project worked in two different buildings. We didn’t have a written requirements specification. Instead, we held a weekly meeting to focus our efforts for the next week, and then we went off and did our own parts of the work with limited interaction. On at least two occasions, one developer wasted a full week of effort because we all walked out of our meeting with different understandings of what we were supposed to do that week. Even a limited SRS will reduce this sort of waste, as will closer and more frequent collaboration among the project participants.

Testing will be based on requirements

If testers will be writing comprehensive system tests or user acceptance tests from the requirements, they must know just how the system is supposed to behave under various circumstances. In fact, the concept of “testable requirements” has been proposed as a measure of software size.
Tests should cover not only the expected behavior, but also the known exception or error conditions that can arise. Therefore, the requirements specifications need to describe these exceptions well enough so that testers can determine whether the software is functioning correctly. You likely won’t think of all the possible exceptions, but identifying potential problems and specifying how to handle them leads to a more robust product.

Accurate estimates are needed

Project managers or developers who must generate effort and schedule estimates from requirements need enough detail to understand what they’re getting into. I once saw an innocent-looking “functional requirement” that stated: “The XML editor shall respond to editing directives entered by voice.” The way the SRS was written gave no hint that this one item was profoundly more complex than the other 700 functional requirements in the document. That simple statement implied the need for an entire speech-recognition engine and interface! It’s difficult to estimate the cost of implementation without decomposing that high-level statement into enough detail to get a good handle on its size, complexity, and difficulty.

Requirements traceability is needed

Requirements tracing is the act of creating logical links between individual functional requirements, their origins (such as use cases, stories, product features, or business rules), and the work products the team creates to satisfy each requirement. Such downstream work products include design elements, source code, test cases, and help screens. If requirements tracing is important to your project, you need to specify the requirements in detail.

Evidence of requirements traceability is needed for certain safety-critical products, such as those that require U.S. Food and Drug Administration or Federal Aviation Administration (FAA) certification. For instance, the FAA’s safety standard DO-178B specifies that “every line of code be directly traceable to a requirement and a test routine, and that no extraneous code outside of this process be included in the build.” Traceability information ensures that your system has no orphan code and no overlooked requirements. Requirements traceability confirms that following conditions are met:

  • All requirements trace forward to elements of the software design.
  • Each design element can be traced back to specific requirements.
  • All code written traces back to a design element and hence to a requirement.
  • All requirements are implemented in the code.
  • Test cases exist for each requirement.
  • All test cases trace to at least one requirement.

If you’re in a regulated industry, you already know if you need to implement traceability as part of your requirements management activities. Otherwise, the choice is yours. Successful requirements tracing requires some time, discipline, a process to make it happen, and a tool in which to store the data. You might conclude that it’s a waste of time for your project. Before you do, though, consider an insightful comment made by the CEO of a major corporation when I discussed traceability while teaching a requirements course at his company. He asked, “Why wouldn’t you do this for all of your mission-critical systems?” He got it.

Also read How Detailed Should Requirements Be? Part 1

Also read How Detailed Should Requirements Be? 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.

Recently I was chatting at a wine tasting event with a couple of lawyers, who I had just met. One was surprisingly inquisitive about my work in the software requirements arena. Apparently she was working on case involving software at that very time. At one point she asked me, “How do you know how detailed to make the requirements?” It’s an insightful question, one that even experienced business analysts often ask me.

There’s no single correct answer to this question, even assuming we could agree on exactly how to measure requirements “detail.” This is one of those thorny issues that plague BAs. For most such issues, the correct answer is, “It depends.” Despite being true, that’s not a very satisfying reply. Even though there is no simple answer to this simple question, I can give you some ways to think about how much detail is appropriate in a given situation. This is the first in a series of three articles adapted from my book More about Software Requirements (Microsoft Press, 2006). The second article will describe situations in which you can safely get away with less detail, and the final article points out situations where including more detail is a good idea.

Who Makes the Call?

The central question to consider when deciding how detailed to make the requirements is: Who do you want to have making the decisions about requirements details and when? If you’re willing to defer many of the ultimate decisions about product capabilities and characteristics to the developers, you don’t need to include as much information in the requirements documentation. This can also work if appropriate customer representatives are available to work with developers to pin down the details and make the necessary decisions at construction time. However, if you want to describe exactly what you expect to be delivered, more complete specifications are necessary.

As with many decisions made on software projects, you need to balance cost and risk. It costs more to develop requirements in greater detail than to leave them more high-level. Choosing the appropriate amount of detail to include depends upon how risky it is to leave decisions about requirements specifics to developers to make later in the development cycle. The main risk we’re concerned about is having to perform extensive and unplanned rework late in the project or iteration to create a satisfactory product. Nor do you want to hear a developer say, “Gee, if I’d only known more about this requirement two months ago, this would have been easy to implement. Now I have to redo some of what I’ve already built.”

Let me give you an illustration about requirements detail. My house has a security alarm system. When the alarm is set and I enter the house, the alarm starts beeping at me. To disarm the system, I enter my passcode on a numeric keypad. At one level, we could state a requirement for this function quite simply: “When the alarm system is armed and a sensor is triggered, the user shall be able to enter a numeric passcode to disarm the system.” This statement conveys the general intent, but it isn’t enough information for the developer to know just what to design and build. Here are some questions that arise when considering the implications of this requirement:

  • What are the minimum and maximum numbers of digits allowed in a passcode? Does it have to be numeric?
  • How should the system conclude that the user has finished entering the passcode so it can evaluate the entered code?
  • How can the homeowner set and change his passcode? Is there a default?
  • How long does the system wait for the user to enter the correct passcode before it sounds the alarm?
  • What does the system do if the user enters an incorrect passcode before the timer runs out?
  • How many entry attempts does the user get? Or perhaps it’s a function of time: Can the user make as many attempts as he likes within a fixed time interval?
  • If the user enters the wrong passcode, does the timer reset to zero or does the countdown continue toward sounding the alarm?
  • What does the system do if the user does, or does not, enter the correct passcode within the specified time interval?

Clearly, someone has to answer these questions. If the BA doesn’t supply this sort of high-resolution information in the requirements specification, the responsibility falls to the developer. He has to identify all the pertinent questions and either track down the answers or make decisions based on his own judgment. If you’re the BA, you need to decide on the most appropriate approach. Do you want developers to come up with answers for such questions on the fly at design and construction time? Or would you rather have customers and subject matter experts record the necessary information in the requirements specification? It’s your call.

Customers sometimes balk at taking the time to think through these kinds of issues carefully and make decisions. My response to this hesitation is to ask the customer, “If you don’t want to make these decisions now, who do you think should make them and when?” Developers sometimes are comfortable with vague and incomplete specifications, because that gives them the opportunity to interpret the requirements however they want. However, it pays to remember one of my Cosmic Truths about Software Requirements: “The requirements might be vague, but the product will be specific.” The central issue is who the specificity comes from.

Figure 1 identifies some situations in which you need more detail in the requirements documentation and other cases where less rigor will suffice. In the next two articles in this series, I’ll discuss these various conditions in more detail.

Figure 1. Some factors that influence how much requirements detail is needed.

Implied and Assumed Requirements

No requirements specification can ever fully describe a product. Nor should you ever expect written documentation to replace human dialog. Still, I get nervous when I hear people talk about “implied” or “assumed” requirements.

It’s risky to assume that everyone who reads the requirements specification will know exactly what is intended without the BA spelling it out. For example, it’s not reasonable to think that every reader will automatically know which system functions require the user to be logged in and which do not. It’s unrealistic to expect every reader to distinguish those parts of the system that demand particularly rapid response times—and to know just what those response times should be—from the parts that don’t have specific performance expectations.

Quality requirements also dictate many architectural choices. If those high-impact requirements aren’t written down because the people with that knowledge assume that others share their insight, the product could fail to meet expectations for performance, reliability, integrity, and so forth. An expensive rework project then might begin, building a new architecture to try to meet the demands of the operating environment.

Consider this philosophy: “If it’s not in the specification, do not expect to find it in the product.” As with all philosophies, this extreme position needs to be tempered by reality. If you attempt to create a totally inclusive specification, you’ll spend the rest of your life writing requirements and won’t have any time left to build products. At the other extreme, some project teams are reluctant to write down the requirements. But documentation’s not the hard part. The hard, time-consuming part is figuring out what the requirements are. Recording them is mostly transcription at that point.

My preference is to err in favor of writing down anything you aren’t certain that the reader will know. Don’t rely on telepathy and clairvoyance as the technical foundations for your project. They don’t work.

Also read How Detailed Should Requirements Be? Part 2

Also read How Detailed Should Requirements Be? Part 3

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.

 

I don’t know of any way to be absolutely certain that you have not missed any requirements during elicitation. This makes it hard to know just when you can declare your set of requirements—whether for the full product or just the next iteration—complete. Even though you can’t know for sure if you’re done, at some point you need to define a requirements baseline and move ahead with the project work. In this article, adapted from my book Software Requirements, 2nd Edition, I propose several techniques for helping you find requirements you might have overlooked, as well as some ways to judge whether your elicitation process is sufficiently complete.

Finding Missing Requirements

Missing requirements are among the most common requirement defects. They’re hard to spot during reviews because they’re invisible! The following techniques will help you detect previously undiscovered requirements.

  • Decompose high-level requirements into enough detail to reveal exactly what is being requested. A vague, high-level requirement that leaves much to the reader’s interpretation will lead to a gap between what the requester has in mind and what the developer builds. Imprecise, fuzzy terms to avoid include support, enable, permit, process, and manage.
  • Make sure that all user classes have provided input.
  • Make sure that each use case has at least one identified actor.
  • Trace system requirements, use cases, event-response lists, and business rules into their detailed functional requirements to make sure that the BA derived all the necessary functionality.
  • Check boundary values for missing requirements. Suppose one requirement states, “If the price of the order is less than $100, the shipping charge is $5.95” and another says, “If the price of the order is more than $100, the shipping charge is six percent of the total order price.” But what’s the shipping charge for an order with a price of exactly $100? It’s not specified, so a requirement is missing.
  • Represent requirements information in multiple ways. It’s difficult to read a mass of text and notice that something isn’t there. An analysis model visually represents requirements at a high level of abstraction—you’re looking at the forest, not the trees. You might study a diagram and realize that there should be an arrow from one box to another; that missing arrow represents a missing requirement. This kind of error is much easier to spot in a picture than in a long list of textual requirements that all blur together.
  • Sets of requirements with complex Boolean logic (ANDs, ORs, and NOTs) often are incomplete. They might be missing an ELSE condition, for example. If a combination of logical conditions has no corresponding functional requirement, the developer either has to chase down an answer or make his best guess at what the system should do in that case. Instead of just writing out the requirements in natural language, represent complex logic using a decision table or a decision tree to make sure you’ve covered all the possible situations. See Chapter 11 of Software Requirements, 2nd Edition for more about decision tables and decision trees.

A rigorous way to search for missing requirements is to create a CRUD matrix. CRUD stands for Create, Read, Update, and Delete. A CRUD matrix correlates system actions with data entities (individual data items or aggregates of data items) to make sure that you know where and how each data item is created, read, updated, and deleted. Some people add an L to the matrix to indicate that the data item appears as a List selection. Depending on the requirements analysis approaches you are using, you can examine various types of correlations, including:

  • Data entities and system events
  • Data entities and user tasks or use cases
  • Object classes and system events
  • Object classes and use cases

Figure 1 illustrates an entity/use case CRUDL matrix for a portion of an application called the Chemical Tracking System. Each cell indicates how the use case in the leftmost column uses each data entity shown in the other columns. The use case can Create, Read, Update, Delete, or List the entity. After creating a CRUDL matrix, see whether any of these five letters do not appear in any of the cells in a column. If a business object is updated, but never created, where does it come from? Notice that none of the cells under the column labeled Requester (the person who places an order for a chemical) contains a D. That is, none of the use cases in Figure 1 can delete a Requester from the list of people who have ordered chemicals. There are three possible interpretations:

  1. Deleting a Requester is not an expected function of the Chemical Tracking System.
  2. We are missing a use case that deletes a Requester.
  3. The “Edit Requesters” use case is incorrect. It’s supposed to permit the user to delete a Requester, but that functionality is missing from the use case at present.

We don’t know which interpretation is correct, but the CRUDL analysis is a powerful way to detect missing requirements.

Figure 1. Sample CRUDL matrix for the Chemical Tracking System.

How Do You Know When You’re Done?

No convenient green light comes on to indicate when you’ve completed requirements elicitation. As people muse in the shower each morning and talk with their colleagues, they’ll generate ideas for additional requirements. You’ll never be completely done, but the following cues suggest that you’re reaching the point of diminishing returns on elicitation of a particular set of requirements.

  • If the users can’t think of any more use cases or user stories, perhaps you’re done. Users tend to identify use cases and stories in sequence of decreasing importance.
  • If users propose new use cases, but you’ve already derived the associated functional requirements from other use cases, perhaps you’re done. These “new” use cases might really be alternative flows for other use cases that you’ve already captured.
  • If users repeat issues that they already covered in previous discussions, perhaps you’re done.
  • If suggested new features, user requirements, or functional requirements are all out of scope, perhaps you’re done.
  • If proposed new requirements are all low priority, perhaps you’re done.
  • If the users are proposing capabilities that might be included “sometime in the lifetime of the product” rather than “in the specific product we’re talking about right now,” perhaps you’re done, at least with the requirements for the next release.

Another way to determine whether you’re done is to create a checklist of common functional areas to consider for your projects. Examples include: error logging, backup and restore, access security, reporting, printing, preview capabilities, text and field editing, and configuring user preferences. Periodically compare this list with the functions you have already specified. If you don’t find gaps, perhaps you’re done.

Despite your best efforts to discover all the requirements, you won’t, so expect to make changes as construction proceeds. Remember, your goal is to make the requirements good enough to let construction proceed at an acceptable level of risk. Watch out for the dreaded analysis paralysis, spending too much time on requirements elicitation in an attempt to avoid missing any requirements.

To begin tuning up your requirements elicitation approaches, you might think about missing requirements that were discovered late on your last project. Why were they overlooked during elicitation? How could you have discovered each of these requirements earlier? This sort of simple retrospective analysis is a great way to make sure your next project runs more smoothly than the last one.

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.

 

If you’re going to go to all the trouble to build software system, you’d like to be confident that you’re working from the right requirements. You’d like to know that the product you build has a high chance of satisfying customer needs and will let them get their jobs done in a way they find acceptable and maybe even enjoyable. But without taking the time to validate the requirements, the risk of missing the mark goes up.

Most software developers have experienced the frustration of being asked to implement requirements that were ambiguous or incomplete. If they can’t get the information they need, the developers have to make their own interpretations, which aren’t always correct. Substantial effort is needed to fix requirement errors discovered after those requirements have already been implemented. Any measures you can take to detect errors in the requirements specifications will save you considerable time and money. This article, adapted from my book Software Requirements, 2nd Edition (Microsoft Press, 2003), describes the importance of requirements validation and some valuable techniques to try.

Validation Defined

Requirements validation is the fourth component—with elicitation, analysis, and specification—of requirements development. Validation assesses whether a product actually satisfies the customer needs (doing the right thing). In contrast, verification determines whether the product of a development activity meets the requirements established for it (doing the thing right). Both activities are vital to successful product development, but we will focus on validation here. Requirements validation attempt to ensure that:

  • The SRS correctly describes the intended system capabilities and characteristics that will satisfy the various stakeholders’ needs.
  • The software requirements were correctly derived from the system requirements, business rules, or other sources.
  • The requirements are complete and of high quality.
  • All requirements representations are consistent with each other.
  • The requirements provide an adequate basis to proceed with design and construction.

Validation ensures that the requirements exhibit the desirable characteristics of excellent requirement statements (complete, correct, feasible, necessary, prioritized, unambiguous, and verifiable) and of excellent requirements specifications (complete, consistent, modifiable, and traceable). Of course, you can validate only requirements that have been documented, not implicit requirements that exist only in someone’s mind. This is why I endorse actually writing down requirements details instead of relying on imperfect human memories.

Validation isn’t a single discrete phase that you perform after gathering and documenting all the requirements. Some validation activities, such as incremental reviews of the growing SRS, are threaded throughout the iterative elicitation, analysis, and specification processes. Other activities, such as formal SRS inspection, provide a final quality gate prior to baselining the SRS. Include requirements validation activities as discrete tasks in your project plan.

Project participants sometimes are reluctant to invest time in reviewing and testing an SRS. Intuitively, it seems that inserting time into the schedule to improve requirements quality would delay the planned ship date by that same duration. However, this expectation assumes a zero return on your investment in requirements validation. In reality, that investment can actually shorten the delivery schedule by reducing the rework required and by accelerating system integration and testing. Better requirements lead to higher product quality and customer satisfaction, which reduce the product’s lifetime costs for maintenance, enhancement, and customer support. Investing in requirements quality always saves you more money than you spend.

Test Thinking

On many projects, testing is a late-stage activity. Requirements-related problems linger in the product until they’re finally revealed through time-consuming system testing or by the customer. If you start your test planning and test-case development early, you’ll detect many errors shortly after they’re introduced. This prevents them from doing further damage and reduces your testing and maintenance costs.

Figure 1 illustrates the V model of software development, which shows test activities beginning in parallel with the corresponding development activities. This model indicates that acceptance testing is based on the user requirements, system testing is based on the functional requirements, and integration testing is based on the system’s architecture.

Figure 1. The V model of software development incorporates early test planning.

Plan your testing activities and begin developing preliminary test cases during the corresponding development phase. You can’t actually run any tests during requirements development because you don’t have any software to execute yet. However, conceptual (that is, implementation-independent) test cases based on the requirements will reveal errors, ambiguities, and omissions in your software requirements specification (SRS) and analysis models long before the team writes any code.

Reviewing Requirements

I’m a big fan of performing both formal and informal requirements reviews of growing requirements documents. A requirement might make perfectly good sense to the person who wrote it, but if others don’t understand it, there’s a problem. User representatives are particularly well-suited to validating the correctness of each requirement. Developers and testers can examine requirements to assess whether they understand each one well enough to do their part of the project work based on that requirement. The structured and disciplined technique of inspection provides a way for various reviewers to compare their interpretations and make sure they understand each requirement in the same way. This is something that simply passing requirements out to multiple reviewers and asking what they think does not accomplish.

I’m so enthusiastic about reviews of requirements and other software project deliverables that I wrote a book about it, Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002). I’ve provided some recommendations about how to get the most out of your requirements reviews in two earlier blog posts titled “Two Eyes Aren’t Enough,” parts one and two.

Evaluating Prototypes

Most people have difficulty envisioning how a new system will look and behave from reading a textual requirements specification. Prototypes are a way to bring requirements to life, to put something more tangible in front of the user and solicit feedback. A prototype represents a partial, preliminary, or possible way you might address a particular set of requirements. Prototypes can be static or dynamic, electronic or paper, evolutionary or throwaway. When you create a prototype, you’re taking a tentative step into the solution space. While not committing you to building the software in a particular way, a prototype is an excellent tool for requirements validation. Users can interact with prototypes, thereby simulating their interactions with the ultimate system, to see if a system based on those requirements would really meet their needs.

In recent years, vendors have developed numerous tools to help automate and streamline this process. You can now buy tools that actually simulate proposed systems, help you quickly build prototypes or wireframe representations of the system, and model the behavior of the system based on a set of use cases or functional requirements. All of these tools are intended to facilitate a user’s understanding of requirements to help validate that those are in fact the correct requirements for the system.

Defining Acceptance Criteria

Software developers might believe that they’ve built the perfect product, but the customer is the final arbiter. Customers perform acceptance testing to determine whether a system satisfies its acceptance criteria. If it does, the customer can pay for a product developed under contract or the user can cut over to begin using a new corporate information system. Acceptance criteria—and hence acceptance testing—should evaluate whether the product satisfies its documented requirements and whether it is fit for use in the intended operating environment. Having users devise acceptance tests is an effective requirements development strategy. The earlier in the development process that users write acceptance tests, the sooner they can begin to filter out defects. In fact, some agile software development methodologies employ user acceptance tests in lieu of writing detailed functional requirements.

Acceptance testing should focus on anticipated usage scenarios. Key users should consider the most commonly used and most important use cases when deciding how to evaluate the software’s acceptability. Acceptance tests focus on the normal courses of the use cases, not on the less common alternative courses or whether the system handles every exception condition properly. Automate acceptance tests whenever possible. This makes it easier to repeat the tests when changes are made and additional functionality is added in future releases. Acceptance tests also ought to address nonfunctional requirements. They should ensure that performance goals are achieved on all platforms, that the system complies with usability standards, and that all committed user requirements are implemented.

Having customers develop acceptance criteria thus provides another opportunity to validate the most important requirements. It’s a shift in perspective from the requirements-elicitation question of “What do you need to do with the system?” to “How would you judge whether the system satisfies your needs?” If the customer can’t express how she would evaluate the system’s satisfaction of a particular requirement, that requirement is not stated sufficiently clearly. However, keep in mind that user acceptance testing does not replace comprehensive requirements-based system testing, which covers both normal and exception paths and a wide variety of data combinations that users might not think of.

Simply writing requirements isn’t enough. You also need to make sure that they’re the right requirements and that they’re good enough to serve as a foundation for design, construction, testing, and project management. Acceptance test planning, peer reviews, prototype evaluation, and requirements testing techniques will help you to build higher-quality systems faster and more inexpensively than you ever have before.

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.

 

Great business analysts are grown, not trained. The job includes many soft skills that are more people-oriented than technical. An organization’s BAs likely will come from diverse backgrounds, which could include the business side, the IT side, and subject matter experts. Whatever their backgrounds, new BAs will have gaps in their experience, knowledge and skill sets because of the unique bridging and communication-centric nature of this vital project role. This article looks at some of the skills and knowledge issues associated with business analysts who come to the job from various previous positions.

Anyone pursuing a career as a BA should study an inventory of relevant knowledge, such as the Business Analysis Body of Knowledge developed by the International Institute of Business Analysis. I’ve developed a suggested business analyst job description (available from the Process Impact Website). All BAs should determine the job knowledge and skills that pertain to their situation, identify their own knowledge gaps, and actively seek the information that will let them do a first-rate job. Classroom training, eLearning courses, self-training, coaching, and practice will all be useful methods for bridging the gaps. New BAs also can benefit from mentoring from those who have more experience, perhaps in the form of an apprenticeship.

The Former User

Many corporate IT departments employ business analysts who migrated into that role following a career as an end user of business applications. These individuals have a solid understanding of the business and the work environment, and they easily can gain the trust of their former colleagues. They speak the user’s language. They know the existing systems and business processes.

On the downside, former users who are now in the BA role often have little understanding about software development and how to communicate with technical people. If they are not familiar with various analysis modeling techniques, they likely will express all requirements information in natural-language textual form. They might not appreciate the importance of specifying how the system should handle exception conditions, which is how you make a software application robust. Users who become BAs will need to learn more about the technical side of software development so they can represent information in the most appropriate forms for their multiple audiences.

Some former users believe that their understanding of what is needed is better than that of the current users, so they don’t solicit or respect input from those who will be using the new system. Recent users can be stuck in the here-and-now of the current ways of working, such that they don’t see opportunities to improve business processes with the help of a new information system. It’s also easy for a former user to fall into the trap of thinking of requirements strictly from a user interface perspective. Focusing on solution ideas can impose unnecessary design constraints from the outset and often fails to solve the real problem.

Despite these shortcomings, moving from a user position to a BA role can be a meaningful career option. The senior manager of a medical devices division in a large company once told me that he had a problem. “Two years ago I hired three medical technologists into my division to represent our customers’ needs,” he said. “They’ve done a great job, but they are no longer current in medical technology, so they can’t speak accurately for what our customers need today. What is a reasonable career path for them now?”

This manager’s former medical technologists might be ready to move into a BA role. Although they aren’t up on the latest happenings in the hospital laboratory, they can still communicate effectively with other med techs. Spending two years in a product development environment gave them a good appreciation for how product development works. They might need some additional training in requirements-writing techniques, but these employees have accumulated experience that could make them valuable analysts.

The Former Developer

Project managers who lack a dedicated BA often expect developers to fill the job. Unfortunately, the skills and personality needed for requirements development aren’t the same as those needed for software development. The stereotypical geek isn’t the most socially adroit of human beings. A few developers have little patience with users, considering them a necessary evil to be dealt with quickly so the developer can hustle back to the real job of cutting interesting code. Of course, many developers recognize the criticality of the requirements process and are willing to work as analysts when necessary. Those who enjoy collaborating with customers to understand the needs that drive software development are good candidates to specialize in business analysis.

The developer-turned-analyst might need to learn more about the business domain. Developers can easily lapse into technical thinking and jargon, focusing on the software to be built instead of the users’ needs. Former developers also will benefit from training and mentoring in the soft skills that the best analysts master, such as effective listening, negotiation, and facilitation.

The Subject Matter Expert

In his book Effective Requirements Practices (Addison-Wesley, 2001), Ralph Young recommends having the BA be an application domain or subject matter expert, as opposed to being a typical user. As Young puts it, “SMEs can determine…whether the requirements are reasonable, how they extend the existing system, how the proposed architecture should be designed, and impacts on users, among other areas.” Some product-development organizations hire expert users of their products with extensive domain experience into their companies to serve either as BAs or as user representatives.

One risk here is that the BA who is a domain expert might specify the system’s requirements to suit his own preferences, rather than addressing the needs of diverse user classes. SMEs sometimes strive for a high-end, all-inclusive system, when in fact a less comprehensive solution might well meet the needs of most users. It often works better to have a BA from the development team work with the SME, who then serves as a key user representative (product champion).

The Project Manager

These days I hear a lot of discussion juxtaposing the business analyst and project manager roles. There seems to be an expectation that the same people readily can perform both roles on a project, or that there is significant overlap between the roles. I don’t see it that way. I think both project management and business analysis are challenging tasks with their own bodies of knowledge. Certainly, there is some commonality in applicable soft skills and personality characteristics, such as the ability to foster collaboration and negotiation among stakeholders who might have conflicting interests. Activities like scoping and prioritization are also common to both roles. But there are some significant differences.

A project manager who takes on a BA role will likely need to learn more about how to ask the right kinds of questions of user representatives to elicit a robust set of requirements. He’ll also need to learn how to represent that requirements knowledge in various forms, including well-crafted natural language requirement statements and graphical models. Conversely, a BA who picks up project management tasks may need to learn about estimation, planning risk management, resource allocation, and metrics. While a close partnership between a project manager and a business analyst is important to project success, anyone who is thrust from one role into the other should identify and fill crucial gaps in his knowledge and skills.

I believe that people can become good BAs regardless of their background, provided they have the right personality for the job and an appropriate combination of skills, knowledge, and experience. It doesn’t happen simply by decree or by desire, though. All novice BAs need to be honest about the gaps in their background so they can ramp up to full effectiveness quickly.

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.

 

Software developers often want to freeze the requirements following some initial requirements work and then proceed with development, unencumbered with those pesky changes. This is the classic waterfall paradigm. It doesn’t work well in most situations. It’s far more realistic to define a requirements baseline and then manage changes to that baseline.

Baseline Defined

The term baseline comes from the domain of configuration management. The IEEE Standard Glossary of Software Engineering Terminology defines a baseline as:

A specification or product that has been formally reviewed and agreed on, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures.

A baseline is given a unique name so that the project participants can refer to it unambiguously. Good configuration management practices allow the team to reconstruct accurately any previous baseline and all its components.

A requirements baseline is a snapshot in time that represents the agreed-upon, reviewed, and approved set of requirements committed to a specific product release. That “release” could be a complete delivered product or any interim development increment of the product. When stakeholders “sign off” on requirements, what they’re really doing is agreeing and committing to a specific requirements baseline (whether they think of it in those terms or not).

Once the project team establishes a requirements baseline, the team should follow a pragmatic change control process to make good business and technical decisions about adding newly requested functionality and altering or deleting existing requirements. Change control is not about stifling change. It’s about providing decision makers with the information that will let them make timely and appropriate decisions to modify the planned functionality. That planned functionality is the baseline.

The Requirements Baseline

Whereas the scope definition distinguishes what’s in from what’s out, the requirements baseline explicitly identifies only those requirements that the project will implement. A baseline is not a tangible item but rather a defined list of items. One possible storage location is a software requirements specification (SRS) document. If that SRS contains only—and all—the requirements for a specific product release, the SRS constitutes the requirements baseline for the release. However, the SRS might include additional, lower-priority requirements that are intended for a later release. Conversely, a large project might need several software, hardware, and interface specifications to fully define the baseline’s components. The goal is to provide the project stakeholders with a clear understanding of exactly what is intended to go into the upcoming release.

Perhaps you’re storing your requirements in a requirements management tool, rather than in documents. In that case, you can define a baseline as a specific subset of the requirements stored in the database that are planned for a given release. Storing requirements in a tool allows you to maintain an aggregated set of both currently committed requirements and planned future requirements. Some commercial RM tools include a baselining function to distinguish those requirements (perhaps even down to the specific version of each requirement) that belong to a certain baseline.

Alternatively, you could define a requirement attribute in the tool to hold the release number or other baseline identifier. Moving a requirement from one baseline to another is then a simple matter of changing the value for that requirement attribute. The attribute approach will work when each requirement belongs to only a single baseline. However, you might well allocate the same requirement (or different versions of the same requirement) to several baselines if you’re concurrently developing multiple versions of your product, such as home and professional versions. Tool support is essential for such complex baseline management.

When following an incremental or iterative development life cycle, the baseline for each iteration will represent just a fraction of the overall system’s functionality. A small project my team once worked on took this approach. This project worked in three-week release cycles. For each cycle, the BA specified the requirements that were to be designed, coded, integrated, and verified during the next three weeks. Each requirements baseline was therefore quite small. In a classic agile approach, the product grew incrementally toward full functionality as the developer periodically released useful versions to the users.

When to Baseline

Business analysts sometimes struggle with exactly when to define a requirements baseline. It’s an important decision because establishing the baseline has the following implications:

Formal change control begins. Change requests are made against an established baseline. The baseline therefore provides the point of reference for each proposed change. Make sure your change control process and players are in place before you define any project baselines.

Project managers determine the staffing levels and budgets needed. There are five dimensions to a software project that must be managed: features, quality, schedule, staff, and budget. Once the features and quality goals are defined in the baseline, the project manager adjusts the other three dimensions to accomplish the project’s objectives. It can work the other way, too. If staff, budget, and/or schedule are pre-established by external forces, the baseline composition is necessarily constrained to fit inside the project box bounded by those limits.

Project managers make schedule commitments. Prior to baselining, requirements are still volatile and uncertain, so estimates are similarly volatile and uncertain. Once a baseline is established, the contents of the release should be sufficiently well understood so that managers can make realistically achievable commitments. The managers still need to anticipate requirements growth by including sensible contingency buffers in their committed schedules.

Baselining requirements too early can push your change process into overdrive. In fact, receiving a storm of change requests after defining a baseline could be a clue that your requirements elicitation activities were incomplete and perhaps ineffective. On the other hand, waiting too long to establish a baseline could be a sign of analysis paralysis. Perhaps the BA is trying too hard to perfect the set of requirements before handing them to the development team.

Keep in mind that requirements development attempts to define a set of requirements that is good enough to let the team proceed with construction at an acceptable level of risk. Use the checklist in Table 1 to judge when you’re ready to define a requirements baseline as a solid foundation for continuing the development effort.

Table 1. Factors to Consider Before Defining a Requirements Baseline

Business Rules Determine whether you’ve identified the business rules that affect the system and whether you’ve specified functionality to enforce or comply with those rules.
Change Control Make sure a practical change control process is in place for dealing with requirement changes and that the change control board is assembled and chartered. Ensure that the change control tool you plan to use is in place and configured and that the tool users have been trained.
Customer
Perspective		 Check back with your key customer representatives to see whether their needs have changed since you last spoke. Have new business rules come into play? Have existing rules been modified? Have priorities changed? Have new customers with different needs been identified?
Interfaces See if functionality has been defined to handle all identified external interfaces to users, other software systems, hardware components, and communications services.
Model Validation Examine any analysis models with the user representatives, perhaps by walking through test cases, to see if a system based on those models would let the users perform their necessary activities.
Prototypes If you created any prototypes, did appropriate customers evaluate them? Did the BA use the knowledge gained to revise the SRS?
Alignment Check to see if the defined set of requirements would likely achieve the project’s business objectives. Look for alignment between the business requirements, user requirements, and functional requirements.
Reviews Have several downstream consumers of the requirements review them. These consumers include designers, programmers, testers, documentation and help writers, human factors specialists, and anyone else who will base their own work on the requirements.
Scope Confirm that all requirements being considered for the baseline lie within the project scope as it is currently defined. The scope might have changed since it was originally defined early in the project.
TBDs Scan the documents for TBDs (details yet to be determined). The TBDs represent requirements development work remaining to be done.
Templates Make sure that each section of the SRS template has been populated. Alternatively, look for an indication that certain sections do not apply to this project. Common oversights are quality requirements, constraints, and assumptions.
User Classes See whether you’ve received input from appropriate representatives of all the user classes you’ve identified for the product.
Verifiability Determine how you would judge whether each requirement was properly implemented. User acceptance criteria are helpful for this.

You’re never going to get perfect, complete requirements. The BA and project manager must judge whether the requirements are converging toward a product description that will satisfy some defined portion of customer needs and is achievable within the known project constraints. Establishing a baseline at that point establishes a mutual agreement and expectation among the project stakeholders regarding the product they’re going to have when they’re done. Without such an agreed-upon baseline, there’s a good chance someone will be surprised by the outcome of the project. Software surprises are rarely good news.

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.