Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 4: Inception is Not the Requirements Phase.

Similar presentations

Presentation on theme: "Chapter 4: Inception is Not the Requirements Phase."— Presentation transcript:

1 Chapter 4: Inception is Not the Requirements Phase

2 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.

3  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? 4.2 What is Inception?

4  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?

5  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.2 How Long Should the Inception Phase be?

6  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; 4.3 Which Artifacts Should be Started?

7  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.

8  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.

9  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.4 You Know you did not Understand Inception when …

10  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 4.5 Conclusion

Download ppt "Chapter 4: Inception is Not the Requirements Phase."

Similar presentations

Ads by Google