How Do I Get Stakeholders to Focus on Business Requirements?

Author: Adriana Beal

A participant of the course, Crafting Better Requirements asks:

We run into situations where the business users want provide the design of the solution besides the business requirements. The technical team is against it — they would prefer to be responsible for the design phase. How can a BA approach this situation and get the business stakeholders to just provide the business requirements, and not the solution?

Under what circumstances (if any) it is OK for the business side to provide solutions?

These are great questions about a situation many BAs routinely face while performing their role, but they don’t provide a complete picture, because it misses an important step between business requirements and the design phase: solution requirements.

In the classical engineering approach, sets of requirements are used as inputs into the design phase of product development, as illustrated in the diagram below:

Standard Software Process

As described in the BABOK® Guide, business requirements are “higher-level statements of the goals, objectives, or needs of the enterprise”. Getting business requirements right is a crucial first step for any software project, but the involvement of business stakeholders in meeting a business need doesn’t end there. Users and other business stakeholders, because they are closest to the need, must be involved in defining the software requirements and approving the design decisions that represent a suitable solution for the business requirements.

The problems that many BAs experience trying to keep stakeholders focused on the business requirements typically come from the fact that it’s easier for people to “jump into solution mode” than to concentrate on the problem space. Consider a couple who is hiring an architect to design a house for their family. What type of conversation do you think is more likely to happen, when the architect asks what the couple has in mind?

#1: “We’d like to have a master suite, and 3 bedrooms, one for each of our 2 kids, and one for guests. We’d also like to have an office, a playroom for the kids, and…”.

#2: “Well, we want everybody to have their privacy, and also need an area where the 2 kids can play together. We would like to be able to house guests without having to move anyone to another room. And we need a functional workspace where my husband and I can be productive while working from home…”

For most people, it’s easier to describe their vision of a designed solution–how many rooms are needed to achieve the desired accommodations (conversation #1). However, defining the needs first (conversation #2) yields much better results, because it doesn’t create unnecessary constraints in the architect’s work. For example, the same goals of privacy and shared space for the kids might be better achieved with a larger room that separated the two sleeping areas with a nice playing area, increasing the space the kids would have to play.

The real question here is not how to get the business stakeholders to “to just provide the business requirements, and not the solution”, but rather, how to get the business stakeholders to focus first on the high-level requirements, before attempting to determine software requirements, or make design decisions. And the answer is simple: the same way a talented architect will ask good questions to clarify the actual needs of the family who will live in the house before starting to prepare drawings and present solution ideas for the client to review, a BA may need to ask questions repeatedly in order to surface the objectives and needs behind the stakeholders’ description of a particular implementation.

If, for example, during the software requirements elicitation phase a user says, “I need a pull down menu to choose which category of projects I want to open next”, in order to find the actual requirement behind this design decision, the BA would then ask questions to uncover the actual capability needed–which could be, for instance, “ability to filter projects by category”. Later, during the design phase, the designers would study the available alternatives in order to propose the most appropriate (which may or may not involve a pull down menu).

Here’s an example that illustrates the difference between business requirement, solution requirement, and design:

Business Requirement Solution Requirement Design
The business needs to be able to tell what type of relationship it has with its partners (i.e., customer, supplier, both) without having to look up information from each individual business unit or subsidiary. Whenever the name of a partner is visible on the screen, there must be an indication of the type of relationship the company has with it (customer, supplier, or both). Whenever the name of a partner is visible on the screen, next to the name the system will display one of 3 symbols that identifies the partner as a customer, supplier, or both. The logic behind this display will take into account the relationship the partner has with each of the company’s business units and subsidiaries at various levels and different touch points. When the mouse is placed over the symbol, the corresponding label (Customer, Supplier, Both) will be displayed.

As you can see in this example, the second and third columns represent one of many potential solutions for the stated business requirement. There could be other solution requirements potentially fulfilling the same need (e.g., “from anywhere in the system, the users must be able to inquire about the overall relationship a partner has with the company”), which in turn could be accomplished by multiple design options (e.g., “include a search box at the top of all pages that will display the partner relationship in the search results once the user enters the desired partner name”, or “display the name of partners as links that when clicked will open a pop-up window containing the partner relationship”).

Typically, the solution requirement will be recommended by the BA as a result of the elicitation process. By examining the detailed activities related to this particular business need, the analyst could discover that in most cases the person who needs the information is able to view the screen with the name of the partner(s), but not use a keyboard or mouse to perform a search or click on a partner’s name. This would dictate the solution requirement that appears on the table above, as opposed to the alternative described below it. Clearly, business stakeholders must be providing input and sign-off during the requirements phase (emphasis on”what”)  and the design phase (emphasis on “how”) to help ensure that the final product will be fit for purpose.

Now, regarding the second question asked:

Under what circumstances (if any) it is OK for the business side to provide solutions?

As discussed above, it’s not only OK, but expected that the business side will be involved in defining the solution that will be built to address a business problem or opportunity. The solution requirements, which describe the characteristics of the solution, are defined through requirements analysis with the participation of the business stakeholders. We could, however, rephrase the question to say,

Under what circumstances (if any) it is OK for the business side to define technical solutions or establish design constraints?

With the question phrased this way, the answer changes. Design constraints (defined as preexisting design decisions that mandate how the final product must look or how it must comply technologically) should be avoided during the requirements phase. However, there are certain cases in which a specific technology, user interface, or other design element, is required to comply with:

  1. a regulatory rule (for example, if federal regulations required a company from a regulated industry to protect data confidentiality using cryptography, the requirements document should include this design constraint);
  2. contractual agreements with other companies (e.g., two partners agree to use common standards for transmission of data in order to keep their products compatible);
  3. enterprise-level architecture or other internal policies that require software products to conform to specific standards

Under these, and similar circumstances, there is indeed a legitimate reason for the business side to impose restrictions on the solution that will be developed. Also, we must keep in mind that the requirements/design process is iterative; requirements lead to the selection of certain design options, which in turn may initiate new requirements. By using a disciplined and repeatable process for controlling requirements sessions, and having all stakeholder groups represented when discussing an element of functionality they use or require, it is possible to ensure that business and software requirements are correctly and unambiguously defined to serve as the right foundation for the design and construction phases.

Editor’s Note: To receive Adriana’s personal feedback on your requirements specifications, check out Crafting Better Requirements, an online course with individual instructor feedback to help you improve your requirements specifications.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.

Comments

  1. what do u do at a kickoff meeting?

  2. Mike, I waited until I, too, was sober, to reply :-).

    “The biz requirement should be, in my very humble opinion, about what the business needs to know or to do in order to complete their work.””

    Agreed. Business requirements describe business needs.

    “I therefore agree column 2 is not a conversation solely with the solution provider. The biz people need to understand how the solution will satisfy the needs they have.”

    I’m glad we are on the same page! That’s exactly my view too.

    Thank you again for bringing your knowledge and experience to the conversation, and I look forward your comments in the follow-up article, which will be published on Wednesday August 10. Cheers!

  3. mike Lachapelle says

    Adriana, let me address your challenge.

    On sober second thought, ’cause obviously I was dunk when I wrote part of that previous post, I concede I may have misconstrued the message in the table. Long winded way to say I have re-thought what the table is conveying, and the middle column is not definitively a conversation with the solution provider. Let me take another crack at it.

    The biz requirement should be, in my very humble opinion, about what the business needs to know or to do in order to complete their work. In light of that view (column 1) the biz requirement is people need to know the nature of the relationship with the “partner”, and they need that information without having to do research.

    Where this differs from the solution requirement, is the latter is about what the solution needs to provide to the user to satisfy that need to know or to do. In this case (column 2), the solution must provide an indicator of the nature of the relationship whenever the company’s information is presented.

    I therefore agree column 2 is not a conversation solely with the solution provider. The biz people need to understand how the solution will satisfy the needs they have.

    It has been a while since I did requirements gathering, but when I did, I made the effort at the outset with the clients to frame the business requirements in terms of my understanding the narrative (i.e. the story) of how they do their work. It can be hard effort, as noted before, people have a great deal of difficulty separating their work from the tools they use to do the work. As Adriana notes above, the liberal use of “what, why, when” and consciously pulling them away from the ‘tech’, helps to get much more clear “business” requirements.

  4. I wanted to let you know that I’m right now working on a follow-up for this post,in which I’ll quote from Pat Kennedy’s comment in this thread since it’s a great summary for what needs to happen (“steer the conversation to the requirements of why, what, when”).

    It’s scheduled for publishing on August 10. I look forward reading your additional comments there (and Mike’s reaction to my response to his comment about solution requirements being a conversation you have with the solution providers 😉 ).

  5. Michelle Swoboda says

    Lately I have been finding that the business stakeholders are being pulled in too many directions and projects and they are unable to give the requirements their due diligence.
    Setting up one on one sessions to clarify and understand are a good idea. The group review is important and I am approaching it differently this time – send out the requirements one week prior to the meeting, with a clear agenda and expectations to review the requirements and come to the meeting with your comments and changes. I will let you know how that goes!
    I am also finding that some stakeholders only look at the requirements that they perceive as important to them – missing the point that a requirement could easily impact them.

  6. @Akarsh: indeed, asking “why” is crucial to getting to the real business need — I’m happy to learn that you insist on this question with your stakeholders. And now Mike has two votes for writing a post about his excellent additions to the conversation :-).

    @Michelle: Thank you for the compliment, I’m glad you thought the post was clear (I struggled a bit to write it because there were so many points to make, and I didn’t want to make the article too big). Yes, it is intriguing to see the BA not being allowed to be part of the solution, considering how much knowledge he/she develops about the need business need. I look forward your comments in the next post, where I’ll expand in this subject, as I think you will have relevant experiences to share with the community here.

  7. Michelle Swoboda says

    Adriana, very enlightening post! Lately I have been struggling with the territory between the business analyst and the functional analysts – a new role that is part of my project. I tend to do the business requirement and the solution requirement but in this contract I am stepping on toes.
    It is intriguing to see that the person closest to the business – the BA, is not able to be part of the solution. Also that the solution is not separate from the design. You have made it very clear and I believe that this will help many BAs in their roles.

  8. Akarsh MG says

    @Adriana – Great post and examples you have put it across.

    There are always business stakeholders i have come across they directly on solutions as they want to define the solutions first and then come back explain why they want to solution this way to cater there business problem.

    Most of the time it has worked for me asking “Why” many times to customer and also quick prototype in PPT has helped to make sure i take back my stakeholder to business requirement before he says this is the solution what i want.

    @Mike – Comments were great may be you expand that comments into a blog with some more examples!!

  9. @Pat: What you say makes a lot of sense. My approach may differ from yours in certain points, but the goal and result are the same.

    Your comment and Michael’s, reminded me of a slide for a presentation I made once at the request of the head of development, for his developers, showing the spiral that happens from the problem space to the solution space and back. I may use the same diagram in my next article, as I believe the visual helps in this case.

    “Now part of the question is how to keep the stakeholders from recommending solutions at this point or actually even earlier, so the design (solution) can be left to the designers.””

    My approach does not involve keeping the stakeholders from recommending solutions. I welcome all suggestions and proposals they make about solution (which includes requirements and design). But after they have voiced their ideas and preferences, I do what Mike L. describes: ask “why” many times. What you learn from this process is invaluable to help you (the BA) understand the capabilities that are truly needed, and document them accordingly.

    More in the article, because the comments section doesn’t allow you to add diagrams that would help here :-).

  10. Pat Kennedy says

    Adriana – I agree with your point about Column 2. I agree with your explanation that the second column is the requirement for the solution after the BA has written it and it is ready to be interpreted/communicated to the developers/designers/system architects–etc… Now part of the question is how to keep the stakeholders from recommending solutions at this point or actually even earlier, so the design (solution) can be left to the designers. I hope I am getting this correct and I know you have more points to make on this subject. I just wanted to see what you thought about having a conversation with the stakeholders before the process begins and then as often as needed during the requirements gathering process about this topic.

    How solutions look in the end, need to be reserved till the end – because……here a BA might have at least three examples of solutions that when one requirement is used to design the look, function or feature without considering all the requirements, plus the knowledge of a GUI designer and or developer then a less efficient and sometimes clumsy interface/feature is the result. So gain agreement that the solution may be different – no less than needed and in many cases better after the complete picture is known. Then steer the conversation to the requirements of why, what, when, changes over time, etc… to make sure the solution includes all the functionality and features it needs to solve the business problem it is needed to solve. I always find that complimenting an individual on their business acumen or knowledge/expertise and then asking them to let the actual solution design unfold after all the requirements are considered can be very useful in getting them to let go of their perceived solution (disarming the ego) and allowing you to move on, without committing to a partially conceived (all be it a small portion) piece or part of the solution. Does this make any sense?

  11. Mike, thank you for your thoughts! I hope everybody reads the comments here not to waste what could have been a blog post itself :-).

    “I have a sneaking suspicion that at the heart of the difficulties around requirements specification is the focus on having the client identify “requirements”. It might be a more effective approach to have a conversation with the client about the job they have to complete and what they need to accomplish that”

    I absolutely agree with you. End users, for example, are very good at talking about the problems they have, but typically not good at translating the needs into requirements. The BA plays a crucial role translating user goals and tasks into quality requirements for the solution team.

    “In Adriana’s table, column 1 is the conversation you have with the client, column 2 is the conversation you have with the solution providers.”

    This is the part I disagree with, but it will probably be better to write another post to explain why, rather than to try to do it here. Thanks again for sharing your views (and for giving me the idea for my next article ;-).

  12. mike Lachapelle says

    When I speak about BAs, and to BAs about their work, somewhere in the conversation I refer to the three most common problems faced by BAs:
    1 – not defining the problem correctly
    2 – not validating information you have been given
    3 – clients/customers who want to start with the solution

    The second question is the easiest with which to deal. I have seen many projects get into trouble because the BAs took information “in good faith” figuring the client knew their subject. Always validate, especially if the information is from one source. Here’s an example: working on a project for a capturing the work of a remote procurement group, I was handed information they processed ~9000 contracts a year, each contract took ~30 minutes to enter in the management system. When we validated the information it turned out the group’s clients actually processed almost 8800 of the transactions themselves, the group ‘advised’ them on that work. Of the remaining 200 or so contracts it took 30 minutes to record the full contract in the management system, but the reporting system (which was the key to capturing the work of the remote group) could be done in 5 minutes. Yes, the group was responsible for 9000 contracts, but that was not the pertinent statistic – validate the information.

    Problem one is a difficult one because get this wrong and you have scope problems and can have a very successful project that fails to solve the critical issues for which it was initiated. I have seen that many times. To help with this problem I use an interesting tool created by the Kellogg Foundation for applicants for grants, it’s call the Theory of Change Model. It helps to define the scope of an initiative by asking 6 questions:
    – what is the specific problem you are trying to solve (problem statement)
    – why is this a problem that has to be addressed now (drivers)
    – what do you hope to achieve by solving the problem (objectives)
    – what will influence the solving of this problem (context and influencers)
    – are there other solutions that may exist (alternative approaches)
    – what are you assuming about this problem (assumptions & constraints)

    Problem three is the most insidious. We, as BAs, have all faced this problem in one form or another, driven by two factors: exposure – they have seen a solution they are convinced can be used to solve their problem (see problem 1); myopia – they tend to be very short sighted, seeing their work only through the immediate tools they use. In today’s work environment it is very difficult to segregate the work people do from the tools they use to do that work. A BAs job is to get the client to step back and tell them the “story” of their work. To borrow from the domain of business modelling, it is about getting the client to express the job-to-be-done and the BA to understand the needs that have to be satisfied to get the job done. Those needs become the basis of the solution (the requirements). The most important question in a BAs arsenal is “WHY”. It can never be asked too many times.

    I have a sneaking suspicion that at the heart of the difficulties around requirements specification is the focus on having the client identify “requirements”. It might be a more effective approach to have a conversation with the client about the job they have to complete and what they need to accomplish that. Clients have to have the confidence you have captured and understand their needs. Solution providers have to have a clear specification of what the solution is require to do. In Adriana’s table, column 1 is the conversation you have with the client, column 2 is the conversation you have with the solution providers.

    But… that’s just my opinion, I may be wrong.

Before you go, would you like to receive our absolutely FREE training?

(No formal experience required.)

21689
21690

Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.