The Essential Practices for Business Analysis Success

Every project and product initiative succeeds or fails based on its requirements. You need some requirements even to build that first prototype. Requirements let you answer important questions, including: What are we building? Why are we building it? What will users be able to do with it? Which quality characteristics are most important? What features do we implement first, later, and maybe never?

My hefty 2013 book Software Requirements with co-author Joy Beatty describes 52 “good practices” for requirements engineering. Other books advocate even more requirements and business analysis practices, more than 100 in one book. While such comprehensive books are valuable resources, who can remember — let alone apply — all of those activities?

I’ve distilled those comprehensive lists down to the 20 core practices that are most vital to requirements — and hence project — success. These apply to every software and systems development or enhancement activity, conducted by project or product teams who are following either agile or traditional methods and building any type of product. These practices are described in my recent book with Candase Hokanson, Software Requirements Essentials.

As with all recommended practices, methods, and techniques, don’t follow this list blindly. Think through each practice and ask yourself, “Would doing this add value to our project? Would it reduce risk, keep us on track, improve quality, or speed things up? Could we get in trouble if we didn’t do it?” If the answers to those questions are all No, then don’t do it. Otherwise, it’s a pretty good idea.

Laying the Foundation

Practice #1. Understand the problem before converging on a solution. Don’t assume that any presented problem or solution is necessarily correct. Perform a root cause analysis to ensure that the team addresses the right problem and designs a solution to solve it.

Practice #2. Define business objectives. Business objectives tell you why you’re working on an initiative. They let you determine when a business problem is solved, a need is fulfilled, or an opportunity is exploited. Defining business objectives up front keeps the team focused on achieving the desired outcomes.

Practice #3. Define the solution’s boundaries. Defining boundaries lets everyone know which business processes, functions, and events will be part of the solution and which will not. Visual models like the context diagram and ecosystem diagram show what’s inside the solution, its external interfaces, and how the solution fits into the organization’s overall systems environment.

Practice #4. Identify and characterize stakeholders. If you overlook some of the people or groups who care about the project or can influence its direction, you’re likely to miss important requirements and constraints. Stakeholders can be inside the development team, inside the organization, or external to the organization. Identify and engage with those individuals who can authoritatively provide input on behalf of each stakeholder group.

Practice #5. Identify empowered decision makers. Identify the types of requirements decisions the team will face and the people who should be involved in making each one. Each decision-making group needs to select an appropriate decision rule so they can efficiently reach closure.

Requirements Elicitation

Practice #6. Understand what users need to do with the solution. Focus elicitation activities on usage, not on product features. Understanding what users need to accomplish with the product helps ensure that the team implements the correct features and doesn’t waste time building unnecessary functionality that just seems cool.

Practice #7. Identify events and responses. Both businesses and software systems respond to a variety of external events that trigger specific responses from a system under specific conditions. Techniques such as event-response tables and state-transition diagrams can ensure that no event/response combinations are overlooked.

Practice #8. Assess data concepts and relationships. Identifying data objects and the logical connections among them reveals the functionality needed to manipulate them. Entity relationship diagrams, data flow diagrams, and data dictionaries are good ways to document the team’s knowledge of the relevant data.

Practice #9. Elicit and evaluate quality attributes. To build quality into the product from the outset, requirements exploration needs to consider which of the many quality attributes are most important to stakeholder satisfaction and product success. You need to understand the stakeholders’ quality expectations so designers can make appropriate trade-off decisions among conflicting quality attributes.

Requirements Analysis

Practice #10. Analyze requirements and requirement sets. Some analysis activities examine individual requirements: decomposing them into details, identifying ambiguities and exceptions, defining acceptance criteria, and determining pertinent constraints, and business rules. Other activities evaluate sets of requirements for conflicts, gaps, dependencies, and priorities to reach a rich understanding.

Practice #11. Create requirements models. Visual analysis models represent requirements knowledge in the form of diagrams that complement textual requirements. Many valuable models are available to represent requirements information in different ways. Models often reveal problems that aren’t apparent from text.

Practice #12. Create and evaluate prototypes. Prototypes are partial, preliminary, or possible solution approaches that make abstract requirements more tangible. Various types of interaction design and technical design prototypes can reveal and validate previously unrecognized requirements before the team commits to a specific solution.

Practice #13. Prioritize the requirements. Prioritizing a set of requirements lets the team sequence their implementation to provide the maximum customer value in the minimum time. The decision makers allocate requirements to upcoming development increments based on their priority.

Requirements Specification

Practice #14. Write requirements in consistent ways. To facilitate effective and accurate communication — which is the goal of all requirements development work — it’s helpful to write requirements of different kinds according to consistent patterns. Representing requirements knowledge at different levels of abstraction — from high-level to detailed — helps to manage complexity.

Practice #15. Organize requirements in a structured fashion. You can use a variety of containers to store requirements information: documents, spreadsheets, requirements management tools, sticky notes, or whatever works for your team. Organize the information you store for easy access, understandability, and revision.

Practice #16. Identify and document business rules. Business rules — such as policies, standards, and regulations — are the source of functional and data requirements for software systems that must enforce or comply with the rules. Decision tables are a good way to document business rules that involve complex logic.

Practice #17. Create a glossary. A glossary of significant terms, abbreviations, acronyms, and synonyms helps make sure that all project participants understand these important concepts in the same way.

Requirements Validation

Practice #18. Review and test the requirements. Peer reviews and conceptual testing of requirements are both effective ways to allocate quality effort up front and prevent excessive rework due to requirements problems later on. Acceptance tests can flesh out requirement details, and testing models is much cheaper than testing code.

Requirements Management

Practice #19. Establish and manage requirements baselines. Teams can define either time-bound or scope-bound baselines as agreements of what functionality will be included in a given development iteration, a group of iterations, or a product release.

Practice #20. Manage changes to requirements effectively. Every team needs a defined process for proposing, evaluating, deciding about, and communicating the inevitable changes in requirements. Impact analysis is an important component of change management.

These 20 practices aren’t magic solutions to all of your project problems. However, they'll go a long way toward ensuring that your teams build the right solutions efficiently and effectively.

================

This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson. Karl is the author of numerous books on software development and other topics, including Software Requirements (with Joy Beatty), Software Development Pearls, and The Thoughtless Design of Everyday Things. Candase is a business architect at ArgonDigital. She has written numerous articles on best practices in requirements management and agile product ownership.