The following terms and abbreviations are defined with respect to their use with
respect to Agile Modeling.
- Agile model.
A model that is
just barely good enough.
This means that it fulfills its purpose and no
more; is understandable to its intended audience; is
simple; sufficiently accurate, consistent, and detailed;
and investment in its creation and maintenance provides
positive value to your project.
- Agile Modeling (AM).
A practice-based methodology for effective
modeling of software-based systems.
- Agile modeling session.
A modeling session where you follow the
principles, and apply the practices, of AM.
- Analysis modeling session.
A modeling session where your focus is on
fleshing out the requirements for your system.
- Analysis paralysis. The fear of
moving forward until your models are perfect.
A developer responsible for working directly with
project stakeholders to potentially gather/elicit
information from them, document that information, and/or
validate that information.
- API. Application programming
- Architecture modeling session. A modeling session where your focus is on identifying a
high-level strategy for how your system will be built.
A deliverable or work product.
A tested and certified version of a deliverable
representing a conceptual milestone which thereafter
serves as the basis for further development and that can
be modified only through formal change control
particular version becomes a baseline when a responsible
group decides to designate it as such.
Big design up front.
- Behavioral requirement.
A category of requirements that describe how a
user will interact with a system, how someone will use a
system, or how a system fulfills a business function.
- Boundary object.
An object that represents user interface elements
such as screens, reports, HTML pages, or emails
- Business rule. An operating
principle or policy that your software must satisfy.
Represents the concept "how many?" in associations.
- CASE. Computer-aided system
- CASE tool. Software that supports
the creation and manipulation of models of
A next generation software process for the systematic
business-driven development of component-based systems.
- Change case.
An artifact used to describe a potential
requirement for a system or a potential modification to
- Class diagram.
A UML diagram that depicts classes, their static
inter-relationships (including inheritance, aggregation,
and association), and the operations and attributes of
- Class Responsibility Collaborator
(CRC) card. A standard index card that has been divided
into three sections, one indicating the name of the
class that the card represents, one listing the
responsibilities of the class, and the third listing the
names of the other classes that this one collaborates
with to fulfill its responsibilities.
- Class Responsibility Collaborator
collection of CRC cards.
The degree of relatedness within an encapsulated unit
(such as a component or a class).
diagram. A UML diagram that show instances of
classes, their interrelationships, and the message flow
diagrams provide a birds-eye view of a collection of
collaborating objects working together to fulfill a
- Collaborative modeling tool. A CASE tool that enables several developers to simultaneously
work on one or models with real-time updates of those
- Collaborative writing tool.
A word processing tool that enables several
people to simultaneously write a document with real-time
updates of that document.
The act of transmitting information between
- Component diagram.
A UML diagram that depicts the software
components of a system, their interfaces, and the
relationships between the components.
Between two software elements, A and B, the
property by which a change in A would require a change
to B to preserve overall correctness within your system.
- Context model. A diagramshowing how your system fits into its overall environment.
It is common to develop high-level data flow
diagrams or deployment diagrams for this.
Contract model. A model that
defines an agreement between two or more parties. A
contract model is something that the parties should
mutually agree to and mutually change over time if
models are often required when an external group
controls an information resource that your system
requires, such as a database, legacy application or
- Control object. An object that
serves as the glue between boundary/interface objects
and entity objects, implementing the logic required to
manage the various objects and their interactions.
- Constraint. A restriction on the
degree of freedom you have in providing a solution.
The degree of relatedness within an encapsulated unit
(such as a component or a class).
- Data domain.
A collection of related data entities and the
relationships between those entities.
Most data domains are based on a common theme or
concept within your business domain, such as customer,
account, brokerage, and insurance within a financial
- Data model. A diagram that depicts
data entities and their inter-relationships.
diagram (DFD). A diagram that shows the movement
of data between processes, entities, and data stores
within a system.
- Death march.
A doomed software project, without any apparent
hope of success, where the developers carry on anyway.
- Deliverable. An artifact that is
delivered as part of your overall system.
Examples include source code, user documentation,
and technical system documentation for operations and
- Deployment diagram. A diagram that
depicts a static view of the run-time configuration of
processing nodes and the components that run on those
- Design modeling session. A modeling
session where your focus is on identifying a detailed
strategy for building a portion of your system.
- Developer. Anyone directly
involved in the creation of a software development
in the roles of programmer, modeler, and tester are
examples of developers.
- Development team.
Developers + active project stakeholders.
- Document. Any artifact external to
source code whose purpose is to convey information in a
Persistent information written for people that
describes a system, including both documents and
comments in source code.
- Documentation handoff.
This occurs when one group or person provides
documentation to another group or person.
- Domain model. A model depicting
major business classes or entities and the relationships
is common to use a class diagram or data diagram for
- Drawing tool.
software tool that supports the ability to draw
tools are effectively low-end CASE tools.
- DSDM. Dynamic Systems Development
The act of creating and evolving models that
depict the business and technical infrastructure of your
- Enterprise requirementsmodeling.
of creating and evolving models that reflect the
requirements of your organization.
- Entity object. An object that is
typically found in your domain model, for example Order
and Item in an inventory control system.
- Essential use-case.
A simplified, abstract, generalized use case that
captures the intentions of a user in a technology and
implementation independent manner.
- Essential user interface prototype.
A low-fidelity model of a portion of the user
interface for a system in a technology independent
Enterprise Unified Process.
- Executable UML (xUML).
A strategy in which systems are modeled using the
artifacts of the UML and a formal language such as the
OCL from which working software is generated.
- Executive overview.
A definition of the vision for the system and a
summary of the current cost estimates, predicted
benefits, risks, staffing estimates, and scheduled
Someone responsible for planning, running, and
managing modeling sessions.
diagram depicting the logic flow of a business process
or software operation.
Flow charts are a primary artifact of
A collection of definitions of terms that are
relevant to your project.
user interface (GUI).
A style of user interface composed of graphical
components such as windows and buttons.
computer, switch, printer, or other hardware device.
The difference between two releases of a system.
- Information radiator.
A display of information posted on the wall where
passersby can see it.
In Java, a collection of zero or more operation
signatures that a class implements in whole.
- Interface object.
See boundary object.
- IT. Information Technology.
To move on to the next step/task, often in a
repetitious manner taking small steps each time.
Unified Process term referring to a distinct
sequence of activities with a baselined plan and
valuation criteria resulting in a release (either
internal or external).
- Ivory tower architecture.
An architecture developed in isolation from the
developers, or teams of developers, responsible for
application development (JAD). A structured, facilitated
meeting in which modeling is performed by a group of
are often held for gathering requirements or for
modeling candidate architecture(s).
Keep it simple stupid.
- Landscape model.
See overview model.
The organization of software collections (layers)
of classes or components that fulfill a common purpose.
user interface element.
A large-grained item such as a screen, HTML page,
box. The long, thin, vertical boxes that appear
on sequence diagrams which represent invocation of an
operation on an object or class.
user interface element.
A small-grained item such as a user input field,
menu item, list, or static text field.
- Model. An abstraction that describes one or more aspects
of a problem or a potential solution addressing a
problem. Traditionally, models are thought of as zero or
more diagrams plus any corresponding documentation.
However non-visual artifacts such collections of CRC
cards, a textual description of one or more business
rules, or the structured English description of a
business process are also considered to be models.
An activity where one or more people focus on the
development of one or more models.
The UML combines the concepts of cardinality and
optionality into the single concept of multiplicity.
- Network diagram.
A model that depicts the various types of
hardware nodes and the interconnections between them.
- Non-behavioral requirement.
A category of requirements that describe
technical features of a system, features typically
pertaining to availability, security, performance,
interoperability, dependability, and reliability.
A data modeling technique, the goal of which is
to organize data elements in such a way that they are
stored in one place and one place only.
An object modeling technique, the goal of which
is to organize behavior in such a way that it is
implemented in one place and one place only.
A modeling construct for adding free-form text to
Constraint Language (OCL).
The industry standard specification language
defined by the Object Management Group (www.omg.org).
in a sequence diagram, the life span of an object during
Object-oriented analysis and design.
OOA&D should be considered activities, not phases.
Represents the concept "do you need to have it?" in
- Operations documentation.
This documentation typically includes an
indication of the dependencies that your system is
involved with; the nature of its interaction with other
systems, databases, and files; references to backup
procedures; a list of contact points for your system and
how to reach them; a summary of the
availability/reliability requirements for your system;
an indication of the expected load profile of your
system; and troubleshooting guidelines.
- Organization chart.
A model that depicts the reporting structure
between the people, positions, and/or teams within an
- Osmotic communication.
Indirect information transfer through overhearing
conversations or simply noticing things happening around
- Overview diagram.
A high-level depiction of one aspect of your
Any type of diagram, such as a UML class diagram
or a data model, may be used as an overview diagram when
appropriate for the given view.
- Phase modeling sessions. A modeling
session where your focus is on creating models pertinent
to the major phases of traditional development.
This includes but is not limited to requirements,
analysis, architecture, and design modeling sessions.
- Physical prototype. A physical
model of the actual environment in which a system is to
Process improvement group (the pun is intended).
- Process object.
See control object.
- Project overview.
A document that summarizes critical information
such as the vision for the system, primary user
contacts, technologies and tools used to build the
system, the critical operating processes (some
applicable to development, such as how to build the
system and some applicable to production, such as how to
back up data storage), and references to critical
project artifacts such as the source code, the permanent
models, and other documents. This document serves as a starting point for anyone new to
- Project Stakeholder. A direct user, indirect user,
manager, senior manager, operations staff member,
support (help desk) staff member, testers, developers
working on other systems that integrate or interact with
this one, or maintenance professionals potentially
affected by the development and/or deployment of a
software project. For the sake of Agile Modeling
developers working on the project shall be excluded
whenever the term "project stakeholder" is
used, even though they clearly have an important stake
in the projects that they work on.
The deployment of a working version of a system.
Releases may be internal, available only to the
development team, or external, available to some or all
of the users for the system.
- Requirements document.
This document defines what the system will do,
summarizing or composed of requirements artifacts such
as business rule definitions, use cases, user stories,
or essential user interface prototypes (to name a few).
- Requirements modeling session. A modeling session where your focus is on defining what your
project stakeholders want your system to do.
- Requirements traceability matrix. The artifact used to record traceability relations between
- Robustness diagram. A model that
depicts the major objects - classified into
boundary/interface objects, entity objects, or
control/process objects - that participate in
fulfilling an actor's interaction with a system as
defined by a usage scenario.
Rational Unified Process.
A person responsible for recording information
during a modeling session.
Software engineering process group.
- Sequence diagram. A UML diagram
used to explore the logic of usage scenarios.
- Software development artifact. See artifact.
- Source code.
A sequence of instructions, including comments
describing those instructions, for a computer system.
Also known as program code, program source code,
or simply as code.
style of writing, such as Object Constraint Language (OCL)
and Structured English, used to describe logic in a
- SPI. Software process improvement.
- SRS. Software Requirements
- State chart diagram.
A UML diagram used to depict the various states
that an object may be in and the transitions between
A UML stereotype denotes a common usage of a
are used to extend the UML in a consistent manner.
- Structure diagram.
A diagram that depicts the modules of
procedure-based code and the invocation
relationships between those modules.
- Structured English.
A traditional, easy to read, style of
- Support documentation.
This documentation includes training materials
specific to support staff; all user documentation to use
as reference when solving problems; a trouble-shooting
guide; escalation procedures for handling difficult
problems; and a list of contact points within the
The software, documentation, hardware,
middleware, installation procedures, and operational
- System documentation.
The purpose of this document is to provide an
overview of the system and to help people understand the
information in this document includes an overview of the
technical architecture, the business architecture, and
the high-level requirements for the system.
- System use case.
A use case in which high-level implementation
decisions are reflected, such as the specific type of
user interface and your physical environment.
- Technical requirement. A
requirement pertaining to a non-business-related aspect
of your system, such as a performance-related issue, a
reliability issue, or a technical environment issue.
The ease of which the features of one artifact
- perhaps a document, model, or source code - are
related/traced to the features of another.
- Truck insurance.
The assurance that if the development team
leaves, or gets hit by a truck, that critical
information about the project is left behind in the form
An estimate of minimum number of people you would
need to lose from your team before you find yourself in
trouble (e.g. the number of people that would need to be
hit by a truck).
- UML. Unified Modeling Language.
- UP. Unified Process.
- Usage scenario.
A description of a single path of logic through
one or more use cases or user stories.
- Use case.
A sequence of actions that provide a measurable
value to an actor.
- Use case diagram.
A UML diagram used to depict a collection of use
cases, actors, their associations, and optionally a
system boundary box.
- Use case model.
The combination of one or more use case diagrams
and the supporting use cases and actor definitions.
- User documentation.
Documents describing how to work with your
system, including reference manuals, usage guides,
support guides, and training materials.
- User interface (UI).
The portion of software that a user directly
- User interface element.
See major user interface element and minor user
- User interface flow diagram. A
diagram that enables you to model the high-level
relationships between major user interface elements,
depicting a birds-eye view of the user interface of your
- User story.
A reminder to have a conversation with your
project stakeholders that captures a behavioral
requirement, a business rule, a constraint, or a
control tool. A software tool used to check
in/out, define, and manage versions of project
- Virtual meeting tool.
A tool that enables communication between several
people in different physical locations.
- Work product.
A type of artifact, such as a model or project
schedule, that you create during development that you
may discard or evolve into an actual deliverable.
- Working software.
Software that has been tested, accepted by its
users, and then released.
- xUML. See Executable UML.
You Ain't Gonna Need It Anyway.