Techniques Used in Business Requirements Gathering

Techniques involving visualization of the requirements like storyboards, prototypes, scenarios are helpful when you have a business user who may not be worried about the ins and outs of technical solution or have long attention duration for legalizing the requirements with users to let the analyst drive his discovery efficiently than just reading a document with a prospective user.

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. Therefore the usefulness of a technique is determined by its need and the kind of advantages it offers in a particular project. There are 10 essential requirement gathering techniques that you must be aware of in order to manage the projects in a better way and run your business successfully are:

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Interview
6. Observation
7. Prototyping
8. Requirements Workshop
9. Reverse Engineering
10. Survey

 It is utilized in requirements elicitation to gather good number of ideas from a group of people. Usually brainstorming is used 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.

Document Analysis is an important gathering technique. Evaluating the 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. In today’s world, you will also be determining the requirements that drove making of an existing system- a beginning point for documenting all current requirements. Chunks of information are mostly buried in present documents that assist you in putting questions as a part of validating the requirement completeness.

A focus group is actually gathering of people who are customers or users representatives for a product to gain its feedback. The feedback can be collected about opportunities, needs, and problems to determine requirements or it can be collected to refine and validate the already elicited requirements. This type of market research is different from brainstorming in which it is a managed process with particular participants. There is a risk in following the crowd and some people think that focus groups are at best unproductive. One danger that we usually end up with is with least common denominator features.

Interface for any software product will either be human or machine. Integration with external devices and systems is another interface. The user centric design approaches are quite effective to ensure that you make usable software. Interface analysis- analyzing the touch points with another external system- is vital to ensure that you do not overlook requirements that are not instantly visible to the users.

Interviews of users and stakeholders are important in creating wonderful software. Without knowing the expectations and goal of the stakeholders and users, you are highly unlikely to satiate them. You also have to understand the perspective of every interviewee, in order to properly address and weigh their inputs. Like a good reporter, listening is a quality that assists an excellent analyst 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. Low fidelity prototypes make a good listening tool. 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. Prototypes are very effectively done with fast sketches of storyboards and interfaces. Prototypes in some situations are also used as official requirements.

Popularly known as JAD or joint application design, these workshops can be efficient for gathering requirements. The requirements workshops are more organized and structured than a brainstorming session where the involved parties get together to document requirements. Creation of domain model artifacts like activity programs or static diagrams is one of the ways to capture the collaboration. A workshop with two analysts is more effective than one in which on works as a facilitator and the other scribes the work together.

Is this a last resort or starting point? 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 can be used. The survey insists the users to choose from the given options agree / disagree or rate something. Do not think that you can make a survey on your own but try to add meaningful insight in it. A well designed survey must give qualitative guidance for characterizing the market. It should not be utilized for prioritizing of requirements or features.