I've had the privilege of sharing some thoughts on doing Requirements well in the "real world" and I love the questions that it spawned from the Business Analysis community. Here are some of those questions and some ideas I had on how I would respond.
"How do you identify the right stakeholders?"
Creating agendas and preparing your questions of what you wish to accomplish
"Some people may fear that they may be complaining and may be reluctant to offer up 'pain points' - how do you best work with these situations to understand the current issues?"
Ask people what they LOVE about what they do - what works well? What could be better? As you follow this approach, the stakeholders will often start to highlight the exceptions to what works really well and that will give you the opportunity for improvement, but it's an expression of what could be better versus asking what's wrong.
If there is a conflict between the stakeholders regarding what should be consider a requirement...what can we do?
With conflict, I love to isolate the problem. A simple technique is to "throw it on the wall and see what sticks!" I literally write the problem statement on the board and so your stakeholders "attack" the challenge versus attacking each other. Now we're a team trying to overcome the challenge at hand (versus disagreeing amongst each other).
How do you establish your expertise in the Requirements space, specifically, if the client himself isn't technically qualified and is insisting on limiting the BA to certain templates to use?
If someone asks you to use a template, ask them to walk you through it. Do a collaborative approach with the stakeholder so that you can use your elicitation skills and ask good questions, even if the answers have to go in a predetermined 'box'.
How would you recommend handling an environment where many areas may are a part of a process/transaction, but true ownership is not clear? Multiple managers may either view they own the process or no one feels they own it at all.
Try changing the focus to the product. Who manages it today? Identify who would be affected if you change a process - show how their daily routine would change based upon a decision. And when in doubt - get them in a room and walk through the process around the decision so that everyone sees what the considerations may be.
How do you deal with participants who give you non-functional or design specs as opposed to the function or business requirements?
Ask them WHY! These will start to draw out the requirements at a higher level then where they are focused. And ask for use cases and scenarios around what they are describing. Even if the use case or scenario doesn't give you the specific business requirements, it will at least give you more stakeholders to approach as you may need to seek a different audience.
What tips do you have to match elicitation techniques to project/audience?
Know your project and more importantly your audience! If the outcome is well defined, then use techniques that focus on specifics such as traceability and process flows. If you are exploring options then use techniques such as brainstorming and focus group to allow the freedom of expression. As well as even consider if you need greater engagement then consider using collaborative games. This comes out of your BA planning work
PRIOR to beginning your elicitation when you are doing stakeholder analysis.
A scribe may be helpful, but what are alternatives when resources are limited?
Having another BA assist you is a great way to job shadow and even be assessed on your own skill sets. And if you're needing greater stakeholder engagement, ask the stakeholders to take turns capturing the discussion points and outcomes. And don't forget to ask if you can record a session for playback later. Reinforce you understand the sensitivity of the conversation and share all results and they may be more open to ideas that improve even current processes.
Have you used Use Cases in the past and if so, did you find it useful to subsequently extract requirements and/or to ensure the requirements are complete?
Use cases are great for helping you validate your requirements and trace them to completeness. I often ask for scenarios as story telling can be an easier approach for your stakeholders than asking them to give a 'checklist' of requirements - definitely can feel more natural to your stakeholders!
What are your thoughts on mockups being inserted into requirements?
Mockups are great for drawing out requirements. Use the language your customers are comfortable when trying to elicit information. The check is to go back and not only verify but then validate these represent the value your customer is expecting to add.
Do you find the use of "and" in requirements causes issues for designers or developers?YES!! However, if this is how your stakeholders start off with requirements, then take it and work to verify them by separating them out as you ask more details. Functional decomposition usually is a great way to help your stakeholders separate and isolate the requirements that make it easy for the next team who will work on them, such as designers and developers.
How do you position and integrate business rules into requirements?Business rules are part of your requirements so they are often intermingled. Walk through the process so you get the process mapped. As you verify the process, while walking through the process maps, capture requirements in one table and business rules in another. Then identify the dependencies so that you know if you test or change one you must re-verify and validate the associations.
What if the requirement has been approved but later the solution was not as expected and all the estimates allotted were consumed? What do we do with the requirement?
When you wrote the requirement, did you write acceptance criteria? This acceptance criteria should still hold true to leading to project/initiative success and so the requirement is still required. This is when you rely on change control processes to help you coordinate getting the resources to deliver the value. It is easier to get more resources when you show the value of what they will provide.
Is it acceptable practice to use words like "YOU/YOUR" or "WE/OUR" while doing business analysis in a context with respective stakeholders who may be also part of same organization?
use personal nouns when creating vision, describing success criteria and acceptance criteria as you want the personal buy-in of the stakeholders. As you move to requirements and user stories, utilize the role that is affected or acting in the situation to draw out the need, not simply the want. If the requirement can stand for anyone in the role it helps articulate business value to the organization than a one time occurrence for "you."
If you are an IIBA member, the presentation on "Requirements for Requirements" is available in their archived webinars section on their website IIBA.org.
Do you have any "Tips and Tricks" for BA's to share? Please COMMENT and share your thoughts as well!
