Tag Archive for: karl wiegers Page 6

Tag Archive for: karl wiegers

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.

 

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

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 two articles in this series I have shared some “cosmic truths” about requirements concepts in general and about how requirements affect the project stakeholders. This closing article in the series, adapted from my book More about Software Requirements, presents four more universal truths regarding requirements specifications.

Cosmic Truth #7: The first question a business analyst should ask about a proposed new requirement is, “Is this requirement in scope?”

Anyone who’s been in IT for long has worked on a project that has suffered from scope creep. It is normal and often beneficial for requirements to grow over the course of a project. Scope creep, though, refers to the uncontrolled and continuous increase in requirements that makes it impossible to deliver a product on schedule.

To control scope creep, the project stakeholders must first agree on a scope definition, a boundary between the desired capabilities that lie within the scope for a given product release and those that do not. Then, whenever some stakeholder proposes a new functional requirement, feature, or use case, the BA can ask, “Is this in scope?” To help answer this question, some project teams write their scope definition on a large piece of cardstock, laminate it, and bring it to their requirements elicitation discussions.

If a specific requirement is deemed out of scope one week, in scope the next, then out of scope again later, the project’s scope boundary is not clearly defined. And that’s an open invitation to scope creep.

Cosmic Truth #8: Even the best requirements document cannot—and should not—replace human dialog.

Even an excellent requirements specification won’t contain every bit of information that developers and testers need to do their jobs. There will always be tacit knowledge that the stakeholders assume—rightly or wrongly—that other participants already know, along with the explicit knowledge that must be documented in the requirements specification. BAs and developers will always need to talk with knowledgeable users and subject matter experts to refine details, clarify ambiguities, and fill in the blanks. This is the rationale behind having some key customers, such as product champions, work intimately with the BA and developers throughout the project. The person performing the role of BA (even if this is one of the developers) should coordinate these discussions to make sure that all the participants reach the same understanding so the pieces all fit together properly. A written specification is still valuable and necessary, though. A documented record of what stakeholders agreed to at a point in time—a “group memory”—is more reliable than human memories.

You need to include more detail in the requirements specifications if you aren’t going to have opportunities for frequent conversations with user representatives and other decision makers. A good example of this is when you’re outsourcing the implementation of a requirements specification your team created. Expect to spend considerable time on review cycles to clarify and agree on what the requirements mean. Also expect delays in getting questions answered and decisions made, which can slow down the entire project.

This very issue was a major contributing factor in a lawsuit I know of between a software package vendor and a customer. The vendor allowed no time in the schedule for review following some requirements elicitation workshops, planning to begin construction immediately. Months later, numerous key requirements issues had not yet been resolved and the project status didn’t remotely resemble the project plan.

Cosmic Truth #9: The requirements might be vague, but the product will be specific.

Specifying requirements precisely is hard! You’re inventing something new, and no one is exactly sure what the product should be and do. People sometimes are comfortable with vague requirements. Customers might like them because it means they can redefine those requirements later on to mean whatever they want them to mean. Developers sometimes favor vague requirements because they allow the developers to build whatever they want to build. This is all great fun, but it doesn’t lead to high-quality software.

Ultimately, you are building only one product, and someone needs to decide just what that product will be. If customers and BAs don’t make the decisions, the developers will be forced to. This is a sign that the key stakeholders are abdicating their responsibility to make requirements-level decisions, leaving those decisions to people who might know far less about the problem or the business.

Don’t use uncertainty as an excuse for lack of precision. Acknowledge the uncertainty and find ways to address it, such as through prototyping. A valuable adjunct to simply specifying each requirement is to define fit criteria that a user or tester could employ to judge whether the requirement was implemented correctly and as intended. Attempting to write such fit criteria will quickly reveal whether a requirement is stated precisely enough to be verifiable. See Suzanne Robertson and James Robertson, Mastering the Requirements Process, Second Edition (Addison-Wesley, 2006) for more information about fit criteria.

Cosmic Truth #10: You’re never going to have perfect requirements.

Requirements are rarely finished or complete. There is no way to know for certain that you haven’t overlooked some requirement, and there will always be some requirements that the BA won’t feel are necessary to record. Rather than declaring the requirements “done” at some point, define a baseline, a snapshot in time that defines an agreed-upon foundation for subsequent work and modifications. Once you’ve established a baseline, follow your change control process to modify the requirements, recognizing the implications of making changes. It’s folly to think you can freeze the requirements and allow no changes after some initial elicitation activities.

Striving for perfection can lead to analysis paralysis. Analysis paralysis, in turn, can have a backlash effect. Stakeholders who have been burned once by a project that got mired in requirements issues sometimes are reluctant to invest in requirements development at all on their next project. This is an even quicker path to failure.

You don’t succeed in business by writing a perfect specification. From a pragmatic perspective, strive to develop a set of requirements that are good enough to allow the team to proceed with design, construction, and testing at an acceptable level of risk. The risk is the threat of having to do expensive and unnecessary rework. Have team members who will need to base their own work on the requirements review them to judge whether they provide a suitably solid foundation for that subsequent work. Keep this practical goal of “good enough” in mind as you pursue your quest for quality requirements.

Read the Cosmic Truths about Software Requirements, Part 1.

Read the Cosmic Truths about Software Requirements, 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.

 

The first article in this series presented three “cosmic truths,” realities about requirements that I’ve discovered to apply to virtually all software projects. This article continues with three more such insights, focusing on requirements and the project stakeholders.

Cosmic Truth #4: The interests of all the project stakeholders intersect in the requirements process.

Consultant Tim Lister once defined project success as “meeting the set of all requirements and constraints held as expectations by key stakeholders.” A stakeholder is an individual or group who is actively involved in the project, who is affected by the project, or who can influence its outcome. Figure 1 identifies some typical software project stakeholders. Certain stakeholders are internal to the project team, such as the project manager, business analysts, developers, and testers. Other stakeholders are external, including customers who select, specify, or fund products; users who employ the systems; compliance certifiers; auditors; and marketing, sales, and support groups. The business analyst performs a central communication role, being responsible for interacting with all these stakeholders. Further, the BA is responsible for seeing that the system being defined will be fit for use by all customers, perhaps working with a system architect to achieve this goal.

Figure 1. Some typical software project stakeholders.

Identify your key stakeholder groups at the beginning of the project. Then determine which individuals will best represent the interests of each group. You can count on stakeholders having conflicting interests that must be reconciled. They can’t all have veto power over each other. You need to identify early on the decision makers who will resolve these conflicts, and these decision makers must determine what their decision-making process will be. As my friend Chris, a seasoned project manager, points out, “I have found that there is usually one primary decision maker on a project, oftentimes the key sponsor within the organization. I don’t rest until I have identified that person, and then I make sure he is always aware of the project’s progress.”

Cosmic Truth #5: Customer involvement is the most critical contributor to software quality.

Various studies have confirmed that inadequate customer involvement is a leading cause of the failure of software projects. Customers often claim they can’t spend time working on requirements. However, customers who aren’t happy because the delivered product missed the mark always find plenty of time to point out the problems. The development team is going to get the customer input it needs eventually. It’s a lot cheaper—and a lot less painful—to get that input early on, rather than after the project ostensibly is done.

Customer involvement requires more than holding a workshop or two early in the project. Ongoing engagement by suitably empowered and enthusiastic customer representatives is a critical success factor for software development. Following are some good practices for engaging customers in requirements development (see my book Software Requirements, 2nd Edition for more information about these practices):

Identify user classes. Customers are a subset of stakeholders, and users are a subset of customers. You can further subdivide your user community into multiple user classes that have largely distinct needs. Unrepresented user classes are likely to be disappointed with the project outcome.

Select product champions. You need to determine who will serve as the literal voice of the customer for each user class. I call these people product champions. Ideally, product champions are actual users who represent their user-class peers. In some cases, though, you might have limited access to actual users, so you need to employ surrogates to speak for certain user classes to the best of their ability. Such surrogates might be subject matter experts or marketing personnel. When developers are forced into the position of trying to identify user needs, they often don’t do a great job.

Build prototypes. Prototypes provide opportunities for user representatives to interact with a simulation or portion of the ultimate system. Prototypes are far more tangible than written requirements specifications and easier for users to relate to. However, prototypes aren’t a substitute for documenting the detailed requirements. You also have to watch out for the risk that users who evaluate prototypes will conclude that the system is almost done and press the development team to release the prototype as a delivered product. This is usually a disaster.

Agree on customer rights and responsibilities. People who must work together rarely discuss the nature of their collaboration. The BA should negotiate with the customer representatives early in the project to agree on the responsibilities each party has with respect to the requirements process. An agreed-upon collaboration strategy is a strong contributor to the participants’ mutual success.

Cosmic Truth #6: The customer is not always right, but the customer always has a point.

It’s popular in some circles to do whatever any customer demands, claiming “The customer is always right.” Of course, the customer is not always right! We all know this. Sometimes customers are in a bad mood, uninformed, or unreasonable. If you receive conflicting input from multiple customers, which one of those customers is “always right”? It’s a silly philosophy.

The customer might not always be right, but the BA needs to understand and respect whatever point each customer is trying to make through his request for certain product features or attributes. The BA must be alert for situations in which the customer could be in the wrong. Rather than simply promising anything a customer requests, strive to understand the rationale behind the customer’s thinking and negotiate an acceptable outcome. Following are some examples of situations in which a customer might not be right:

  • Presenting solutions in the guise of requirements.
  • Failing to prioritize requirements or expecting the loudest voice to get top priority.
  • Not communicating business rules and other constraints, or trying to get around them.
  • Expecting a new software system to drive business process changes.
  • Not supplying appropriate representative users to participate in requirements elicitation.
  • Failing to make timely decisions when a BA or developer needs an issue resolved.
  • Not accepting the need for tradeoffs in both functional and nonfunctional requirements.
  • Demanding impossible commitments.
  • Not accepting the cost of change.

The final article in this series will present four additional cosmic truths dealing with requirements specifications.

Read the Cosmic Truths about Software Requirements, Part 1.

Read the Cosmic Truths about Software Requirements, 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.