best practices Archives

Tag Archive for: best practices

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.

Books on business analysis and requirements engineering, such as my own Software Requirements, describe dozens of “good practices” that can help any organization improve the way it develops and manages requirements for its products. Learning about the practices is one thing; implementing them and reaping the benefits is quite another.

Putting better practices into action is the essence of software process improvement. In a nutshell, process improvement consists of using more of the approaches that work well for us and avoiding those that have given us headaches in the past. However, the path to improved performance is paved with false starts, resistance from those who are affected, and the frustration of having too little time to handle current tasks, let alone improvement programs.

The ultimate objective of software process improvement is to reduce the cost of creating and maintaining software. There are several ways to accomplish this:

Correcting problems encountered on previous or current projects.
Anticipating and preventing problems that you might encounter on future projects.
Adopting practices that are more efficient than the practices currently being used.

If your team’s current methods seem to work well (or if people insist that they do despite evidence to the contrary), people might not see the need to change their approach. However, even successful software organizations can struggle when confronted with larger projects, different customers, long-distance collaborations, tighter schedules, or new application domains. An approach that works for a co-located team of five people with a single customer doesn’t scale up to 125 project participants located in two different time zones who are serving hundreds of corporate customers. At the least, you should be aware of other approaches to requirements that could be valuable additions to your software engineering tool kit.

Let’s begin our journey through requirements process improvement by seeing how requirements activities relate to various other key project processes. Changing how your projects handle requirements will of necessity affect these other processes, and vice versa. If you want to succeed with requirements improvement, you’ll need to get the owners of these other process areas to play along.

How Requirements Relate to Other Project Processes

Requirements lie at the heart of every well-run software project, supporting and enabling the other technical and management activities. Figure 1 illustrates some connections between requirements and other processes; the sections that follow briefly describe these process interfaces.

Figure 1. Relationship of requirements to other project processes.

Project planning. Too often, project deadlines and staff allocations are determined before the requirements are well understood. It’s no wonder then that so many projects overrun their schedules and budgets. A more realistic approach is to make requirements the foundation of the project planning process. The planners select an appropriate software development life cycle and develop resource and schedule estimates based on the requirements. Thoughtful planning might indicate that it’s not possible to deliver the entire desired feature set within the available bounds of resources and time. The planning process can lead to reductions in the project scope or to selecting an incremental or iterative to deliver functionality in planned chunks.

Project tracking and control. Project tracking includes monitoring the status of each requirement so that the project manager can see whether construction and verification are proceeding as intended. If not, management might need to request a scope reduction through the change control process. If you find early on that your team isn’t implementing requirements as quickly as planned, you’ll need to adjust the expectations to reflect the reality of your team’s productivity. Sometimes this means reallocating lower priority requirements from the backlog into later iterations than planned. It doesn’t matter whether you, your managers, or your customers like this or not: that’s just the way it is.

Change control. After a set of requirements has been baselined, all subsequent changes should be made through a defined change control process. The change control process helps ensure that:

The impact of a proposed change is understood.
All people who are affected by a change are made aware of it.
The appropriate people make informed decisions to accept changes.
Resources and commitments are adjusted as needed.
The requirements documentation is kept current and accurate.

System testing. The testing and requirements processes are tightly coupled. User requirements and functional requirements are key inputs to system testing. If the expected behavior of the software under various conditions is not clearly specified, the testers will be hard-pressed to identify defects and to verify that all planned functionality has been implemented as intended. An excellent starting point is to start thinking about testing from the very beginning. Think of user acceptance tests for each requirement as you specify it. This is a great way to identify missing exceptions and ambiguous requirements.

Construction. Although executable software is the ultimate deliverable of a software project, requirements form the foundation for the design and implementation work, and they tie together the various construction work products. Use design reviews to ensure that the architecture and detailed designs correctly address all of the requirements, both functional and nonfunctional. Unit testing can determine whether the code satisfies the design specifications and the pertinent requirements. Requirements tracing lets you document the specific software design and code elements that were derived from each requirement.

User documentation. I once worked in an office area that also housed the technical writers who prepared user documentation for complex software-containing products. I asked one of the writers why they worked such long hours. “We’re at the end of the food chain,” she replied. “We have to respond to the final changes in user interface displays and the features that got dropped or added at the last minute.” The product’s requirements are an essential input to the user documentation process, so poorly written or late requirements will lead to documentation problems. The long-suffering people at the end of the requirements chain, such as technical writers and testers, are often enthusiastic supporters of improved requirements engineering practices.

The central point here is that you can’t modify your requirements practices in a vacuum. The thoughtful improvement leader will consider the context and identify stakeholders of other internal processes who would be affected by changes in the requirement development and management processes. By engaging those counterparts in a collaborative effort to improve the way your teams approach requirements, everyone will come out ahead.

At Jama, we work with the world’s most innovative companies and government agencies to manage the entire lifecycle of product delivery. They think differently, challenge the status quo, and are constantly looking for new ways to improve product delivery to gain that competitive edge. Unfortunately many find it really challenging to work with a legacy tool that no longer meets their needs. What is the risk to the business? What is the cost to move all the old data to a new solution?

We have built a world-class solution to help you move active data from IBM DOORS to Jama, a lower cost, cutting-edge product delivery platform. Jama’s import capabilities for IBM DOORS include the ability to bring along the requirements, test cases and other information you care about.

Don’t work the old way. Now is the time to move off IBM DOORS. We can help. Bring what you need into Jama, when you need it. The Jama DOORS migration solution will maintain all relationships, so you can easily configure or change any elements.

How does it works

Learn more! Contact us to see how it works.

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.

Looking for Jama Contour? It’s still here as the solution for collaborative requirements management software, we just dropped the “Contour” and added a “Connect.” Meet Jama Connect! We’re excited to begin the next chapter of our story: redefining product delivery.

Product delivery involves the entire company. It doesn’t start with Product Managers defining requirements and end with Engineering and QA teams delivering a finished product. Successful product delivery requires connecting the right people in a company to take strategies and concepts all the way to market and ultimately translate them into business value.

Jama Connect builds on Contour’s proven requirements and test management success. It extends the current collaboration capabilities amongst the team, allowing them to capture ad-hoc conversations and decisions within the context of their projects and items. Most importantly, it provides product teams the ability to engage stakeholders outside the team into the right discussions to make timely decisions that will be part of the project’s system of record.

I’ve been a big fan of technical peer reviews and inspections for nearly twenty-five years now. I’ve seen the benefits, and I’ve learned something from every review in which I’ve participated. Weaving peer reviews into the cultural fabric of an organization takes time, though. A new review process is fragile, being easily disrupted by unpleasant experiences (“my reviewers treated me like an idiot”) or ineffective results (“we wasted all that time and didn’t find a single major defect”). This article describes several factors that make a review program work (Figure 1) and points out several review traps to avoid.

Figure 1. Critical success factors for a successful review program

Critical Success Factors

The people involved and their attitude toward quality are the greatest contributors to a review program’s success. The first critical factor is for your team members to prefer to have peers, rather than customers, find defects. Your “customers” include anyone whose work is based on your deliverable, such as a tester who will develop system tests from a requirements specification. Practitioners must appreciate the many benefits that peer reviews can provide, including early defect removal, reduced late-stage rework, document quality assessment, cross-training, and process improvements for defect prevention. Once your team members understand cost-of-quality and return-on-investment concepts, they can overcome barriers such as the perception that adding reviews to the project schedule delays delivery.

Even motivated team members will struggle to perform reviews if you don’t obtain management commitment. Commitment isn’t simply a matter of giving permission or saying “Everybody do reviews.” You don’t need permission. Management commitment includes establishing policies and goals; providing resources, time, training, and recognition; and abiding by the review team’s decisions. You absolutely do need such commitment if you want to establish—and sustain—an effective review program.

A third critical element is to train reviewers and review leaders, as well as the managers of projects that are conducting reviews. Nearly half of the respondents to one survey indicated that untrained practitioners impeded their initial use of inspections. Training can teach people why and how to perform inspections, but only experience enables them to provide and receive insightful comments.

Be sure to allocate time in the project plan for reviews and rework. Despite their good intentions, swamped practitioners will skimp on reviews when time pressures mount. This leads to even greater time pressure in upcoming months as the latent defects become evident. Devoting several percent of a project’s effort to peer reviews is a powerful sign of management’s commitment to quality.

Groups in which I have worked found it valuable to set goals for the review program. One team committed to reviewing 100 percent of its requirements specifications, 60 percent of design documents, 75 percent of the code, and so on. Setting numerical goals forced us to track the quantity of each kind of artifact we created so we could measure progress toward our goals. We achieved our goals, and in the process ingrained peer review as a routine practice. Another goal might be to reduce your rework levels from a known starting point to a specified lower percentage of your total development effort. Make sure your review goals are attainable, measurable, and aligned with your organization’s objectives.

Next, identify a review champion, perhaps yourself, who has personally experienced the benefits. The champion serves as a local advocate, speaking from experience rather than from theoretical knowledge. A review champion who is respected by other team members—whether he is a technical peer, a manager, or a quality engineer—can break down the initial resistance to peer reviews. A highly capable developer who invites reviews sends the signal that everyone can benefit from input from his colleagues.

Plan to review early and often, formally and informally. Use the cheapest review method that will satisfy your objectives for each situation and each work product. A quick ad hoc review sometimes suffices. At other times, you will need the brainstorming of a walkthrough, the structure of a team review, or the rigor of an inspection. Informal, incremental reviews of a work product under development can filter out many defects quickly and cheaply. One risk is that the reviewers might tire of examining the same document repeatedly, perhaps starting to feel that they’re doing the author’s work. Another risk of reviewing early is that you’ll have to repeat the review because of modifications made after other documents have changed. Nonetheless, using multiple types of reviews in sequence provides a powerful way to improve document quality.

Your first reviews won’t go as well as you’d like, thanks to the unavoidable learning curve. To improve their effectiveness, analyze your early reviews. Set aside a few minutes at the end of each peer review to collect some lessons learned, to help make all future reviews better. Continuously improve your peer review procedures, checklists, and forms based on experience. You can download an inspection lessons learned questionnaire from http://www.processimpact.com/pr_goodies.shtml.

Review Traps to Avoid

Several traps can undermine the success of a peer review program. These problems occur most commonly with inspections; informal reviews that lack a defined process aren’t susceptible to having the process be misunderstood or not followed. Watch out for the following pitfalls.

Trap #1: Participants don’t understand the review process. One symptom of this trap is that team members do not use an accurate, consistent vocabulary to describe peer reviews of various types. Another clue is that review teams do not follow a consistent process. Inappropriate behavior, such as criticizing the author instead of pointing out issues with the item being reviewed, is a clear sign of misunderstanding. Training and a practical, documented peer review process are essential. All potential reviewers must understand the what, why, when, how, and who of reviews.

Trap #2: The review process isn’t followed. Before taking corrective action, learn why the process isn’t being followed. After you have diagnosed the underlying causes, select appropriate actions to get the review program into gear. If the process is too complex, practitioners might abandon it or perform reviews in some other way instead. If your managers have not conveyed their expectations through a policy, practitioners will perform reviews only when it’s convenient or personally important to them. If quality is not a success driver for a project, the quality benefits of peer reviews won’t provide a compelling argument for performing them. However, the productivity enhancements that reviews can provide might support a project goal of meeting an aggressive delivery schedule. Introducing reviews on a project that is already in deep trouble with schedule overruns, churning requirements, and tired developers will be hard, but it will be worth the effort if the reviews help get the project back on track.

Trap #3: The right people do not participate. Inappropriate participants include managers who came without being invited by the author and observers who attend without a clear objective. While you can include a few participants who are there primarily to learn, focus on inviting reviewers who will find problems.

Some reviews will be crippled if key perspectives are not represented. As an example, a requirements specification review needs the customer’s viewpoint to judge correctness and completeness and to quickly resolve ambiguities and conflicts. The customer could be represented by actual end users or by surrogates such as marketing staff. To underscore the need for the right participants, below is an e-mail I received from one of my consulting clients, describing her experiences with requirements specification reviews:

The reviews were extremely helpful, especially given that the users were in-house and were very motivated to influence project decisions. User contributions to the requirements reviews were highly valued by all participants. We canceled more than one review for lack of user participation, and I remember one review where we called in a user unexpectedly because the others had failed to show up. The one who came had no preparation time, and we delayed the start of the meeting waiting for her to show up, but she provided very valuable insights and suggestions nevertheless. User participation in the reviews was an unqualified success and led to software that was more valued by its users and to a better working relationship between the project and the users.

Trap #4: Review meetings drift into problem-solving. Unless a review has been specifically invoked as a brainstorming session, the group should focus on finding⎯not fixing⎯errors. When a review meeting switches to finding solutions, the process of examining the product comes to a halt. Participants tune out if they aren’t fascinated by the problem being discussed. When the reviewers realize the meeting time is almost up, they hastily flip through the remaining pages and declare the review a success. In reality, the material they glossed over likely contains major problems that will haunt the development team in the future. Moderator failure is the prime contributor to this problem.

Trap #5: Reviewers focus on style, not substance. An issue log that lists only style problems suggests that the reviewers were distracted by style, were not adequately prepared, or did only a superficial examination. To avoid this trap, define coding standards and adopt standard templates for other project documents. Coding standards address layout, naming conventions, commenting, language constructs to avoid, and other factors that enhance readability and maintainability. As part of judging whether a work product satisfies its inspection entry criteria, have a standards checker see if it conforms to the pertinent standard. Use code reformatting tools to automatically enforce layout standards, helping reviewers focus on the important logical, functional, and semantic issues.

If you keep these success factors for peer reviews in mind and avoid stepping into the traps I’ve warned you about here, you’ll have a good chance of implementing a successful review program in your organization. I think you’ll be glad you did.

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.

Software products are rarely delivered in final form with the first release. More commonly, they evolve through a series of releases or iterations that correct defects, add progressively more features, and enrich or update previously implemented features. This means that during requirements development you’ll be accumulating requirements that could be targeted for various releases. You need to determine the best way to store and manage these requirements so that no one is confused about the contents of each upcoming release.

A related issue pertains to requirements that were proposed, but never approved. Similarly, you might approve certain requirements for a specific release, only to delete them later (perhaps deferring them to a future release or iteration) either because they are no longer valuable or because of time and resource limitations. Deleted requirements, rejected requirements, ideas, and potential requirements for the future have a way of resurfacing before the project is finished. You don’t want to lose sight of the fact that these requirements once were proposed or considered to be in scope. Nor do you want anyone to work on them under the mistaken belief that they’re intended for the next release.

There are several ways to deal with requirements that are not a part of the current build. The goal is to produce specifications that clearly identify the requirements for each release, while still providing access to all requirements that describe the historical and possible future states of the product. This article compares three strategies for solving this problem:

• Storing all requirements in a single software requirements specification (SRS).

• Creating a separate SRS for each release.

• Storing requirements in a requirements management tool.

Single Requirements Specification

One option is to begin by writing an SRS that contains just those requirements that are planned for the initial product release. This approach makes sense if your team is continuously working on the next set of prioritized requirements and modifications in the backlog, creating a release whenever they have a bundle of enhancements and changes ready to go. When you think the initial SRS is complete, define it as a baseline for that first release. Store the baselined document in a version control tool. Then use check-in and check-out procedures to make changes to the SRS and maintain a revision history of changes made.

As you identify new or modified requirements for any planned release, highlight those changes using your word processor’s revision marks feature. Indicate the planned release number so everyone will know which requirements are in scope for each release. Also, explicitly identify those requirements that have been deleted or that were proposed once but not approved, along with an explanation of why each decision was made. This retains those requirements for possible future use.

After you’ve recorded all the requirements you intend to implement in the next release, take the following actions:

1. Archive the SRS in the version control tool, with the revision marks included to identify changes made since the previous version of the document was baselined.

2. Create a copy of the marked-up file. Accept all the revisions, thereby making all the requirements and changes made to them current. Save that version in your version control tool, too. Identify this document as now representing the full set of requirements for the specified product release, including all functionality that was implemented in previous releases.

3. Continue the process of entering changes with revision marks turned on and periodically baselining the SRS for each subsequent release.

This approach results in developing a single master SRS that contains all the requirements that fully describe your product as it grows through multiple releases. The revision marks in any single historical version represent just the deltas from the previous version.

Creating a master SRS provides the advantage of collecting all the requirements in a single place. You can place new requirements placed in context wherever they belong. It’s also easy to handle requirements that were originally planned for a future release but have moved into scope for the current release. Because these requirements are already in the document, it’s just a matter of indicating that they are now planned for the upcoming release.

The single-spec approach has some shortcomings, though. It’s easy to get confused about which requirements the developers are supposed to implement in a specific release. It’s also difficult to view just the subset of the requirements that describe a specific incremental release because the requirements for multiple releases are all threaded together. Suppose that for release 5 you have 23 new requirements sprinkled throughout your 50-page master SRS. Developers and testers will need to print the entire document and study the revision marks to figure out exactly what to do. This is inefficient and error-prone.

Multiple Requirements Specifications

If your organization treats each new product release as a separate project, consider writing a separate SRS for each such release. This can also work in an iterative environment, treating each iteration as a micro-project. The SRS for the first release should follow a comprehensive SRS template, such as the one available from http://www.processimpact.com/goodies.shtml. Much of this information will remain unchanged for future releases.

Each incremental SRS for a subsequent release will be simpler than the first one, without all the global and background information that appeared in the initial SRS. Each incremental SRS will describe just those functional requirements that are being added or changed, along with associated performance requirements, other quality attributes, and business rules. Consider using different document templates for the comprehensive initial SRS and for the smaller and simpler incremental specs.

If you create multiple specifications in this way, then you can use each separate document to describe exactly what the team is going to do in a particular release. This is more reliable than hoping that every reader will correctly glean all the changes from an increasingly bulky master SRS. Individual specifications are smaller, less intimidating, and easier to work with, especially in hard copy form.

Creating multiple specifications presents some disadvantages, though. Shifting a requirement from one planned release to another requires that you actually move the text describing that requirement from one document to another. Writing a separate SRS for each release doesn’t provide the context and big-picture synthesis of what the whole product is today. Someone who wants to get a complete description of any feature, let alone the entire product, has to assemble bits of information from multiple sources. With multiple specifications, it’s also easy to lose track of those requirements that were not allocated to a particular product release and yet remain in the backlog of possible future work. There’s no logical place to put them, unless you create yet another document to contain the “leftover” requirements that might be of future interest.

Requirements Management Tool

The most robust strategy is to store the requirements in the database of a commercial requirements management tool. This keeps the requirements for all releases stored together. You can use the tool’s baseline-definition feature to distinguish the subsets of requirements that belong to different releases. Alternatively, you could define a requirement attribute to hold the planned release number for each requirement. Reallocating a requirement from one release to another then becomes a simple matter of changing this attribute. A status attribute helps you distinguish rejected or deleted requirements from the others.

When you store requirements in a tool, an SRS becomes a report generated from the database contents according to specific query and filter criteria. You have several options:

• To see a complete specification for the entire product to date, extract all the requirements for the current version and all previous releases.

• To see the specification for a single release, report just the requirements allocated to that release.

• To see the requirements that were proposed but rejected, or those that never made it into the product in the first place, base your query on the appropriate values of the status attribute.

Requirements management tools overcome many of the limitations of document-based storage. For example, some tools will retain all historical versions of every individual requirement, whereas version control tools generally maintain previous versions of entire documents. Commercial RM tools let you store requirements in a single master location that is always current and is accessible via the Internet to authorized stakeholders. These products aren’t cheap, but their capabilities often outweigh the costs. You can find descriptions and feature comparisons of many commercial RM tools at http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx and http://www.volere.co.uk/tools.htm. Chapter 23 of my book More about Software Requirements (Microsoft Press, 2006) provides recommendations for how to use requirement management tools effectively on a project.

As with so many of the other thorny issues about requirements, there is no perfect and simple solution to the matter of concurrently managing requirements for multiple product releases (or similarly, multiple variations of a single product). It’s most important that your project team determine in advance what techniques and tools it will use to deal with this situation, using the strategies I’ve described here as a starting point.

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 major consequence of requirements problems is rework—doing over something that you thought was already done. Rework can consume 30 to 50 percent of your total development cost, and requirements errors account for 70 to 85 percent of the rework cost. The data from Hewlett-Packard in Figure 1 shows that it costs far more to correct a defect that’s found late in the project than to fix it early on. Preventing requirements errors and catching them early therefore has a huge leveraging effect on reducing rework. Imagine how different your life would be if you could cut your rework effort in half! You could build products faster, build more and better products in the same amount of time, and perhaps even go home occasionally.

Figure 1. The relative cost to correct a requirement defect depends on when it’s discovered

Shortcomings in requirements practices pose many risks to project success. I describe some of the most common requirements risks in this post.

Insufficient User Involvement

Customers often don’t understand why it is so essential to work hard on gathering requirements and assuring their quality. Developers might not emphasize user involvement, either because working with users isn’t as much fun as writing code or because they think they already know what the users need. In some cases, it’s difficult to gain access to people who will actually use the product, and user surrogates don’t always understand what users really need. Insufficient user involvement leads to late-breaking requirements that delay project completion. There’s no substitute for having the development team work directly with actual users throughout the project.

Creeping Requirements

As requirements evolve and grow during development, projects often exceed their planned schedules and budgets. Such plans aren’t always based on realistic understandings of the size and complexity of the requirements; constant requirements modifications make the problem worse. The problem lies partly in the users’ frequent requests for changes in the requirements and partly in the way that developers respond to these requests.

To manage scope creep, begin with a clear statement of the project’s business objectives, strategic vision, scope, and success criteria. Evaluate proposed new requirements or changes against this reference. An effective change process that includes impact analysis will help the stakeholders make informed business decisions about which changes to accept and the associated cost. Change is often necessary, but change always has a price. To minimize quality degradation, flow requirements changes through the architecture and design rather than implementing them directly into code.

Ambiguous Requirements

One symptom of ambiguity is that a reader can interpret a requirement statement in several ways. Another sign is that multiple readers of a requirement arrive at different understandings of what it means. Ambiguity also results from imprecise and insufficiently detailed requirements that force developers to fill in the blanks. Ambiguous requirements result in wasted time when developers implement a solution for the wrong problem. Testers who expect the product to behave differently from what the developers intended waste time resolving the differences.

One way to ferret out ambiguity is to have people who represent different perspectives formally review the requirements. Simply passing around the requirements document for comments isn’t sufficient to reveal ambiguities. Suppose different reviewers interpret a requirement in different ways but it makes sense to each of them. That doesn’t reveal the ambiguity! Writing test cases against the requirements and building prototypes are other ways to discover ambiguities.

Gold Plating

Gold plating takes place when a developer adds new functionality that he believes “the users are just going to love.” Often, users don’t care about that functionality, and the time spent implementing it is wasted. Rather than simply inserting new features, developers and analysts should present the customers with creative ideas and alternatives for their consideration. Developers should strive for leanness and simplicity, not for going beyond what the customer requests without customer approval.

Customers sometimes request features or elaborate user interfaces that look cool but add little value to the product. Everything you build costs time and money, so you need to maximize the delivered value. To reduce the threat of gold plating, trace each bit of functionality back to its origin so that you know why it’s included.

Minimal Specification

Sometimes marketing staff or managers are tempted to create a limited specification, perhaps just a product concept sketched on a napkin. They expect the developers to flesh out the spec as the project progresses. This approach can work with a tightly integrated, agile team that’s building an application incrementally, on exploratory or research projects, or when the requirements truly are flexible. In other cases, though, it frustrates the developers (who might be operating under incorrect assumptions and with limited direction) and disappoints the customers (who don’t get the product they envisioned).

Overlooked User Classes

Most products have several groups of users who might use different subsets of features, have different frequencies of use, or have varying experience levels. If you don’t identify the important user classes for your product early on, some user needs won’t be met. After identifying all user classes, make sure that each has a voice, some person who will work with the business analyst to elicit the needs of a specific user class.

Inaccurate Planning

“Here’s my idea for a new product; when will you be done?” Don’t answer this question until you know more about the problem being discussed. Vague, poorly understood requirements lead to overly optimistic estimates, which come back to haunt us when the inevitable overruns occur. An estimator’s off-the- cuff guess sounds a lot like a commitment to the listener. The top contributors to poor software cost estimation are frequent requirements changes, missing requirements, insufficient communication with users, poor specification of requirements, and insufficient requirements analysis.

Benefits from a High-Quality Requirements Process

A great reward from effective requirements processes comes from reducing unnecessary rework during development and throughout the lengthy operational period. Many people mistakenly believe that time spent discussing requirements simply delays delivery by the same duration. A holistic cost-of-quality perspective, though, reveals the value of emphasizing early-stage quality practices. Sound requirements processes emphasize a collaborative approach to product development that involves multiple stakeholders in a partnership throughout the project. Collecting requirements lets the development team better understand its users or market.

Engaging users in the requirements-gathering process generates enthusiasm for the product and builds customer loyalty. By emphasizing user tasks instead of superficially attractive features, the team can avoid writing code that won’t ever be used. Customer involvement reduces the expectation gap between what the user needs and what the developer delivers. You’re going to get the customer feedback eventually. Try to get it early rather than late, perhaps with the help of prototypes that stimulate user feedback. This is far cheaper than correcting a lot of problems in beta testing or after release. Documented, unambiguous requirements greatly facilitate system testing, which in turn increases your chances of delivering high-quality products that satisfy all stakeholders.

No one can promise a specific return on investment from an improved requirements process. You can go through an analytical thought process to imagine how better requirements could help you, though. First, consider the cost of investing in a better process. This includes the cost of assessing your current practices, developing new procedures and document templates, training the team, buying books and tools, and perhaps using outside consultants.

Your greatest investment is the time your teams spend gathering, documenting, reviewing, and managing their requirements. Next, think about the possible benefits you might enjoy and how much time or money they could save you. You can’t quantify all the following benefits, but they’re real:

• Fewer requirements defects • Reduced development rework • Fewer unnecessary features • Lower enhancement costs • Faster development • Fewer miscommunications • Reduced scope creep • Reduced project chaos • Higher customer and team member satisfaction

Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.

The CEO of a major corporation who was present when I described requirements traceability at a seminar asked, “Why wouldn’t you create a requirements traceability matrix for your strategic business systems?” That’s an excellent question. He clearly saw the value of having that kind of data available to the organization for each of its applications. If you agree with this executive’s viewpoint, you might be wondering how to incorporate requirements traceability into your systems development activities in an effective and efficient way.

Tracing requirements is a manually intensive task that requires organizational commitment and an effective process. Defining traceability links is not much work if you collect the information as development proceeds, but it’s tedious and expensive to do on a completed system. Keeping the link information current as the system undergoes development and maintenance takes discipline. If the traceability information becomes obsolete, you’ll probably never reconstruct it. Outdated traceability data wastes time by sending developers and maintainers down the wrong path, so it’s actually worse than having no data at all.

Requirements Traceability Procedure

If you’re serious about this effort, you need to explicitly make gathering and managing requirements traceability data the responsibility of certain individuals. Otherwise, it just won’t happen. Typically, a business analyst or a quality assurance engineer collects, stores, and reports on the traceability information. Consider following this sequence of steps when you begin to implement requirements traceability on a specific project:

Select the link relationships you want to define from the possibilities shown in Figure 2 from the first article in this series on requirements traceability.
Take another look at the second article in this series and choose the type of traceability matrix you want to use: the single matrix shown in Table 1 or several of the matrices illustrated in Table 2. Select a mechanism for storing the data—a table in a text document, a spreadsheet, or a commercial requirements management tool.
Identify the parts of the product for which you want to maintain traceability information. Start with the critical core functions, the high-risk portions, or the portions that you expect to undergo the most maintenance and evolution over the product’s life.
Modify your development procedures and checklists to remind developers to update the links after implementing a requirement or an approved change. The traceability data should be updated as soon as someone completes a task that creates or changes a link in the requirements chain.
Define the tagging conventions you will use to uniquely identify all system elements so they can be linked together. If necessary, write scripts that will parse the system files to construct and update the traceability matrices. If you don’t have unique and persistent labels on requirements, design elements, and other system elements, there’s no way you can document the connections between them.
Educate the team about the concepts and importance of requirements tracing, your objectives for this activity, where you will store the traceability data, and the techniques for defining the links—for example, using the tracing features of a requirements management tool.
Identify the individuals who will supply each type of link information and the person who will coordinate the traceability activities and manage the data. Obtain commitments from all of them to do their part.
As development proceeds, have each participant provide the requested traceability information as they complete small bodies of work. Stress the need to assemble the traceability data as they work, rather than attempting to reconstruct it at a major milestone or at the end of the project.
Audit the traceability information periodically to make sure it is being kept current. If a requirement is reported as implemented and verified, yet its traceability data is incomplete or inaccurate, your traceability process isn’t working as you intend.

This procedure is described as though you were starting to collect traceability information at the outset of a new project. If you’re maintaining a legacy system, odds are that you have some traceability data available. There’s no time like the present to begin accumulating this useful information. The next time you have to add an enhancement or make a modification, write down what you discover about connections between code, tests, designs, and requirements. Build the recording of traceability data into your procedure for modifying an existing software component. This small amount of effort might make it easier the next time someone has to work on that same part of the system. You’ll never reconstruct a complete requirements traceability matrix, but you can grow a body of knowledge a bit at a time during the application’s life.

Is Requirements Traceability Feasible? Is it Necessary?

You might conclude that creating a requirements traceability matrix is more expensive than it’s worth or that it’s not feasible for your project. That’s fine: it’s your decision. But consider the following counter-example. A seminar attendee who worked at an aircraft manufacturer told me that the requirements specification for his team’s part of the company’s latest jetliner was a stack of paper six feet thick. They had a complete requirements traceability matrix. I’ve flown on that very model of airplane several times, and I was happy to hear that the developers had managed their requirements so carefully. Managing traceability on a huge product with many interrelated subsystems is a lot of work. This aircraft manufacturer knows it is essential; the Federal Aviation Administration agrees.

Not all companies build products that can have grave consequences if the software has problems. However, you should take requirements tracing seriously, especially for your business’s core information systems. You should decide to use any improved requirements engineering practice based on both the costs of applying the technique and the risks of not using it. As with all software processes, make an economic decision to invest your valuable time where you expect the greatest payback.

Check out Links in the Requirements Chain, Part 1

Check out Links in the Requirements Chain, 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.