This illustration shows how a project begins, and how the various workflows relate. It is constructed from the Workflow Details as they would appear at the time of the first iteration of the project. The intent is to indicate dependencies and show where workflows occur in parallel. The lengths of the bars in the chart (indicating duration) have no absolute significance.

The degree of business engineering performed depends on the desired results. If the purpose of business engineering is merely to set context for the system, the effort should be restricted to the subset of the business which will be supported by the system to be developed. Further business engineering, while perhaps valuable for other reasons, tends to be de-focusing for the system development team.

Define the vision and scope of the system

Risk List.

Clarify the functionality

Conduct sessions to collect stakeholders' opinions on what the system should do. This can be done using various. You can also include building an initial outline of the Use Case Model in this session. The Glossary will likely be started to simplify the maintenance of the use-case model, and to keep it consistent.. The main result of these sessions is the Stakeholder requests and an outline of the Use Case Model.

Project feasibility, and project plan outline

With the input from the use-case modeling, translate the vision into economic terms, updating the Business Case, factoring in the project's investment costs, resource estimates, the environment needed, and success criteria (revenue projection and market recognition). Update the Risk List to refer to the identified use cases and add new identified risks. Establish the initial Software Development Plan, mapping out the phases (Inception, Elaboration, Construction, and Transition), and major milestones.

Prepare the environment

Assess the current state of the project and its surrounding organization). The Systems Analyst develops a first version of the Development Case. The Architecture Group selects tools for the project, to support the Requirements work. The Systems analyst produces a first draft of the Use Case Modeling Guidelines.

Refine the project plan

At this stage, the stakeholders of the system should have a fairly good understanding of its vision and the feasibility of the project. An order of priority among features and use cases is established. The Project Manager refines the Software Development Plan, mapping out a set of iterations using the prioritized use cases and associated risks. The plans developed at this point are refined after each subsequent iteration, becoming more accurate as iterations are completed.

Note: this is a key differentiator in using this process, recognizing that initial project plan estimates are rough estimates. But that those estimates become more realistic as the project progresses and there are real metrics on which to base estimates; successive refinement of the project and iterations plans is both expected and essential.

The scope of the remaining work in this initial inception iteration is planned in the Iteration Plan will depend on the project manager's assessment of the risk.

Because, for example, the system is unprecedented, the domain is new to the development team, or the requirements are still not well understood or are particularly onerous. If the risk is low there may be need for little more than clarifications of some requirements. In refining the Systems Definitions and Manage Changing Requirements, before a decision can be taken by the stakeholders to commit to development, and the elaboration phase can begin.

If the risks are judged to be high, then it may be necessary to do more exploration in this initial inception phase iteration. The Systems Architect determines a set of architecturally significant requirements, which are modeled or prototyped, with the objective of increasing confidence in the feasibility of the project.

At the end of the initial inception iteration, the scope of the project and its associated risks are reevaluated to update the Business Case. Then the Iteration Plan for the next iteration is constructed; in parallel, the Software Development Plan and any of the artifacts it contains are updated, if this is warranted.

• Vision
• Business Case
• Software Development Plan

The scope of the project should be understood, and the stakeholders initiating the project should have a good understanding of the project's ROI (return on investment), i.e. what is returned, for what investment cost. Given this knowledge, a go/no go decision can be taken.

In cases where the project involves new product roll-out or creation of new technology, subsequent iterations may be needed to further define the scope of the project, the risks and the benefits. This may involve further enhancing the use-case model, business case, risk list, architectural proof-of-concept, or project and iteration plans. Extension of the Inception phase may also be advisable in cases where both the risk and the investment required are high, or where the problem domain is new or the team inexperienced.