The Business Analyst as Explorer (Part 3 of 6): Open-Ended Questions
An effective business analyst is not simply a scribe who records whatever customers say. The BA needs to stimulate the thinking of the people he’s interviewing to get below the surface. The BA should ask questions such as “What else could happen that we haven’t already discussed?” and “Would anyone ever want to <do something>?” and “Could <some condition> ever occur?” These are ways to discover possible lower-probability scenarios or options the system should provide to the user.
In their classic book Exploring Requirements: Quality Before Design (Dorset House Publishing, 1989), Donald Gause and Gerald Weinberg describe “context-free questions.” In their words, context-free questions “are high-level questions that can be posed early in a project to obtain information about global properties of the design problem and potential solutions. Context-free questions are completely appropriate for any product to be designed….” The BA can use such questions to explore both processes and products. They’re a valuable complement to specific questions about the capabilities and characteristics of the product being specified.
In my experience, requirements elicitation discussions typically emphasize the expected normal behavior of the system. However, anyone who has ever done any programming knows that a good developer writes a lot of code to deal with exception conditions. An important aspect of requirements elicitation is to identify things that could go wrong, determine how the system should detect an error, and describe how the system should respond to the error. As a BA, you need to probe around the exceptions during your requirements discussions. Ask questions such as “What should happen if <some error condition arises>?” This is a way to detect missing requirements that haven’t come up in the discussion yet. It’s also a way to surface previously unstated assumptions. Testers are particularly adept at spotting exception conditions, so I like to have someone with testing experience participate in requirements elicitation sessions, if possible. I also engage a tester to review the emerging requirements documentation and look for exceptions and alternatives we haven’t considered.
Beware of asking questions that solicit a yes/no or multiple-choice type of response. Such questions can unnecessarily constrain the answer so that the requirements discussion misses an opportunity to discover (or invent) something that goes beyond the BA’s preconceptions. Of course, this doesn’t mean you can’t ever ask a question with a closed list of possible responses. Just make sure you aren’t prematurely constraining the exploration.
The last question I typically ask in a requirements elicitation discussion is, “Is there anything else I should be asking you?” This is an example of a metaquestion, a question about a question. I freely admit that I don’t know all the right questions to ask. Sometimes the person of whom I’ve asked this question realizes that we haven’t yet discussed some important topic. I simply didn’t know enough to bring it up.
I use this same question in daily life. A few years ago I had new kitchen counters installed in my house. I’d never done any home remodeling before and didn’t know that much about the process. Near the end of my discussion with a contractor, I asked, “Is there anything else I should be asking you about this job?” He thought for a moment and then brought up an issue we had not yet discussed. This is also a collaborative question to ask. It acknowledges that you rely on the expertise of other people to work toward a mutually satisfactory project outcome.
Business analysis is hard! Because it is intrinsically a communication-centric human activity, I don’t know of any shortcuts. Business participants in the requirements elicitation process can get frustrated by the number of questions the BA asks and how long the process can take. But that’s just the way it is. And it’s a whole lot cheaper and less painful to have those discussions before you’ve actually built the software.
Author Bio:
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is Software Requirements, 3rd Edition, co-authored with Joy Beatty (Microsoft Press, 2013).
[cta id=”7662″]
Follow-Up Q&A to The Agile Business Analyst Webinar
Wow! More people than ever showed up to the Enfocus Solutions Webinar Series last week when CEO John Parker presented The Agile Business Analyst. There were so many questions asked that we couldn’t even begin to answer them during the webinar.
The original plan was to publish the Q&A as a blog post, but there were just way too many questions to do that! So, below are a few of our favorites. All answers were provided by the webinar presenter, John Parker.
It was really hard to pick just a few. If you’d like to read the answers to all of the questions asked, download the complete Q&A.
Q: How do we keep track of the changes made in a system if we don’t document them?
A: The changes are documented with user stories, maintaining clean code, and writing an efficient level of system documentation. Agile does not mean “producing no documentation.” Agile documentation is lightweight and sufficient.
Q: What do you recommend for system documentation that must be maintained? At the end of the day, organizations need a document outlining business process, business rules, data rules, etc.
A: This information is usually maintained in a collaborative business architecture and maintained separately from the team. When an Epic is defined, necessary changes to the business architecture are identified as change impacts. These changes are further refined as Epics are decomposed into Features. Stories simply represent changes to the business architecture. I did not discuss all of this in the webinar, but this is a key part of agile portfolio and program management.
Q: How do you make agile work with a global workforce? Our developers are in India, but all the other resources are positioned all over the globe.
A: Great question and one that is faced by many organizations. Here are some recommendations:
- Use a scaling framework such as DAD or SAFe to support complex issues such as integration between teams and distributed teams.
- Organize Teams into Agile Release Trains (ARTs) to support all activities within a given value stream.
- Separate product management functions from Product Owner responsibilities. Product Managers work with business stakeholders and Product Owners work with the Teams. The Product Manager and Product Owner will work closely together.
- Use an automated tool such as Enfocus Requirements Suite™ to support collaboration between teams and business units.
- Perform Inspect and Adapt activities to monitor quality.
- Each team needs to work on fixed cadence using predefined sprints and have a demo at the end of each sprint to demonstrate progress.
Q: Are [user story] conversations documented? How are they tracked?
A: Most agilests will tell you it is not important to document conversations, as the real measure for agile is working software and not documentation. The real intent of agile is face-to-face communications.
However, I do not totally agree with this position. Face-to-face communications are not always possible. Documented conversations are very important when you have distributed offshore teams, have time zone barriers, or have a lot of distrust between the business and the developers. They are also important when you have large teams with differing responsibilities. For example, if BAs are working on the team, they will generally document conversations with users and discuss them face-to-face with developers. This simply keeps things from falling through the cracks.
Q: What is the best tool to manage all these backlogs, stories, and tasks, and track the relation and connectivity?
A: We of course recommend our own tool, Enfocus Requirements Suite™, for portfolio and program level backlogs, and we recommend JIRA for team backlogs. The two tools work very well together and are fully integrated.
Q: When you’re talking about keeping the backlogs separate, how do you recommend accomplishing this for an enterprise level? The way I interpreted your discussion of the slide, you glossed over an enterprise (we’re [a state government], and our OIT covers so many major applications).
A: This is precisely why multiple backlogs need to be maintained separately. First, you might want to maintain a Statewide (OIT) portfolio backlog that contains business and architecture epics on a statewide basis. At the program level, you would probably want to have a backlog for each state agency. For example, Transportation is a completely separate program and value stream than Human Services. The programs need to integrate with multiple team backlogs, which may vary from agency to agency. Breaking it down this way can make agile very applicable for State Governments. Here are some basic guidelines:
- Use Epics to control governance and funding. Epics need to be approved by OIT.
- Use agile Inspect and Adapt methods to evaluate Epics and measurable results.
- Epics are broken into Program Epics and Features. This process is done at the agency level. For rare initiatives that cross multiple agencies, use Program Epics to break down the work.
- Break Program Epics into Features. Validate each Feature before building or coding it.
- If work is contracted out, define clear conditions of satisfaction for each Feature.
- Each team or contractor should maintain a separate backlog.
- Use Inspect and Adapt methods to manage vendor activities.
Q: We are still following waterfall, but are interested in exploring what agile has to offer. Where do we start if we want to begin our agile transformation?
A: A complete agile transformation requires a strategy. We recommend contacting us for a free needs assessment to get started on a strategy that will work for your organization’s current needs. The needs assessment is a great place to start because there is no obligation to buy our software and services. Our goal with the needs assessment is to provide some free advice and make sure you’re on the right track in your agile transformation.
If you need more help than a brief conversation can provide, we recommend Enfocus Solutions’ strategic set of consulting services. The goal of our services is to provide on-going assistance to organizations looking for guidance during an agile transformation. The services focus on four key areas:
- IT Service Strategy and Design—Integrate your existing agile processes with IT service strategy and design best practices according to ITIL. Enfocus Solutions will improve the way you understand customer needs and help you design better IT services.
- Business Analysis and Requirements Management—Business analysis is much more than just requirements development and management. The business analyst is poised to be an enabler of successful change in the organization. Enfocus Solutions will help your business analysis team expand their skillset to deliver more value to the organization.
- Business Change Management—Changes to the organization are capable of causing chaos. When change is transparently and collaboratively managed, customers and employees are happier with the outcome and more willing to go along with the next one. Enfocus Solutions will help you to collaboratively manage your business architecture to make sure there are no surprise or unwanted changes.
- Enterprise Agile Transformation—Everyone seems to be making the switch to agile, but where do the project managers and business analysts fit in? Enfocus Solutions will help transform your project management and business analysis processes to work in an agile environment.
Download a list of all the questions and answers from the webinar here.
[cta id=”7662″]
The Business Analyst as Explorer (Part 2 of 6): Eliciting Business Requirements
We explore business requirements to gain a shared understanding of the business opportunity being created or exploited, the organization’s business objectives, success criteria, product vision, and project scope boundaries. Business requirements answer the question, “Why are we undertaking this project?” Some organizations use the term “business requirements” to refer to any requirements received from the business, but I’m specifically using that term to refer to the objectives the business has that led to launching a software project in the first place.
The project manager has a strong interest in determining the business requirements. Perhaps the first question the project manager and the business analysis must assess for a proposed requirement is whether it’s in scope for the overall project. It’s impossible to make this judgment until the scope has been determined based on the business objectives. If a proposed requirement is out of scope, the PM and BA don’t need to think it about any more. (However, you don’t want to lose sight of the fact that someone once proposed that requirement, because it might come back into scope in the future.) If the requirement is in scope for the project, though, the PM will need to allocate it to a specific release or iteration. These sets of allocated requirements determine the scope for each planned iteration.
If some new requirement request for a particular iteration comes along later, as it inevitably will, the PM must evaluate that requirement’s priority against the backlog of work already allocated to that iteration. Do you defer that new requirement to a later iteration, bump a lower priority allocated requirement to a later iteration, or consciously increase the scope of the iteration by adding the new requirement to it? You can’t just keep cramming more functionality into a planned iteration and expect to get it done on the original schedule. Serious, ongoing prioritization is essential to effective scope management, and it demands clearly defined business requirements. This process requires collaboration between the BA, the PM, and appropriate customer representatives.
Sources of business requirements include senior managers, marketing managers, funding sponsors, product visionaries, and others who know the rationale and business drivers for the project. Such folks might already have established their business requirements, perhaps in a project charter or a business case document. In other situations, though, it can be helpful to have a skilled BA work with the right people to elicit this vital knowledge. Following are some questions to consider asking if you’re a BA working with the holders of the business requirements.
What business problem are you trying to solve? This helps align subsequent requirements development and software development activities with the right objectives.
What’s the motivation for solving this problem? Team members work together more effectively and more enthusiastically if they understand the rationale behind their work.
What would a highly successful solution do for you? Management should be able to state the benefits they and their customers will receive from the product.
How can we judge the success of the solution? People often don’t think about how they will determine whether some enterprise has been successful. Contemplating this evaluation early on helps crystallize the stakeholders’ thinking about objectives and steers the project toward a clearly successful outcome. Project success criteria are the subject of Chapter 4 of my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007).
What’s a successful solution worth? Whenever possible, quantify the business outcomes. All projects involve some cost–benefit analysis. Understanding the potential return in meaningful units helps participants make cost-effective decisions.
Who are the individuals or groups that could influence this project or be influenced by it? This question seeks to identify potential stakeholders in the project. The BA might need to consult these stakeholders to understand their interests in the project, their expectations, and the nature of their involvement. Stakeholders could be internal to the project, internal to the organization, or external to the organization. And you can bet that your stakeholders will have conflicting objectives, requirements, and priorities.
Are there any related projects or systems that could influence this one or that this project could affect? Look for dependencies between projects and systems that need to be analyzed and accommodated. Sometimes apparently small changes can have vast ripple effects across multiple interconnected systems.
Which business activities and events should be included in the solution? Which should not? These questions help define the scope boundary. Modifying the established project scope is a business decision that has implications for cost, schedule, resources, quality, and tradeoff decisions.
Can you think of any unexpected or adverse consequences that the new system could cause? Consider whether certain individuals, organizations, customers, or business processes could experience a negative impact from the system or product being developed. For example, a new information system that automates a process that has been performed manually in the past could threaten the job stability of the people who perform that process. Employees might need retraining, or their job descriptions could change, both of which could lead to resistance to the project and unwillingness to cooperate.
As you gain experience with these sorts of dialogues, you’ll build a set of your own questions that you find helpful to pull out the key information. You might write those kinds of questions down on index cards. When you find that an elicitation discussion is stalling out or nearing an end, randomly pull out one of those cards and see if the question on it has already been addressed. If not, the question just might help you surface another tidbit of knowledge that will help you plan the project and keep it on track.
Author Bio:
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is Software Requirements, 3rd Edition, co-authored with Joy Beatty (Microsoft Press, 2013).
[cta id=”7662″]
The Business Analyst as Explorer (Part 1 of 6): An Inquiry, Not an Inquisition
Many years ago, my manager, Jerry, sat in on a discussion I had with a customer named Steve to explore his requirements for a new application. After the meeting, Jerry pointed out that I had been rather aggressive in my questioning of Steve. He was right. I hadn’t realized how hard I’d been pressing Steve to make up his mind on certain points and tell me exactly what he wanted. Fortunately, when I contacted Steve to apologize, it was clear that he wasn’t offended. Nonetheless, our discussion probably felt like an inquisition to Steve, rather than an inquiry into what he was asking us to build. Not the best strategy for a business analyst to take.
Another extreme approach to requirements elicitation is for the business analyst simply to record whatever the customer says and pass that information on to the developers. This doesn’t work very well, either. As with most things in life, the appropriate behavior lies in between the possible extremes.
Requirements elicitation is a process of exploration and discovery, not just collection (which is why I don’t talk about “gathering requirements”), and the BA is the guide. BAs need to recognize that customers won’t be able to present all their requirements in a single workshop or discussion. They probably don’t even know what their real requirements are yet. Elicitation requires multiple cycles of refinement, clarification, and adjustment as the participants move back and forth between high-level concepts and specific details.
This series of articles describes some questions a BA might consider asking during elicitation discussions—as well as some to avoid. The articles are adapted from my book More About Software Requirements (Microsoft Press, 2006). A classic resource of good questions for discussing requirements for any type of project is Exploring Requirements: Quality Before Design by Donald Gause and Gerald Weinberg (Dorset House Publishing, 1989). Roxanne Miller also suggests hundreds of questions to help the BA with elicitation of nonfunctional requirements in her book The Quest for Software Requirements (MavenMark Books, 2009).
But First, Some Questions to Avoid
The worst question you can ask during a requirements discussion is “What do you want?” The second-worst question is “What are your requirements?” No one knows quite how to answer these questions. Customers and other elicitation participants might not share the BA’s understanding of what the word “requirement” even means. When customers attempt to answer these questions in good faith, they typically generate a large number of random—yet important—thoughts.
I’ve observed this in some of my training classes, in which small groups of students conduct a practice requirements elicitation workshop on a sample project called the Cafeteria Ordering System. The groups are trying to learn how to employ use cases to explore user requirements. One member of each group plays the role of a user who would employ this system to order meals. Some groups begin by asking this student, “What do you want?” because this is how they’re accustomed to launching requirements discussions. They typically get responses such as:
- I need to be able to pay by either credit card or payroll deduction.
- I want to be able to order group meals for lunch meetings.
- The system has to be available from home as well as from work.
- I’ll have to submit delivery instructions for my meals.
- I shouldn’t have to pay any delivery charges.
- Can contractors order meals or just employees?
- I want to be able to order meals at least a week in advance.
- It would be nice if I could easily reorder the same meal I ordered sometime in the past.
- Could I get nutrition information for a whole meal?
These are unquestionably important thoughts and ideas. However, when asked “What do you want?” the workshop participants tend to spew out these thoughts in a random sequence with no organizing structure. This makes it hard for both the BA and the customers to know what the information means, what to do with it, where to store it, and what to discuss next. The student groups who take this approach invariably flounder in the sea of random input. In contrast, those groups that grasp the use case approach early on make much faster progress. An important BA skill is to structure the dialogue and ask questions that will guide elicitation participants through progressive layers of refinement in an organized fashion.
The BA should remember his role as a neutral facilitator. We all filter what we hear through our own biases, preferences, experiences, and hot button issues. Avoid asking leading questions that steer customers to agree with your own intentions. Also avoid overruling a customer’s idea just because it doesn’t agree with your own point of view. I once observed a 60-participant “voice-of-the-customer” workshop that one of my consulting clients conducted to explore requirements for a major new product. The workshop facilitator was the senior manager responsible for the product. He had strong opinions about the project’s direction and didn’t hesitate to steer the discussion toward his predetermined outcomes. This is discouraging for participants, who will feel that they’re wasting their time if the facilitator already knows what the answers will be.
In the next installment in this series, I’ll explore some questions that are helpful for eliciting business requirements. These requirements define the organization’s business objectives for undertaking the project, define the product vision, and enable scope definition and management.
[cta id=”7606″]
There’s More to Being Agile than Agile Software Delivery
When the term “agile” comes up in a conversation these days, the mind often jumps to agile software development.
But there’s so much more to being agile than delivering software products iteratively and incrementally.
If our planning or change strategies aren’t agile, we can forget about being able to deliver the maximum amount of business value possible to our customers. Our entire organization must be agile in order to be able to “keep our finger on the pulse” and rapidly adapt to meet today’s demands.
On top of being agile, the most successful organizations out there are also lean mean machines, capable of effectively managing the portfolio to avoid surprises and respond to threats quickly and efficiently.
In our webinar last month, The Path to Business Agility, Enfocus Solutions’ CEO John Parker discussed the four components that make up a lean agile business:
Enterprise Agile Delivery
The agile organization must have the ability to deliver products and services iteratively and incrementally based on discovered and validated customer needs.
Agile software delivery is usually the first place organizations start when adopting agile. Many organizations have yet to move onto implementing agile in other areas of the organization, and limit their focus to the responsibilities of the agile team. In reality, the agile team only makes up one part of Enterprise Agile Delivery, and Enterprise Agile Delivery only makes up one of four fundamentals that must be addressed for the organization to be considered agile. In the Lean Business Agility Framework, Enterprise Agile Delivery is achieved via three key elements:
- Agile Teams (Scrum or Kanban)—Support day-to-day work of self-organized teams (using either Scrum or Kanban) to reduce cycle times and defect density.
- Agile Portfolio and Program Management—Implement Agile Portfolio and Program Management to deliver more business value and provide more transparency.
- DevOps—Manage DevOps to increase visibility and coordinate release management across multiple teams at once.
Customer Needs Validation
The agile organization must be able to understand who their customers are, what the customers’ needs are, and whether those needs are true or not.
According to the 2013 Standish Group CHAOS Report, even in the agile world, 64% of functionality is rarely or never used. That’s because organizations are giving the go-ahead to start developing software before getting an accurate understanding of customer needs. While traditional lengthy requirement gathering processes are a thing of the past, there’s still a need for performing minimal front-end analysis before starting to build anything. Unfortunately, most organizations don’t even do the minimum. But in order for the organization to be lean, we need to get rid of the waste of developing features and functions that are of no use to our customers, and that’s going to require iterative and incremental discovery and validation activities. The three key elements of successful Customer Needs Validation include:
- Customer Discovery—Discover customers and understand their problems to gain a competitive advantage by being able to deliver products that customers want.
- Customer Validation—Validate customer needs before building to reduce developer frustration and costs.
- Customer Experience—Understand and enhance the customer experience to improve customer loyalty.
Service Strategy and Design
The agile organization must have the ability to design services and manage the service portfolio according to a service strategy aligned with customer needs.
Enfocus Solutions has found that the concepts and best practices of agile and the Information Technology Infrastructure Library (ITIL) work really well together. That’s because, when you get down to it, isn’t software just a more specific term for a type of service being provided to your customers? For example, is an Apple iPhone a product or a service? We see it as a service. When you purchase an iPhone, it includes support, delivers content, and answers questions such as, “Siri, where is the nearest donut shop?”
By applying agile principles to ITIL best practices, we are able to design and manage a cost-effective IT service portfolio that improves business and customer outcomes. The key to Service Strategy and Design is addressing the following three elements:
- Service Portfolio Management—Identify service enhancements and manage the service portfolio to satisfy customer needs.
- Service Delivery Model—Develop a Service Delivery Model that will increase efficiency and significantly reduce costs.
- Service Design—Improve service design processes for better alignment between IT and the business and greater customer loyalty.
Business Change Management
The agile organization must have the ability to manage the effects of service changes on the entire organization.
When a new software feature gets delivered to the organization, the size of the effect potentially ranges from minimal to enormous, depending on what gets developed. When we don’t track the impact that software changes have on the rest of the organization, we often end up with some unpleasant surprises come delivery time. In a large organization, business processes, IT services, people, data, rules, and other capabilities may be affected by a software change. It’s our responsibility to ensure that the right parts of the organization are involved in supporting the necessary business changes. The three key elements to successfully performing Business Change Management include:
- Collaborative Business Architecture—Collaboratively manage the business architecture to make informed decisions, increase transparency, and establish a common vocabulary.
- Impact Analysis—Manage change following Lean best practices to achieve faster and wider user adoption.
- Lean Change Management—Assess impacts, gaps, and risks in the portfolio to avoid surprises and respond to threats and opportunities more quickly and effectively.
Strategies for achieving business agility are discussed in our white paper, The Four Components of Lean Business Agility, available soon. Sign up for the eNewsletter on the home page to make sure you get a copy.
[cta id=”7620″]
Creating a Culture that Respects Requirements
Written by Karl Wiegers and Joy Beatty
The leader of a corporate requirements organization once posed a problem. “I’m experiencing issues in gaining agreement from some of our developers to participate in requirements development,” she said. “Can you please direct me to any documentation available on how developers should be engaged in the requirements process so I can help them understand the value of their participation?” In another organization, a BA experienced a clash between developers seeking detailed input for an accounting system and an IT manager who simply wanted to brainstorm requirements without using any specific elicitation techniques. “Do readers of your book risk cultural conflict?” this BA asked.
These questions exemplify the challenges that can arise when trying to engage BAs, developers, and customers in a collaborative requirements partnership. You’d think it would be obvious to a user that providing requirements input makes it more likely that he’ll get what he needs. Developers ought to recognize that participating in the process will make their lives easier than being hit on the head by whatever requirements document flies over the proverbial wall. Obviously, not everyone is as excited about requirements as you are; if they were, they’d probably all become business analysts!
Culture clashes frequently arise when teams are working on requirements. There are those who recognize the many risks associated with trying to develop software based on minimal or telepathically communicated requirements. Then there are those who think requirements are unnecessary. It can be tough to gain business-side cooperation on projects like legacy-system replacement if users see this as unrelated to their own business problems and not worth their time. Understanding why people resist participating in requirements development is the first step to being able to address it.
It’s possible that the resisters haven’t been exposed to solid requirements practices. Or they might have suffered from poor implementation of requirements processes, perhaps working on a project that produced a large, incomplete, and ignored requirements specification. That would leave anyone feeling frustrated. Perhaps the resisters don’t understand and appreciate the value of those practices when performed effectively. They might not realize the price they have paid for having worked in a casual and unstructured environment in the past. That price mostly shows up as unexpected rework that leads to late deliveries and poor software. Such rework is buried in the daily activities of the project participants, so they don’t recognize it as a serious inefficiency.
If you’re trying to get developers, managers, and customers on board, make sure everyone understands the past pain the organization and customers have experienced because of requirements problems. Find specific examples to demonstrate the impact in case individuals haven’t felt the pain themselves. Express the cost in units that are meaningful to the organization, be it dollars, time, customer dissatisfaction, or lost business opportunities. Development managers often aren’t aware of how badly requirements shortcomings hurt their teams’ productivity. So show them how poor requirements slow down design and lead to excessive—and expensive—course corrections.
Even if you don’t have data available to quantify the costs of requirements problems, every organization has an anecdotal legacy of project failures. People remember systems that were dead on arrival, rejected by users as unacceptable. Isn’t it strange how project teams never feel that they have the time to devote to getting the requirements right, and yet they always find the time, staff, and money to fix systems that were deeply flawed because of requirements errors? Use such stories from the corporate folklore to help steer the culture to a recognition that, without solid requirements, failure is highly likely.
Developers are stakeholders in the project, but sometimes their input isn’t solicited and they become the “victims” of the requirements that are thrust upon them. Therefore, they benefit from providing input that will make the requirements documentation as useful and meaningful as possible. I like to have developers review requirements as they are evolving. That way they know what’s coming and can spot areas that need more clarity. You also need developer input when specifying internal quality attributes that aren’t visible to users. Developers can offer suggestions no one else might have thought about: easier ways to do certain things; functionality that would be very expensive to implement; unnecessary imposed design constraints; missing requirements, such as how exceptions should be handled; and creative opportunities to take advantage of technologies.
Quality assurance staff and testers are also valuable contributors to excellent requirements. Instead of waiting until later in the project, engage these sharp-eyed people in the iterative review of requirements early on. They’re likely to find many ambiguities, conflicts, and concerns with the requirements as they are developing their test cases and scenarios from the requirements. Testers can also provide input on specifying verifiable quality attribute requirements.
Management plays a powerful role—often the dominant role—in shaping the culture of an organization. The organization’s leadership must understand the need for the organization to have effective business analysis and requirements engineering capabilities as strategic core competencies. Though project-specific and localized grassroots efforts are important, without management commitment, the improvements and benefits likely won’t be sustained after the project ends or after a reorganization. It doesn’t help if your senior people say they “support” the improvements but then revert to the same old processes the minute there is a fire. Behaviors—not pronouncements—constitute evidence of commitment to quality. Figure 1 lists ten signs that your organization’s management is truly committed to excellent requirements processes.
Figure 1. Some behaviors that indicate management’s commitment to excellent requirements processes.
Resistance to process or culture change can indicate fear, uncertainty, or lack of knowledge. If you can discern the source of the resistance, you can confront it with facts, reassurance, clarification, and education. Show people how their constructive participation in the requirements process not only is in their personal best interest but also will lead to collectively better results.
[cta id=”7441″]
Introduction to the Lean Business Agility Framework™
Business agility is more important now than ever, according to a recent report by Forrester Research. In the report, they define business agility as “the quality that allows an enterprise to embrace market and operational changes as a matter of routine.” As Forrester astutely points out, seventy percent of the companies that existed on the Fortune 1000 list ten years ago are no longer in service—the number one cause being the inability to adapt to change.
Many organizations have adopted agile methods for software or product development. Agile methods have helped organizations deliver more rapidly, increase customer satisfaction, and improve quality. However, agile development alone does not make the enterprise agile. An agile business must be able to make rapid changes that affect people, processes, data, technology, and rules to support threats and opportunities in the market.
The Lean Business Agility Framework™ is here to guide you through choosing the methods that will enable change and achieve business agility in your organization.
There are many great existing frameworks and methodologies for implementing agile best practices. However, the Lean Business Agility Framework combines all best practices into one comprehensive guide. The Lean Business Agility Framework was developed by Enfocus Solutions to help organizations visualize what is needed to transform to an agile enterprise. The framework incorporates current trends and integrates various methods from sources such as the Scaled Agile Framework® (SAFe), ITIL®, Lean Thinking, and Lean Startup® into a cohesive approach for moving to business agility. The framework is intended to serve only as a guide and requires an organization to selectively choose the methods that best fit their organization based on their level of maturity and culture.
For a full-size version of the Lean Business Agility Framework, download the white paper.
Inspired by the Scaled Agile Framework, The Lean Business Agility Framework takes the three levels from SAFe®, front-ends them with a Strategy Level, and back-ends the SAFe® levels with Business Change. In total, there are five levels in the Lean Business Agility Framework:
- Strategy
- Portfolio
- Program
- Team
- Business Change
This blog will summarize the five levels of the Framework and the suggested methods of achieving each level’s specific goals. For in-depth descriptions of each of these levels, download the white paper.
Strategy Level
Before developing a service to be delivered to customers, we need to understand who our customers are and what they need (not just what they want). This requires developing a set of hypotheses and assumptions about our customers and the service offerings necessary to meet their needs. Then, we focus on designing services that are guaranteed to meet their needs, and develop value stream maps to visualize the value delivered by the designed services.
Suggested Methods
- Customer Development
- Service Portfolio Management
- Service Design
- Value Stream Mapping
Portfolio Level
We need to ensure the solutions we innovate align with discovered customer needs. The goal of this level is to develop an Epic Backlog that satisfies customers’ unmet needs. After an Epic is defined, we must understand its associated impacts, gaps, and risks to ensure we can successfully deploy the new software to customers. These tasks are made easier with a supporting collaborative business architecture that establishes a common vocabulary, vision, and degree of transparency that is required to make agile work. At the Portfolio Level is also where we align budgeting and accounting tasks with our Lean and Agile goals by providing our accountants with special Lean tools.
Suggested Methods
- Innovation Management
- Impacts, Gaps, and Risks
- Lean Budgeting and Accounting
- Value Flow Management
- Collaborative Business Architecture
Program Level
We start at the Program Level with breaking up Epics into Features that meet customer needs and have the ability to be independently developed and deployed. As we do this, it’s important to keep in mind the Plan-Do-Inspect-Adapt cycle to iteratively and continuously improve our product or service. Our goal is to deliver a continuous stream of value to the customer throughout many releases.
Suggested Methods
- Discovery
- PDIA: Plan-Do-Inspect-Adapt
- Release Planning and Management
Team Level
At the Team Level, we focus on developing the software and assessing progress throughout the development lifecycle. We use an “inspect and adapt” approach to improve quality and reduce time to market.
Suggested Methods
- Agile Product Development
Business Change Level
Agile change agents and Lean best practices such as the Lean Change Canvas replace the traditional organizational change approaches followed by waterfall or plan-driven organizations. We use the Lean Change method developed by Jeff Anderson, which is an approach based on learning, co-creation, and experimentation. We don’t leave stakeholders out of the loop—in fact, we negotiate changes with stakeholders that will be impacted by proposed changes.
Suggested Methods
- Lean Change Canvas
- Negotiated Changes
- Kanban Management
- Validated Learning
All of the levels of the Lean Business Agility Framework, as well as the suggested methods for being successful on each level, are described together in our white paper, the Lean Business Agility Framework.
[cta id=”7620″]
The Six Blind Men and the Requirements: Part Four — Selecting Appropriate Views
There is no single correct way to document specific requirements information. Every BA needs a rich tool kit of techniques at her disposal so that she can choose the most effective requirements view in each situation. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I offer some ideas about how to make that choice.
Often, it’s valuable to represent information at both high and low levels of abstraction. The high level offers a big-picture perspective, whereas the low level of abstraction presents the nitty-gritty details. Certain audiences only need the high-level view, whereas developers and testers do need to see all those specifics, as well. An effective requirements analysis technique is to create an alternative view of the requirements from the initial set of information and examine it for problems.
Here’s an actual example. I once reviewed a requirements specification for a client who was developing the firmware for a device for testing integrated circuit components. The spec contained a long table that listed the various states this device could be in and what behaviors lead to changes from one state to another. Table 1 shows a portion of this table. I needed to know if all possible states were described and that the allowed state changes were all correctly specified. But how could I judge that? Missing requirements are hard to spot precisely because they don’t exist.
I decided to draw a state-transition diagram from the information in the original table, which appears in Figure 1. A state-transition diagram is a simple analysis model that provides a high-abstraction view of such a system. It shows the various states the system could be in at a given time (rectangles), the permitted transitions between states (arrows), and the conditions and actions that lead to each transition (could be written on the arrows if desired). Other conventions have similar notations variously called a state machine diagram, statechart diagram, or simply a state diagram.
Sure enough, I found some problems with this diagram, shown with the dotted red lines in Figure 1. First, the table contained no functionality to get to the Off state! That is, I expected to see an arrow in the diagram going from Shutdown to Off, but I found no requirement to make this happen. Also, the table didn’t mention the possibility of an error occurring while in the Running state. Thus, by creating this second view as an analysis tool, I identified a couple of missing requirements. Better now than later, I always say.
Table 2 suggests techniques that are appropriate for representing various types of information at both high and low levels of abstraction. Chapter 12 of my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) provides more details on many of these methods and contains references to additional sources to learn about these techniques. Use this table to help you select appropriate techniques for documenting your requirements information.
[cta id=”7463″]
The Six Blind Men and the Requirements: Part Three — Some Alternative Requirements Views
An effective business analyst doesn’t just “write requirements.” Instead, the BA should think about the most appropriate way to represent requirements-related information in a given situation. Besides the traditional default of writing natural language statements, the BA should determine when a picture or some other representation would be valuable. This article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), briefly describes some alternative types of requirements views to consider.
Analysis Models
Analysis models are diagrams that present information visually. The table below lists several of the graphical analysis models that are available to the BA. Some of these date back to the structured analysis movement of the 1970s and 1980s. Others are part of the Unified Modeling Language, which provides a rich set of conventions for object-oriented analysis and design. I don’t have the space to describe these various techniques in detail here. See my book with Joy Beatty titled Software Requirements, 3rd Edition (Microsoft Press, 2013) for descriptions and examples of several of these—and other—modeling notations.
Note that some requirements authors use the term model to describe any method for representing requirements information, including a list of textual functional requirements. When I say model or analysis model, I’m referring to a diagram that represents requirements information visually, generally at a higher level of abstraction than written requirements offer. I highly recommend that you use standard notations when drawing these kinds of diagrams. There are enough types of models in the software literature to cover nearly every situation, so you should almost never have to invent a new kind of diagram. Remember that these are communication tools. If you make up your own kind of picture using some other language of symbols, no one else will know how to read it. This rather defeats the purpose of communication. Instead, take the time to learn about the various modeling notations. You can practice with them by documenting an existing system, so you learn which types of models are useful for showing certain kinds of information.
Decision Tables and Decision Trees
These are tabular and graphical techniques, respectively, for representing complex logical expressions (such as a sequence of if/then statements) and the associated system behaviors. They are a great way to ensure that you have written requirements to cover the system’s behavior with all logical combinations of conditions. Complex logic often leads to missing requirements because certain combinations of ANDs, ORs, ELSEs, and NOTs were overlooked. Decision tables and trees are particularly good techniques to spot exceptions whose handling hasn’t been specified.
Test Cases
Functional requirements describe the behavior of the software to be built. Test cases describe ways to determine if the correct requirements have been implemented properly. Functional requirements and test cases represent two complementary ways of thinking about the software system. The first is from a constructive perspective (let me describe how to make it), and the second is from a destructive perspective (let me try to break it).
One school of thought maintains that detailed written requirements aren’t necessary; user acceptance tests provide an adequate description of what needs to be built. I prefer to think of specifications and test cases as being complementary views of the requirements. Thinking about the system from both perspectives often reveals inconsistencies and gaps in the BA’s and user’s knowledge.
Prototypes and Screen Designs
When prototyping, the BA is taking a tentative step from the requirements domain into the solution space. A prototype is like an experiment. It tests the hypothesis that the requirements you have developed to date are accurate and complete. Most people find it more insightful to work with a prototype than to read through a long list of functional requirements. A prototype serves as a tangible first cut at some portion of the possible product.
A low-resolution prototype, such as a wireframe, provides the gist of the proposed user interface, whereas a high-resolution prototype presents detailed screen designs. However, even a detailed visual prototype does not depict the details hidden behind the presentation layer. A prototype doesn’t show input field interactions or describe how the system processes input stimuli to produce output responses. As with analysis models, a prototype is a useful but insufficient means of “documenting” requirements; you still need to record the details somewhere.
Tables and Structured Lists
If multiple requirements are worded similarly except for a particular change from one requirement to the next, consider grouping them in the form of a table or a structured list. Grouped requirements are more maintainable because a global wording change need be made only once. This is more concise than writing out all the individual requirements in detail, and the differences between the similar requirements will be obvious. For traceability purposes, each item in a list should receive a unique identifier. Following is a set of similar requirements from an actual SRS, shown in the original style (bulky, repetitive, and eye-glazing) and then as a much more compact structured list. The list form more efficiently communicates the same information and still provides a unique label for each requirement.
Before:
SGML.Insert.23: The product shall provide a facility that will insert SGML data corresponding to signature block formats selected by the user from among a set of available boilerplate signature blocks.
SGML.Insert.24: The product shall provide a facility that will insert SGML data corresponding to leaveout formats selected by the user from among a set of available boilerplate leaveouts.
SGML.Insert.25: The product shall provide a facility that will insert SGML data corresponding to caption formats selected by the user from among a set of available boilerplate captions.
After:
SGML.Insert: The product shall provide a facility that will insert SGML data selected by the user from among a set of available boilerplate formats for the following:
.23: Signature blocks
.24: Leaveouts
.25: Captions
Mathematical Expressions
Mathematics provides a precise, concise, and unambiguous language for represent certain types of knowledge, particularly that associated with performing computations. Some types of computational information are better represented in the form of tables. Two examples are interest rates as a function of investment bond term and discount percentages applied to volume purchases of a product.
Always keep in mind that specifying requirements is a communication process. Every BA should develop a rich toolkit of techniques for representing information effectively. If natural language is the best technique in a particular situation, fine: use it. But first ask yourself whether some other method, either by itself or in conjunction with the text, will do the job better.
[cta id=”7434″]
The Six Blind Men and the Requirements: Part Two — Why Create Multiple Requirements Views?
If you create only one view of the requirements, you must believe it. You have no other choice. If you develop multiple views, though, you can compare them to look for disconnects that reveal errors and different interpretations. There’s an old saying, variously attributed to the Swedish Army, the Swiss Army, the Norwegian Boy Scouts, a Scottish prayer, and a Scandinavian proverb: “When the map and the terrain disagree, believe the terrain.” Unfortunately, we have no absolute “terrain” for requirements: every representation is a map! Even though you can’t tell which representation is correct, differences between them indicate problems. In this article, adapted from my book, More About Software Requirements (Microsoft Press, 2006), I’ll explain the value of creating more than one view of your requirements.
Consider the figure below. A use case presents a high-level view of requirements from the user’s perspective. It describes some goal the user needs to accomplish with the help of the system, expressed as a sequence of interactions between a user and the system that leads to an outcome of value. A primary purpose of the use case technique is to help the BA derive the functional requirements that developers must implement to let users perform a use case. These functional requirements represent a second, more detailed view. The BA might also draw graphical analysis models, diagrams that represent additional views of the requirements. The BA should be able to relate the functional requirements to elements shown in the models to make sure that these complementary views agree.
Suppose a tester were to write some test cases—thereby creating yet another view of the requirements—based on the use case. Now the BA can compare the test cases with the functional requirements and the analysis models to look for mismatches. You might find that a particular test case cannot be “executed” with the current set of functional requirements. (Note that you don’t even have to have any executable software to benefit from this sort of conceptual testing.) Or you might discover that a specific functional requirement is not covered by any test case. Such disconnects can reveal missing and unnecessary requirements, as well as missing and incorrect test cases.
Ambiguities, assumptions, or missing information in the use case description can lead the BA and the tester to different conclusions, which they can find by comparing the various views derived from the use case. Every time I’ve performed this kind of comparison between test cases, functional requirements, and other views, I have discovered errors. Fixing those errors at this stage is a whole lot easier than fixing them much later in the project.
Pictures, such as graphical analysis models, represent information at a higher level of abstraction than detailed text. It’s often valuable to step back from the trees and see the forest as a whole—the big picture. This is a valuable way to find missing and incorrect requirements. A reviewer could examine two pages of detailed functional requirements that seem to make sense, but he might never detect the one requirement that isn’t there or the one that is simply wrong.
Suppose, however, you draw a picture—a model—based on your mental image of how that part of the system ought to function. Then you compare the model to the list of requirements, and you find that a line from one object in the diagram goes to a different destination than the corresponding requirement says it should. Which is correct? The BA might not be able to determine which is right, but the difference between the two views points out a problem you need to resolve.
This high level of abstraction allows the reader to see how pieces of information fit together without getting mired in the gory details immediately. Of course, developers and testers eventually will need the details so they can do their jobs. Early in the days of structured analysis, the philosophy was that diagrams could completely replace the need for a detailed requirements specification. This simply doesn’t work. Models, prototypes, and the like are highly valuable, but they don’t contain all the information developers and testers need. Use high-abstraction models to supplement—not replace—textual specifications with an alternative communication vehicle.
Different people learn and comprehend information in different ways. Some people like to read, others prefer pictures, while still others learn best by listening or while manipulating something with their hands. To accommodate these different learning styles, try to depict information in a variety of ways. It’s not obvious how to help tactile learners examine a requirements specification, but multimedia can provide a rich communication experience. You can embed hyperlinks in a word-processing document to other types of objects:
- Sound clips that explain a particular concept.
- Video clips that illustrate how something works or how a user performs a task.
- Photographs that depict views of an object from various angles.
I see little use of hypertext in the requirements documents I review, yet hypertext is an excellent way to provide your readers with easy access to other related information. Consider incorporating links to reusable sources of common data definitions, user class and actor descriptions, glossary entries, business rules, and the like.
As with every other requirements technique, creating multiple views incurs a cost. In addition to expending effort to create the different views, the BA must keep them all current as changes are made. If the views get out of sync with each other, readers won’t know which one to believe (if any). This reduces the value of the multiple views. You might not need to update a high-level model every time you change some detailed functionality description, but you’ll probably need to revise the corresponding test cases. Don’t become a slave to the modeling, caught in the analysis paralysis trap of endlessly perfecting the pictures. In many cases, though, the cost of creating and maintaining multiple representations is more than outweighed by the insights into the requirements that different views offer and the errors they reveal early in the game.
[cta id=”7463″]