Requirements Team

Definition

Requirements Team

the team that performs the primary requirements engineering tasks

Classification

As illustrated in the preceding figure, Requirements Team is part of the following inheritance hierarchy:

• Type: Concrete
• Superclass: Engineering Team
• Subclasses:
  • None

Responsibilities

The team-specific responsibilities of the Requirements Team are to:

• Develop a top-level vision of the system or application.
• Elicit, reuse, analyze, specify, and manage the real requirements of the endeavor.
• Produce a formally documented consensus among all endeavor stakeholders (e.g., client, users, management, and developers) concerning these requirements for the next version [incremental iteration] of the application.
• Prioritize the requirements and determine the version of the application by which the requirements shall be implemented and delivered.
• Produce and maintain the associated requirements set of work products.
• Provide input (e.g., number of use cases and use case paths) to the endeavor cost and schedule estimation task.
• Provide a basis (e.g., use cases and use case paths) for the scheduling of the endeavor phases and builds.
• Maximize the quality of the requirements (e.g., correctness, completeness, consistency, testability, and understandability).
• Ensure that architects, designers, and implementers do not goldplate (i.e., add unrequired features to) the application.
• Work with the metrics team to ensure that the appropriate requirements metrics are collected, analyzed, and reported including for example:
  • Number and percentage specified, baselined, tested, and validated.
  • Requirements volatility.
  • Requirements engineering return on investment (ROI) estimates.

The requirements team typically inherits the general team responsibilities from the team method component.

Roles

The requirements team typically consists of two or more persons playing the following roles:

• Requirements Engineer, who:
  • Leads the requirements engineering activity by coordinating the efforts of the requirements team members.
  • Works with the other team members to:
    • Schedule the requirements engineering tasks and milestones.
    • Report the status of the requirements engineering activity (e.g., number of requirements identified, analyzed, and specified, and number of use cases identified and modeled).
  • Ensures that all members of the team use an appropriate requirements analysis (e.g., modeling) approach.
  • Ensures that the requirements are of sufficient high quality (e.g., consistent, complete, and testable).
  • Works with the customer representative, system architect, and test engineer to ensure an optimal, consistent prioritization of the requirements.
• Customer Representative, who:
  • Provides and clarifies requirements in his or her area of expertise.
  • Prioritizes the requirements from the business perspective.
  • Approves operational scenarios to be used in determining application acceptability.
• User Representative, who:
  • Provides and clarifies requirements in his or her area of expertise.
  • Prioritizes the requirements from the user perspective.
• Domain Expert, who provides and clarifies requirements in his or her area of expertise.
• Security Analyst, who:
  • Engineers the security requirements.
  • Acts as a liaison to the security team.
• User Analyst, who:
  • Engineers the user interface requirements.
  • Acts as a liaison to the user experience team.
• System Architect, who:
  • Identifies architecturally-significant requirements and ensures that they are addressed early.
  • Prioritizes the requirements from an architecture, design, and implementation perspective.
  • Ensures that each requirement is implementable from a system’s perspective.
  • Performs engineering trade-offs studies to reduce the risk of high-risk requirements.
  • Ensures (to the extent practical) that the requirements are optimally organized so that the requirements are easily allocatable and traceable to the major components of the system architecture.
  • Acts as a liaison to the architecture team.
• Software Architect, who:
  • Ensures that each requirement is implementable from a software perspective.
  • Acts as a liaison to the architecture team.
• Test Engineer, who:
  • Prioritizes the requirements from a testing perspective.
  • Ensures that each requirement can be validated.
  • Determines the validation approach for each requirement (e.g., testing, inspection, or demonstration).
  • Produces operational scenarios to be used in determining application acceptability.
  • Acts as a liaison to the independent test team.
• Technical Writer, who:
  • Specifies the analyzed requirements in the requirements specifications.
  • Produces and maintains the other requirements documents.

Tasks

The requirements team typically performs the following team-specific tasks in an iterative, incremental, parallel, and time-boxed manner:

• Requirements Engineering:
  • Application Visioning
  • Requirements Reuse
  • Requirements Identification
  • Requirements Analysis
  • Requirements Specification
  • Requirements Management

The requirements team typically inherits the common team tasks from the team method component.

Work Products

The requirements team typically produces the following work products:

• Application Vision Statement
• Actor Card
• Use Case Card
• Requirements
• Requirements Executive Summary
• System Requirements Specification
• External API Specification
• Glossary
• Domain Model Document

Guidelines

• A requirements team, even if its membership overlaps with other teams, is almost always appropriate.
• The amount of time and frequency of meeting of the requirements team will vary during the endeavor based on the phase of the endeavor and the volitility of the requirements.
• Members of the requirements team should:
  • Understand and be trained in:
    • Requirements engineering.
    • The application domain.
    • The desires and true needs of the customer and user organizations.
  • Have decision authority regarding the requirements and changes in scope, cost, and schedule of the endeavor due to the impact of changes in requirements.
  • Have excellent interpersonal skills for interacting with all of the stakeholders in the requirements.
  • Understand and respect the needs and viewpoints of all of the stakeholders in the requirements.
  • Be able to quickly achieve consensus and move on.
• The membership of the requirements team may well change during the course of the endeavor as:
  • Different types and levels of requirements are engineered.
  • The emphasis on requirements engineering changes.
• A requirements team should recognize that:
  • Requirements engineering is an ongoing activity that is performed iteratively, incrementally, and in a parallel and timeboxed manner.
  • Some of the stated requirements are neither good quality nor real requirements.
  • Some requirements will change during the course of the endeavor.
• A requirements team typically inherits the common team guidelines from the team method component.