Detailed Business Requirements

From MIKE2.0 Methodology

Activity: Detailed Business Requirements

Objective

This activity refines the Detailed Business Requirements for a particular increment. The resulting specifications should be detailed enough to begin the design for the particular increment. On subsequent increments this activity revisits the key business and information requirements out of the Blueprint as a starting point for strategic priorities.

The purpose of this Activity is to validate, refine, categorize and prioritise business requirements for this particular increment. It involves reviewing the existing documentation from Phases 1 and 2 and conducting additional interviews to define the purpose, goals/drivers, objectives, CSFs, KPIs and risks of the increment(s).

Major Deliverables

• Detailed Business Requirements
• Changes to initial set of Strategic Requirements

Tasks

Validate Strategic Business Requirements

Objective:

Validate the Business and Technology Requirements from the overall Blueprint vision and ensure that they are still valid. Working off a list of prioritised requirements, define the functional capabilities that will be delivered as part of this release.

Input:

• Overall Release Functionality
• Conceptual Data Model
• High Level Information Requirements

Output:

• Validated Strategic Business Requirements

Refine Strategic Business Requirements to Detailed Requirements

Objective:

Refine the Requirements to a level of detail from which more detaile design can be conducted. This may involve a going to a lower level of granularity through sets of interviews to clarify specific points with users. The focus, however, should be on "drilling-down" on Blueprint requirements (where required) as opposed to adding new requirements not included in the vision.

Input:

• Overall Release Functionality
• Conceptual Data Model
• Validated Strategic Information Requirements

Output:

• Detailed Business Requirements

Categorise Detailed Business Requirements

Objective:

Requirements will already be categorised across Applications, Infrastructure and Information. Ensure these categorisations are still valid before assigning them to team members for design. Also review requirements to make sure areas of overlap and dependencies are well-understood. When requirements are categorised they may overlap into multiple areas, this is fine as long as it is clearly understood that there is ownership of a particular requirement for the different design and testing teams.

Input:

• Detailed Business Requirements

Output:

• Categorised, Detailed Business Requirements

Prioritise Detailed Business Requirements

Objective:

For all requirements that are to be implemented as part of this increment, prioritise those that are most important. This will help set importance levels with the team and make sure that focus is put on the most critical areas. Importance should be set based on 3 factors:

• An important business requirement is a "must have" in terms of functionality for the business
• An important technical requirement must be implemented to ensure the reliability or integrity of the system
• An important dependency means that this capability must be implemented as there is a large degree of functionality dependent on the implementation of this specific requirement.

Importance levels should then influence timing of project plan and resourcing.

Input:

• Categorised, Detailed Business Requirements

Output:

• Prioritised, Categorised, Detailed Business Requirements

Determine Detailed Analytical Requirements

Objective:

This task is specific to gathering the detailed information requirements for a Business Intelligence System. These requirements tend to be more complex, composite requirements that are dependent on data from many systems and detailed analytics. Examples include:

• Standard Reports and Queries (Operational Information) - monitoring operational performance against business objectives and analysing relatively short term trends where requirements for queries are well known, definable, and repetition is required.

• Ad-hoc Query Capability - allow business community independence from IS for information access. Evolve often-used queries into standard reports over time.

• Statistical Analysis Systems - perform complex statistical operations on selected sets of variables and their observations.

• Data Pattern Analysis/Data Mining - where measurement criterion is not well understood or very complex. These applications may require multidimensional visualization tools or fuzzy logic query engines.

Experience throughout the industry has shown that decision support requirements can be difficult for subject matter experts in the business community to specify and define. Ad-hoc reporting capabilities in user applications can quickly be developed using technology and tools. Training is required to develop strategies to review ad-hoc queries with the intent of turning them into repetitive canned queries that benefit the entire organisation.

Data pattern analysis (data mining) is an important process to develop strategies based on marketing or scientific trends. These trends emerge from analysis of large amounts of historical data. This form of processing is not dependent on definable measurement criterion and can assist users when the effects that each factor has on the outcome of a business driver is very complex or not fully understood. The use of multidimensional data visualization tools or fuzzy logic query generators assist the business community far beyond standard quantitative statistical analysis approaches.

With these initial systems and a greater understanding of information processing our clients will be able to develop effective decision support applications. These applications will enhance their decision making capabilities and provide the information necessary to develop rapidly changing strategies.

Input:

• Overall Release Functionality
• Conceptual Data Model
• Prioritised, Categorised, Detailed Business Requirements

Output:

• Detailed Analytical Requirements

Core Supporting Assets

• Reporting Requirements Deliverable Template

Yellow Flags

• Completed requirements are too high level to begin appropriate design
• Business staff are not available to assist with requirements definition – IT plays too large a role

Key Resource Requirements

• Senior Business Analyst
• Business Analyst