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.
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.
· Quality Assurance Analyst.
· Application Architect.
· Data Modeler.
· Database Analyst.
· Infrastructure Analyst.
· Information Architect.
· End User.
· Subject Matter Expert.
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 Roles and Responsibilities
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.
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.
· 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.
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.
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.
The BA reviews the following:
· 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.
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
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.
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.
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.
Once the final product or solution has been developed, the close out activities will terminate the project.
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.
Changes can significantly alter the original project plans. Re-planning is an ongoing activity which can exist throughout the entire initiative.
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.
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 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.
· 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.
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.
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.
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.
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.
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.
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:
Its context, along with related issues.
Whether it lies within the project scope.
Its connection with other requirements.
The change upon external stakeholders and processes.
Its validity among team members.