Process Steps Involved in Elicitation of Requirement

Process Steps Involved in Elicitation of Requirement:

  • Requirement inception: Relates to the use of context free questions
    • To establish the basic understanding of the problem,
    • To understand the people who wants the solution,
    • To understand the overall nature of the solution expected,
    • To gauge the effectiveness of the collaboration between customers and developers.
  • Requirement Identification: It Involves
    • Enlisting the basic well known and fairly defined needs
    • Articulating the basic well known and fairly defined needs
  • Requirement elicitation: Refers to finding out or extracting from the clients/ users
    • Requirements which are unclear, vague, or concealed and need explicit articulation for the understanding of the developer team.
    • About what the overall product/solutions objectives are.
    • About which needs are to be supported on priority.
    • About how the product / solution fits in to the business needs.
    • About what kind of use will be made of the product/solutions on day to day basis.

Quality Requirement Elicitation

Quality Requirement Elicitation:

While Gathering requirements, attention should be paid to ensure that quality requirements are gathered during the elicitation process. Every requirement should confirm to the following quality norms:

  • Correctness – The correctness of the requirement should be confirmed with the client’s stakeholders.
  • Feasible – The requirement should be deliverable by making use of available tools, technique, method and people, within budget and time.
  • Necessary – With respect to undertaking, the development and immediate implementation for meeting the basic needs of the client, the ranking of the feature should be of relatively high importance.
  • Prioritized – With respect to priority scale, the ranking of the feature should be one of relatively high importance.
    • Requirements, if very important, should be immediately included in the present release of the proposed system.
    • Requirements, if absolutely necessary should be essentially implemented in the next release.
    • Requirements, if important but not necessary, should be conditionally included in next release.
    • Finally, requirements if purely optional, their implementation should depend upon the constraints of the resources and schedule.
  • Unambiguous – The requirement should be easy to read and understood by all.
  • Concise – The requirement should be brief or short or to the point with only the relevant information. It should be mixed up with other details related to project scope parameters or background.
  • Verifiable – The implementation of the requirements in the end product or software deliverable should be testable and measurable by human or mechanized means.