10 reasons to focus on requirement elicitation before project kick-off

Requirement Elicitation or Gathering can be termed as the practice of making research on requirements for a system from users, customers or stakeholders. For a project team, some of the most important tasks that a Business Analyst (BA) performs include acquiring, gathering, recording, and reviewing project specifications.BA’s use this approach mostly during planning and need to gather feedback and provide key information from partners as well as organize and facilitate effective execution of requirements.

Following are the essential guidelines needed to be taken care of during Requirement Elicitation before the project Kickoff :

• Establishment of Project goals and scope:

  Define why you organize and schedule this meeting and what you hope to accomplish by holding the gathering and elicitation session of these requirements. You should have clearly defined goals and goals to explain why this meeting is going on. Your stakeholders should have a clear understanding of why they were invited and why they should attend this meeting to help you get the project requirements.

• Discover and record requirements from all relevant sources.

  One should gather the requirement from many sources including the stakeholders, SME’s i.e…, Subject Matter Expertise, Managers and if necessary then from the customer too. Operational user’s input is important since their inputs are important in delivering a product, system or services that help improve the efficiency of the end products.

  Reverse Engineering is also an option where new requirements can be used to uncover requirements for legacy systems which might not be documented. Nevertheless, with many changes in the activities of investors, a continual compilation of specifications and refining activity is needed to ensure that initial requirements are identified and subsequent capability evaluations are undertaken by evaluating the next iteration of requirements due to change, enhanced clarity in need, or a staggered approach to implementation.

• Documentation

  It may be difficult to categorize and coordinate most criteria. As the process matures, the attributes of requirements need to be documented and kept up to date in order to remain traceable during testing, validation, and verification. This process helps in defining criteria that are inconsistent, incomplete and conflicting.

  Such specifications are the most frequently tracked attributes.Such specifications are the most frequently tracked attributes.

• Identifying the Stakeholders

  There are often hidden stakeholders inside a project. Hence, it becomes very important to identify them. In your kickoff and introductory meetings ask questions in order to figure out who the real users are. Such individuals will often not be the main decision-makers, but their buy-in is vital to a successful project. Dissatisfied consumers who are required to use a program that has been built without their knowledge every day are a key ingredient in a failed project.

• Be transparent with Requirement Elicitation

  One should be transparent with the requirement elicitation phase and brush them efficiently before explaining it to the other team members and stakeholders. Not only does this transparency help to ensure that everyone is on the same page, it also fosters a sense of customer buy-in throughout the project beginning with business requirements.

• Be sure and don’t make Assumptions about the requirement

  Don’t think you understand everything even though it seems apparently clear.
  Even a seemingly clear requirement can mask all sorts of underlying, assumptions and requirements. One makes assumptions based on their available knowledge, expertise or facts. These are anticipated incidents or situations that will arise during the life cycle of your project.

  Assumptions are supposed to be true, but they don’t necessarily end up being true; they can sometimes turn out to be false, which can have a significant impact on your project. They contribute risks as they may or may not be true to the project. Hence, one needs to be specific about the project requirement and must analyze it before.

• Prioritize your Product Features

  Companies are moving towards a Minimum Viable Product (MVP) in an agile approach that encapsulates the least amount of features that would qualify at release as a successful product. Even if you follow a non-agile methodology, when you collect requirements, prioritizing is your friend. It’s easy to turn into wishlist meeting sessions where investors tell Santa everything they want. The idea is not to disregard this knowledge (in fact, if you’re using Active Listening, it often shows expectations and assumptions), but rather to prioritize simply and transparently what you’re listening to and what’s in the context of your initial launch and what’s not. You still want to log wish-list items, “nice-to-have” items, etc. but prioritizing lets you concentrate your attention and allows you to make things better.

• Define the Capability Scope and Risk Involved

  It is necessary to generate the capability scope that provides a framework for the project and guides the requirements collection process of the requirement. It is the first source of information that is being generated before any product went underway.

  Scope evaluations are not limited to the phase of requirements. These are often used to include construction operations from start to finish, specific activities (e.g. pilots and tests) and minor roles in larger projects. Scopes of capabilities are created as needed.

  There are certain things that are needed to be taken care of during this phase. Let us have a look at all of them.

  • What is the purpose behind the project? Or What will the project Achieve.
  • Who are the Sponsors?
  • What activities and deliverables are required during the project and Out-of-scope things involved.
  • Critical assumptions and Queries related to the project.
  • Risks involved with the projects.
  • Certain Constraints related to time, milestones, resources and funding that may dictate how the project will be carried out.

• Work to obtain final agreement from stakeholders to contribute.

  Planning to hold a face-to-face evaluation meeting at the end of the requirements collection process, attended by participants who submitted requirements. When possible, involve members of the project team. Last-minute changes in requirements are often necessary in order to reach an agreement that they are complete and correct. Requirements are “baselined,” “locked,” or “frozen” at that point.

  But one needs to be careful since flexibility is required throughout the life cycle to ensure that program development and implementation do not try to satisfy the exhaustive set of requirements when it is possible to achieve quicker production or maybe reduced costs, which is why the priority stage is very critical.

• Document Requirements for Final Approval.

  Much of the future work of the project will be determined by the design plan or specification. Ask reviewers who know the features of “good” requirements to review it before the specification is approved. Good requirements are unique and distinctive, feasible, consistent, comprehensive, traceable, testable, non-implementable, achievable, unambiguous and verifiable. Changing or removing “bad” requirements and their dependents may be necessary. Dependent requirements are related requirements, often implied or resulting from a functional requirement.