Habits of Effective Business Analysts, Part 2

Requirements & Requirements Management

Habits of Effective Business Analysts, Part 2

By |

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.

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.

 

Karl Wiegers
Latest posts by Karl Wiegers (see all)