The following are the techniques used by a Business Analyst to gather user requirements:
- Brain storming
- Produce numerous ideas
- Set a time limit
- Make it visual
- Designate a facilitator (usually the BA)
- Watch group size! (ideally 6-8)
- Establish ground rules
- criteria for evaluating and rating ideas
- do not allow criticism
- limit discussion and evaluation
- At the end, use criteria to evaluate ideas
- Can be fun, productive, and motivating
- Document analysis
- Elicit information from existing documentation
- Helpful when subject matter experts are not available or no longer with the organization
- Use relevant documentation to study and understand relevant details
- business plans, project charters, business rules, contracts, statements of work, memos, emails, training materials, etc
- Focus Groups
- Elicit information from a select group via a moderator
- Very formal process
- More structured
- Usually has 6-12 attendees
- Requires a skilled moderator
- Promotes discussion
- Asks open questions
- Engages all members
- Remains neutral
- Saves time and cost from not conducting
- Interface Analysis
- Identify interfaces between solutions and define requirements for them
- A basis for successful interoperability
- Clarify the boundaries of the applications
- Identify interfacing stakeholders
- Define the inputs and outputs of the interface
- plus validation rules and events that trigger the interactions
- Some types of interfaces
- to/from external applications
- to/from internal applications
- to/from external hardware devices
- Interviews
- Ask questions geared toward uncovering information
- Formal or informal
- Directed at an individual or selected group
- Maintain focus on the goals of the interview
- Open-ended questions find information and gaps
- Closed-ended questions confirm and validate
- Success depends on
- Knowledge of interviewer and interviewee(s)
- Experience of the interviewer
- Skill in documenting discussions
- The readiness of interviewee to provide information
- Relationship between the parties interview
- Observation
- Study a stakeholder’s work environment
- Good when documenting current or changing processes
- Passive/Invisible
- observer does not ask questions
- takes notes
- generally stays out of the way
- Active/Visible
- dialog with the user
- while they are performing their work
- Maybe disruptive
- Maybe time-consuming
- Process Modeling
- Understand work with multiple steps, roles, or departments
- Initiated by an event
- Activities to include
- Manual
- Automated
- Combination of both
- Visual nature may help some people
- It can become complex and unwieldy if not structured carefully.
- Complex processes should be broken into their components to aid in understanding
- Prototyping
- Visually represent the user interface
- Good validation measure
- Great for interaction
- Supports visual learners
- Focus on the whole solution or just a specific area
- Great for validating requirements and uncovering gaps
- Can take lots of time if bogged down in the “hows” instead of the “whats”
- Requirements Workshops
- One of the most effective techniques
- Have an agenda
- Carefully select attendees
- Use an experienced, neutral facilitator
- Use a scribe (not the facilitator)
- One or a few days in duration
- Elicit information in a short period
- Too many participants slow it down
- Too few participants cause gaps
- Team member availability is an issue
- Combine with other techniques
- surveys or questionnaires
- prototyping for clarity
- process modeling for understanding
- Survey/Questionnaire
- Efficiently elicit information from many people
- Have a purpose
- Appropriate audience
- Establish a timeframe
- Clear and concise questions
- Focus on the business objective
- Support with follow-up interviews
- Closed-ended questions
- Range of possible responses is very well understood
- Easier to analyze
- Open-ended questions
- Extra detail when the range of response is not well understood
- Harder to analyze and quantify
Yes, all the methods are different and effectively used based on case to case and situation to situation.