Define the process that will be used to approve requirements for implementation and manage changes to the solution or requirements scope.
This task determines the appropriate requirements management process for a particular initiative. It includes determining the process for requirements change, which stakeholders need to approve change, who will be consulted or informed of changes, and by extension, who does not need to be involved. The task also includes assessing the need for requirements traceability and determining which requirements attributes will be captured.
Business Analysis Approach: The selected approach may include a definition of appropriate requirements management processes.
Business Analysis Plan(s): The business analysis plan(s) define which deliverables are to be produced and when. Deliverables cannot be managed until they are created.
Organizational Process Assets:Standard templates or processes for requirements management within the organization may exist. The business analyst must be knowledgeable about the organization’s approach to requirements definition, as it will greatly influence the process steps, tasks and deliverables required or expected during the requirements planning and monitoring activities.
A requirements repository is a method of storing requirements, including those under development, those under review, and approved requirements. Repositories may include whiteboards, word processing documents, diagrams and models, wikis, requirements management tools and applications, or any other method of recording information that allows requirements to be single-sourced and available to all relevant stakeholders for as long as they are needed. All approved requirements should be found in a repository (as opposed to using tools such as email, which may not reach all relevant stakeholders and may not be retained) and stakeholders need to be able to locate requirements in that repository.
The system for adding, changing and deleting requirements should be consistent and clearly understood by the team. File or component naming standards will assist with categorizing and maintaining requirements.
Determine whether and how to trace requirements based on the complexity of the domain, the number of views of requirements that will be produced, potential impacts from risk, and an understanding of the costs and benefits involved. Tracing requirements adds considerable overhead to business analysis work and must be done correctly and consistently to have value.
3. Select Requirements Attributes
Requirements attributes provide information about requirements, such as the source of the requirement, the importance of the requirement, and other metadata. Attributes aid in the ongoing management of the requirements throughout the project lifecycle. They need to be planned for and determined, along with the requirement themselves, but are not in themselves part of the solution definition.
Requirements attributes allow the requirements team to associate information with individual or related groups of requirements and facilitate the requirements analysis process by expressing such things as which requirements may add project risk or require additional analysis. The information documented by the attributes helps the team efficiently and effectively make tradeoffs between requirements, identify stakeholders affected by potential changes, and understand the impact of a proposed change.
Some commonly used requirements attributes include:
4. Requirements Prioritization Process
Requirements do not all deliver the same value to stakeholders. Requirements prioritization focuses effort on determining which requirements should be investigated first, based on the risk associated with them, the cost to deliver them, the benefits they will produce,or other factors. Timelines, dependencies, resource constraints, and other factors influence how requirements are prioritized. Planning the requirement prioritization process helps ensure that stakeholders determine and understand how requirements will be prioritized throughout and at the end of the business analysis effort.
Formality. The formality and rigor of the requirements prioritization process is determined partly by the methodology chosen, and by the characteristics of the project itself. Differences will lie in the level of detail, the amount of formal structure in the prioritization process (i.e. formal meetings versus informal conversations) and the amount of documentation needed to support the prioritization process.
Establishing The Process And Technique. The process to plan how requirements prioritization will occur needs to include which prioritization technique(s) will be used.
Plan The Participation. The business analyst, in conjunction with the project manager and sponsor should work together to determine the participants needed for the prioritization process.
Whom to invite and who does the inviting depends on organizational norms and best practices. Since sponsors are ultimately accountable for the solution’s effectiveness and major project decisions, they need to be invited to participate in the discussion, even if they delegate the participation to subject matter experts. Another key stakeholder is the project manager, whose project plan is dependent on which requirements are released and when. The invitees depend on methodologies, organizational norms, and the engagement of the sponsor. When there are multiple limiting factors, invite participants accordingly.
5. Change Management
Some considerations when planning for handling changes are:
Determine the process for requesting changes. The process can, but does not have to, set authorization levels for approving changes. For example, it may be decided that if a change is estimated to take less than a certain number of hours or dollars, the requestor and project manager can approve the change. If a predefined time or cost limit is exceeded,the sponsor has to approve it.
Determine who will authorize changes. The planning activity needs to include a designation of who can approve changes after requirements have been approved. Plan-driven methods usually have a formal Change Control Board (CCB) or Change Authority, which considers the requested change, and provides initial judgment on the merits of that request. The CCB can consist of any number of people in any number of positions. It may or may not include the sponsor, the project manager, the business analyst, subject matter experts, or other parties. Change-driven methods are more likely to allow the project team or a single product owner to have direct control over changes.
Impact Analysis. Specify who will perform the analysis of such impacts as business processes, information requirements, system and hardware interfaces, other software products, other requirements, test strategies and plans,to name a few.
Plan the wording of the request. It is important to set the expectation at the beginning of the business analysis activities that although the amount of documentation required to request changes is project and methodology dependent, the wording of the request must be clear. The requested change must be expressed in unambiguous terms. Therefore, it will be necessary to discuss the nature of the request with the requestor and other interested stakeholders.
The requirements process needs to spell out the nature of the components within a request for change.These might include:
Coordinate Prioritization Of Change. The priority of the proposed change must be established relative to other competing interests within the current project phase. The requestor should provide a priority as described in the section above. Project decision makers will need to consider the priority as well any potential risk of deferring implementation until a later time.
Change-driven methodologies (in particular, agile software development methods) do not typically have a change control process that is separate from the requirements prioritization process. All requirements, including “new” and “changed” requirements, are recorded in the product backlog and prioritized. At the beginning of each iteration, the highest priority requirements are selected from the backlog and estimated, and these estimates are used as input to determine whether the requirement will be implemented in that iteration.
6. Tailoring the Requirements Management Process
An organization’s requirements management process may need to be tailored to meet the needs of a specific initiative or project. Factors in the tailoring process include:
Decision Analysis : Can be used to assess the possible value delivered by a change and assess areas of uncertainty.
Problem Tracking : Used to track possible changes and ensure that a decision is reached.
Risk Analysis : Used to identify possible risks associated with the change management process and possible risks associated with making or choosing not to make the change.
Domain SME: Consulted in order to determine the importance of requirements and to assess the value of change requests.
End User: Consulted in order to determine the importance of requirements and to assess the value of change requests.
Implementation SME: Consulted in order to determine the difficulty of implementing a requirement or proposed change.
Operational Support: Informed of changes to requirements to ensure that the solution can operate effectively.
Project Manager: Responsible for managing changes to the project scope and accountable for delivery of the project scope. Changes to the solution and requirements scope are almost certain to impact the project scope. Similarly, changes to the project scope may impact the solution and requirements scope. Most projects use a single change management process to handle both and describe the impacts to solution and project scope in a single change request. This will require the involvement of the project manager in this task and agreement on the person responsible for the change management process.
Tester: Informed of changes to requirements to ensure that test plans are effective.
Sponsor: Accountable for the solution scope and must approve prioritization of requirements and changes to requirements.
Requirements Management Plan.A requirements management plan describes the:
Business Analyst Related Interview Questions
|Business Analyst Interview Questions||Business Letter Format Interview Questions|
|Business Communications Interview Questions||Business Environment Interview Questions|
|Business Management for Financial Advisers Interview Questions||Business Development Interview Questions|
|Business Management Interview Questions||Executive Business Analyst Interview Questions|
|Business Objectives Interview Questions||Business Development Manager Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.