The 6 Most Important Requirements Practices

Written by Karl Wiegers on March 22, 2023. Posted in Articles.

Authors sometimes make things longer and more complicated than necessary. Some readers might feel that I’ve been guilty of this myself. The third edition of my book Software Requirements, co-authored with Joy Beatty, is about 245,000 words long, nearly 640 pages in a rather small font. Maybe that seems like overkill, but to be fair, the requirements domain is large and complex.

Books like Software Requirements, Mastering the Requirements Process by Suzanne and James Robertson, and the IIBA’s Business Analysis Body of Knowledge describe dozens of valuable techniques for requirements elicitation, analysis, specification, validation, and management. They’re all useful when thoughtfully applied in appropriate situations. But if you don’t have time to wade through these large volumes, you might like this TL;DR version of the six most important requirements practices that every project team should perform. This article is adapted from Software Requirements Essentials: Core Practices for Successful Business Analysis by Karl Wiegers and Candase Hokanson.

Practice #1: Define Business Objectives

Organizations undertake a project to solve a problem, exploit a business opportunity, or create a new market. Defining the project’s business objectives communicates to all participants and other stakeholders why they are working on the project. The organization could hope to achieve both financial and non-financial business objectives with the new product. Try to quantify the business objectives, and make them measurable, with statements like these:

Capture a market share of X percent within Y months.
Reach a sales volume of X units or revenue of $Y within Z months.
Save X dollars per year currently spent on a high-maintenance legacy system.

Using business objectives aligns all of the team’s work and key decisions. Without defined business objectives, you can’t craft a clear product vision statement or establish the scope of either the entire project or any development increment. The team can’t make good decisions about scope changes or proposed functionality unless they know how those changes match up with the business objectives.

Keeping the scope in focus helps the team avoid scope creep while still adapting to changing business realities. And how can you know if the project was a success unless someone defined its business objectives and success criteria up front?

Practice #2: Understand What Users Need to Do with the Product

I strongly advocate taking a usage-centric approach to requirements development and solution design, rather than a feature- or product-centric approach. Understanding the tasks that users need to perform and the goals they want to achieve lets the business analyst (BA) derive the functionality that developers must implement.

When you focus on exploring features rather than user goals, it’s easy to overlook some necessary functionality. It’s also easy to include functionality that seems cool but doesn’t help users get their jobs done. Use cases are an effective technique for maintaining this usage-centric mindset.

Seeking to understand what users need to do with the product implies several other important BA activities, including these:

Identifying a wide range of project stakeholders
Characterizing distinct user classes that have largely different requirements
Identifying individuals to serve as the voice of the customer for each user class (product champions)
Selecting appropriate requirements elicitation techniques to engage with users
Establishing decision-making processes to resolve conflicts and priorities across user classes
Building and evaluating prototypes or early releases to stimulate user feedback

Practice #3: Prioritize the Requirements

I doubt that any project has ever implemented every bit of requested functionality. Even if you could implement it all, you can’t do it all at once. Your goal is to deliver the maximum business value to your customers at the lowest cost and in the shortest time. Achieving this goal demands that you prioritize requirements so the team can work on them in the most appropriate sequence.

Prioritization involves considering how much each proposed requirement contributes to achieving the project’s business objectives. Prioritizing requirements lets the team decide which of the work items remaining in the backlog to defer or omit because of time and resource constraints. There are numerous requirements prioritization techniques available, including these:

In or out
Pairwise comparison and rank ordering
Three-level scale
MoSCoW
Relative weighting
$100 test

Some of these methods take more effort than others, but those methods also help the project manager or product owner make finer-grained choices. Choose any technique that lets the right stakeholders make good business decisions throughout the project to avoid a frantic “rapid descoping phase” late in the game.

Practice #4: Explore Nonfunctional Requirements

People naturally focus on a product’s functionality when discussing requirements, but those are only part of the solution. Nonfunctional requirements contribute heavily to user satisfaction and suitability for use. When speaking of “nonfunctional requirements,” people most commonly think of quality attributes, sometimes called the “-ilities.” These product characteristics include usability, maintainability, security, reliability, and many others. To help designers devise the most appropriate solution, BAs need to discuss nonfunctional requirements as part of requirements elicitation.

Developers generally don’t directly implement requirements that describe safety, reliability, portability, security, or other characteristics. Instead, these attributes serve as the origin of many functional requirements and drive design decisions. Table 1 indicates the likely categories of technical information that different types of quality attributes will generate.

Table 1. Translating quality attributes into technical specifications (from Software Requirements, 3rd Edition)

Another challenge is that it’s not possible to optimize all of the desired quality factors at once. Designers must make trade-off decisions among the various attributes. Therefore, the team needs to determine which ones are most important to customer success and optimize those. Carefully specifying quality attributes lets you build a product that delights its users, beyond merely doing what it’s supposed to.

Practice #5: Review the Requirements

How do you know if your requirements are accurate? How can you tell if they’re clear enough so all the team members know what to do with them and other stakeholders know what to expect in the solution? No matter how you choose to represent requirements knowledge, it is sometimes ambiguous, incomplete, or simply incorrect.

One of the most powerful quality practices available is peer review of requirements. Convene some colleagues to review both textual requirements and diagrams. Different project participants—BAs, designers, developers, testers, users—will find different kinds of problems during these reviews. Requirements reviews pose some particular challenges. Rather than simply inviting people to look over the requirements, provide some training so reviewers know how to participate effectively and can find as many issues as possible.

A related requirements validation practice is to write conceptual tests based on requirements. Testing requirements is something you can do early in each development cycle to reveal many errors before they are cast into code. Requirements and tests are complementary views of the same knowledge. Requirements describe how the product should behave under certain conditions; tests describe how to tell if it’s exhibiting the correct behaviors.

Practice #6: Plan for Requirements Change

No matter how well you understand the problem and how carefully you prepare the requirements, they won’t be perfect, complete, or static. The world changes around us as we work. New users and new ideas appear. Business rules surface and evolve. Projects inevitably grow beyond their originally envisioned scope. Every team must anticipate requirements changes and establish mechanisms for dealing with them without derailing the team’s commitments.

When you know the project outcome is incompletely defined and likely to change a lot, an incremental, agile approach is a good way to cope with it. You plan to build the requirements—and the solution—in a series of small chunks, expecting the direction to change and accepting the uncertainty of what you’ll have at the end and when you’ll have it.

When the likely degree of change is less extreme, plan to accommodate some growth (along with risks, imprecise estimates, and unexpected events) by building contingency buffers into development schedules. Establish a requirements change process so the right people can get the right information to make good business decisions about which proposed changes to incorporate to add value with minimal disruption.

Don’t use the expectation of change as a justification for skimping on requirements thinking, though. Excessive requirements churn often indicates that objectives were unclear or the elicitation approach wasn’t effective.

Neglect These Practices at Your Peril

Of course, there are many other valuable requirements activities besides these six. However, these practices greatly increase your chances of building a solution that achieves the desired business outcomes efficiently and effectively. Applying them doesn’t guarantee success for any BA, product owner, or product manager. But neglecting them likely ensures failure.

Do You Consider “Opportunity Cost” In Your Analysis?

Written by Adrian Reed on March 16, 2023. Posted in Articles.

I’m a fan of live music, and I particularly enjoy music festivals. If you’ve never been to a music festival, you’re missing out. They usually involve multiple days of listening to music, dancing and having fun. There’s often multiple stages so one challenge is deciding which bands to listen to.

I was reminded of this fact last summer when I bumped into a friend of mine (who is also a BA) at a music festival. It turned out that we’d both created (and printed) spreadsheets showing who was playing when at what time. My spreadsheet even used color coding with green being bands we planned to see, and yellow being ‘backups’ (in case the first choice was too full, or there was some other reason we couldn’t get there). Well, everyone loves a spreadsheet, don’t they?

Comparison and Opportunity Cost

Spreadsheets aside, this illustrates a point that is important in projects and product development initiatives too. Typically every action or decision has an opportunity cost associated with it. Taking one course of action means that it isn’t possible to pursue others (as time and budget is focused on the course of action that’s been chosen).

At a music festival, the opportunity cost is fairly easy to calculate. If I see Band A on the main stage at 8pm, I can’t see Band B on another stage at the same time. I also can’t go to the bar (probably for the best), nor can I grab an overpriced hotdog. The act of deciding on an action means that other options are no longer open to me.

The same is true when it comes to deciding which projects to progress, which features to focus on, or which requirements to prioritize. When writing an options paper, it’s usual to consider the impact of ‘doing nothing’, but in some cases it may be worth extending the thinking even further and considering what else could be done with the time and money.

When prioritizing requirements, there are always trade-offs. It’s desirable to deliver the features first that will enable the most benefit to be realized. This is certainly true, and this is something that I’m sure we all aspire to… but in reality aren’t things often a bit more complicated than that? There’s often resource contention (multiple development and testing teams, often with limited resources), organizational level challenges (code freezes, budget changes) and a whole load of other opportunities and threats outside of the immediate orbit of the project.

Sometimes It Makes Sense To Do The Second Best Thing

There might be cases when it actually makes sense to do the second most beneficial thing. Imagine there’s a high priority set of requirements. Everyone agrees those will yield the most benefit. However, the technical experts that need to work on them are also needed to work on some essential maintenance. Although systems maintenance and the art of ‘keeping the lights on’ is never as glamorous as delivering new features, it’s still super important.

Within the project, the logical decision is to go for the highest priority requirements. But, there’s an opportunity cost for the organization. If that action is taken, the maintenance is delayed. That might be a very bad idea, depending on the nature of the maintenance.

The key point here is that progressing the second best thing for the project might actually be the best thing for the organization overall.

Know Which Decision Options Are “Perishable”

Some options available to us “perish” if they aren’t taken. If you’re at an airport and delay deciding whether to get on the plane for too long, your option to board that plane will eventually disappear (as it’ll have taken off without you). The same is true at a music festival, if Band A clashes with Band B, then you have a straight choice to make. Choosing Band A means you don’t see Band B at that festival.

These are different from prioritization decisions where you can do both things sequentially. Delaying requirement A so the team can do some urgent maintenance probably doesn’t mean that requirement A will never be delivered… it’ll just be delayed. There will be an impact on the timing of benefits realization, but it’s not a binary “yes or no” decision. It’s important these types of prioritization decisions are separated from those where there really is one chance, and one chance only.

BAs as Facilitators of Decision Making

All of this leads to an interesting conclusion: An important and often overlooked element of the BA role is to facilitate decision making. Whether that’s over prioritization of projects, feature requests, requirements or something else, we are on hand to analyze the different perspectives and ensure an informed decision is made.

Ensuring that we do this consciously, taking into account multiple factors (while keeping ‘opportunity cost’ in mind) is crucial. It’s one of the many areas where BAs add value!

Your Next Process Model’s Degree of Abstraction

Written by Edmund Metera on March 15, 2023. Posted in Articles.

Any process model is so much more than a flowchart. It is an abstraction of current or future real-world operations.

Process modeling is one of the core competencies of any capable business analyst. Both the International Institute of Business Analysis (IIBA) Business Analysis Standard[1], and the Project Management Institute (PMI) Guide to Business Analysis[2] call for certified business analysts to be capable of preparing and using process models.

Business analysts and process improvement analysts may prepare process models at key points of business process management, information technology, and regulatory compliance project methodologies. They may specify current or future functional, organizational, and information systems architectures, functional requirements, workflow designs, and even automated operations. What any process model needs to communicate will vary from one project to the next. The highest quality process model examples provide clear, accurate process information of direct interest to their readers.

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve. You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question:

What is this model’s required degree of abstraction?[3]

There are three generally accepted degrees of abstraction to consider: conceptual, logical, and configuration.

A Conceptual Process Model

A conceptual process model graphically presents the defining structure of what a process is.

Business analysts, project sponsors, project managers, domain subject matter experts, regulators, and other process stakeholders use conceptual process models, for the following purposes:

To make process governance and scoping decisions;
To gain agreement about and communicate the process’s defined scope and structure, unequivocally distinguishing that process from all others in their business;
To design enterprise architecture, to define technology solution architectures,
To be the sound foundation on which forthcoming detailed problem analysis or detailed process definition is scoped out or planned;
To support project management decisions (e.g. budgeting, scoping).
To further elicit and fit logical process details upon its sound contextual and structural foundation.

Some business analysts and systems analysts might interpret the term conceptual to mean “high level”. That would be an oversimplification and a mistake. To serve its purpose, a conceptual process model should unequivocally define the sound, stable structure of the process. Despite being the highest degree of abstraction, a high-quality conceptual process model is still precise. It can clearly and graphically communicate all of these process-defining information:

The process’s name.
The process’s initiating event(s) that causes the process to be performed.
The process’s activities and their expected sequence of execution.
The process’s expected outcome(s).
The process’s customer(s).

A Logical Process Model

A logical process model elaborates contextually relevant details about how a process is required to operate, is designed to operate, or currently operates.

A high-quality logical process model could graphically, answer any of these types of how-elaborating questions:

The decomposition or summary of some of the process’s activities.
The rule-driven or decision-driven conditional work that may be performed.
The assigned responsibilities for performing the process’s activities.
The data or information required to be used and/or produced.
The causes of the process to be delayed or interrupted.
The processing errors that may occur while the process is executing, and how they will be resolved.
The process’s related performance or measurement data, and text-based operating procedures, documents, or other specifications.

There is a spectrum of uses for logical process models. Process owners and analysts use logical process models to determine what and where to measure an existing process’s performance or to design and communicate proposed process improvements. They also define requirements for, or the design of manual or automated procedures, or describe the design of workflows.

Competent business analysts and process analysts can anticipate, elicit and document a range of logical refinement types, using clear agendas and reusable modeling patterns[4]. They also know that no two logical process models need to communicate all of the same types of logical refinements. So they will consider the model’s mission within each project and tailor their modeling efforts to focus on eliciting and documenting the types of logical refinements that suit each model’s intended use within its project’s methodology.

A Process Configuration Model

A process configuration model communicates concrete implementation mechanisms such as software operations and user procedures or workflows.

A process configuration model is the lowest degree of abstraction. Business analysts and systems analysts typically prepare process configuration models in low-code and no-code software platforms. The platform consumes the process configuration model along with detailed process-related roles, security, forms, system interface, and data specifications to generate operating software, on top of an already well-rounded software product architecture. There is otherwise no or very little programmer intervention in translating the model into working software. When updates to requirements or defects emerge, the analyst revises the configuration model, and the platform regenerates and redeploys the software.

You must adopt and adhere exactly to a chosen low-code or no-code platform’s process modeling syntax. You can learn that by taking the training offered by the low-code or no-code platform’s vendor. Along with a process configuration model, you would specify, in detail:

System users, their assigned roles, and their responsibilities to perform the configured process flow.
The sequence of execution of configurable functional components, of an automated end-to-end workflow.
The configurable functional components involved in the process flow configuration. These are typically the user interfaces (e.g. forms, reports) system integrations (e.g. APIs), and the data attributes used in an automated process workflow.

Since process configuration models are precisely translated into operating software and business operations, any errors or omissions in the modeling become errors or omissions in the generated software and business operations. It stands to reason that to be a successful business analyst or systems analyst in a low-code or no-code environment, you must design process configuration models based on sufficiently detailed logical requirements, that you have elicited and understood.

How to Choose Your Next Process Model’s Degree of Abstraction

Follow these guidelines to choose what the required degree of abstraction of your next process model will be:

Use conceptual process models to get agreement about and communicate what the process is. What is the scope? What causes it to be performed? What are the activities and their expected sequence? What is or are the expected outcome(s)? Use conceptual process models for planning, scoping, and architecture definition.

Use logical process models to get agreement and communicate how a process works or is required to work. Be prepared to elicit and document the answers to logical details such as: What are the detailed or summary activities? Who is responsible for what? What happens if? What happens when? What decisions will be made? What information is produced or used? Remember to elicit and include the details that are relevant to your model’s intended audience: those who participate in the lifecycle of your business process management or information technology project. Keep your model’s intended audience in mind when eliciting and documenting details. Use appropriately detailed logical process models for detailed functional requirements or design.

Use process configuration models to specify the configuration of concrete software modules, physical devices, and/or manual operating procedures that implement a process.

You typically use process configuration models in no-code or low-code software generation. To gain the benefits, you must specify very precise and accurate process implementation details, and exactly follow the process configuration modeling syntax.

Conclusion

A process model is not just a flowchart. It communicates what are, or will be, real-world operations. It may play a crucial role in the success or failure of your next business process management, information technology, or regulatory compliance project.

The most competent business analysts and process analysts clarify what their model’s required degree of abstraction will be, at the start of their analysis. They then focus their own and their project stakeholders’ efforts and time on the types of model content and format that will best suit each project’s unique needs.

You are welcome to learn more or share your comments and experiences about Your Next Process Model’s Degree of Abstraction via the Contact Us page at www.ProcessModelingAdvisor.com.

Copyright 2023, Edmund Metera

[1] The Business Analysis Standard (IIBA, November, 2022)

[2] PMI Guide to Business Analysis (PMI Inc, 2017)

[3] The Universal Process Modeling Procedure: The Practical Guide to High-Quality Business Process Models (Metera, 2018, 2022)

[4] The Universal Process Modeling Procedure: The Practical Guide To High-Quality Business Process Models Using BPMN (Metera, 2022)

Delivering Analysis: Working With the System

Written by Anna Rajander on March 9, 2023. Posted in Articles.

Business analysis is an evolving profession characterized by change. However, not all businesses embrace evolution and change in the same way. This can result in business and delivery practices constraining the use of newer, more agile approaches to business analysis. This article presents some ideas and techniques to help business analysts identify, understand, and work with constraining business practices.

The Challenge

You may have heard the serenity prayer. It goes something like this:

God, grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and wisdom to know the difference.

The origins of the serenity prayer date back to the 1930s and 1940’s. It is one of the most well-known and quoted prayers in the Christian world, with versions adorning posters, fridge magnets and trinkets across the globe. And while the prayer predates the business analysis profession by decades, the sentiment of the prayer is relevant for many analysts – even those of us who aren’t religious.

Business analysis is a profession of change. Indeed, the IIBA defines business analysis as the “practice of enabling change” in an enterprise. Whether it be learning a new technique or method, or applying skills to a new business domain, business analysts are encouraged to constantly experiment, learn and adapt. We are often looking for opportunities to apply new skills or techniques, or engage with enterprises that are using newer, more agile delivery methods. This constant exposure to change can make business analysts very comfortable with change.

It can therefore be frustrating when we find ourselves in environments where prevailing business practices prevent us from delivering analysis in the way we would like. Outdated systems, over-zealous governance, rigid templates and document heavy processes can constrain our ability to used more modern, agile delivery methods and techniques. And inflicting change on stakeholders using outdated delivery practices can seem like a double standard! Yet, working against such practices and processes can cause even more problems, resulting in business resistance, conflicts with stakeholders, delays, and even failure to deliver.

Identifying Constraining Business Practices

Business analysts need to fully understand the business context in which they are delivering change. This includes understanding the business and delivery practices being used to define, design and implement change, and how they impact business analysis. Early identification of constraining business and delivery practices gives business analysts an opportunity to find ways of working with them – rather than against them.

There are several common business analysis techniques that can be used to help identify and understand restrictive business and delivery practices. For example:

SWOT Analysis – A SWOT analysis can be used to help identify business practices that may impede or constrain business analysis activities (in other words, are a threat to the delivery of good analysis), identify opportunities to improve business practices, and identifying any strengths/weaknesses that may help/hinder delivery given the constraints.
Process Analysis and Modelling – Understanding when and how analysis activities will engage with constraining business practices can support the creation of efficient business analysis plans that meets all delivery requirements.
Stakeholder Analysis – Remember the saying It’s who you know – not what you know? This is too often true – particularly when it comes to governance and approvals processes. Understanding who the influential stakeholders are and engaging them early can often alleviate and even remove constraints.
Root Cause Analysis – There is usually a reason why things are done the way they are, although it may not always be obvious. Uncovering that underlying reason for a given business practice can help analysts a) identify areas for improvement, or b) accept it for what it is.

Conclusion

Understanding business and delivery practices that constrain business analysis can help analysts:

Identify and champion opportunities for business improvement
Identify ways of working with or within existing business practices that may better support analysis, or
Accept and work with prevailing business practices as efficiently as possible.

To paraphrase the serenity prayer – accept the things you cannot change, change the things you can, and understand the difference!

Anna Rajander, Dec 2022

Resources:

Serenity Prayer – Wikipedia, accessed Dec 2022.
A Guide to the Business Analysis Book of Knowledge (BaBOK) v3, IIBA, 2015.

Business Analysis Amalgamation with Product Management

Written by Neethu Nair on March 2, 2023. Posted in Articles.

In today’s fast-paced business environment, organizations constantly seek ways to improve their processes, products, and services. Business Analysis and Product Management are two key areas essential to achieving these goals. Traditionally, these functions have been viewed as separate disciplines, with Business Analysts focusing on identifying and analyzing business requirements, while Product Managers focus on the development and management of products and services.

However, there has been a growing trend towards amalgamating these two functions to create a more integrated approach in recent years. By combining Business Analysis with Product Management, companies can benefit from a more holistic understanding of customer needs, more effective use of data, and improved collaboration and communication between teams.

An Overview of Business Analysis and Product Management:

Business Analysis is the process of identifying, analyzing, and documenting business requirements, processes, and workflows. The role of a Business Analyst is to help organizations improve their processes and systems by identifying areas of improvement, gathering and analyzing data, and making recommendations for change. Business Analysts often work closely with stakeholders and other teams within an organization, including IT and project management.

Product Management, on the other hand, is focused on developing and managing products or services. The role of a Product Manager is to identify market opportunities, define product requirements, and work with cross-functional teams to bring products to market. Product Managers must have a deep understanding of customer needs and market trends and/ or the ability to manage budgets, timelines, and resources.

Benefits of Amalgamating Business Analysis and Product Management:

While Business Analysis and Product Management are distinct roles, there are many benefits to amalgamating the two functions. Here are a few of the key advantages.

Better understanding of customer needs:

One of the key benefits of amalgamating Business Analysis and Product Management is the ability to better understand customer needs. By working together, these two functions can create a more complete picture of customer requirements, preferences, and pain points. This can lead to better product design, more effective marketing, and higher customer satisfaction.

Alignment towards Business Goals:

Amalgamating Business Analysis and Product Management also improve team collaboration and communication. These two functions can ensure that everyone is aligned on business goals, product requirements, and timelines. This can lead to better project outcomes and faster time to market.

More practical use of data:

Another benefit of combining Business Analysis and Product Management is effectively using data. Business Analysts are skilled at collecting, analyzing, and interpreting data, while Product Managers deeply understand market trends and customer needs. These two functions can leverage data to improve product design, pricing, and marketing decisions by working together.

Faster problem-solving:

Amalgamating Business Analysis and Product Management also lead to faster problem-solving. By having a team of experts who can analyze data, identify issues, and recommend solutions, organizations can respond more quickly to changing market conditions or customer needs. This can help companies stay ahead of the competition and achieve their business objectives more effectively.

Better outcomes over outputs:

Finally, combining Business Analysis and Product Management can improve project outcomes. By working together, these two functions can ensure that products are designed to meet customer needs and that projects are delivered on time and within budget. This can lead to improved customer satisfaction, increased revenue, and a stronger competitive position in the market.

The amalgamation of Business Analysis and Product Management can benefit organizations looking to stay ahead in today’s competitive business landscape. By combining these two functions, companies can improve collaboration and communication, better understand customer needs, use data more effectively, and achieve better project outcomes. Whether a small start-up or a large enterprise, an integrated approach to Business Analysis and Product Management can help you achieve your business objectives more effectively.