
 They are a subset of the requirements as described by the use cases, the vision, and the supplementary specification;
 Subsequent iterations will grow these until a full system is implemented;
 The current requirements are not complete, they will evolve and benefit from feedback …


 Other requirements remain to be discovered;
 Most will need further analysis;

 However after the inception phase we must have a basic, documented, set of requirements:
 These need to be scheduled over the next few development cycles (the elaboration phase);
 Only the first few cycles need to be scheduled at this stage (a very detailed schedule is not feasible at this point in time due to the fuzziness of the remaining requirements);
 An iteration must be time-boxed, say between 2 weeks and 8 weeks (why?)
 To decide which requirements should be tackled early in the project we can use the following criteria:
 Risk : includes both technical complexity and other factors, such as uncertainty of effort or usability.
 Coverage : implies that all major parts of the system are at least touched on in early iterations, perhaps a "wide and shallow" implementation across many components.
 Criticality : refers to functions the client considers of high business value.

 We can then rank use cases, and other high-level features, according to these criteria:
Rank Requirement
(Use Case or
Feature)
Comment
High Process Sale
Logging
…
Scores high on all rankings
Pervasive. Hard to add later
…
Medium Maintain
Users
…
Low …
Affects security
…
…
 This ranking should be reviewed after each iteration as new requirements and new insights will influence it:
 The schedule needs to be adaptive;
 In addition, we will always consider the Start Up use case: to consider all the necessary initialisations in a systematic way.

 For the POS:
 Implement a basic, key scenario of the Process Sale use case: entering items and receiving a cash payment.
 Implement a Start Up use case as necessary to support the initialization needs of the iteration.
 Nothing fancy or complex is handled, just a simple happy path scenario, and the design and implementation to support it.
 There is no collaboration with external services, such as a tax calculator or product database.
 No complex pricing rules are applied.
 User Interface Prototyping if not done already (we will not see this)

 Discussion:
 Subsequent iterations will grow on these foundations;
 The requirements have been simplified for the first iteration : to fit in a given time-box;
 In iterative lifecycle processes (such as the UP, XP,
Scrum, and so forth): We start production-quality programming and testing for a subset of the requirements, and we start that development before all the requirements analysis is complete : contrast to a waterfall process.
 A use case can span more that one iteration : see
Figure 8.1

1 2 3 . . .
Use Case
Process Sale
Use Case
Process Sale
Use Case
Process Sale
A use case or feature is often too complex to complete in one short iteration.
Therefore, different parts or scenarios must be allocated to different iterations.
Use Case
Process Rentals
Feature:
Logging
Figure 8.1:
Spreading Use Cases

 The inception phase may only last 1 week (typically more) : it is not very long:
 It determines basic feasibility, risk, and scope, to decide if the project is worth more serious investigation (Elaboration).
 During the Inception phase the following may occur:
 a short requirements workshop;
 most actors, goals, and use cases named;
 most use cases written in brief format; 10 to 20% of the use cases are written in fully dressed detail to improve understanding of the scope and complexity;
 most influential and risky quality requirements identified;
 version one of the Vision and Supplementary Specification written;

 risk list;
 For example, leadership really wants a demo at the POSWorld trade show in
Hamburg, in 18 months. But the effort for a demo cannot yet be even roughly estimated until deeper investigation.
 technical proof-of-concept prototypes and other investigations to explore the technical feasibility of special requirements;
 user interface-oriented prototypes to clarify the vision of functional requirements
 recommendations on what components to buy/build/reuse, to be refined in elaboration

 high-level candidate architecture and components proposed
 This is not a detailed architectural description, and it is not meant to be final or correct.
Rather, it is brief speculation to use as a starting point of investigation in elaboration. For example, "A Java client-side application, no application server, Oracle for the database,
…" In elaboration, it may be proven worthy, or discovered to be a poor idea and rejected.
 plan for the first iteration;
 candidate tools list;
 On to the Elaboration phase:
 Elaboration is the initial series of iterations during which:
 the core, risky software architecture is programmed and tested
 the majority of requirements are discovered and stabilized
 the major risks are mitigated or retired
 Elaboration often consists of two or more iterations; each iteration is recommended to be between two and six weeks; prefer the shorter versions unless the team size is massive.
Each iteration is timeboxed, meaning its end date is fixed.
 Build the core architecture, resolve the high-risk elements, define most requirements, and estimate the overall schedule and resources.

 Key ideas during elaboration:
 do short timeboxed risk-driven iterations;
 start programming early;
 adaptively design, implement, and test the core and risky parts of the architecture;
 test early, often, realistically;
 adapt based on feedback from tests, users, developers;
 write most of the use cases and other requirements in detail, through a series of workshops, once per elaboration iteration;
 Treat each iteration during elaboration as a miniproject;

In addition to the artifacts created during inception (and which need to be refined during elaboration) the following artefacts can be created during the iterations of the elaboration phase:
Artefact Comment
Domain Model
Design Model
This is a visualization of the domain concepts; it is similar to a static information model of the domain entities.
This is the set of diagrams that describes the logical design. This includes software class diagrams, object interaction diagrams, package diagrams, and so forth.
Summarizes the key architectural issues and their resolution in the design.
Software
Architecture
Document
Data Model
Storyboards, UI
Prototypes, Artwork
This includes the database schemas, and the mapping strategies between object and non-object representations.
A description of the user interface, paths of navigation, and so forth.

 The elaboration phase will start before the specification is complete …
 The elaboration phase will be followed by a longer Construction phase.
 During several iterations, the elaboration phase, builds the core architecture, resolves the high-risk elements, defines most requirements, and estimates/refines the overall schedule and resources.
 The Elaboration phase is not about requirements, nor design, nor coding : it is all of these at once for the most important
(possibly simplified) aspects of the project …
 During Elaboration, feedback will evolve/complete the requirements.
 We must produce fully-tested, documented, production-grade code