The requirement gathering techniques may differ from one project to another. Some requirement gathering techniques may prove highly beneficial for you in one project but may not be as productive in the other project or for some other company.
It a crucial part for any company to understand what, how and why they need a product and solution. We always take an opportunity to sit and brainstorm with the elite group member or and an individual to understand his idea and try to improvise it with our input to make it more great. In this stage we spend time with the creator of the product or solution in identifying all possible solutions to problems and simplifies the detail of opportunities. It casts a broad net, determining various discreet possibilities. Prioritization of such possibilities is vital to locate needles in haystack.
One the brainstorming techniques with client is over we try to gather all reference and documents shared by the client to analysis more deeper. We then prepare a final documentation of a present system can assist when making AS-IS process documents and also when driving the gap analysis for scoping of the migration projects.
Referring to old Chunks of information for enhancement projects are really helpful as its assist you in putting questions as a part of validating the requirement completeness.
We like to deep dive with our discussion to people who are customers or users representatives for a product to gain its feedback. Collecting a feedback about opportunities, needs, and problems to determine requirements and it helps us to refine and validate the already elicited requirements.
Based on our brainstorming sessions and interacting with focus group of people we the outline the project interface for any software product will either be human or machine. We then build connection between interfaces with external devices if project demands for it.
Analysing of interface help us to understand the touch points with another external system- is vital to ensure that we do not overlook requirements that are not instantly visible to the users. This is a very important part during requirement gathering as UI/UX plays a vital role in engaging an end user in first place.
We prefer to Interview our users and stakeholders who are really important in creating wonderful software. Without knowing the expectations and goal of the stakeholders and users, you are highly unlikely to satiate them. We also have to understand the perspective of every interviewee, in order to properly address and weigh their inputs, we listening to them patiently to gain better value through an interview as compared to an average analyst.
The observation covers the study of users in its natural habitat. By watching users, a process flow, pain points, awkward steps and opportunities can be determined by an analyst for improvement. Observation can either be passive or active. Passive observation is provides better feedback to refine requirements on the same hand active observation works best for obtaining an understanding over an existing business process. You can use any of these approaches to uncover the implicit requirements that are often overlooked.
Prototyping can be very helpful at gathering feedback. Based on all inputs and analysis we develop a low fidelity prototypes to ensure we have understood client’s requirement quite well. Many a times, people are not able to articulate a specific need in the abstract. They can swiftly review whether a design approach would satisfy the need. We provide our client with fast sketches of storyboards and interfaces. Prototypes in some situations are also used as official requirements.
When a migration project is not having enough documentation of the current system, reverse engineering will determine what system does? It will not determine what the thing went wrong with the system and what a system must do?
When gathering information from many people: to many to interview with time constraints and less budget: a questionnaire survey is used. The survey insists the users to choose from the given options agree / disagree or rate something.