Stakeholder Interviewing and Facilitated Meetings: steps for eliciting requirements

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

 business

 stakeholder with business rules

 solution

• functional
• nonfunctional

 transitional

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).