An Overview of Requirement Elicitation

An Overview of Requirement Elicitation

  • January 15, 2018
  • Technology


Elicitation requirement is getting business requirements thorough various processes from users and stake holders as well as to understand the system constrains

Here are some Elicitation techniques


Brainstorming is all about the solving problems. In brainstorming we can use to solve the existing problem in early or middle or end of a project.


Individual: Project team member creates a list of ideas

Open: Participants call out ideas that are captured by scribe

Structured: Participants write down their ideas, Facilitator goes participant to participant to have them share on idea each, Continue sharing process until all ideas are exhausted


  • Generates multiple ideas quickly
  • Involves multiple perspectives
  • Promotes equal participation


  • Ideas are not discussed /explored
  • True meaning may be ambiguous or misunderstood

Best Practices

  1.             Determine type of brainstorming meeting ahead of time
  2.             Publish an agenda prior to the brainstorming session
  3.             Clearly state the objective of the meeting
  4.             Create environment to encourage participation
  5.             Establish ground rules

Do not discuss ideas during the brainstorming session – only questions to clarify

  • Do not dismiss or discount an idea or person
  • Do build on others suggestions and ideas
  • Do have fun

Create process for combining, categorizing, and summarizing like ideas

  • If complex, create multiple meetings to keep meeting fatigue low
  • Schedule follows – up meetings
  • Prioritize final ideas to plan further analysis
  • Allows votes for top ideas

Requirement Workshop

Requirement workshop can be defined as a structured and facilitated event for getting carefully selected stakeholders together to discover, refine, prioritize, validate and discuss requirements.


Formal requirement workshop

Highly structured and formal

Carefully selected group of stakeholders

Define, create, refine and reach closure on business requirement

Business Process Improvement Workshops

Semi formal

Analyzes existing business processes

 Identify and agree upon solutions implement process improvements

Agile Requirement Workshop

Generally more unstructured and informal

Used generally to document the scope of the requirements


  • Effective at getting real requirements instead of perceived requirements
  • Greater change of obtaining consensus because issues and questions are asked in real time
  • Confirmation of requirements accuracy is immediate
  • Successfully gather requirements from a large group in a short period of time
  • Documentation is completed within hours of the session and provided quickly back to participants for review


  • Difficult to get appropriate stakeholders in one room at same time
  • Increased number of global projects poses logistic difficulties and adds complexity
  • Success of the session is highly dependent on the expertise of the facilitator
  • Can be expensive

 Best Practices

  • Determine the type of requirement workshop ahead of time
  • Be clear on what the session will deliver
  • Utilize modelling tools to visualize the processes and requirements
  • Facilitator should be experienced


Interviewing is a systematic approach for eliciting information from a person (or a group of people) in an informal or formal setting by asking questions and documenting the responses. In interviewing we can gain understanding of high level needs, constrains and assumptions. It reduces the misunderstanding due to cultural differences, lack of openness and acronyms. It can be informal and formal.


  • Personal Interviews
    • Scripted questions-interviewees answers are documented
    • Exploratory questions to clarify and validate requirements, while removing assumption
  • Job shadowing
  • Walk through a work day with a user or user group observing them
  • Customer site visits
  • Understand operational environment
  • Task Analysis
  • Ask end users to walk through their current jobs
  • Show as in process in order to identify essential and frequent tasks
  • Interviewer asks questions to understand what works well and what doesn’t


  • Promote interactive discussion to explore detailed information
  • Identify conflicts or discrepancies about stated needs or requirements
  • Encourage participation and build relationships by establishing rapport with the stakeholder
  • Enable observations of nonverbal behaviour
  • Allow immediate follow-up to ensure understanding


  • Require access and commitment of stakeholders
  • Creation of scripted interview questions can be consuming
  • Stakeholders have difficulty describing their future needs, so the focused on what they do currently
  • Resulting documentation is subject to interpretation of the interviewer
  • Transcription and analysis of interview data can be complex and expensive

Best Practices

  1. Determine the best interview type to accomplish your goal
  2. Appropriately prepare for the interview
  3. Schedule interviews ahead of time
  4. Check understanding often
  5. Ask for examples of their issues and document screen shots
  6. Be sure to interview end users, not just senior management who think they know how the process/system is used
  7. Allow time in the schedule to debrief and finish documentation after each interview

Interview Document

In interview document generally contains name of the interviewee, role of person and their primary responsibilities, open ended question, space for interviewer’s insights, action item box for flagging key pieces of information


Surveys are the process of ask a question or a series of questions in order to gather information about what most people do or review of quantifiable data already available


  • Open ended questions

Gives respondents an opportunity to answer in their own words

Useful, but very time consuming to interpret and catalogue

  • Closed ended questions

Finite set of answers for each question

Lends itself to statistical analysis

Tough to create questions that are not leading or need an other answer


  • Require limited stakeholders time
  • Effective at reaching geographically dispersed stakeholders
  • Relatively fast and inexpensive to administer
  • Supplement more subjective information, such as options gained through interviews


  • Relatively low response rate
  • Poorly word questions may provide inaccurate information
  • Use of open ended questions requirements more analysis by the business analyst
  • Require both instrument training and problem or business domain experience
  • Incentives for responding might be expensive

Building Best Surveys

1.Make Sure that Every Question Is Necessary

You’re building your survey to obtain important insights, so every question in the survey should play a direct part. It’s best to plan your survey by first identifying the data you need to collect and then writing your questions.

2. Keep it Short and Simple

You’re building your survey to obtain important insights, so every question in the survey should play a direct part

3. Question should be direct

Ask direct question clear and precise language

  1. Save demographic information for last
  2. Create rewards for participating
  3. Notify the participants when the survey is available and continue to remind them to participate


Documentation Review: what is it?

  • Review existing documentation
  • User guides
  • Prior System implementation documentation, including lessons learned
  • Technical documentation
  • Lessons learned after completion of latest project
  • Formulates context for understanding the scope of the project


  • current process documentation provides a starting point


  • Existing documents may be old and out-of-date
  • The reviewer needs domain and technical
  • Expertise to determine if existing
  • can be time consuming and may not provide the desired payback

Documentation Review: Best practices

  • know the purpose for reviewing
  • set self -imposed time Limits
  • Create a glossary of terms former project documentation

Analysing Interfaces: what is it

  • Reviewing the system, People, and process linkage
  • Determine needs for input, output, and the medium
  • Describes manual and automated processesWhy do I need Requirements?
  • Guides the design of the eventual solution
  • Without correct requirements, you cannot design or build the correct product

Categories of Requirements

1.Functional Requirements

  • Things the product must do
  • Action the product must take

2.Non Functional Requirements

  • Properties or qualities the product must have
  • how the product will behave


  • Global requirements
  • purpose of the project
  • Users of a product

  Product Constraints

  • purpose of the Product-reason for building the product
  • Client ,customer and stakeholders – people that interact with product
  • Users of the Product- intended end-users and how they affect product usability
  • Requirements Constraints-Limitations of the project and restrictions on design
  • Naming Conventions and Definitions- vocabulary of the product
  • Assumptions-assumptions developers are making

Product Constraints Examples

  • The product budget must not exceed $50,000
  • The product shall run on the company’s existing machines
  • Implementation of the product cannot interrupt daily business
  • The last 5 years of historical data needs to be made available in the product


Functional Requirements

  • Scope of the product-defines the boundaries and connections to other products
  • Functional and Data Requirements-Things the product must do and data

Manipulated by the functions

Functional Requirements Examples

  • The product must track recipes down the ingredient and quantity level
  • The recipes must be editable by an administrator
  • The product must display the orders that need to be completed
  • The product must interact with the current Point of Sale system
  • The product must display the recipes to make the orders

Non-Functional Requirements

  • Look and Feel Requirements-intended appearance
  • usability Requirements-based on the intended users
  • Performance Requirements-how fast, big, accurate, safe, reliable
  • Operational Requirements-Product’s intended operating environment
  • Maintainability and Portability Requirements-how changeable product must be
  • Security Requirements-Security, confidentiality and integrity of the product
  • Legal Requirements-conformance to applicable laws

Non-Functional Requirements Examples

  • The product shall use the company colours and logos
  • The Product shall be intuitive, even to first time users
  • The product shall only bakers and administrators to view recipes
  • The product shall be easily upgraded for future business needs
  • The product shall be scalable to multiple bakery locations

SMART Requirements


  • it clear ,no ambiguity
  • Consistent, same terminology
  • Simple


  • Measure progress towards goal
  • Indicators should be quantifiable


  • Validate requirement is feasible


  • Validate the effort is worth the requirement


  • Trace requirements through design implementation and testing

 Tips for Producing Valid Requirements

  • Should use the word shall
  • Only one shall per requirements
  • written in short, simple sentences
  • Consistent terminology
  • Stated positively
  • Accompanied by notes and comments to support and clarify
  • Stated imperatively
  • Don’t use will and should

Translations for Requirement Verbiage

  • Or-Select one of the options
  • Can, should-Expresses desire or suggestion instead of requirement
  • Must-reliability
  • Are, is will-Descriptive part to lead into the requirement
  • Support and -confusing
  • But not limited -Incomplete requirement
  • Shall-dictates specification and functional capability

Phases of the Requirements Process

1. Requirements Elicitation

Requirements Elicitation all about how do the documentation and how stakeholders through various different techniques

 2. Requirements Analysis

Take all requirements spinning them and modelling them in a way there for business and technique to draw the same conclusion it more important make the requirements readable

3.Requirements Specification

Requirements Specification all about categorization requirements which is functional or non-functional

4.Requirements Approval

The 3 level of approval the business, the technical, oracular responsible     approval

Business Rules

A business rule is a rule that defines or constrains some aspect of business and always resolves to either true or false.

Business Rules Examples

  • Entered email address must appear valid
  • Each class must have at least one instructor
  • Customer must have a valid driver’s license to rent a vehicle
  • A quote must be completed prior to an invoice being generated

 Business Rules Best Practise

  • When documenting business rules, keep it simple
  • Business requirements are used to comply with business rules
  • Each business rule may need multiple requirements
  • Business rules should not be changed


Leave a Reply

Your email address will not be published. Required fields are marked *


Subscribe to our monthly newsletter with useful information about building valuable software products.
Don’t worry, we value your privacy and won’t spam you with any bussines enquiries!

Subscribe to our monthly newsletter with useful information about building valuable software products.

Recent Posts

Are we ready for business?

Leave a Reply

Your email address will not be published. Required fields are marked *