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.
Artifact [] | Comment |
---|---|
Vision and Business Case | Describes the high-level goals and constraints, the business case, and provides an executive summary. |
Use-Case Model | Describes the functional requirements. During inception, the names of most use cases will be identified, and perhaps 10% of the use cases will be analyzed in detail. |
Supplementary Specification | Describes other requirements, mostly non-functional. During inception, it is useful to have some idea of the key non-functional requirements that have will have a major impact on the architecture. |
Glossary | Key domain terminology, and data dictionary. |
Risk List & Risk Management Plan | Describes the risks (business, technical, resource, schedule) and ideas for their mitigation or response. |
Prototypes and proof-of-concepts | To clarify the vision, and validate technical ideas. |
Iteration Plan | Describes what to do in the first elaboration iteration. |
Phase Plan & Software Development Plan | Low-precision guess for elaboration phase duration and effort. Tools, people, education, and other resources. |
Development Case | A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project. |
[] -These artifacts are only partially completed in this phase. They will be iteratively refined in subsequent iterations. Name capitalization implies an officially named UP artifact.
For example, the Use-Case Model may list the names of most of the expected use cases and actors, but perhaps only describe 10% of the use cases in detaildone in the service of developing a rough high-level vision of the system scope, purpose, and risks.Note that some programming work may occur in inception in order to create "proof of concept" prototypes, to clarify a few requirements via (typically) UI-oriented prototypes, and to do programming experiments for key "show stopper" technical questions.
Isn't That a Lot of Documentation?
Recall that artifacts should be considered optional. Choose to create only those that really add value for the project, and drop them if their worth is not proved.And since this is evolutionary development, the point is not to create complete specifications during this phase, but initial, rough documents, that are refined during the elaboration iterations, in response to the invaluable feedback from early programming and testing.Also, often the point of creating artifacts or models is not the document or diagram itself, but the thinking, analysis, and proactive readiness. That's an Agile Modeling perspective: that the greatest value of modeling is to improve understanding, rather than to document reliable specifications. As General Eisenhower said, "In preparing for battle I have always found that plans are useless, but planning indispensable" [Nixon90, BF00].Note also that artifacts from previous projects can be partially reused on later ones. It is common for there to be many similarities in risk, project management, testing, and environment artifacts across projects. All UP projects should organize artifacts the same way, with the same names (Risk List, Development Case, and so on). This simplifies finding reusable artifacts from prior projects on new engagements.