COEPD – Center of Excellence for Professional Development Happy Learning
As a BA knowledge about developing a product is the most important criterion.
These are the major steps we do follow while gathering the requirements
We strictly follow
- Question everything & every problem of the client is unique
- Identify SME for clarifications in Requirements
- BA should focus on “what” and “when” to develop rather than focus on “how” to develop.
- Never imagine anything and should not be hurried.
- Do not interrupt the client, when they are giving you the problem.
- Never try to give solutions to the client straight away with your previous experience and assumptions. And never say No to the client.
When the client explains the requirement, we will make sure to ask related questions for the application development. We need to find SMEs for more clarifications and we can schedule calls to get more information about the application. Before taking signoff on the requirements we need to get approval from stakeholders/clients.
We have some measures/ techniques to get requirements such as
REQUIREMENTS GATHERING: A requirement is a usable representation of a need, by using elicitation techniques.
ELICIATION TECHNIQUES: Is used to gather requirements.
Interview: It is a systematic approach where clients or stakeholders will be asked relevant questions related to the software and documented responses.
Prototyping: It is an attractive idea for complicated and large systems for which there is no manual process or existing system to determine requirements.
Survey/ Questionnaire: For obtaining limited system requirements detail from the user/stakeholders that have minor input or are geographically remote.
JAD: It has higher customer satisfaction and fewer errors as the user is directly involved in the development process.
Document Analysis: Is done by reading a document and understanding the product, process and project.
Workshop: A workshop may be used to scope, discover, define, prioritize and reach closure to the target.
Focus Groups: This means eliciting ideas and attitudes about a specific product, service or opportunity in an interactive group environment.
Observations: By doing their part of the job, can provide information on existing processes, inputs and outputs.
Reverse Engineering: Re-producing anything based on the extracted information. This involves disassembling something and analyzing its components and workings in detail. Majorly used in migration projects.
Brain Storming: It is an effective way to generate lots of ideas on a specific issue and then determine the best solution. It can be done individually or in a group, these ideas are reviewed and analyzed.
After gathering requirements we check the scope of development with the technical team and we go for prototypes and wireframes if needed, then we will get approval/ signoff from the internal team & client.
Likely for a good User Story
A good user story has a clear description of the feature or function. It also has a clear goal for the user and a clear deadline for completion. I like to include acceptance criteria in my user stories, which are measurable requirements that the feature or function needs to meet. For example, I once wrote a user story for a project that had acceptance criteria like ‘the user can view their account balance’ and ‘the user can make deposits.’ When the development team worked on the project, they knew exactly what they needed to do.
