Chapter 04: Inception is Not the Requirements Phase

1
Chapter 04 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
• Detailed 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? What platforms are
  targetted?)
• It is not the documentation of the full detailed
  requirements I.e. the writing-up of the software
  specification in the waterfall-way.

2

• 4.2 What is Inception?
• A phase to clarify things-up a bit
• What is the vision of this project, its scope?
• Feasible? Proof of concept.
• Buy components and glue them together 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?
• For games, it may be necessary to develop a quick
  and dirty prototype, some artwork etc. What do
  you think?

3

• 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

• 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 I want this
  game based on this film that will come out in 2
  years time here is the film storyboard, costumes
  design, target market analysis ... and it must
  have the same puzzles as the latest Harry Potter
  game.
• Sometimes business negotiations will take much
  longer however

5

• 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 to 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

6

• 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. often much more
  valuable than the details of the documents.

7

• 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 centred on humans not
  documents
• The UML will play little role during this phase
  apart from Use Case Diagrams.
• Because these documents are collobative and will
  have to be maintained on an on-going basis, using
  a Cloud based solution is recommended
• Google Docs are good
• Bitbucket hosting with Mercurial Distributed
  Version Control System

8

• 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 artefact
• All the use case were written in detail.

9

• 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
• Inception in Games
• Convince the producer/investors. Developing a
  game is very risky because of costs describe the
  idea, the seed of the game, its originality, the
  main goal, unique feature, potential for series
• There will be many unknown elements of course,
  hopefully more ideas will arise later
• The inception phase must be short because it may
  be run at a loss
• Idea of cost and schedule very hard initially
• Developing games is a creative process hard to
  control and plan
• But proceeding with a poor concept is dangerous
• There will inevitably be many turning points or
  changes during the project

10

• The software development process used, the staff
  personalities are extremely important for a
  software project
• Resources
• Atsushi Inabas lecture on Lessons from
  Viewtiful Joe Making a Creatively and
  Financially Successful New Game at
  http//www.gamasutra.com/gdc2005/features/20050309
  /postcard-sheffield.htm is interesting as he is a
  producer
• Extract That's why Inaba says that a good
  producer that has nurtured a seed into a tree,
  must not be afraid of lopping off branches that
  have gone in the wrong direction, while
  simultaneously continuing to water this seed.
  Indeed, a good producer will stop development
  entirely if he or she cannot truly envision how
  the product could turn into an excellent game.