The document discusses the elaboration phase of requirements engineering. Elaboration involves expanding and refining requirements information gained during inception. It consists of modeling, refinement tasks, and creating and refining user scenarios over multiple iterations. Key artifacts produced include domain models, design models, software architecture documents, data models, use case storyboards, and UI prototypes. Planning for the next iteration involves organizing requirements by risk, coverage, and criticality.

2. ELABORATION
 Elaboration is a activity in which information
about the requirements is expanded and
refined.
 This information is gained during inception.
 The elaboration consists of several modeling
and refinement tasks.
 In this process user scenarios are created and
refined. Basically how end user will interact with
the system.
 Elaboration often consists of two or more
iterations; – each iteration is recommended to
2~6 weeks

3. Elaboration in one sentences
 Each iteration is calledTime boxed iteration.
This is conducted with in the fixed time.
 Elaboration: Build the core architecture,
resolve the high-risk elements, define most
requirements, and estimate the overall
schedule and resources.

4. Artifacts in Elaboration.
 Artifacts
 Domain Model
 Design model
Comment
This is a visualization of the
domain concepts it is
similar to static
information model of the
domain entities.
This set of diagram that
describes the logical
design.This includes
software class diagram,
package diagram and so
forth.

5. Artifacts in Elaboration
 Software architecture
document
 Data Model
 A learning aid that
summarizes the key
architecture issues and
their resolution in
design.
 This include the
database schemas,and
the mapping strategies
between object and non
object representation.

6. Artifacts in Elaboration
 Use case storyboards
UI prototypes
 A description of the
user interface paths of
navigation ,usability
models , and so forth

7. Planning the next iteration
 Organize requirement and iterations by risk,
coverage and criticality.
 Risk: include both technical complexity and
other factors, such as uncertainty of effort or
usability.
 Coverage:”wide and shallow” implementation
across many component.
 Criticality : Refers to function the client consider
of high business value.

9. Domain model
The most important and classic modelin OO
analysis.
A visual representation of conceptual classes or
real situation objects in a domain .
Also called conceptual models, domain object
models, and analysis object models.
“focusing on explaining ‘things' and products
important to a business domain”, such as POS
related things.

10. Domain model
 Domain model illustrated with UML CLASS
DIAGRAMS. It provides a conceptual
perspective.
 Domain object and conceptual classes
 Association between conceptual classes
 Attributes of conceptual classes.

11. Domain model as a visual
Dictionary:
 Domain model shows the abstraction of
conceptual classes.
 The information in domain model can be
expressed in plain text.
 But the conceptual classes and their
relationship with other classes can be
expressed using visual language.

12. Example for domain model