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!

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.

Prioritizing Requirements: An Analogy

Written by Eileen Raycroft on March 1, 2023. Posted in Articles.

I work with “business sponsors” in my company. Some of them are old hands at going through the process of requesting a new application, or a rewrite, or enhancing an existing application. Others, though, may never have been involved in requesting software, whether it’s a custom-built application, or something offered by a third party vendor. In any case, it can be daunting to make decisions about what to ask for, especially when they have to submit a request to get the money to proceed.

Most people I know enjoy engaging in “blue sky” conversations – if you had all the resources in the world at your fingertips, what would you like this new application to do, to support what you and your clients need? And to be honest, I enjoy those conversations as well. It’s fun, and liberating, to just let your imagination take flight and ask for the world! At the end of those blue sky sessions though, it’s time to bring ourselves back to reality, look at the lineup of desired requirements, and put a priority on each of them. And one of the prioritization methods I’ve had the most success with is the MoSCoW method.

MoSCoW Prioritization Categories:

M = Must Have. Non-negotiable needs that are mandatory for the business.

S = Should Have. Important features that are not critical but have much value.

C = Could Have. Nice to have features that will not impact the usability of the application in a detrimental way if they are not included.

W – Will Not Have/Wish. Features that should be placed in the product backlog for future consideration.

I often use analogies to drive home various concepts to my stakeholders, especially if it is something they aren’t familiar with. Analogies help them grasp these concepts more quickly, rather than using a lot of “wordy” explanations. I use this analogy about prioritization when appropriate.

How to Research buying a Refrigerator

Recently my husband and I purchased a new refrigerator. Our old one was on its last legs, and we wanted to purchase a new one before the old one gave out at a most inconvenient time, as we had experienced several times in the past! (If you’ve ever had a fridge give out on you when you had a great load of food in it, you know the stress I’m talking about!)

Since it had been quite a few years since our last purchase, we started looking around and were astonished at all of the new configurations and features that were available in new fridges. The price tags too, had changed – wow, were they expensive!! So, I said to my husband, “Why don’t we write down all of the features we think we would like in a new fridge, and then go shopping with that list?”

So we sat down at the kitchen table with our son, who lives at home (gathered all the stakeholders), and I started the list of “requirements” for our new fridge. Did we want an ice/water dispenser, which our old fridge had? What about extra room for vegetables, now that we had committed to eating more healthy? How many cubic feet of space did we want? How about a deli drawer? Or a computer on the outside of the fridge?

Feature	Prioritization
Ice maker/dispenser	M
Maximum room to store vegetables	M
Minimum cubic feet 26 cu ft	M
French door style	S
Deli drawer	C
Energy efficiency	M
Computer built in the front of the fridge	W
Etc.

Once we had our list written down, we used the MoSCoW technique of prioritization, and each requirement was given a must-have, should-have, could-have and won’t have/wish. We also had to figure out what our budget was–not many people have infinite resources, and we are certainly not in that league, financially!

So, armed with our requirements and our budget number, we started shopping. On-line, and in person, we spent many hours researching the available options. Some of those could-haves and wishes dropped off the list pretty quickly, because although we had what we felt was a moderate budget, it certainly weeded out the more extravagant models.

We were able to find a refrigerator that had all of our M, S, and most of our C items in our list that was within our budget. And because of all this work we did in advance, we actually felt good about our purchase—we were very satisfied we’d made the best choice for us. That didn’t mean we got everything we wanted, but we didn’t feel disappointed. We’re still loving this fridge three years later.

Conclusion

And that’s exactly the feeling I want my business sponsors and stakeholders to feel – very satisfied that they’ve made the best decisions for the application/enhancement or whatever the initiative is. Do your research, prioritize your requirements and move forward with confidence.

Tag: Business Analysis