Requirements Management and Communication

4.0 Overview

  • Activities and considerations for managing and expressing REQ to a broad and diverse audience
  • Communication:
  • Ensure that all stakeholders have a shared understanding of the nature of a solution
  • Ensure that those stakeholders with approval authority are in agreement as to the requirements that the solution shall meet
  • Is both challenging and critical to the success of any initiative
  • Management:
  • Assists with understanding the effects of change and linking business goals and objectives to the actual solution that is constructed and delivered
  • Ensures that the knowledge and understanding of the organization gained during business analysis is available for future use

4.1 Manage Solution Scope & Requirements

  • Purpose
    • Obtain and maintain consensus among key stakeholders regarding the overall solution scope and the REQ that will be implemented
  • Description
    • Securing approval of REQ from stakeholders
    • Managing issues that emerge during elicitation and analysis
    • As REQ are refined or changed as the result of new information, changes will be tracked as well
    • If the business need changes during the lifetime of an initiative, the solution scope must also change
    • Changes to the solution scope may also lead to changes in previously approved requirements, which may not support the revised scope
    • Change-driven approaches typically do not use a formal change control process
  • Input
    • Requirements Management Plan – process to be followed
    • Solution Scope – can be managed in its own right
    • Stakeholder List, Roles, and Responsibilities – reviewing and approving REQ
    • Stakeholder, Solution, or Transition Requirements [Communicated or Traced]
  • Elements
    1. Solution Scope Management
      • Stakeholders will frequently identify additional needs that the solution may be capable of addressing
      • If additional REQ are invalid or do not fall within the solution scope, BA must act to resolve the conflict, done by
        • Amending the business REQ and solution scope
        • Reaching agreement that the REQ does not fall within the scope of the initiative
    2. Conflict and Issue Management
      • As REQ are developed and reviewed, conflicts often arise
      • Facilitate communication between the stakeholders, through formal meetings among affected stakeholders
      • Conflicts must be resolved before formal approval is given to those requirements
    3. Presenting Requirements For Review
      • Formally in a written system REQ specification or a structured walkthrough with various levels of stakeholder
      • Informally in an e-mail message, a note, or verbally
      • Needs to be enough formality to support the methodology and ensure that the stakeholders will review, understand, and approve them
    4. Approval
      • Ensure that the stakeholder(s) responsible for approving requirements understands and accepts the requirements
      • Required for the result of other BA work (allocation of requirements, proposed problem resolutions)
      • A record of the decision may be kept
  • Techniques
    1. General Techniques
    2. Baselining
      • Once REQ are approved, they may be baselined
      • Future changes are recorded and tracked
      • Current state may be compared to the baselined states
    3. Signoff
      • Formalizes agreement by stakeholders
      • May be required by organizational standards
      • Typically involves a face-to-face final review
      • Approval may be verbal or be recorded
  • Stakeholders
    • Domain SME – Involved in the review and approval of REQ
    • Implementation SME – Ensure that the REQ can be implemented
    • Project Manager – Involved in assessing the solution scope in order to define the project scope
    • Sponsor – Reviewing and approving
  • Outputs
    • Requirements [Approved]

4.2 Manage REQ Traceability

  • Purpose
    • Create and maintain relationships between business objectives, requirements, other team deliverables, and solution components to support business analysis or other activities
  • Description
    • “Tracing” a REQ refers to the ability to look at a REQ and the others to which it is related
    • Identifies and documents the lineage of each requirement
      • Backward traceability (derivation)
      • Forward traceability (allocation)
    • Ensure solution conformance to requirements
    • Reasons for creating relationships
      • Impact Analysis
      • Requirements Coverage
      • Requirements Allocation
  • Input
    • Requirements – May potentially be traced to other requirements
    • Requirements Management Plan – Defines how and whether traceability is being performed, the tools that will be used to support traceability and the processes that will be used to manage it
  • Elements
    1. Relationships
      • Need: if a related requirement is also implemented
      • Effort: easier to implement if a related REQ is also implemented
      • Subset: decomposed outcome of another requirement
      • Cover: fully includes the other requirement
      • Value: affects the desirability of a related requirement
    2. Impact Analysis
      • To assess or evaluate the impact of a change
    3. Configuration Management System
      • To trace large numbers of requirements
  • Techniques
    • Coverage Matrix – table used to manage tracing when there are relatively few requirements
  • Stakeholders
    • Implementation SME: to link the requirements to the solution
    • Project Manager: supports project change management
    • Tester: when creating test plans and test cases
  • Outputs
    • Requirements [Traced]: have clearly defined relationships to other requirements within the solution scope

4.3 Maintain Requirements for Re-use

  • Purpose
    • To manage knowledge of REQ following their implementation
  • Description
    • Identify REQ that are candidates for long-term usage by the organization
    • REQ must be clearly named and defined and easily available to other analysts
    • May be stored in a repository
    • It can facilitate impact analysis of new, proposed changes to the business
    • It can support activities including training, corporate governance, and standards compliance
  • Input
    • Organizational Process Assets: how and when requirements should be maintained for re-use
    • Requirements: as long as they describe information of use to the organization beyond the lifetime of an initiative
  • Elements
    1. Ongoing Requirements
      • Contractual obligations, quality standards, service level agreements, business rules, business processes
    2. Satisfied Requirements
      • It is still a requirement as long as the business stakeholders need it
  • Techniques
    • None
  • Stakeholders
    • Business Analyst: different business analyst than the author
    • Domain SME: REQ referenced by him
    • Implementation SME: development of regression tests and impact analysis of enhancements
  • Outputs
    • Requirements [Maintained and Reusable]:
      • Expressed in a form that makes them suitable for long-term usage
      • May become organizational process assets

4.4 Prepare Requirements Package

  • Purpose
    • To select and structure a set of requirements in an appropriate fashion to ensure that the requirements are effectively communicated to, understood by, and usable by a stakeholder group or groups
  • Description
    • To decide which format(s) are appropriate for a particular project and its stakeholders
    • Must be clear, concise, accurate, and at the appropriate level of detail
    • Provide evaluation of possible alternatives, formal reviews and approvals, inputs to solution design, conformance to contractual and regulatory obligations, and maintenance for re-use
    • To help decide how to present requirements:
      • How detailed do the requirements need to be?
      • What information is important to communicate?
    • Misunderstanding of requirements will adversely affect solution implementation
    • Possible forms for requirements packages:
      • Formal Documentation – Vision Document or Software Requirements Specification
      • Presentation – high-level overview of the functionality delivered
      • Models – process map, or captured on a whiteboard
  • Input
    • Business Analysis Communication Plan: describe the stakeholder groups, their communication needs
    • Organizational Process Assets: templates that can be used
    • Requirements: may be packaged at any point in their lifecycle
    • Requirements Structure: should contain a consistent, cohesive, and coherent set of requirements
  • Elements
    1. Work Products and Deliverables
      • A work product is a document or collection of notes or diagrams used by the business analyst during the requirements development process:
        • Meeting agendas and minutes
        • Interview questions and notes
        • Issues log
        • Presentation slides
      • A deliverable is a specific output of the business analysis process that the business analyst has agreed to produce. Used as communication mechanisms
    2. Format
      • Combination of many formats in one requirements package
      • Each organization also has an approved suite of tools that are used for documentation
      • Additional Considerations for Requirements Documentation:
        • Package may have a Table of Contents outlining what is included
        • Grouping of the requirements into categories should be clearly identified
        • Include a revision log to document changes between versions
  • Techniques
    1. Requirements Documentation
      • Business Requirements Document
      • Product Roadmap
      • Vision Document
    2. Requirements for Vendor Selection
      • Request for Information (RFI)
        • Seeking information to evaluate possible options
      • Request for Quote (RFQ)
        • Seeking vendors who can implement an option
      • Request for Proposal (RFP)
        • Follows formal review and selection process of vendor
      • Consider how each vendor solution will be evaluated
      • Develop evaluation criteria based on the business requirements before looking at available products
      • Avoid using closed ended questions
      • Stimulate the vendors to provide extensive information regarding their product and service offerings
  • Stakeholders
    • Domain SMEs and End Users – Interested in ensuring that the REQ are achieved.
    • Implementation SMEs – Obtain an understanding of the overall requirements
    • Project Managers – Include deliverables in the project plan
    • Regulators – Specific legal, contractual, or governance requirements
    • Sponsors – Want summaries and high-level requirements
    • Testers – Build an effective testing strategy
  • Output
    • Requirements Package – Document, presentation, or package of requirements ready to be reviewed by stakeholders

4.5 Communicate Requirements

  • Purpose
    • Essential for bringing stakeholders to a common understanding of REQ
  • Description
    • Includes conversations, notes, documents, presentations, and discussions
  • Input
    • Business Analysis Communication Plan – what information, which stakeholders, when the form it should occur in
    • Requirements – Any requirement may be communicated
    • Requirements Package – Must be distributed, reviewed, and the contents must be communicated to stakeholders
  • Elements
    1. General Communication
      • Performed iteratively and in conjunction with most of the tasks in the other knowledge areas
      • May lead to elicitation of additional requirements:
        • Enterprise Analysis Tasks – Business case and solution scoping
        • Elicitation Tasks – Requires specific communication skills
        • Requirements Analysis Tasks – Refined, modified, clarified and finalized through effective communication
        • Solution Assessment and Validation Tasks – Assessments of the solution, allocation of requirements to solution components, organizational readiness, and transition requirements all must be communicated
    2. Presentations
      • Ensure that internal project quality standards have been adhered
      • Formal and Informal Presentation
  • Techniques
    • Requirements Workshops – to familiarize all parties with the existing solution scope
    • Structured Walkthrough – begins with a review of the requirements to be discussed
  • Stakeholders
    • All
  • Outputs
    • Communicated Requirements

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s