Chapter 6

Plan Requirements Activities

In This Chapter:

Planning Requirements Activities

After the decisions described in Chapter 5 have been made, the business analyst works with the core planning team to capture and record the following information in the requirements management plan:

Requirements elicitation activities and deliverables, e.g., interviews, workshops, procedures, surveys, current system reviews. Deliverables include interview notes, workshop output (models, text statements), survey results.

Requirements analysis deliverables, e.g., requirements understanding models, diagrams, lists, tables, structured text

Requirements specification and documentation deliverables, e.g., user requirements statements, business requirement document, concepts of operations document, initial solution concept document, statement of work, system requirements document, domain, process and data models

Requirements management deliverables, e.g., requirements management plan, system engineering management plan, requirements verification and validation plan, requirements traceability and verification plans

Requirements verification and validation activities, e.g., requirement artifact quality reviews, user acceptance test activities

It is tempting to plan the requirements elicitation activities only at the beginning of the requirements phase. However, it is risky to focus on only one aspect of requirements development, since plans for later activities may impact the amount of elicitation that is needed. In addition, elicitation activities will likely be conducted in an iterative manner when the business analyst is performing later requirements tasks. Therefore, we recommend a rolling wave approach to planning requirements activities. This means establishing plans for all activities in the requirements phase at a detailed level and establishing plans for the requirements activities in the design, construction, test, and deliver phases at a summary level. These plans are then detailed later in the project life cycle. Refer to Figure 6-1 for a depiction of the requirement planning and elicitation activities conducted following the approval of the new project in the Enterprise Analysis phase.

Figure 6-1—Flow of Information into the Requirements Planning and Elicitation Process

Detailed Requirements Phase Plans

At the beginning of the project, detailed plans are established for all activities in the requirements phase. A synopsis of the resources needed, the activities to be conducted, and the deliverables to be produced is provided for each requirements subphase. See Figure 6-2 for a work breakdown structure (WBS) template depicting the requirement work to be considered when planning requirements activities throughout the project. Based on the project life cycle that has been selected, and the size, complexity, and risk of the project, select the activities that should be performed to ensure project objectives are met.

Requirements Elicitation Planning

When planning for requirements elicitation, consider the following:

Resources. Identify all stakeholders (end-users, business unit process owners, business unit manager, customers, etc.) that will be involved in the requirements elicitation sessions. In addition, identify the core team that will prepare for and conduct the elicitation activities.

Activities. Plan for all elicitation sessions with customers, users, and stakeholders to begin the requirements capture process. Typical elicitation activities include stakeholder analysis, requirements workshops, interviews, surveys, workplace observations, focus groups, interface analysis, reverse engineering, prototyping, review of existing system and business documents, and note-taking and feedback loops.

Deliverables. Identify deliverables that will be produced at the conclusion of each elicitation session. Deliverables may be a stakeholder list accompanied by information about the stakeholders to involve in each elicitation session, interview notes, survey response compilation and analysis, workshop results in the form of notes, requirements statements, use cases, scenarios, tables, graphs, and models.

Figure 6-2—Requirements Activities WBS

Requirements Analysis Planning

Establish plans for all requirements analysis activities. Refer to Getting It Right: Business Requirement Analysis Tools and Techniques, another volume in this series, for detailed information about requirements analysis activities and deliverables.

Resources. Bring together a small core team of business and technology experts who will be involved in analyzing and progressively elaborating the business requirements. This team will likely be composed of some of the same members who conducted elicitation; however, expert modelers and tool users may need to be added.

Activities. Plan for all activities that will take place to analyze the information captured during elicitation sessions, including some or all of the following:

Structure requirements information into various categories, evaluate requirements for selected qualities, represent requirements in different forms, derive detailed requirements from high-level requirements, and negotiate priorities.

Determine required function and performance characteristics, the context of implementation, stakeholder constraints and measures of effectiveness, and validation criteria.

Decompose and capture requirements in a combination of text and graphical formats.

Study requirements feasibility to determine if each requirement is viable legally, culturally, technically, operationally, and economically; trade off requirements to determine the most feasible requirement alternatives.

Assess requirements risks and constraints and modify requirements to mitigate identified risks.

Model requirements to restate and clarify them. (Note that text statements are appropriate when precise definitions are needed and that graphical representations are preferred when sequence and timing are required. Sometimes simple tables or lists suffice.)

Derive additional requirements as more is learned about the business need.

Prioritize requirements to reflect the fact that not all requirements are of equal value to the business.

As requirements are decomposed and restated, conduct feedback sessions with those who provided the requirements.

Deliverables. Identify all deliverables that will be produced at the conclusion of each analysis activity. Identify the number and types of models, documents, tables, lists, matrices.

Requirements Specification and Documentation Planning

Establish plans for all requirements specification activities. Refer to Getting It Right: Business Requirement Analysis Tools and Techniques for detailed information about requirements specification and documentation activities and deliverables.

Resources. Bring together a small core team of business and technology experts who will be involved in specification of the business requirements. This is likely to be a subset of the original core requirements team.

Activities. Plan for all specification activities:

Elaborate and structure requirement specifications, providing a repository of requirements with a complete attribute set.

Through the process of specification and progressive elaboration, the requirements team often detects areas that are not defined in sufficient detail, which if not addressed can lead to uncontrolled change to system requirements.

Identify all the precise attributes of each requirement. Doing so ensures an understanding of the source, criticality, risk, priority, and relative importance of each unique requirement.

Deliverables. Identify deliverables that will be produced at the conclusion of each specification activity. The system specification document(s) or database that archives all requirement information is the key output of the requirements specification process.

Requirements Validation and Requirements Phase Exit Planning

Establish plans for all requirements validation and phase exit activities. Refer to Getting It Right: Business Requirement Analysis Tools and Techniques for detailed information about requirements validation and phase exit activities and deliverables.

Resources. Bring together small focus groups of business and technology experts to validate the business requirements.

Activities. Plan for all validation and phase exit activities, including:

Quality review sessions with focus groups of business and technology experts.

A formal control gate review to gain approval to baseline the requirement set and formally control subsequent requirements changes, exit the requirements phase, and proceed to solution design and construction.

Deliverables. Identify deliverables that will be produced at the conclusion of the requirements phase:

Updated project schedule, cost, and scope estimates (made by the project manager), and business case (made by the business analyst), to provide the information needed for management to determine whether continued investment in the project is warranted

Baselined requirements; a method to trace requirements through development, verification, and validation plans; and a formal requirements change control process to manage changes to requirements

Summary-Level Requirements Plans for Design, Construction, and Test Activities

Establish high-level plans for all requirements activities performed during design, construction, and test phases.

Resources. Establish a small business analysis team that works with the design and development team to manage requirements throughout the development life cycle.

Activities. Plan for all requirements management activities:

Allocating requirements to different subsystems or subcomponents of the system.

Tracing requirements throughout system design and development to track where in the system each requirement is satisfied.

Managing changes and enhancements to the requirements to add, delete, and modify requirements during all project phases.

Continually validating and verifying requirements with requirements sources throughout the project.

Deliverables. Identify deliverables that will be produced during the design, construction, and test phases. These deliverables might include documented change requests, implemented changes to requirements, and requirements traceability confirmation.

Summary-Level Requirements Plans for Delivery of the Business Solution

Establish plans to prepare the business and technical communities to accept and operate the new business solution and to measure the business benefits achieved.

Resources. Establish a small team of business and technical experts that will build plans to establish readiness to accept and operate the new business solution.

Activities. Plan for all requirements solution deployment activities:

Business operations: transitioning from the old to the new business policies, processes, tools, application systems and technologies; designing and developing training, organizational structuring, staffing, facilities, desktop tools, communications, etc.

Technical operations: transitioning from development to operations environments; designing and developing training, organizational structuring, staffing, facilities, infrastructure hardware and software, communications, etc.

Metrics and measurement system to determine the business benefits of the new solution.

Deliverables. Identify deliverables that will be produced to manage the deployment of the new business system, including memos, e-mails, training sessions, training manuals, user manuals, operations manuals, etc. In addition, plan for the development of the measurement system to determine the benefits attained by the organization from the new business solution, including measurement collection, analysis, and reporting system.

Requirements Planning Considerations

Several barriers may arise when planning requirements activities. These barriers include:

Distributed, culturally diverse users. Users and team members are not co-located and do not speak the same business language.

Difficulty getting user involvement. Understand and keep in mind that users, sponsors, and customers must continue to support business operations while attending requirements elicitation sessions.

Difficulty articulating requirements. It requires a very different skill set to describe a business process than to operate it.

The business analyst works collaboratively with all key business and technical stakeholders to overcome these barriers to success.

The Requirements Management Plan

The requirements management plan (RMP) is an agreement between the project manager, the business analyst, the project sponsor, and all key project stakeholders on not only the requirements elicitation approach, but also on the methods for requirements analysis, specification, documentation, and validation. All decisions made by the core team during the requirements planning process are documented in the RMP. This plan helps to ensure that the funds are secured and the time is scheduled to complete requirements-related tasks and identifies the subject matter experts that will need to be made available for elicitation and validation activities. The RMP serves as a key communication tool for the business analyst and project manager. It is first used to secure the business and technical resources needed to complete the early requirements activities. The resources in the business units or the field may not be readily available to participate in interviews and workshops unless plans are developed and approved by management. Sufficient time needs to be provided for organizations to free the resources that are best suited to provide the needed expertise. An example of the potential complexity when global teams are involved for one task is illustrated in Table 6-1.

Benefits of the Requirements Management Plan

The RMP becomes the roadmap for requirements documentation and management throughout the life of the project. There are other names for this plan, such as business analyst work division strategy or business analyst work plan. Key benefits of an RMP are:

Communicating the requirements activities that will be completed and who will be responsible or involved in the process

Ensuring that users, sponsors, customers, and developers have a common understanding of the requirements-related work

Serving as an agreement on tasks that require funding and scheduling in the project management plan

Drawing the line on what requirements can be included in the time allocated

Narrowing the expectation gap at the beginning of the project rather than later, when it is too late to make adjustments

Table 6-1—Sample Requirements Elicitation Task Information

Relationship to Project Management Plan

Unfortunately, most teams don’t use an RMP. Without it, business analysts are neglecting to use a valuable tool that contributes significantly toward delivering the project on time, on budget, and within the expected scope.

The requirements management plan is a subsidiary to the project management plan (PMP), but is typically a separate document. The variances between the two plans are shown in Table 6-2.

After the RMP has been reviewed and approved by the project sponsor, changes are to be made in a controlled manner. The RMP not only defines requirements elicitation, analysis, and documentation activities, but also supports requirements verification and validation and requirements change management.

Table 6-2—Variances between the PMP and the RMP

Project Management Plan	Requirements Management Plan
Primary project control document for baselining budget, time and scope assumptions, and constraints	Subsidiary element of the project management plan
Owned by the project manager	Owned by the business analyst
Documents project management objectives to meet schedule, cost, time, and scope	Documents product objectives throughout the project life cycle

Requirements Management Plan Elements

As a formal project document, the RMP provides several key pieces of information:

The methods, tools, and techniques to be used

The identified stakeholders and users to be involved

The elicitation, analysis, specification, documentation, and validation activities

The requirements artifacts to be created, e.g., documents, models, tables, lists

The process to manage changes to requirements during design, construction, test, and delivery

A typical RMP table of contents is shown in Figure 6-3. See Appendix C for a sample RMP template.

Requirements Management Plan Approval

Successful business analysts gain an agreement in advance on the scope of business analysis activities. As you can see by the sample RMP depicted in Figure 6-3, there are a significant amount of requirements activities that can be conducted. The business analyst is cautioned to plan requirements activities that will be completed to gain an understanding of the requirements that is just good enough to proceed to design.

Figure 6-3—A Typical Table of Contents for an RMP

The project manager and business analyst secure the approval of the project sponsor, formally agreeing to the planned requirements activities. It is best to have a formal meeting between the project team and the sponsor, customers, and users to present how requirements will be gathered. The goal of this session is to secure allocation of time for business and technical representatives to participate in the elicitation process.

Summary

The RMP is a formal project plan that describes the requirements process used on the project.

The RMP is a communication tool to propose requirements activities. Once approved, it becomes the work plan for requirements tasks.

The RMP is used to secure agreement between the project team and the key stakeholders on their participation in the requirements process.

Key elements in the RMP are:

Description of project scope, applicable standards, and related documents

Stakeholder and user identification

Requirements deliverables and mandatory attributes

Verification and validation process

Requirements change management process

Requirements-related risks

Resource estimates for completing requirements tasks

Capital and expense requests

Action Plan for the Business Analyst

Identify examples of the issues associated with the requirements planning processes that have been encountered in the past.

Detect if the process problems are associated with lack of planning for the requirements activities.

Prepare a requirements management plan for the next project.