Business Analysis: Planning and Management Requirements

This article covers the tasks involved with planning for the requirements of the project.

Requirements Planning Once the project is approved and funded, the project development phase begins. This includes requirements planning and management, which defines how requirements will be elicited, analyzed, and documented. It requires the BA to identify key team roles within the project, select the activities for information gathering, and develop communication strategies between stakeholders.

Requirements planning and management ensures the following:

· Team roles are filled by appropriate personnel.

· The most effective and efficient methods of gathering information are used.

· Stakeholders are properly identified and represented in the requirements gathering process.

· The team has a common understanding of the goals, scope, and activities of the project.

· Effective monitoring and reaction to problems, challenge, and opportunities.

· Tools and resources are scheduled and available.

· Requirements activities are coordinated with other project work.

· Changes are captured and reported quickly.

The BA will typically work closely with the project manager to provide direction to the team and reporting to the portfolio management group throughout this process. There are several sequential tasks that a BA goes through to plan the requirements phase of the project.

Task #1. Define Team Roles

The BA will identify and document all team roles relevant to requirements activities. Some team roles may exist only as needed while others will remain throughout the entire project. Depending upon the size of the project or the enterprise, single individuals may fill more than one role.

Typical team roles include:

· Executive sponsor (Solution Owner).

· Business Analyst.

· Project Manager.

· Developer.

· Quality Assurance Analyst.

· Trainer.

· Application Architect.

· Data Modeler.

· Database Analyst.

· Infrastructure Analyst.

· Information Architect.

· End User.

· Subject Matter Expert.

· Stakeholder.

Task #2. Identify and Document Role Responsibilities

Once the roles have been established, the BA will manage the work division among team members. He will document and communicate project responsibilities to the team. Responsibilities will be divided among team members according to their role in the company; requirements activities can sometimes overlap and some team members may share responsibilities, while others may have a narrow role. Broader responsibilities will require clear definition and communication so that each member understands the timing and reporting structure for the requirements.

Figure 5-1 shows some typical roles and their responsibilities. The titles and activities may change from company to company.

Figure 5-1 Roles and Responsibilities

The RACI Matrix

In order to easily define each role's responsibility within the requirements planning stage, a BA must illustrate the level of involvement during each step of the project. The commonly accepted model is the RACI matrix. This model defines each role's level by responsible (R), accountable (A), consulted (C), and informed (I). Figure 5-2 exhibits some common high-level responsibilities.

Figure 5-2

Task #3 Identify and Describe Stakeholders

Because a project's ultimate goal is to satisfy the needs of the stakeholders, one critical step in requirements planning is to identify and categorize stakeholders. A stakeholder is an entity that has a tangible interest in the outcome of the initiative or solution. It's important to recognize the stakeholders' role in the process early on, because discovering stakeholder needs later can cause disruptions, or worse, revisions.

Stakeholders can be identified by a few different techniques. The BA can start by reviewing reference materials, such as previous project documents. To identify additional interested parties that aren't listed, a questionnaire to the referenced stakeholders can be effective. Personal interviews and Web surveys are alternative ways to uncover or confirm interested parties.

Once they have been identified, the BA will then describe each stakeholder's interest, authority, and key characteristics that affect the project. The final deliverable is a stakeholder summary which includes a stakeholder list and the relationship each has in the initiative.

To gain a clear understanding of stakeholders' roles, the BA develops questions that have similar targets to those below:

· What are your job functions or duties?

· Who are your customers and/or vendors?

· What are your key business issues?

· How many end users do you manage or represent?

· How many and which computer systems do you use?

· How will the solution or initiative resolve your business issues?

· Are you a change leader or a change beneficiary?

· What needs will be met by the solution or initiative?

· What needs are missing from the project?

· Do any of your needs conflict with other stakeholders? How do they conflict?

· What are your inputs and outputs in your business process?

· What level of risk can you tolerate?

· Have you been involved with other projects?

· How are your needs prioritized? Is that prioritization affected by the solution or initiative?

· Will you provide requirements for the project?

· What is your responsibility within the project (RACI)?

· What is your availability in terms of resources and time involved in the project?

The questionnaire can be delivered during a face-to-face interview, by telephone, or through technology such as video conferencing.

Task #4. Define Work Division Strategy

The way in which project requirements will be fulfilled is determined by the business analyst. She will develop a systematic plan intended to meet goals within the project. If there is a project team, work must be divided among members according to their functionality. The strategy should both define the work division and coordinate information and knowledge transfer between team members.

The work division strategy can be designed using one of the following methodologies:

1. Subject Matter Expertise . Responsibilities are divided up according to the skill set required. For example, the BA most familiar with a process task, such as data modeling, will be the point person for that information.

2. Task Complexity . Activities will be assigned according to the level of knowledge or experience that the BA has. A multi-dimensional project may have a senior business analyst coordinating data collection while individual tasks are performed by less seasoned analysts.

3. Previous Stakeholder Relationships . If a BA has worked on an earlier project and had a favorable relationship with a particular stakeholder, he may be assigned activities that relate to that stakeholder.

4. Geography and Culture . If the initiative involves international business units or stakeholders, the team's work may be divided according to each BA's location and shared cultural beliefs and customs. This is particularly useful when specialized linguistic skills are required.

5. Areas of Interest . Similar to subject matter expertise, the work is divided according to the level of interest each team member has in a particular area. For example, if one BA is attracted to work flow analysis and another is interested in capabilities, then the activities will be divided accordingly.

6. Physical Limitations . If one or more team members are restricted by physical capacity or location, the work division will accommodate those limitations.

7. Availability . Work division will be allocated according to schedules, milestones, and deadlines. Not all BAs may be available throughout the entire project or may only be available during the requirements elicitation phase.

Task #5. Coordinate Information Flow among Team Members

The BA must ensure that information is collected, documented, and accurately represented according to the organization's architecture and business environment. In order to manage information flow, all requirements for management activities should comply with both team and company norms.

The BA reviews the following:

· Standards.

· Policies.

· Processes.

· Documentation.

· Methodologies.

· Templates.

· Additional commonly accepted practices.

The goal of this task is to create a seamless, consistent process method which will easily connect team members with their requirements activities and each other. It should save time and help avoid work stoppage or re-work.

Task #6. Knowledge Transfer

One of the more critical points of a project is when tacit knowledge (hard to articulate) is converted to explicit knowledge (clearly defined). According to the IIBA, knowledge transfer is "a systematic approach to capture, collect, and share tacit knowledge in order for it to become explicit knowledge." As this is a part of information flow, the BA must ensure that the transfer meets team and enterprise guidelines.

Knowledge transfer can be complex because a) it generally is known by one or a few organization members and b) it can be challenging to express according to information flow standards. Some tacit knowledge resides in undefined habits and culture.

Examples of knowledge that must be transferred include:

Embrained knowledge
Embodied knowledge
Encultured knowledge
Embedded knowledge
Encoded knowledge

---------------------

Planning Considerations

Requirements planning and management is typically the responsibility of the business analyst. This phase is very important as it will have a great impact upon requirements identification, documentation, and response mechanisms. If tasks are missing or requirements are not identified properly, the entire project will suffer. The BA develops requirements planning to fit within the project manager's overall project planning.

There are seven steps in the requirements planning process. The tasks involved with this phase include the following:

Task #1. Identify Key Planning Impact Areas

The BA must consider all requirements activities that will impact both the organization and project specifics. The planning elements should address project objectives and conform to the project charter. Some of the elements that will be considered include:

· Project risks.

· Project expectations, goals, and objectives.

· Organizational standards, policies, processes, and others.

· Re-planning strategies.

· Stakeholder needs, criteria, and location.

· Project type.

Within the requirements planning phase, there are methodologies that are used to address the life cycles (timelines) of system and product development. Typically, there is a heavy IT system component that must be developed within the project's framework and the BA will include this component during this phase. The methodologies most often used are the System Development Life Cycle (SDLC) and Project Life Cycle (PLC). They are distinct yet related, and each will have a significant impact on the project's outcome.

Task #2. Consider the SDLC Methodology

The process by which the IT components are developed must fit the enterprise's architecture and follow the company policies, procedures, process, culture, and so forth. One of the methodologies is the System Development Life Cycle (SDLC) method. This process uses a multiphase approach that manages the product through initial requirements, to implementation, and to testing and maintenance.

Want to learn more? Take an online course in Business Analysis.

The BA will develop a model that will usually include the following steps:

1. Planning. Starting with a concept, the BA will explore relevant stakeholder needs and construct an initial framework.

2. Design. Working with the information architect, database analyst, and other IT stakeholders, the BA will determine the platform and data requirements.

3. Implementation. The IT developer will assist in putting the system in place. This can be done iteratively or following complete system design.

4. Testing. This phase can be done in two stages: 1) the development team runs programs to uncover bugs within the system architecture, and 2) end users will beta test the system to determine the ease of use and appropriate data collection and distribution methods.

5. Acceptance. Following the software release test phase, the project manager and team members will approve the version that the enterprise will use. This may require top level approval from decision makers.

6. Maintenance. As the system is used, problems, opportunities, and risks will be monitored, and updates will be developed as needed.

There are three common process flow options that can be employed: 1) waterfall, where each step is completed in order, 2) iterative, where incrementally larger steps are added following completion of initially small steps, and 3) agile, where feedback is received at each level of development following regular testing.

Task #3. Consider PLC Methodology

The Project Life Cycle (PLC) methodology also encompasses all the steps involved in completing the project. The BA will usually work with the project manager to define, categorize, and prioritize each task. The model used may either be already determined by the enterprise architecture or can be developed by the BA. Figure 6-2 displays some typical phases in the process flow. Each phase can be broken down into tasks and subtasks.

Figure 6-2 Process Flow

Once the final product or solution has been developed, the close out activities will terminate the project.

Task #4. Consider Project Risks, Expectations, and Standards

The BA will analyze the requirements risks, stakeholder expectations, and organizational standards to ensure appropriate project planning and management. Because stakeholder requirements can change, and project risks can materialize, the BA must consider requirements change management strategies that will reduce the overall negative impact to the project. Priorities should be clearly defined and communicated as the project planning and execution is conducted. The BA may use the RACI model or others to manage this process.

Task #5. Re-planning

At times, planning activities must be revised to meet changing requirements. This will require the BA to modify and update the requirements planning periodically. The IIBA describes this phase as "evaluating the impact of proposed change(s) in the project environment or requirements to determine the impact on the base lined plan."

Changes can significantly alter the original project plans. Re-planning is an ongoing activity which can exist throughout the entire initiative.

Task #6. Consider Stakeholder Needs and Location

Stakeholder requirements and location can have significant impacts on the project outcomes. Dispersed locations increase the complexity of the proposed solution or initiative. Communication strategies and requirements delivery must be managed in order to enable an efficient process, so it's important for the BA to determine, define, categorize, and prioritize stakeholder requirements during the initial phase of requirements planning and management.

Task #7. Consider Project Type

In order to manage requirements delivery that meets the solution or initiative, the BA must clearly define the project's outcome. The type of initiative that is undertaken will determine the complexity of the requirements activities. For example, purchasing and implementing a new software package will typically require a lower level of detail than developing the software in-house. At times, the project type may not be apparent at the beginning of the project, due to changing requirements and/or stakeholder involvement.

Types of projects include:

· New software development.

· Improved business processes.

· Outsourced process development.

· Software selection and/or maintenance.

· Organizational change.

The differences in requirements planning and management can vary greatly depending on the initiative. Also, the stakeholders involved, their needs and locations may alter the BA's choice of requirements strategy.

Selecting Requirements Activities

The business analyst, as part of the requirements management process, will determine, define, and communicate the requirements activities that form the foundation of the solution or initiative. In doing so, the BA must "select a complete set of requirements activities such that the result is a clear, concise set of requirements on which the realization of the solution can be based." The activities that the BA outlines heavily influence the outcome of the project.

The four major sets of activities include:

· Requirements Elicitation. Gathering key criteria and data from stakeholders.

· Requirements Analysis and Documentation. Defining, categorizing, and prioritizing requirements to ensure appropriate outcomes for the solution or initiative.

· Requirements Communication. Transferring knowledge to the analysis team and stakeholders.

· Solution Assessment and Validation. Observing the solution or initiative impact and confirming that the project was implemented correctly and achieved the stated objectives.

The BA will evaluate, modify or discard activities as necessary while the requirements process moves forward. The BA will employ the following steps as he plans the activities:

1. Determine Elicitation Stakeholders and Activities.

The goal is to choose all key stakeholders that will either impact or be impacted by the project. The roles can be filled by either the actual stakeholder or a representative. The BA must ensure that each stakeholder has both the time and the knowledge to provide business or user requirements input. Once the parties have been identified, the BA will draft a set of activities intended to gather a complete set of requirements from each stakeholder. The processes for elicitation should align each requirement with its value, timing, impact, and importance within the project.

2. Determine Analysis and Documentation Activities.

Appropriate analysis and documentation tools and models must be in place once the requirements are elicited from stakeholders. The BA may choose to employ templates that have been previously used on other projects, if applicable, or may design a model that fits the specific needs of the project. Typically, a work breakdown structure (WBS) is used during this phase.

3. Determine Requirements Communication Activities.

The BA will establish the appropriate resources, techniques, and strategies to communicate requirements. They must implement the most efficient, cost effective and complete methods of knowledge delivery. The documentation activities that have been determined earlier must address the communication needs of all audiences involved (including internal and external stakeholders).

4. Determine Solution Assessment and Validation Activities.

The BA must ensure that the solution or initiative chosen matches the business and the user requirements that have been elicited. He must also confirm that the stated objectives were met. A set of activities is developed to assess the design, dependencies, and architecture of the solution or initiative, and validate that the solution fits the organizational goals, processes, architecture, and culture.

Requirements Risk ManagementWithin the requirements phase, there may be risks that must be discovered, defined, communicated, and managed. A requirements risk is a positive or negative outcome that is a direct result of requirements activities. These may be risks that only present issues within the requirements process or they can affect the overall project outcome. One example would be poor quality interview techniques during requirements elicitation. Often the project manager will be responsible for overall project risk management, while the BA will manage these requirements risks.

Some requirements may present a risk of regulatory non-compliance, whereas others may risk public relations issues. Requirements risks can carry impacts to multiple requirements or stakeholders, or a risk may arise that creates dependent risks later in a process. There are also risks that jeopardize the project's capacity to deliver on its objectives. Each requirement must be examined using a cost-benefit ratio combined with a risk assessment profile.

There are several tasks involved in defining, assessing, and managing requirements risks (see Figure 6-1). The BA must first identify potential risks, making sure that the risk assessment is complete and contains sufficient detail to determine an appropriate response. Next, they will define the approach to planning, monitoring, and controlling risk response. Action plan and mitigation strategies are then developed to respond to unforeseen risks. Finally risk monitoring is done to make sure planning and assessment are updated to meet changes in requirements activities.

Figure 6-1 Tasks for Managing Risks

------------------

Establish Estimates

One of the BA's fundamental requirements is to make sure the project meets organization expectations. In order to quantify those expectations, the BA must establish estimates that are based upon empirical data gathered throughout the enterprise analysis. These data include three basic components: scope, schedule, and resources. Each requirements task will then be assigned to the appropriate resource, based upon skill level, knowledge base, and availability.

There are seven key tasks that are performed while establishing requirements estimates: 1) identify mil1stones, 2) define units of work, 3) estimate the effort needed per milestone, 4) estimate time required per unit of work, 5) identify assumptions, 6) identify risks, and 7) modify the requirements plan. The requirements milestones will mark a point where the task or sub-task is complete. A unit of work is defined by the IIBA as "a task that cannot be decomposed further." Assumptions are factors that exist but are not documented. Figure 7-1 defines the BA functions used to establish estimates.

The BA can use similar requirements activities from previous projects to determine units of work and duration per unit of work. While reviewing past documents, the BA must take into account any differences in project assumptions, processes, and resource availability between the previous and present projects. Elements such as problem resolution, knowledge sharing, stakeholder feedback, and document review, and revisions should also be built into requirements estimates. The BA must also be mindful of any gaps or deficiencies that exist between the two projects.

Figure 7-1 BA Functions Used to Establish Estimates

Manage Requirements ScopeWhile the requirements are being defined and scheduled, the requirements scope must be developed in order to establish and maintain a baseline from which new or modified requirements can be included. The scope also provides a model with which the BA can trace requirements activities, tasks, and components, can identify impacts to internal and external systems and processes, and can identify requirements changes that are necessary because of activities changes.

Task #1. Establish Requirements Baseline

The BA will define standards, points of reference, from which modifications can be measured. The baseline is typically signed off by the project manager and the affected stakeholders. The final deliverable is usually the business requirements document. Without a baseline, the project scope is difficult to define and requirements changes cannot be measured. For iterative and agile projects, requirements are not typically baselined at the same time. The BA will review the baseline periodically to ensure its constant validity.

Task #2. Create Requirements Tracking Model

Traceability of requirements allows the BA to manage requirements changes from the baseline. He can perform vital function including: 1) verifying that all stakeholders affected by changes are properly considered, 2) considering the impacts of changes to the solution or initiative, and 3) monitoring differences in requirements that occur following the establishment of a baseline.

Many times the BA will use a model to define traceability. The traceability matrix connects one set of activities to another and shows the interaction among requirements to be implemented. The following types of traceable information can be managed using a traceability matrix (see Figure 7-2):

Source. Where the requirement originated, identified by stakeholder.
Rationale. The business goal that the requirement is intended to satisfy.
Requirements. Which requirements are involved and any dependencies upon other requirements.
Design (Test). Which elements are necessary to implement or test a requirement.
Interfaces. Where a requirement affects an external system or stakeholder.

Traceability Matrix

Figure 7-2 Traceability Matrix

The BA can analyze the matrix to identify missing requirements or gaps in connectivity between requirements. He can also determine which requirements are predecessors (prior needs) and which are successors (dependent activities). A requirement is considered complex if the predecessor has many successors. In this case, the requirement may have to be decomposed further to simplify its traceability.

Task #3. Identify Impacts to External Systems and other Project Areas

Will requirements change affect other project areas or systems outside the organization? The BA will determine if adjustments to requirements lie outside the baselined list, and what impact they will have on external schedules, costs, risks, resources, and systems. As changes occur, they should be reflected in the traceability matrix and communicated to impacted areas quickly.

Task #4. Determine Scope of Change Management

The BA determines how the project's scope will be managed during the project. The BA will usually develop a scope management policy that exists throughout the requirements process. Part of that process deals with how to respond to changes in requirements. Requirements change management (RCM) is the process of monitoring and responding to requirements changes as they relate to systems development, process improvement, or re-engineering, and organizational change. A BA will develop a change model to organize how a project will adapt to changes. Metrics, sometimes called Key Performance Indicators, are used to define a baseline from which change can be assessed. Roles and responsibilities following a change are also defined.

Some requirements, particularly customer requirements, change frequently throughout the project's life cycle. Specifications, yields, output thresholds, and other criteria may change throughout product development, so the requirements model must be updated to reflect those changes. For example, many IT development projects require constant RCM due to changing technological capabilities and system bugs. The BA's scope management policy must also ensure that any requirement change (and response) meets project goals and objectives.

Measurement and Reporting

The system that the BA chooses for measuring and reporting requirements activities is critical to the success of the project. The tools used will often dictate whether objectives are met on time and on budget. Typically, the BA will use units of measurement called metrics. The metrics used will usually be like those used in other enterprise projects or within industry standardized techniques. The system that the BA chooses for measuring and reporting requirements activities is critical to the success of the project.

There are two primary sets of metrics in a product development project:

Project Metrics. Those associated with carrying out the project.
Product Metrics. Those associated with a product output.

Measurement collection can take place throughout the project, either as requirements are fulfilled or on a scheduled basis. As metrics may be evaluated by multiple stakeholders, accurate and timely reporting is critical as well.

Managing Requirements ChangeThe success of any requirements planning and management is dependent upon how the BA or team handles changes within a project. The BA will usually determine who will handle changes, and how changes will be administered and communicated. Once a modification, cancellation, or adaptation of an existing requirement is asked for (called a change request), the change management process should define the process and timeline that the change request will undergo.

The BA must first understand the request and examine its impact (stakeholder's affected, processes altered, structure change, and others), then the BA will document the changes and define any dependencies which need modification. Next, he'll analyze the change request to determine: