PART II INCEPTION Chapter 4 Inception is Not The Requirements Phase

Introduction 4.1 What is Inception? 4.2 How Long is Inception? 4.3 What Artifacts May Start in Inception? 4.4 You Know You Didn’t Understand Inception When……

Introduction Inception is the initial short step to establish a common vision and basic scope for the project. It will include analysis of perhaps 10% of the use cases, analysis of the critical non-functional requirement, creation of a business case, and preparation of the development environment so that programming can start in the following elaboration phase.

4.1 What is Inception? Most projects require a short initial step in which the following kinds of questions are explored: What is the vision and business case for this project? Feasible? Buy and/or build? Rough estimate of cost: Is it $10K-100K or in the millions? Should we proceed or stop?

Defining the vision and obtaining an order-of -magnitude(unreliable)estimate requires doing some requirements exploration. However, the purpose of the inception step is not to define all the requirements, or generate a believable estimate or project plan. At the risk of over- simplification, the idea is to do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system, and decide if it is worthwhile to invest in deeper exploration.

Thus, the inception phase should be relatively short for most projects, such as one or a few weeks long. Indeed, on many projects, if it is more than a week long, then the point of inception has been missed: It is to decide if the project is worth a serious investigation, not to do that investigation.

Inception in one sentence: Envision the product scope, vision, and business case. The main problem solved in one sentence: Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation?

Does this Analogy Help? In the oil business, when a new field is being considered, some of the steps include: 1. Decide if there is enough evidence or a business case to even justify exploratory drilling. 2. If so, do measurements and exploratory drilling. 3. Provide scope and estimate information. 4. Further steps…

The inception phase is like step one in this analogy. In step one people do not predict how much oil there is, or the cost or effort to extract it. Although it would be nice to be able to answer “how much” and “when” questions without the cost and effort of the exploration, in the oil business it is understood to not be realistic.

In UP terms, the realistic exploration step is the elaboration phase. The preceding inception phase is akin to a feasibility study to decide if it is even worth investing in exploratory drilling. Only after exploration (elaboration) do we have the data and insight to make somewhat believable estimates and plans. Therefore, in iterative development and the UP, plans and estimates are not to be considered reliable in the inception phase. They merely provide an order-of-magnitude sense of the level of effort, to aid the decision to continue or not.

4.2 How Long is Inception? The intent of inception is to establish some initial common vision for the objectives of the project, determine if it is feasible, and decide if it is worth some serious investigation in elaboration. If it has been decided beforehand that the project will definitely be done, and it is clearly feasible (perhaps because the team has done projects like this before), then the inception phase will be especially brief.

4.3 What Artifacts May Start in Inception? Table 4.1 lists common inception (or early elaboration) artifacts and indicates the issues they address. Subsequent chapters will examine some of these in greater detail, especially the Use-Case Model.

A key insight regarding iterative development is to appreciate that these are only partially completed in this phase, will be refined in later iterations, and should not even be created unless it is deemed likely they will add real practical value. And since it is inception, the investigation and artifact content should be light.

For example, the Use-Case Model (to be described in following chapters) may list the names of most of the expected use cases and actors, but perhaps only describe 10% of the use cases in detail— done in the service of developing a rough high-level vision of the system scope, purpose, and risks.

Isn’t That a Lot of Documentation? Recall that artifacts should be considered optional. Choose to create only those that really add valued for the project, and drop them if their worth is not proved. The point of an artifact is not the document or diagram itself, but the thinking, analysis, and proactive readiness.

4.4 You Know You Didn’t Understand Inception When… It is more than “a few” weeks long for most projects. There is an attempt to define most of the requirements. Estimates or plans are expected to be reliable. You define the architecture; rather, this should be done iteratively in elaboration.

You believe that the proper sequence of work should be: 1) define the requirements; 2) design the architecture; 3) implement. There is no Business Case or Vision artifact. All the use cases were written in detail. None of the use cases were written in detail; rather, 10~20% should be written in detail to obtain some realistic insight into the scope of the problem.