Tag Archive for: best practices Page 4

Tag Archive for: best practices

In Part 1 of this series, adapted from my book Practical Project Initiation, I shared four best practices that can help you lay the foundation for a successful project and two practices that are useful for project planning. This article continues the series by describing five additional project planning best practices and several practices for estimating the work needed to complete the project.

Planning the Project (continued)

Practice #7: Develop planning worksheets for common large tasks. If your team frequently undertakes certain common tasks—such as implementing a new class, executing a system test cycle, or performing a product build—develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Tailor the worksheets to meet the specific needs of individual projects. I’ve used such worksheets when creating eLearning versions of my training courses. They helped me avoid overlooking an important step in my rush to finish the project.

Practice #8: Plan to do rework after a quality control activity. I’ve seen project plans that assumed every test will be a success that lets you move on to the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule should include rework as a discrete task after every quality control task. Base your estimates of rework time on previous experience. If you collect a bit of data, you can calculate the average expected rework effort to correct defects found in various types of work products. And if you don’t have to do any rework after performing a test, great; you’re ahead of schedule on that task. This is permitted in all fifty states and in many other countries. Don’t count on it, though.

Practice #9: Manage project risks. If you don’t identify and control project risks, they’ll control you. A risk is a potential problem that could affect the success of your project. It’s a problem that hasn’t happened yet—and you’d like to keep it that way. Simply identifying the possible risk factors isn’t enough. You also have to evaluate the relative threat each one poses so you can focus your energy where it will do the most good.

Risk exposure is a combination of the probability that a specific risk could materialize into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities aren’t as effective as you hope.

A simple risk list doesn’t replace a plan for how you will identify, prioritize, control, and track risks. Incorporate risk tracking into your routine project status tracking. See Chapter 6 of Practical Project Initiation for an overview of software risk management.

Practice #10: Plan time for process improvement. Your team members are already swamped with their current project assignments. If you want the group to rise to a higher plane of software development capability, though, you’ll have to invest in process improvement. This means you’ll need to set aside some time from your project schedule for improvement activities. Don’t allocate one hundred percent of your team’s available time to project tasks and then wonder why they don’t make any progress on the improvement initiative.

Some process changes can begin to pay off immediately, but you won’t reap the full benefit from other improvements until the next project. Process improvement is a strategic investment in the organization. I liken process improvement to highway construction: It slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput is greater.

Practice #11: Respect the learning curve. The time and money you spend on training, self-study, consultants, and developing improved processes are part of the investment your organization makes in sustained project success. Recognize that you’ll pay a price in terms of a short-term productivity loss—the learning curve—when you first try to apply new processes, tools, or technologies. Don’t expect to get fabulous benefits on the first try, no matter what the tool vendor or the consultant claims. Make sure your managers and customers understand the learning curve as an inescapable consequence of working in a rapidly changing, high-technology field.

Estimating the Work

Practice #12: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labor-hours) associated with a task, and then translate the effort into a calendar-time estimate. A twenty-hour task might take 2.5 calendar days of nominal full-time effort, or two exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. I base the translation of effort into calendar time on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.

If you track how you actually spend your time at work, you’ll know how many effective weekly project hours you have available on average. Tracking time like this is illuminating. Typically, the effective project time is only perhaps fifty to sixty percent of the nominal time team members spend at work, far less than the assumed one hundred percent effective time on which so many project schedules are planned.

Practice #13: Don’t over-schedule multitasking people. The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multitasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so therefore she could do five of them at once. Forty hours per week divided by eight is five, right? In reality, she’ll be lucky if she can handle three or four such tasks. There’s just too much friction associated with multitasking.

Some people multitask more efficiently than others, even thriving on it. But if certain of your team members thrash when working on too many tasks at once, set clear priorities and help them do well by focusing on just one or two objectives at a time.

Practice #14: Build training time into the schedule. Estimate how much time your team members spend on training activities each year and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way.

Recognize that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company’s time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the student puts the knowledge to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.

Practice #15: Record estimates and how you derived them. When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project leader is naturally skilled at predicting the future. Develop estimation procedures and checklists that people throughout your organization can use.

The Wideband Delphi method is an effective group estimation technique. This technique asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Wideband Delphi method more reliable than simply asking a single individual for his best guess. Chapter 11 of Practical Project Initiation presents a tutorial on the Wideband Delphi estimation method.

The final article in this series will describe two additional estimation tips, along with several good practices for tracking your progress and learning how to plan and manage future projects more effectively.

Also read Project Management Best Practices, Part 1
Also read Project Management Best Practices, 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.

Managing software projects is difficult under the best circumstances. The project manager must balance competing stakeholder interests against the constraints of limited resources and time, ever-changing technologies, and challenging demands from high-pressure people. Project management is a juggling act, with too many balls in the air at once.

Unfortunately, many new project managers receive little training in how to do the job. Anyone can learn to draw a Gantt chart, but effective project managers also rely on the savvy that comes from experience. Learning survival tips from people who’ve already done their tours of duty in the project management trenches can save you from learning such lessons the hard way.

This three-part series, adapted from my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007), introduces twenty-one valuable practices that can help both rookie and veteran project managers do a better job with less pain. The practices are organized into five categories:

  1. Laying the foundation.
  2. Planning the project.
  3. Estimating the work.
  4. Tracking your progress.
  5. Learning for the future.

When initiating a new project, study this list of practices to see which ones would be valuable contributors to that project. Build the corresponding activities into your thinking and plans. Recognize, though, none of these practices will be silver bullets for your project management problems. Also, remember that even “best” practices are situational. They need to be selectively and thoughtfully applied only where they will add value to the project.

Laying the Foundation

Practice #1: Define project success criteria. At the beginning of the project, make sure the stakeholders share a common understanding of how they’ll determine whether this project is successful. Begin by identifying your stakeholders and their interests and expectations. Next, define some clear and measurable business goals. Some examples are:

  •  Increasing market share by a certain amount by a particular date.
  • Reaching a specified sales volume or revenue.
  • Achieving certain customer satisfaction measures.
  • Saving money by retiring a high-maintenance legacy system.

These business goals should imply specific project success criteria, which again should be measurable and trackable. These goals could include achieving schedule and budget targets, delivering committed functionality that satisfies acceptance tests, complying with industry standards or government regulations, or achieving specific technology milestones. The business objectives define the overarching goal. It doesn’t matter if you deliver to the specification on schedule and budget if those factors don’t clearly align with business success.

Not all of these defined success criteria can be your top priority. You’ll have to make some thoughtful tradeoff decisions to be sure that you satisfy your most important priorities. If you don’t define clear priorities for success, team members can work at cross-purposes. Chapter 4 of Practical Project Initiation presents a tutorial on defining project success criteria.

Practice #2: Identify project drivers, constraints, and degrees of freedom. Every project must balance its functionality, staffing, budget, schedule, and quality objectives. Define each of these five project dimensions as either a constraint within which you must operate, a driver strongly aligned with project success, or a degree of freedom you can adjust within some stated bounds. I explain this idea more fully in my book Creating a Software Engineering Culture (Dorset House, 1996).

I’m afraid I have bad news: not all factors can be constraints, and not all can be drivers. If you are given a defined feature set that must delivered with zero defects by a specific date by a fixed team size working on a fixed budget, you will most likely fail. An over constrained project leaves the project manager with no way to deal with requirement changes, staff turnover or illness, risks that materialize, or any other unexpected occurrences.

I once heard a senior manager and a project leader debate how long it would take to deliver a planned new large software system. The project leader’s top-of-the-head guess was four times as long as the senior manager’s stated goal of six months. The project leader’s response to the senior manager’s pressure for the much shorter schedule was simply, “Okay.” A better response would have been to negotiate a realistic outcome through a dialogue:

  •  Does something drastic happen if we don’t deliver in six months (schedule is a constraint), or is that just a desirable target date (schedule is a driver)?
  • If the six months is a firm constraint, what subset of the requested functionality do you absolutely need delivered by then? (Features are a degree of freedom.)
  • Can I get more people to work on it? (Staff is a degree of freedom.)
  • Do you care how well it works? (Quality is a degree of freedom.)
  • Can I get more funding to outsource part of the project work? (Cost is a degree of freedom.)

Practice #3: Define product release criteria. Early in the project, decide what criteria will indicate whether the product is ready for release. Some examples of possible release criteria are:

  • There are no open high-priority defects.
  • The number of open defects has decreased for X weeks, and the estimated number of residual defects is acceptable.
  • Performance goals are achieved on all target platforms.
  • Specific required functionality is fully operational.
  • Quantitative reliability goals are satisfied.
  • Specified legal, contractual, or regulatory goals are met.
  • Customer acceptance criteria are satisfied.

Whatever criteria you choose should be realistic, objectively measurable, documented, and aligned with what “quality” means to your customers. Decide early on how you will tell when you’re done, track progress toward your goals, and stick to your guns if confronted with pressure to ship before the product is ready for prime time. See Chapter 5 of Practical Project Initiation for more about defining product release criteria.

Practice #4: Negotiate achievable commitments. Despite pressure to promise the impossible, never make a commitment you know you can’t keep. Engage in good-faith negotiations with customers, managers, and team members to agree on goals that are realistically achievable. Negotiation is required whenever there’s a gap between the schedule or functionality the key project stakeholders demand and your best prediction of the future as embodied in project estimates.

Principled negotiation involves four precepts, as described in Getting to Yes by Roger Fisher, William Ury, and Bruce Patton (Penguin USA, 1991):

  • Separate the people from the problem.
  • Focus on interests, not positions.
  • Invent options for mutual gain.
  • Insist on using objective criteria.

Any data you have from previous projects will strengthen your negotiating position, especially because the person with whom you’re negotiating likely has no data at all. However, there’s no real defense against truly unreasonable people.

Plan to renegotiate commitments when project realities (such as staff, budget, or deadlines) change, unanticipated problems arise, risks materialize, or new requirements are added. No one likes to have to modify his commitments. But if the reality is that the initial commitments won’t be achieved, let’s not pretend that they will right up until the moment of disappointing truth.

Planning the Project

Practice #5: Write a plan. Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is doing the planning—thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you encounter later in the project. A useful plan is much more than just a schedule or task list. It also includes:

  • Staff, budget, and other resource estimates and plans.
  • Team roles and responsibilities.
  • How you will acquire and train the necessary staff.
  • Assumptions, dependencies, and risks.
  • Target dates for major deliverables.
  • Identification of the software development life cycle that the project will follow.
  • How you will track and monitor the project.
  • Metrics that you’ll collect and analyze.
  • How you will manage any subcontractor relationships.

Your organization should adopt a standard software project management plan template, which each project can tailor to best suit its needs. You might start with the project management plan template available at www.ProjectInitiation.com. Adjust and shrink this template to suit the nature and size of your own projects.

If you commonly tackle different kinds of projects, such as major new product development projects as well as small enhancements, I suggest you adopt a separate project plan template for each project class. The project plan should be no longer or more elaborate than necessary to make sure you can successfully execute the project. One page might suffice in some cases. But always write a plan.

Practice #6: Decompose tasks to inch-pebble granularity. Inch-pebbles are miniature milestones (get it?). Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking. Select inch-pebbles of a size that you feel you can estimate accurately. I feel most comfortable with inch-pebbles that represent tasks of about five to fifteen labor-hours. Overlooked tasks are a common contributor to schedule slips. Breaking large problems into smaller bits reveals more details about the work that must be done and improves your ability to create accurate estimates. You can track progress based on the number of inch-pebbles that the team has completed at any given time, compared to those you planned to have done by that time.

Part 2 of this series will continue with additional practices for planning the project and several tips for preparing more realistic estimates.

Also read Project Management Best Practices, Part 2
Also read Project Management Best Practices, 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.

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.

In the first article in this series, I pointed out that there’s no easy answer to the question of how detailed the requirements need to be. Instead, I can present a thought process the business analyst can use to assess the appropriate level of detail for each case. As I describe in this article, which is adapted from my book More about Software Requirements, several conditions make it appropriate to leave the requirements descriptions at a higher level of abstraction. Recognize that these are broad guidelines. The BA should perform a risk-benefit analysis to balance the potential downside of omitting important information against the effort required to include it.

Customers are extensively involved

If you have extensive, ongoing, and intimate involvement by the right customer representatives, you can get away with less written requirements documentation. This is the premise behind the on-site customer in agile development methodologies. In such situations, developers need just enough written information about requirements to estimate their size and get a general idea of the customer’s intent. The details will come later from conversations with customer representatives and subject matter experts.

This approach works only when developers have ready access to customers who have the time, knowledge, and authority to make decisions on behalf of the communities they represent. Even if the customers can provide just-in-time details, it’s doubtful that anyone will record those details. This makes it harder to reach a shared expectation among the various stakeholders. Your project might lack a written reference to ensure that the product is adequately tested and that no requirements were inadvertently overlooked during implementation. Of course, you can capture the requirements details as the developers obtain them, thereby growing the requirements specification—or, as in some agile approaches, the suite of acceptance tests—incrementally.

Developers have considerable domain experience

Developers with extensive application domain knowledge can sometimes supply a lot of the necessary requirements details. Watch out for developers who are overconfident, certain that they understand what users need without asking. Ideally, knowledgeable representatives of specific user classes will work with the BA to develop requirements.

There’s always a risk of a disconnect when using surrogates who will not actually use the product being developed. Technically sophisticated developers might not be representative of the typical end user. Even developers with a lot of domain experience sometimes aren’t aware of the current needs in a changing business environment. If their knowledge is obsolete, they can’t do a good job of supplying the missing requirements.

If developers are filling in a lot of the requirements details, it’s a good idea to have them run their ideas past the BA and some customer representatives before implementing them. A simple review provides a check to make sure the fleshing out is being done appropriately.

Precedents are available

When precedents are available to use as a model, you don’t need to include all the requirements details in the specification. The developers can turn to the existing product or documentation as a reference for details that aren’t provided in the current specification. This might be the case when reengineering a legacy application, for example.

Watch out, though. Most software contains extensive functionality that is not immediately visible to someone who is simply looking at the user interface or a high-level product description. Some examples are exception handlers, business rule enforcement, and relationships between data in fields on a form or dialog box. You don’t want every developer to have to reverse-engineer the existing product to figure out just what it does, possibly arriving at different conclusions.

A package solution will be used

Projects that plan to acquire a commercial package solution for all or part of the functionality don’t need highly detailed requirements. There’s no point in writing comprehensive functional requirements, because the package vendor has already done that (or so you hope). However, it’s rare that a package will fully meet your needs, so you still must specify the requirements for package extensions, integrations, and customizations.

Use cases are an effective requirements elicitation technique for package-solution projects. The package needs to let your users accomplish specific tasks (use cases), although the details of how this works will vary from one package to another (functional requirements and user interface design). User acceptance tests based on use cases are also helpful for evaluating packages. Knowledge of the pertinent business rules is critical. The package you select must enforce the necessary business rules and let you change or customize them as necessary. Defining quality attribute requirements will also help the stakeholders choose the right package.

Sample Levels of Requirements Detail

Let’s return to the home alarm system example I mentioned in the first article in this series. Following is an illustration of how you might write some functional requirements for disarming the triggered system. The first requirement (our original one) is written at a high level:

Disarm.Alarm 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.

A developer who receives this requirement likely will have many questions. The table below shows how the BA could flesh out this high-level requirement with additional specific functional requirements, if the BA judges that this is a good idea. (These requirements are written in a traditional hierarchical format, expressed using a compact notation to give each child requirement a unique identifier, such as Disarm.Alarm.Timeout.Siren. The parent requirement, Disarm.Alarm, is shown as a title or heading, rather than as a discrete requirement statement.)

Disarm.Alarm: Disarming the triggered system with a user-entered passcode
       .Sound When a sensor is triggered after the system is armed, the alarm system shall emit an intermittent warning tone. The alarm system shall sound the tone until either the system is disarmed or the preset warning duration has passed.
       .Interval The system shall evaluate an entered passcode 1.0 second following user entry of the last digit. Digits entered within less than 1.0 second of the previous digit’s entry are appended to the sequence of passcode digits the user has already entered.
       .OK If the entered passcode is correct, the system shall stop emitting the warning tone and shall set itself to the disarmed state.
       .NoGood If the entered passcode is incorrect, the system shall continue to emit the warning tone, continue counting down the warning duration, and permit the user to reenter the passcode.
       .Timeout If the warning duration is reached before the user enters a valid passcode, the system shall take the following actions:
             .Siren Trigger the alarm system’s siren.
             .Dial Dial the alarm system monitoring company.
             .Log Record the alarm incident in the internal system event log.

Note that these requirements include the names of some data objects, like “warning duration” and “passcode.” I recommend that you collect the meaning and attributes of such objects in a data dictionary, a separate document (or file) or an appendix to the requirements spec. The data elements and structures that pertain to the requirements are defined and hierarchically decomposed in the data dictionary.

Even though these functional requirements answer many of the questions posed earlier in this chapter about the alarm system’s behavior, they’re still missing some important information. What is the cycle frequency of the “intermittent warning tone” described in requirement Disarm.Alarm.Sound? How loud is it? What does it sound like? I’ve never seen a requirement that didn’t have opportunities for improvement. Whether to specify these details in the requirements or leave them to the developer’s judgment is the BA’s choice.

Also read How Detailed Should Requirements Be? Part 1

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.

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.

 

Experienced project managers and developers understand the value of translating software requirements into robust designs and rational project plans. These steps are necessary whether the next release represents one percent or one hundred percent of the final product. This article explores some approaches for bridging the gap between requirements development and a successful product release. In particular, we will look at several ways in which requirements influence designs and code (Figure 1).

Figure 1. Requirements drive project planning, design, coding, and testing activities.

From Requirements to Designs and Code

The boundary between requirements and design is not a sharp line, but keep your specifications free from implementation bias except when you have a compelling reason to intentionally constrain the design. Requirements specification should concentrate on describing the intended external system behaviors. Ideally, the descriptions of what the system is intended to do should not be slanted by design considerations. Practically speaking, many projects contain design constraints from prior products, and backwards compatibility is a frequent requirement. Because of this, a requirements specification almost always contains some design information. However, the specification should not contain inadvertent design. Include designers or developers in requirements reviews to make sure the requirements can serve as a solid foundation for design.

A product’s requirements, quality attributes, and user characteristics drive its architecture. Studying a proposed architecture provides a different perspective that helps to verify the requirements and tune their precision, as does prototyping. Both methods use the following thought process: “If I understand the requirements correctly, then this approach is a good way to satisfy them. Now that I have a preliminary architecture (or a prototype) in hand, does it help me understand the requirements better?”

Architecture is especially critical for systems that include both software and hardware components and for complex software-only systems. An essential requirements analysis step is to allocate the high-level system requirements to the various subsystems and components. A business analyst, systems engineer, or architect decomposes the system requirements into functional requirements for both the software and the hardware subsystems. Traceability information lets the development team track where each requirement is addressed in the design.

Poor allocation decisions can result in the software being expected to perform functions that should have been assigned to hardware components (or the converse), poor performance, or the inability to replace one component easily with an improved version. On one project, the hardware engineer blatantly told my group that he expected our software to overcome all limitations of his hardware design! Although software is more malleable than hardware, engineers shouldn’t use software’s flexibility as a reason to skimp on hardware design. Take a system engineering approach to make optimal decisions about which capabilities each system component will satisfy within its imposed constraints.

Allocation of system capabilities to subsystems and components must be done from the top down. Consider a DVD player, which includes motors to open and close the disk tray and to spin the disk, an optical subsystem to read the data on the disk, a multifunction remote control, image rendering software, and more (Figure 2). The subsystems interact to control the behaviors that result when, say, the user presses a button on the remote control to open the disk tray while the disk is playing. The system requirements drive the architecture design for such complex products, and the architecture influences the requirements allocation.

Figure 2. Complex products such as DVD players contain multiple software and hardware subsystems.

Software design receives short shrift on some projects, yet the time spent on design is an excellent investment. A variety of software designs will satisfy most products’ requirements. These designs will vary in their performance, efficiency, robustness, and the technical methods employed. If you leap directly from requirements into code, you’re essentially designing the software on the fly. You come up with a design, but not necessarily with the best design or even a really good design. Refactoring the code can improve the design, but an ounce of design is worth a pound of refactoring. Thinking about design alternatives will also help to ensure that developers respect any stated design constraints.

Thinking about design can even make your life simpler. I once worked on a project that simulated the behavior of a photographic system with eight computational processes. After working hard on requirements analysis, we were eager to start coding. Instead, we took the time to create a design model, thinking about how we would build a solution instead of trying to understand the problem. We quickly realized that three of the steps in the simulation used identical computational algorithms, three more used another set, and the remaining two steps shared a third set. The design perspective simplified the problem from eight complex calculations to just three. Had we begun coding immediately after requirements analysis, we doubtless would have noticed the code repetition at some point. We saved a lot of time by detecting these simplifications early on. It’s more efficient to revise design models than to rewrite code.

As with requirements, excellent designs are the result of iteration. Make multiple passes through the design to refine your initial concepts as you gain information and generate additional ideas. Shortcomings in design lead to products that are difficult to maintain and extend and which don’t satisfy the customer’s performance, usability, and reliability objectives. The time you spend translating requirements into designs is an excellent investment in building high-quality, robust software products.

You need not develop a complete, detailed design for the entire product before you begin implementation. However, design each component before you code it. Design planning is of most benefit to very difficult projects, systems having many internal component interfaces and interactions, and projects staffed with inexperienced developers. All kinds of projects will benefit from the following actions:

  • Develop a solid architecture of subsystems and components that will hold up during enhancement.
  • Identify the key object classes or functional modules you need to build, defining their interfaces, responsibilities, and collaborations with other units.
  • For parallel-processing systems, understand the planned execution threads or allocation of functionality to concurrent processes.
  • Define each code unit’s intended functionality, following the sound design principles of strong cohesion, loose coupling, and information hiding (McConnell 1993).
  • Make sure that your design accommodates all the functional requirements and doesn’t contain unnecessary functionality.
  • Ensure that the design accommodates exceptional conditions that can arise.
  • Ensure that the design will achieve performance, robustness, reliability, and other stated quality goals.

As developers translate requirements into designs and code, they’ll encounter points of ambiguity and confusion. Ideally, developers can route these issues back to customers or analysts for resolution. If an issue can’t be resolved immediately, any assumptions, guesses, or interpretations that a developer makes should be documented and reviewed with customer representatives. If you encounter many such problems, the requirements weren’t sufficiently clear or adequately detailed before they were passed to the developers. Review the remaining requirements with a developer or two and tune them up before continuing with construction. Also, revisit your requirements validation processes to see how the low-quality requirements made it into the developers’ hands.

From Requirements to Success

I recently encountered a project in which a contract development team came on board to implement an application for which an earlier team had developed the requirements. The new team took one look at the dozen three-inch binders of requirements, shuddered in horror, and began coding. They didn’t refer to the SRS during construction. Instead, they built what they thought they were supposed to, based on an incomplete and inaccurate understanding of the intended system. Not surprisingly, this project encountered a lot of problems. The prospect of trying to understand such a huge volume of even excellent requirements is certainly daunting, but ignoring them is a decisive step toward project failure. It is faster to read the requirements, however extensive, than to build the wrong system and then build it again. It’s even faster to engage the development team early in the project, so they can participate in the requirements work and perform early prototyping.

The ultimate deliverable from a software development project isn’t an SRS; it’s a system that meets the customers’ needs and expectations. The requirements are an essential step on the path from business need to satisfied customers. If you don’t base your plans, designs, and tests on a foundation of high-quality requirements, you’re likely to waste a great deal of effort trying to deliver an excellent product. Don’t become too overly controlled by your requirements processes, though. There’s no point in spending so much time generating unnecessary documents and holding ritualized meetings that no software ever gets written and the project is canceled. Strive for a sensible balance between rigorous specification and off-the-top-of-the-head coding that will reduce to an acceptable level the risk of building the wrong product.

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.