Stakeholder Interviewing and Facilitated Meetings: steps for eliciting requirements


Reading time for this brief article is less than 5 minutes. This article provides high-level steps for eliciting requirements when interviewing or holding a facilitated meeting with stakeholders; it was motivated by an attendee question at a recent Modern Analyst webinar: “Functional vs. Nonfunctional requirements.
The question was, “Can a Business Analyst elicit functional and nonfunctional requirements in the same iteration?” The webinar presenter (author of this article) answered the question with an elaborated yes. This article follows-up with a more comprehensive answer in the form of an elicitation process.

No matter what solution development approach (waterfall, agile or some form of hybrid), someone (regardless of job title) on the project must take on the role of a business analyst to enable change. The BA role can be in the context of addressing the

  • enterprise strategic direction – checking the fit of the business value proposition within the marketplace,
  • enterprise architecture to achieve the direction – insuring the organization components support the strategic direction,
  • benefits/cost to evaluate initiatives – selection of business requirements to pursue as projects,
  • product/service requirement identification to support business requirements.

This article focuses on product/service requirement identification in particular collaborative identification steps when holding stakeholder interviews and/or facilitated meetings. It does not address other elicitation methods such as research and experiments.

Stakeholder interviews and/or facilitated meetings are the activities where a BA elicits the information to form the product or service baseline of a project. During this interview, the BA must show respect for the time and availability of the stakeholder. The BA must have a clear idea of the elicitation end goal and a process of how to get there. The goal being a set of requirements that describe the needed solution that satisfies or supports the business requirements. These business requirements being the result of a marketing study to reaffirm or reset the enterprise strategic direction.

The Elicitation Steps

Knowing the elicitation end goal, the BA conducts a six step process for accomplishing the goal.

  • Step One: rapport and sharing 
    • The BA develops a rapport with the stakeholder: gaining trust by establishing common ground.
    • The BA shares the business requirements identified during enterprise strategic direction to ensure stakeholder understanding of the change urgency in order to manage resistance.
  • Step Two: capability 
    • The BA asks the stakeholder(s) what new or modified capabilities they need in order to achieve or support the business requirements.
  • Step Three: analyze, document and validate 
    • The BA analyzes and documents the stakeholder stated capabilities via
  • declarative statements (The system shall ........)
  • user stories (As a user ........),
  • or use cases (diagrams and scenarios).

Whatever method the BA choses, the BA uses action verbs to describe the capabilities. For example,

  • access
  • create
  • read
  • update
  • delete
  • enter
  • store
  • display
  • print
  • calculate
  • transmit
  • track

After the BA analyzes and documents the needed stakeholder capabilities, the BA follows-up with the stakeholder and validates the documented capabilities to ensure accuracy.

  • Step Four: constraints 
    • The BA asks the stakeholder(s) if there are any constraints associated with the capabilities. The formal name for these constraints are “business rules” and represent capability limitations and restrictions. The BA documents these business rules separately from the capability (i.e., referencing them with tags, e.g., BRxx; see post script) to allow the BA to change capabilities and business rules independently and to allow rules that are shared by multiple capabilities only to be stated once. Note that the importance of these business rules can not be over stressed; the rules will serve as a basis for a test plan in implementation (i.e., acceptance criteria).
  • Step Five: conditions 
    • The BA asks the stakeholder(s) if there are any conditions needed to exist when using the capabilities to ensure they are efficient, effective and secure. For example,
      • performance (response time)
      • availability (when and at what percentage)
      • reliability (percentage)
      • portability (use alternatives)
      • capacity/scalability (user volume)
      • maintainability (update ease)
      • compatibility (common connection)
      • usability (intuitive action)
      • security/audit (authority, restrictions)
      • data retention (time, duration)
      • backup/restore (time, duration)
      • disaster/recovery (time, duration)
      • training (help online or manuals)
      • documentation (references)

Note that most conditions apply to all subject capabilities and are most important to the infrastructure staff. And that nonfunctional requirements are as equally important when compared with functional requirements.

  • Step Six: transition 
    • The BA asks the stakeholder(s) if there are any transitional needs at implementation (i.e., one time requirements for a smooth move from a legacy solution to a replacement). For example,
      • data format conversions
      • record classification changes (i.e., state)

After the stakeholder interviews and/or facilitated meetings, these capabilities, constraints, conditions and transitions are then incorporated as characteristics of the solution using terms such as functional requirements (capabilities), nonfunctional or quality of service requirements (conditions) and transition requirements.

P.S. The real purpose of the requirement classifications is to serve as a checklist


 stakeholder with business rules


  • functional
  • nonfunctional


for the BA. Has the BA identified all the new and/or modified capabilities, business rules, conditions and transitions? There will be times that the BA will have to choose one classification over another – a gray area. For example,

  • Functional Requirement – Customers can access their account remotely
  • Business Rule (BR01) – All remote access must be via two-factor identification versus
  • Nonfunctional Requirement – Remote access must be secured via two-factor identification

In the above example, should the BA use a business rule or a nonfunctional requirement of the functional requirement? The BA can justify the example as a nonfunctional requirement since it describes a secure condition whereas the business rule does not limit a capability. Here is another example,

  • Functional Requirement – Manager can access customer accounts per BR02
  • Business Rule (BR02) – Managers can only access customer accounts that they own.
  • Nonfunctional Requirement – Managers can access customer accounts that they own

The BA can justify the second example as a business rule since it describes a limitation to the capability (access) whereas the nonfunctional requirement does not enhance the capability to being effective, efficient, or secure. Note business rules typically have a history (i.e., existed prior to any automation). Just one more example.

  • Transitional Requirement – Users need initial training on new capabilities.
  • Nonfunctional Requirement – Users need training on all capabilities.

The third example can be justified as a transitional requirement since it uses the word initial which implies upon implementation whereas the nonfunctional requirement describes on-going training.

However, don’t belabor the task of classifying a requirement; the main point is to capture all the requirements and business rules.

Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance. He holds an Advanced Master's Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF).
Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via -



Copyright 2006-2024 by Modern Analyst Media LLC