One of the most important tasks in requirement engineering is requirement elicitation. Requirement elicitation is a practice of gathering things that are needed or wanted and are necessary to draw out or bring forth for a system from users, customers, and other stakeholders. This practice is also sometimes referred as “requirement gathering”.
One of the key objectives of business analysis is to ensure that requirements are visible to and are understood by all stakeholders. It is an active effort to extract information from stakeholders and subject matter expert. Also, requirement elicitation is a technique you can apply appropriately during the requirement phase.
Requirement elicitation is important because one can never be sure to get all requirements from the user and customer by just asking them what the system should do OR not do.
Requirement elicitation technique includes:
Brainstorming:
It is a group creativity technique to produce numerous ideas by which efforts are made to find a conclusion for a particular problem by gathering a list of ideas spontaneously contributed by group members.
Ideally, group size must be of 6-8 members. To ensure this technique, one can set a time limit, make the ideas visual, establish ground rules to evaluate and rate the ideas and do not allow criticism and limit the discussion and rating. This technique is productive and highly motivating.
Document Analysis:
This technique is useful when the subject expert is not available. In this technique, information is extracted from an existing documentation. The documentation should be relevant to the study of matter and based on this information one can understand and analyze.
For example:
Business plans, project charters, business rules, contract, statements of work, memos, emails, training material, etc.
Focus Groups:
This technique saves time and cost by bringing out information from a selected group via a moderator. This process is very formal, more structured and usually of 8-12 attendees. A moderator is a skilled person who promotes discussion, ask open questions, engages all members and remains neutral in the discussion.
Interface Analysis:
Interface Analysis is a business analysis elicitation technique that helps to identify interfaces between solutions/applications to determine the requirements for ensuring that the components interact with one another effectively. This clarifies the boundaries of the application by identifying interfacing stakeholders and by defining the inputs and outputs of the interface. Interfaces can be to/ from external applications, to/ from internal applications, to/from external hardware devices. Interface analysis helps in discovering the requirements needed to integrate software into its new environment.
Interviews:
It is a technique where questions can be geared towards uncovering information. This can be formal or informal that should maintain focus on the goals of the interview. This should aim to find information and gaps between the understandings. This technique can be successful depending upon the knowledge of the interviewer and interviewee(s), the experience of the interviewer and his ability to document discussions.
Observation:
This is a technique to study stakeholder’s work environment by just observing which is beneficial when documenting current or changing processes. An observer can pen down and won’t disturb by asking questions, such an observer is called a passive observer. Whereas, an active observer can communicate when stakeholders are doing their work.
This technique might consume time and also is not able to observe all possible scenario.
Process Modeling:
Business Process Modeling is an analytic representation or illustration of an organization.
For example, UML diagram. It helps to understand work with steps, roles, and department.
It is important that one has to structure this representation in a systematic manner so that it is easier to understand otherwise this can become unwieldy and complex.
For better understanding, one can break complex processed into components.
Prototyping:
In this technique, first the product is manufactured and then can be tested. This helps to understand the gaps and to know what changes can be made. This is very helpful in validating requirements and uncovering gaps.
This represents the user interface with good validation measure.
Also, supports visual learners with great interaction.
Requirement workshops:
Requirement workshops can be defined as an organized and smooth event where carefully selected stakeholders meet to discover, refine, prioritize, validate and discuss requirements. Usually, a skilled facilitator manages workshop sessions.
Also, such workshops have the potential to reduce product defects and scope creep. It also helps to save time and effort by 10% on an average throughout the SDLC.
How does it work:
Ground rules are set initially.
Participants are put into different teams to get the discussion going with each team representing a mix of interests.
Participants are given a problem statement to discuss objectives to achieve. They even have to identify requirements, review existing requirements and prioritize each of them.
Survey/ Questionnaire:
Ad hoc conversations and surveys are helpful for gathering information quickly from a large group of participants. As free online survey software are easily available and hence, surveys is an inexpensive method to accumulate most of the information from potential end users and customers. Along with selecting stakeholders, a successful survey or questionnaire must have well-chosen participants. Questionnaire proves to be beneficial to address issues clearly for all concerned when a number of participants are large enough. Surveys offer open-ended input or string of finite choices for feedback, depending on the needs of the project. Open-ended surveys are beneficial to discover broader business needs; however, it gets more repressive to analyze with a large number of participants involved. The survey should be more precise and must be unambiguous. It is a good practice for an analyst to request gallantly so that survey participants respond by a reasonable deadline and that they keep any proprietary business information contained within the survey confidential.
Conclusion:
Thus using requirement elicitation techniques proves to be an ad on when it comes to gathering requirements. One must try using such techniques so that the fullest of the requirement gets covered.
About Author:
Rajeshwari Pawar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: rajeshwari.pawar@spluspl.com
Was a good read and was helpful.. Thanks!
ReplyDeleteWas helpful! Thanks!!
ReplyDeleteThat is one piece of really helpful article!
ReplyDelete