Start a Conversation

Getting Started With Requirements Elicitation

Blog

We’ve all had our fair share of building pieces of IKEA furniture, right? First, you separate all of the components, count all of the nuts and bolts, and read through the directions to make sure you have everything in place before you start. Someone compiled all of the directions and pieces so you would have all of the necessary pieces to put together. In consulting projects, this person is a Business Analyst. A business analyst performs requirements elicitation so a project team will have the necessary data and requirements documented to carry out the project at hand. They gather not only information on the current situation, but also document what the end goal is.

A business analyst also analyzes, validates, and manages requirements, but for today, we’re only touching on requirements elicitation.

There are two types of requirements: functional and non-functional.

 

Functional Requirements

According to the BABOK Guide, Functional Requirements “describe the capabilities that a solution must have in terms of the behavior and information that the solution will manage.” This includes business requirements, user requirements, and system/technological requirements.

  • Business requirements: documentation of current business objectives and goals and why a change is needed or wanted.
  • User requirements: what is the user’s story? If it’s software, what does the user journey look like? Where are they facing roadblocks?
  • System/technological requirements: what do the organizations’ current technology stack look like? Are there certain programs or technologies they won’t be able to implement or uphold? What is the current technology situation?

Non-functional Requirements

Non-Functional Requirements “do not relate directly to the behavior of the functionality of the solution, but rather describe conditions under which a solution must remain effective or qualities that a solution must-have,” according to the BABOK Guide. Non-functional requirements include these types of characteristics:

  • Accessibility: is it in line with ADA requirements?
  • Interoperability: how are systems communicating with one another?
  • Usability
  • Security
  • Confidentiality
  • Maintainability
  • Manageability
  • Reliability
  • Response time

These don’t necessarily have to be elicited at separate times. Instead, you can gather both functional and non-functional requirements through elicitation techniques. Not all requirements will need to be identified either – it’s highly dependent on a project.

 

Elicitation Techniques

There are several different elicitation techniques. Depending on the stakeholder’s preference and current situation, elicitation techniques will vary among projects. More examples and descriptions of elicitation techniques can be found in the BABOK Guide.

  • Interview Workshops: one on one interviews between a stakeholder and project team member to ask specific, focused questions to gather information. An easy and direct way to gather the information you’re looking for.
  • Focus Groups: typically, open-ended questions asked to a larger group of stakeholders who will be involved in the project. The 5 W’s (who, what, when, where, and why) are good conversation starters.
  • Observation: shadowing and sitting in on existing meetings, learning about how organizations use their existing systems. A good alternative for when people have a difficult time describing what their current working process is like.
  • Documentation Analysis: analysis of any documentation available for review (i.e. reports, system flows, SOP’s, etc.).
  • Brainstorming: a collective effort to come up with ideas or solve problems.
  • Surveys: sending over interview questions instead of doing it in person (good for remote conferences).
  • User Interface (UI/UX) Analysis: identifying gaps in the current user flow to better optimize the users’ experience. Examples of activities in a UI/UX analysis are card sorting exercises and chalk mark exercises.

Requirements elicitation is only one responsibility of a business analyst. Ultimately, a business analyst helps set a project up for success by gathering and documenting the business and technological needs. Carefully selected elicitation techniques will ensure a smooth project kickoff and set the stage for a project’s trajectory.

Need help getting started on a project in your organization? Get in touch with one of our consultants for a free consultation.

Looking for your next opportunity in technology? View our open positions on our careers page.