Requirements Collection

Requirements collection is a crucial process with challenges:

  • Lack of a clear vision
  • Limited buy-in across different functions
  • Conflicting Priorities
  • Difficulty reaching agreement on Scope definition
  • Change management
  • Schedule estimation

PMBOK Requirements Collection:  Requirements Definition, Validation, Documentation, and Management

Tools and Techniques: (Organize the following by Survey, Creativity, Document, Observation, Support Techniques)

  • Interviews
  • Focus Groups
  • Use Case Analysis
  • Observations
  • Facilitated Workshops
  • Questionnaires and Surveys
  • Group Creativity Techniques: Brainstorming  with Nominal group, Affinity, Delphi techniques,  and Mind mapping

“Good for validation but potentially less capable of “unpacking” what is the new problem(s) that we don’t yet understand”

Requirements Collection Plan and Checklist:

It is essential when starting out to create plan for how requirements are going to be collected and managed. The level of detail is guided by the nature of the work and project constraints. It is important to stay focused on the fundamental questions of Why are doing this? What are we trying to accomplish? What is the problem and how will we measure progress? Further consideration of strategy may occur including the use of stop-gap measures.

A Context Diagram (Data Flow Diagram) is an effective resource to create a shared and visual understanding of the interaction between actors and the solution under design. It is a good place to test for completeness of all environmental, system, organizational, and external or third-party components and information flow. It can help uncover important project attributes including stakeholders, integrations, sources, manual interfaces, etc. A Context Matrix may also be used; it contains the same information represented in a tabular fashion.

A checklist is a valuable tool: What are the essential items we must understand to clearly define requirements? Specific, Measurable, Achievable, Realistic, Traceable (SMART Model)

  • Collection Plan (initial stakeholder plan)
    • Traceable to stakeholder (and needed, verifiable, and achievable)
      • Seek to understand and document intent
      • Validate shared understanding of assumptions and constraints
      • Thoroughly examine any implicit requirements that may be “obvious” but not clearly documented
    • Address all facets of entire lifecycle of project and product
      • Flag requirements that are not in scope or have insufficient value or benefit
      • Identify requirements that are not implementable (IT) or may be more suitable as a manual process
      • Do we understand the underlying business and IT processes that currently support each requirement?

Best practice: When writing a requirement, design a test plan to match. By testing early and finding problems early, there is more time to resolve and manage any schedule impact. (requirements collection-test plan development-time management)

Executive level decisions often have impact both at scale, and introduce people and change implications. Requirements collection at the executive level needs to explore and understand forward looking leadership vision and consider objectives, strategy, and change management initiatives. A vital part of project leadership is helping to sustain team alignment and motivation through inevitable turbulence. The ability to internalize and share an ongoing narrative inspiring continuing commitment to the organization’s strategy and objectives is paramount. A higher level perspective on uncertainty should also be elicited and captured for input in to risk management processes. Insight into organizational capability or areas of priority for future competency may influence project design feasibility or procurement decisions. This integrated context is essential to gaining and sustaining team attention, which has a direct effect on realizing quality results throughout the project life cycle.

Particular care must be taken with cross-functional processes. Interaction, communication, coordination processes need to be defined in a manner that meet stakeholder needs or business requirements in a model that is sustainable by being as simple as practically possible. Aligning activities and processes across functions may extend the time required to  collect and document requirements because of the need to gain agreement on an integrated model.

 Best Practice: Validate each requirement can be met within the project objectives and scope.

  • Documentation Plan (templates, checklists)
    • Time stamp to establish “age of requirements”
    • Tables are recommended to document use cases. Use diagrams are better applied during facilitated requirement’s discussions, and can be distracting in a written document.
    • Consider a glossary if there are domain specific terms or concepts that must not be ambiguous or misunderstood
    • Can be and are prioritized (all requirements from all stakeholders must be prioritized-balance ranking criteria by role)
    • For more complex projects, consider more modern tools BPMN (Business Process Modeling Notation) or UML (Unified Modeling Language) Activity Diagrams in place of mature flow charts (originally for punch card programing developed by IBM 1968)
    • “Packaging of Documentation”
      • One package containing all artifacts including flow charts, NRF, use cases, data models, etc.)
        • Consider different audiences: from developer to executive and different information needs
        • It is a good practice to ask stakeholders how they would like the information presented.
      • For Agile models, smaller documentation increments will likely be more appropriate

Best Practice: Care should be taken when using templates as they can artificially limit understanding of requirements, and analysis of impact or risk that may occur during implementation. They should not be the starting point, but may be an important output or Organizational Process Asset.

  • Requirements Management Plan (collection, baseline, ongoing stakeholder communication, change)
    • Include reasonable and agreed upon margins on specifications based on growth projections or other scenarios
    • Alignment of requirements by stakeholder hierarchy, with documentation structure to support each audience level
    • Consistency with organizational strategy and objectives

An important milestone in the process is a facilitated review with the business team, sponsor, and/or key stakeholders to explain the degree of rigor and demonstrable evidence, and communicate attendant risk factors and impact.

How to estimate or set expectations the time to collect requirements from stakeholders (schedules, tools, maturity of thought, etc.)? Time boxing elicitation activities will help define a portion of the schedule and create a sense of urgency. If after review the level of completeness required to meet project goals and risk profile is insufficient, the process can be iterated.

  • Early on in a project, some requirements from stakeholders may not be clearly expressed, could be soft, descriptions that do not meet the Requirements Quality Criteria described below. Facilitating a measurable decision may be effective: option B will do X for ten dollars, option B will do Y for twenty dollars. Validating a mutual understanding of a verifiable requirement is the goal, with a deadline for the stakeholder to reflect and consider change if needed.

Scenario Analysis

Scenario Analysis is an effective approach to elicit and understand requirements. It is most effective to start with the what-goes-right scenarios, and then evaluate variations (what-can-go-wrong).

  • Fundamental criteria: pre-conditions for successful outcome of use case

It is often valuable to undertake a critical thinking exercise encompassing a large picture view of the project’s environment. There may be requirements based functionality, that when placed under more demanding conditions, may cause system failure. Developing design and test models that may be expected over a long time horizon is important.  In general, this technique could include industry trends, potential competitor actions, physical change, duration of use, and changes in laws and regulation. Examining how the environment could change, how the system could be called on to adapt and function, and what other scenarios that could emerge is an important part of the product design context.

Documenting As Is vs. To Be

Of course every organization has a completely documented Enterprise Architecture with all as-is processes and workflow fully documented. It is important to understand “How it is done today”. In the rare case where this in not in place, how much effort should be applied to this work? Some considerations:

  • May surface unusual use cases; they may of course be low frequency occurrences
  • Greater insight into business processes, avoid missing activities manual or automated
  • Better evidence to prioritize what is automated vs. manual
  • Opportunity to critique current processes, benchmark, and apply lean improvement techniques
  • Document decisions
  • Valuable for transition planning


BABOK Reference:

The field of Business Analysis offers many valuable tools, techniques, and processes to build an accurate and well structured requirements model. The BABOK model defines five types:

Business Requirements (Objectives and Goals)

Stakeholder Requirements: (The user shall…..)

  • It is very important to ask, more than once, “Have we forgotten anyone?” Discovering a stakeholder with influence late in a project can lead to unplanned change and delay.

Functional Requirements: (The system shall….)

  • Please see the following page on developing Behavoiral Analysis to develop functional requirements from use cases
  • Performance requirements (card or document) and matching acceptance criteria or test

Non-Functional Requirements: (NFR)

  • The conditions and capabilities that must be in place
    • What is in place today?
    • What needs to be changed, modified, improved, redesigned, simplified, replaced?
    • What new capabilities, technologies, processes are needed?
    • What skills and competencies may be required to support the new model?
  • Regulations, governance, quality, tolerances, etc.
  • Business process requirements
  • IT: availability, response time, security
  • Privacy requirements (what can be displayed, transmitted, stored by state by country)

Transition Requirements (Implementation)

Best Practice: Ask stakeholders “How will we know the deliverable meets your requirement?”, to validate mutual understanding, and establish a clear acceptance protocol.

Requirements Categorization: importance to satisfaction of stakeholders (Kano Model)

  • Basic factors
  • Performance factors
  • Excitement factors

Requirements Quality Criteria: Qualifiers help make it clear, precise, unambiguous and complete

  • Ranked
  • Valid
  • Correct- something that is actually required
  • Objective- no subjective interpretation possible & an objective test or simulation is possible
  • Consistent- no contradictions or multiple explanations or measurement criteria
  • Verifiable- there is a way to determine it has been met
  • Realizable (feasible to implement, and feasible to support long-term)
  • Traceable
  • Complete
  • Understandable- easily understood in a clear and precise statement

With the following analysis work completed:

  • No redundant or duplicate requirements-may be the result of multiple teams collecting requirements resulting in similar requirements that must be sorted and consolidated.
  • At the right level
  • Disability accommodation analysis
  • Risk analysis performed
  • Interface analysis performed
  • Gold Plating eliminated

Best Practice: A formal requirements baseline must be established at the beginning of the project, and requirements should be validated and traceable. The requirements management process can undertake future change impact analysis against this clear and visible reference.