stuck? check out our sample methodologies

description

Fully analyse and define the business problem/opportunity, its impact on the business, and the potential benefits being sought from a solution. This will be the basis for justifying why the project is being undertaken.

description

Agree on the business analysis methodology (e.g. waterfall, agile, six-sigma) to follow, based on the type of project and organisational standards. The level of tailoring and the combination of practices applied will determine the high-level deliverables from the analysis process, together with the nature and timing of the related tasks.

description

Identify business areas, outside of any system solution, which also need to be changed to meet the business need, for example, business processes, job design, system and information architecture.

description

Identify and analyse all potential stakeholders for the proposed project or system. Stakeholders include anyone who has a vested interest in the product or system that is being developed. Stakeholders will have various levels of engagement throughout the project and will need to be communicated with along the way.

description

Determine and schedule the business analysis tasks that will be required. Prepare a plan that details how these tasks will be carried out, estimates of the work effort required, the sequence of events, and the resources that will be allocated to them. Include the nature and timing of stakeholder engagement in the plan.

description

Define the requirements management process, including how requirements are to be communicated, approved and changed. The plan will describe how requirements are to be recorded, what documents or artefacts are prepared from them, and how requirements will be prioritised.

description

The RACI model enables the BA to assign responsibilities(accountable, responsbile, consulted, informed) to each identified stakeholder or project team member.

description

Select the appropriate techniques and estimate the effort required to elicit requirements from the identified stakeholders.

description

Conduct the selected elicitation tasks to gather requirements.

description

Evaluate and define the most viable solution-approach, to the level of detail required to define the solution scope and develop the business case.

description

Specify requirements in multiple ways to define for solution designers and developers what is required of the solution to meet users’ needs; using a combination of textual statements, matrices, diagrams and formal models, in non-technical language.

description

Determine at a general level what is or isn’t going to be catered for in the solution (for example features). This is important for building the business case and managing expectations about the solution.

description

This is a template for specifying high level business requirements, defining scope, and communicating with stakeholders including sponsors, business owners and project managers.

description

Incorporate requirements that respect the needs of the end user/customer, including interaction behaviour, and goals for each persona that the system needs to cater for. This may include demonstrating wire-frame screen mock-ups to end users, incorporating feedback into requirements.

description

This is a template for specifying detailed business requirements, defining scope, and communicating with stakeholders including sponsors, business owners and project managers.

description

Evaluate requirements to ensure they fulfil quality specifications and are sufficiently defined and structured to allow the technical teams to design, develop and implement an effective and efficient solution.

description

Documentation and communication of requirements, throughout the project, to ensure they are correctly understood by all stakeholders and effectively implemented.

description

Baseline and manage changes to the solution scope and requirements.

description

Create and maintain relationships between requirements and other solution components, such as test cases.

description

Define the requirements of any transition tasks, including such things as organisational change, training, data migration, change over and decommissioning.

description

Review the constructed solution to ensure it meets the business need and determine appropriate resolution of any defects. Continue the validation process through the implementation and transition process.

description

Assess the value of the deployed solution and compare the actual costs and benefits to those planned.

description

Conduct the selected elicitation tasks to gather requirements.

description

Evaluate and define the most viable solution-approach, to the level of detail required to define the solution scope and develop the business case.

description

Determine at a general level what is or isn’t going to be catered for in the solution (for example features). This is important for building the business case and managing expectations about the solution.

description

This is a template for specifying high level business requirements, defining scope, and communicating with stakeholders including sponsors, business owners and project managers.

description

Organise the requirements for the solution in a structured way, so that they give a comprehensive, complete and consistent view of the required solution from all stakeholders' (business and technical) perspectives.

description

The product owner describes the highest priority features to the team, who ask questions so they can determine which tasks they will move from the product backlog to the sprint backlog.Sometimes the lower priority items can be saved for the next sprint planning meeting. Together the Scrum team and the product owner define a sprint goal (short description of what the sprint will attempt to achieve).After the meeting, the Scrum team meets to decide how much they can commit to during the coming sprint. Negotiation with the product owner may take place.

description

Assess which requirements can be delivered in this phase, including those backlogged from earlier sprints. The Product Backlog is the master list of all functionality desired in the product. The Product Backlog is then allowed to grow and change as more is learned about the product and its customers. Product backlog items can be technical tasks or more user-centric with user stories. The product owner attends the sprint planning meeting with the prioritized product backlog. The team then negotiates the items for the coming sprint. Items are moved from the Product Backlog to the Sprint Backlog. Both high and low priority items could be selected for a sprint if they are related.

description

Organise the requirements for the solution to align to the sprint, so that they give a comprehensive, complete and consistent view of the required solution from all stakeholders' (business and technical) perspectives.

description

At the end of each sprint an informal sprint review meeting is held during which the Scrum team reveal or demo what they accomplished during the sprint. The project is assessed against the sprint goal determined during the sprint planning meeting.

description

The sprint retrospective meeting is held at the end of every sprint so that the team and ScrumMaster can discuss lessons learnt - what went well and what to improve in the next sprint. The meeting helps to adapt processes over time so that performance improvements can be made and 'bottlenecks' removed.(The product owner does not attend).

description

Define the requirements of any transition tasks, including such things as organisational change, training, data migration, change over and decommissioning.

description

Review the constructed solution to ensure it meets the business need and determine appropriate resolution of any defects. Continue the validation process through the implementation and transition process.

description

Assess the value of the deployed solution and compare the actual costs and benefits to those planned.