IIBA Archives

Tag Archive for: IIBA

Here are some additional recommendations about how to make peer reviews of your requirements documents as effective as possible.

Don’t Overwhelm the Reviewers

Many BAs wait until their requirements specification is complete before they present it to some reviewers. Busy developers, testers, project managers, and users have difficulty finding the time to scrutinize a large document on short notice. It’s far more effective to review an evolving document incrementally. Give reviewers just a few pages at a time, preferably soon after an elicitation activity. Nearly anyone should be able to find thirty minutes to review a small quantity of information once in a while.

Incremental, informal reviews will uncover a lot of problems. Expect to make multiple review passes through the requirements over time. Each review cycle will reveal errors that the reviewers didn’t spot the first time. As the requirements continue to change and grow, people might need to revisit portions of the requirements documentation that they examined in an earlier draft.

You don’t need to hold a meeting for each peer review. Sometimes it works fine just to ask one or a few reviewers to look something over and tell you what they see. Combine these sorts of informal individual reviews, which I call peer deskchecks, with formal inspections of documents that are nearly done.

Build a Collaborative Partnership with Project Stakeholders

Explain to users why their input is so critical to ensuring the quality of the requirements and how it contributes to the quality of the ultimate software product. Make them understand that their review effort is a vital contribution, not an idle exercise. Begin forging this collaboration early in the project so these participants realize they’re valued members of the team.

On many projects, my software development teams at Kodak identified product champions, key customer representatives who worked closely with the business analysts. We negotiated the exact responsibilities with each product champion. But one responsibility was not optional: to review requirements specifications and evaluate prototypes. Without user review, we couldn’t tell whether we’d accurately captured the voice of the customer. We were pleased that all of our product champions accepted this responsibility. They provided great value through their reviews.

Invite the Right Reviewers

Determine early in the project what perspectives you need represented in your requirements reviews and who can provide these perspectives. Figure 1 illustrates the essential points of view a requirements review should take into account. Particularly consider getting the participation of the following:

• Customers who provided requirements input.

• Developers who will have to design and implement the requirements.

• Testers who will have to verify that the requirements were properly implemented.

Work products must be reviewed in a context, not in isolation. The reviewers must ascertain whether the work product meets its own specification. The top-level requirements documentation has no specification or reference document, so you need customers or others who provided requirements input to review the deliverable. Also, you might invite another BA to participate who’s adroit at spotting poorly written or missing requirements. The downstream “victims” of the requirements specification can check to see whether it will satisfy their needs. And if your product connects in some way to any other products, have representatives of those other components make sure the pieces will fit together properly.

Rather than having all these different reviewers just read through the document, consider using perspective-based reading, in which each reviewer examines the deliverable from the point of view of a specific document consumer. For example, a user seeks to determine whether the documented requirements would in fact let him achieve his business objectives. A developer checks to see whether the document contains the information he needs to design and implement a solution. A tester considers whether the requirements are precise and detailed enough to be verifiable. These different points of view will reveal different types of problems.

Have Reviewers Examine Appropriate Deliverables

It might not be reasonable to expect all your user representatives to effectively review a detailed software requirements specification. They should certainly understand use cases, though, as use cases ought to be written from the user’s point of view. Make sure your reviewers can comprehend the requirements documents and diagrams well enough to validate them. If the requirements documents are too technical for the reviewers to follow, you’re wasting their time.

Design for Reviewability

Present the information in a specification in forms that make it easy for reviewers to understand it and to examine it for problems. There are many ways to communicate besides natural language text. If your eyes glaze over when reading a long list of textual requirements, maybe a diagram or a table would be an effective alternative. Remember that a requirements specification is a communication tool. If your requirements deliverables don’t speak to their intended audiences, the deliverables need further work.

Inspect All Requirements Deliverables

Informal reviews certainly are helpful, but more systematic inspections will find more defects. Inspections and other group reviews also are a way to force the issue of getting reviewers to actually look at the work product. Inspections are a powerful technique for spotting ambiguous requirements. During an inspection, one inspector (not the author) serves as the reader. The reader presents his interpretation of each requirement to the other inspectors. If his interpretation doesn’t match their own understanding, perhaps the team has detected an ambiguity, a statement that can be interpreted in more than one way. Individual informal reviews often overlook ambiguities because an ambiguous requirement can make sense to each reader, even if it means something different to each of them.

Emphasize Finding Major Errors

The greatest leverage from a review comes from finding major errors of commission and omission. These are the defects that can help you avoid extensive—and expensive—rework much later in the project. Ambiguous and erroneous requirements send developers and testers in the wrong direction. Missing requirements are among the hardest errors to detect. They’re invisible, so inspectors don’t see them during their individual preparation. Because they don’t exist, the inspection reader won’t describe them.

Fixing typographical and grammatical errors is useful because any changes that enhance effective communication are valuable. However, this should be done before sending out the document out for broad review, perhaps by having a single skilled editor go through it initially. Otherwise, reviewers can trip on these superficial errors and fail to spot the big defects that lie underneath. When I see an issues log from a review that contains mostly cosmetic and spelling mistakes, I worry that perhaps the reviewers overlooked major problems.

No business analyst can get the requirements right on his own. Get a little help from your friends to make sure that what you’ve written will satisfy customer needs and will let the rest of the development team do a first-class job.

Check out Peer Reviews: Two Eyes Aren’t Enough, Part 1.

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

In my view, the most powerful quality practice available to the software industry today is inspection of requirements documentation. A peer review is an activity in which someone other than the author of a work product examines that product to find defects and improvement opportunities. An inspection is a type of formal, rigorous team peer review that can discover more subtle problems than individual reviewers might spot on their own. Removing errors in the requirements saves many times the cost of the inspection because of the rapidly escalating cost of remedying defects that are found later in the project.

Unfortunately, inspections and other peer reviews of requirements documents often aren’t held when intended, and those that are performed don’t always go well. Reviewers take only a superficial look (if they look at all), and they miss many of the major defects that lurk in the specification. Conducting an ineffective review can give the team unjustified confidence in the work product’s quality.

This pair of articles, adapted from my book More about Software Requirements, presents several ways to make your requirements reviews more effective and to encourage prospective reviewers to participate in them. For an in-depth exploration of different peer review approaches and how to make them work for you, see my book Peer Reviews in Software: A Practical Guide (Addison-Wesley, 2002).

Note that, although I refer to requirements documents in these articles, the same principles also apply whether you’re storing your requirements in a spreadsheet, a database, a requirements management tool, or on note cards. No matter what their form, you really ought to have multiple pairs of eyes examine your project’s requirements for problems.

Educate the Reviewers

Suppose someone hands you a document and asks for your input. Your instinctive approach probably is to begin reading at the top of page one and see whether any problems jump out at you as you go. Maybe you’re not too sure what to look for. As you continue reading, you begin to get tired and bored. Your own work backlog tugs at your conscience. So you flip through the rest of the pages, tell the author about the minor issues you found, and move on with your life. There’s a better way.

Don’t expect that reviewers will automatically know what to do. If you’re a business analyst who’s relying on input from others to validate and verify your requirements, you need to educate your reviewers. Ideally, you can get them to take some training on how to perform peer reviews, such as my eLearning course called “Software Inspections and Peer Reviews” (http://www.processimpact.com/elearning.shtml#sipr). If not, at least tell them about the purpose of reviews, the various sorts of review approaches, and what you expect of the reviewers. This is particularly important if you plan to hold inspections, which involve a more structured process than do the more familiar informal reviews.

Interact Respectfully

Peer reviews are at least as much a social interaction as they are a technical practice. I believe that asking someone to tell you about mistakes in your work is a learned behavior, not an instinctive behavior. Authors need to learn how to request and accept constructive input about mistakes they’ve made. If you’re holding inspections or team reviews that involve a meeting, make sure the participants understand how to collaborate effectively and constructively. Many organizations hold ineffective reviews because participants are uncomfortable and they aren’t sure how to behave in a review meeting.

One state government agency that hired me as a consultant told me that their review participants refer to the review as “going into the shark tank”—not an appealing prospect. If you’ve been burned by a caustic review in the past, you’ll be reluctant to participate in such a stressful and ego-busting experience again. Therefore, it’s important to make reviews be constructive experiences in which all participants feel that they’re contributing to improving the team’s collective work products.

People need to be considerate when they provide feedback to the author of the work product being reviewed. I like to simply make observations about the product, rather than telling the author he did something wrong. If you’re the author, you might react differently if a reviewer accusingly says, “You forgot to fill in section 3.4 of the SRS template,” instead of simply commenting: “I didn’t see anything entered in section 3.4 here” or “Section 3.4 seems to be missing.” Be thoughtful about how you phrase your comments. Perhaps you’re a reviewer today, but you might be the author the next time.

Focus on Specific Problems

Tell the reviewers what kind of input you’re seeking in each situation so they can focus their attention on giving you useful feedback. Give them tips on how to study and analyze a requirements specification. For example, you might invite certain reviewers to start reading at some point other than the beginning of the document. After all, developers won’t read the entire document sequentially during construction. This is a way to get fresh eyes looking at various sections, rather than having all of the reviewers peter out partway through the document and miss a lot of errors in the latter pages. Some people suggest reading the document from back to front, section by section, to see whether the questions they come up with are all answered earlier in the document.

Give the reviewers a checklist of typical requirements errors so they can focus their examination on those points. You can find checklists for reviewing software requirements specifications and use case documents at http://www.processimpact.com/pr_goodies.shtml. You might suggest that the reviewers make multiple passes through the document, perhaps during separate review cycles of a growing document. They can look for different types of problems from the checklist during each pass. Alternatively, ask different reviewers to use separate parts of the checklist to broaden the review coverage. Eventually requirements reviewers will internalize the review checklists and know what sorts of problems to look for.

In part two of this article I’ll share some additional tips for making your requirements reviews as effective as possible.

Check out Peer Reviews: Two Eyes Aren’t Enough, Part 2.

The first article in this series described the critical role of the business analyst in bridging the communication gap between business and IT, understanding project scope, and asking meaningful questions during requirements elicitation. This concluding article continues by exploring several additional contributions that BAs make to a software project.

Prioritize Early and Often

Requirements development is an iterative and incremental process, proceeding from fuzzy notions to detailed specifications a layer at a time. If you’re facilitating an elicitation workshop, keep the discussion focused on the right level of abstraction for that day’s objectives. Don’t let the participants get bogged down in excessive detail or premature system design. It can be valuable to sketch out possible user interface screens or build prototypes to clarify requirements. However, diving deeply into design too early can lead to a system that fails to meet the user’s actual needs.

It’s discouraging to realize at crunch time that everything the team has left to do is essential, while they’ve already implemented some features that weren’t really that important. BAs must work with customers to define the priorities for requested product features, so the team can build the most critical functionality in the early iterations. Your job as a BA includes facilitating negotiation between the various stakeholders to ensure that the team makes sensible priority decisions.

Early in the project, identify the various user classes that might contribute requirements. You’ll need to understand which user classes are favored, which (if any) are disfavored, and which groups of users won’t have input to the product’s requirements. The favored user classes typically take precedence if you encounter conflicts in the requirements or priorities presented by different user classes.

Next, work with appropriate representatives of each user class to identify their major use cases. Performing a first-cut prioritization on the use cases will help you determine which ones to explore in detail early on. The top priority use cases are those that are the most important (capabilities the users really need) and the most urgent (capabilities the users need right away). The users might elect to implement only core portions of certain use cases in the initial release or iteration, leaving enhancements for later. Alternatively, they might opt to initially implement the full functionality of a small set of use cases. Understanding the logical dependencies among the requirements will let you determine whether some high-priority requirements should be delayed. Sometimes architectural constraints demand that certain functionality be implemented first.

Create a Collaborative Environment

Software development sometimes is characterized by strained relationships among developers, users, managers, and marketing. The parties may not trust each other’s motivations or appreciate each other’s needs and constraints. In reality, though, the producers and customers of a software product share some common objectives. For information systems development, all parties work for the same company and benefit from improvements to the corporate bottom line. For commercial products, developers and marketing should strive to meet the purchasing customers’ needs, so they will buy more products and rave to their friends. And contract developers should try to make the client happy to get repeat business. A win/win outcome means customers are delighted with the product, the developing organization is happy with the business outcomes, and the development team members are proud of the good work they did.

Achieving a win/win outcome requires honesty. Sharing all relevant information among the stakeholders and telling the truth without blame or judgment promotes free and informed choices. Such a ideal environment isn’t always achievable. In fact, none of my suggestions are likely to work if you’re dealing with truly unreasonable people.

Defining business requirements early in the project will clarify the prospective benefits for both customers and the developing organization. The participants also need to be honest about functionality costs and project constraints. If you think the customer’s cost or schedule expectations are unrealistic, say so and explain your reasoning. Considering the costs will help the stakeholders make sensible business decisions to achieve the maximum value within the existing resource, time, and technology constraints.

It’s not unusual for a BA to solicit input from users only to hear, “I don’t have time to talk to you. You should know what I need.” However, software success is most likely when the BA can forge a collaborative relationship with key stakeholder representatives. Users might hesitate to participate in requirements exploration until they know exactly what you expect from them. Tell your customer collaborators what you need from them so they know why their input is so vital. A vision and scope document will help you identify the right users to talk to and will give them a clear understanding of what the project is trying to achieve.

Insufficient user involvement is well established as a leading cause of software project failure. Point this out to users or managers who don’t want to spend time on requirements discussions. Remind your customers of problems they’ve experienced on previous projects that you can trace back to inadequate user involvement. You can’t afford to keep rebuilding or discarding systems that don’t measure up because the user needs weren’t sufficiently understood. If customers won’t commit to reaching a shared understanding of their requirements, the development organization might be better off avoiding the project. Otherwise, the outcome might well be lose/lose.

Hone Your Skills

The business analyst provides the essential function of bridging the understanding and perspective gap that lies between customers and developers. A competent BA must combine communication, facilitation and interpersonal skills with some technical and business domain knowledge. Even a dynamite programmer or a system-savvy user needs suitable preparation before serving as a BA. The following capabilities are particularly important:

Facilitation techniques, to lead elicitation workshops.
Interviewing techniques, to talk with individuals and groups about their needs.
Listening skills, to understand what people say and to detect what they might be hesitant to say.
Writing skills, to communicate information effectively to users, managers and technical staff.
Organizational skills, to make sense of the vast array of information gathered during elicitation and analysis.
Interpersonal skills, to help negotiate priorities and resolve conflicts among project stakeholders; domain knowledge, to have credibility with user representatives and converse effectively with them.
Modeling skills, to represent requirements information in graphical forms that augment natural language text.

An effective BA has a rich toolkit of tolls and techniques at his fingertips and knows when—and when not—to apply each. My book Software Requirements, Second Edition (Microsoft Press, 2003) describes more than 40 requirements engineering “good practices.”

There’s no substitute for experience, though. One of my consulting clients discovered that they could inspect requirements specifications written by experienced BAs twice as fast as those written by novices because they contained fewer defects. In contrast, another organization asked each developer to write the requirements for the system components for which he was responsible. The result was specifications having wildly divergent styles, organization, and quality. This made it hard for developers to review and use each other’s specifications. A third organization appointed as BAs several developers for whom English was not their native language, while yet another expected its users to write up their own requirements. It’s hard enough to write good requirements when you do it for a living, let alone if you do it just once in a while or in a language in which you aren’t completely proficient.

Requirements for a software product aren’t just lying around waiting for someone wearing a hat labeled “BA” to collect them. At best, requirements exist in the minds of users, visionaries, and developers, from which they must be gently extracted and massaged into a usable form. A talented BA can guide the process to help users understand what they really need to meet their business needs and help developers satisfy those needs. Few project roles are more difficult than that of the business analyst. Few are more critical.

Check out Habits of Effective Business Analysts, Part 1.

Software managers sometimes assume that every talented programmer is also proficient at interviewing customers and writing requirements, without any training, resources, or coaching. This isn’t a reasonable assumption. Like testing, estimation, and project management, requirements engineering has its own skill set and body of knowledge. Unfortunately, computer science curricula often emphasize programming-related knowledge over other software life cycle activities. Self-study and on-the-job learning often neglect softer skills such as those needed in requirements engineering, unless you’re specifically studying in pursuit of a professional business analyst certification.

The role of the business analyst is critical to a software project. Many organizations expect developers or project managers to handle this vital function on their own. And even if a project team does include dedicated analysts, their skills might not be up to the task. Too often, I meet BAs who have had little training in how to perform their job and who have few books or tools available to help them. BAs who come from a user background may lack technical understanding, while those who migrated from the IT world might not understand the user’s business domain and terminology. A BA provides a specialized capability that can make the difference between a project that succeeds and one that struggles. In this two-part series, I describe several characteristics and practices of successful business analysts.

Bridge the Communication Gap

The BA is a communication middleman, bridging the gap between vague customer notions and clear specifications. The BA must first understand the user’s real needs and then define a set of functional requirements and quality goals that allow developers to build and testers to verify the system. To be an effective BA, become proficient in all forms of communication, including listening, speaking, and writing. As you interact with executive project sponsors, marketing, and user representatives, understand their objectives for the proposed system and their concerns about the business and the application. Use the vocabulary of the application domain, rather than forcing your customers to understand computer jargon.

Take the time to learn about your customer collaborators and understand how they prefer to communicate. Watch for assumptions that underlie either the users’ expression of needs or your own thinking. Avoid imposing your personal filter of understanding on what you hear the customers say. Keep one of my axioms of software development—and life, for that matter—in mind: The customer is not always right, but the customer always has a point. You must understand and respect those points, so they can be appropriately addressed in the product.

Try to understand the users’ implicit expectations about the system’s characteristics, such as performance, usability, efficiency, and reliability. Companies sometimes make products that fully meet the functional needs, only to discover that users hate it because it doesn’t work like they expect. When users declare that the system must be “user-friendly,” they have a mental image of what that means to them. As a BA, your job is to understand the intent behind each such expectation, so you can translate something vague and subjective like “user-friendly” into goals the developer can satisfy. One technique is to ask users what would constitute unacceptable performance, usability, or reliability.

Requirements development should lead to an understanding, shared by the various stakeholders, of the system that will address the customer’s problem. The BA is responsible for writing requirements that clearly express this shared understanding. Writing documents that customer representatives can understand and verify, while unambiguously conveying precise functional and nonfunctional requirements to the developers, is a tightrope walk. A single requirements specification might not meet both needs.

In requirements discussions, users often bring up fragments of functionality (“I need to be able to sort the list alphabetically”), quality characteristics (“this system has to be a lot more reliable than the old one”), or solution ideas (“then I select the state where I want to send the package from a drop-down list”). Don’t discard these bits of information because they convey part of what the user has in mind. However, I prefer to focus the early requirements discussions on the tasks users need to accomplish with the system: their use case. This helps you understand why the functionality or characteristics they describe are important. An understanding of user goals leads to the necessary functional requirements, which then leads to detailed user interface design.

Because use cases describe a user view of the system, users should understand them. However, use cases alone rarely convey enough detail to developers. One important BA task is to derive from each use case the specific functional requirements that, when implemented, will let users perform the tasks described in the use case. This means you must be able to communicate effectively in both directions: with users (the task view) and with developers (the technical view). To make sure you’ve been understood, have user representatives, developers and testers review your documents.

Color Inside the Lines

Begin your exploration of a new system’s requirements by defining the ultimate vision of what the product or application will be and do. Talk with the funding sponsor, marketing manager, or product visionary early on to define the project’s business objectives. This information helps you answer this critical question whenever someone suggests a new product feature: “Is this feature in scope?”

Teams rarely implement the ultimate solution in one pass. Instead, define the scope of the first release or iteration as a subset of the final product. Describe a growth path from the initial release toward realizing the ultimate vision through a series of staged releases or iterations. Also, document any known limitations or functionality that you don’t intend to build but which some stakeholder might expect to find. Expectation management is an important strategy.

Ask Revealing Questions

When working as a BA, you’ll need to actively facilitate discussions with users to pull out information that might otherwise go unstated. Ask questions to identify possible alternative ways a user might want to perform some task and to surface related tasks that the user representatives didn’t mention initially. If a user says “the default should be …”, he’s probably describing the normal flow for a use case. The phrase “but I should also have the option to …” suggests an alternative flow for that use case.

Users naturally focus on the system’s normal, expected behaviors. However, developers write much code to handle exceptions, so you should also search for possible error conditions that could arise and decide how the system should respond. If you don’t describe exceptions during requirements elicitation, either the developers will make their best guess at how to handle them, or the system will simply fail when a user hits the error condition. It’s a safe bet that system crashes aren’t in the user’s plans.

A BA isn’t just a scribe, recording whatever customers say they want. A creative BA can suggest ideas and alternatives to users during elicitation. When users truly can’t express what they need, watch them work and suggest ways to automate appropriate portions of the job. BAs can often think out of the box that limits the creativity of people who are too close to the problem being solved. Be careful to avoid gold-plating, adding extra functionality that just seems cool or somehow desirable. An effective BA must be able to think at multiple levels of abstraction. You should be able to generalize from a specific need expressed by one user to define a set of related needs that will satisfy many members of that individual’s user class.

Part 2 of this series will look at some of the other habits that help skilled BAs contribute to building great systems, including prioritizing requirements and creating a collaborative environment.

Read the Habits of Effective Business Analysts, Part 2