Becoming Business Analysis Detective.pptx

Uncovering your users' needs can often feel like solving a mystery. By stepping into the role of a business analysis detective, you can uncover the true needs of your users and the reasons behind them. In this guide, we’ll break down the fundamentals of what requirements are and their importance, explore methods for gathering them, and, lastly, focus on how to effectively document them.

1. Becoming a Business Analysis Detective: Getting to the bottom of your User’s Needs Emmanuel Dauda

2. Who is a Business Analyst? Business analysts use data to form business insights and recommend changes in businesses and other organizations. Business analysts can identify issues in virtually any part of an organization, including IT processes, organizational structures, or staff development.

3. Good business analysts figure out what their users really need, and why they need it.

4. Sometimes, figuring out your user’s needs is a mystery. Becoming a business analysis detective allows you to get to the bottom of what your users really need, and why they need it. Let’s explore the basics of what requirements are and why they matter, techniques for gathering requirements, and then finally documenting requirements. Ready to get on the case?

5. Requirements – What are they and why do we need them? Requirements are something that someone needs, in this case, needs as stated by a stakeholder. T o be a requirement, it must be  quantifiable  and  verifiable Not  to make something “prettier” or “more user-friendly,” since this not measurable The  stakeholder , not the Business Analyst or Salesforce Admin, owns the requirements Requirements tell: Salesforce Admin  what problem needs to be solved, Test Engineers  what to test, and Managers  how they can see the progression of a project Requirements document a contract between you and the stakeholder, identifying what needs to happen before a project can be considered “ completed ”

6. Methods of Requirement Elicitation /Gathering Interviews Workshops Experiencing life as a user Observing users at work Problem reports Helpdesk and Support Teams Trainers and Consultants Customer suggestions and complaints

7. Interview Your Stakeholders Give users room to speak/Avoid giving your view of a problem Appear relaxed Use open, not leading, questions Use sketches and diagrams to clarify requirements

8. “Users may not be able to imagine a new system or how they would use it, but they know what their problem is, and why they would like it fixed”

9. Observing Users at Work What users do Sequence of tasks Tools that they use With whom they interact Where they store and pull information from

10. Sketches

11. Documenting Once you arrive at a comprehensive list of requirements, its critical to document them Documenting creates  clarity for the project More  requirements do  not  equal  better  requirements Try to write each requirement as one short sentence Not necessary to get the wording perfect on the first try - keep them simple and concise Once you think the requirements are in a good place, the next step is to send them to the stakeholders and review together Together, you can then agree on what you’ve discovered and what a complete project will look like When  all the stakeholders sign off and agree to the written requirements , you can mark the elicitation project complete

12. Checking Requirements The requirements process isn’t complete until the user(s) have checked the requirements.

13. Q&A

14. Thank you