Chapter 4: Inception is Not the Requirements Phase

4.1. Introduction Inception is the initial short step to establish a common vision and basic scope for the project. It may include for example: Analysis of perhaps only 10% of the use cases; Identification of main risks; Analysis of the critical non-functional requirements (e.g. performance); Business case; Identification of development environment needs (e.g. do we need a new tool?); It is not the documentation of the full detailed requirements: I.e. the writing-up of the software specification in the waterfall-way.

4.2 What is Inception? A phase to clarify things-up a bit: What is the vision of this project, its scope? Feasibility? Buy components and glue or from scratch? Very rough cost and schedule? Can we convince people of business case? It is not to define and document all requirements: We have to accept that all our estimates and requirements will be, at the end of this phase, still very rough; It is during elaboration (once we get the go-ahead) that these will be refined; The idea is to do just enough investigation to be able to present a rational business case to show purpose, feasibility and need for the proposed software: should we investigate further or stop right now?

Although it would be nice to have all the requirements detailed, the cost and schedule all worked-out before committing to a project, it is unrealistic for most applications (including games). The inception phase is about deciding if the project is worth a serious investigation (during elaboration), not to do that investigation.: This implies that the project may be abandoned during elaboration: this should not be taken as being a project failure or as a mistake having been made during inception; In the UP, the plans and estimates created during the inception phase are not to be considered as reliable: the inception phase is more or less a feasibility study: Can we do it from a technical point-of-view? Does it make sense from a business point-of-view?

4.2 How Long Should the Inception Phase be? Short. It may even be shorter (less than a week) if the project is commissioned by a client. Sometimes business negotiations will take much longer however … What do you think?

4.3 Which Artifacts Should be Started? Potential artifacts: Vision and Business Case: describes the high-level goals and constraints, provides an executive summary; Use Case Model: describes the fundamental requirements: during inception identify the names of the use cases and analyse perhaps 10% of the them; Supplementary specification: describe non-functional requirements, look-and-feel, atmosphere etc. Glossary: keeping track of key terms; Risk list and risk management plan: describe the risks (business, technical, resource, schedule) and ideas for their mitigation; Prototypes and proof-of-concepts: to clarify the vision, and validate technical ideas; Iteration Plan: Describes what to do in the first elaboration iteration, and overall goals of the elaboration phase; Development Case: Customised software development process;

A key aspect, is that while these documents/artifacts may be started during the inception phase they will not be completed during it! The artifacts will only be partial at this stage: they will be refined in later iterations. Coding may take place during this phase for the development of prototypes. These may be used to: Clarify some functional and/or non-functional requirements (animation, look-and-feel etc.); Reduce technical risk by demonstrating (or otherwise!) feasibility; Often the real value is not in the artifacts themselves but in the process that was necessary to write them up: the thinking, the analysis, the communication between the team (with involvement of the client) etc. : much more valuable than the details of the documents.

You must also be honest and realistic: But it is also worthwhile to have some structure (e.g. keeping standard names for documents). You must also be honest and realistic: There is absolutely no point in writing up a document just for the sake it, just for the manager to tick a box in his plan … (this happens very, very often); At the end of the day, a document must bring some value to a project; Being honest and realistic is not always easy (commercial pressures, personnel issues etc.); The agile approach is centered on humans not documents; The UML will play little role during this phase apart from Use Case Diagrams.

4.4 You Know you did not Understand Inception when … It is more than a few weeks long; There is an attempt to define most of the requirements; Plans and estimates are expected to be reliable; There is no business case or vision artifact; All the use cases were written in detail;

4.5 Conclusion The inception phase is not very technical, it is really about deciding if it is worthwhile to invest in deeper exploration (the purpose of the elaboration phase); Not going any further is not a negative outcome … Questions Please