- abstract
- Something which cannot be directly
instantiated; the opposite of concrete.
- abstraction
- The creation of a view or model
that suppresses unnecessary details to focus on a specific set of details of interest.
- acceptance
- An action by which the customer
accepts ownership of software products as a partial or complete performance of a contract.
- active class
- A class representing a thread of
control in the system.
- activity
- A unit of work a worker may be asked
to perform
- actor (instance)
- Someone or something, outside the system
or business that interacts with the system or business.
- actor class
- Defines a set of actor instances,
in which each actor instance plays the same role in relation to the system or business.
- actor-generalization
- An actor-generalization
from an actor class(descendant) to another actor class (ancestor) indicates that the
descendant inherits the role the ancestor can play in a use case.
- aggregation
- An association that models a
whole-part relationship between an aggregate (the whole) and its parts.
- analysis
- The part of the software development
process whose primary purpose is to formulate a model of the problem domain. Analysis
focuses on what to do, design focuses on how to do it. See design.
- analysis & design
- A process
component in the Unified Process, whose purpose is to show how the system's use cases will
be realized in implementation; (general) activities during which strategic and tactical
decisions are made to meet the required functional and quality requirements of a system.
For the result of analysis and design activities, see "Design Model."
- analysis mechanism
- An architectural mechanism
used early in the design process, during the period of discovery when key classes and
subsystems are being identified. Typically analysis mechanisms capture the key aspects of
a solution in a way that is implementation independent. Analysis mechanisms are usually
unrelated to the problem domain, but instead are "computer science" concepts.
They provide specific behaviors to a domain-related class or component, or correspond to
the implementation of cooperation between classes and/or components. They may be
implemented as a framework. Examples include mechanisms to handle persistence,
inter-process communication, error or fault handling, notification, and messaging, to name
a few.
- architectural baseline
- The baseline at the end
of the Elaboration phase, at which time the foundation structure and behavior of the
system is stabilized.
- architectural mechanism
- An architectural mechanism represents a common solution to a frequently encountered
problem. They may be patterns of structure, patterns of behavior, or both.
- architectural pattern
- A description of an
archetypal solution to a recurrent design problem that reflects well-proven design
experience. Presented in the Software Architecture
Document.
- architectural view
- A view of the system
architecture from a given perspective; focuses primarily on structure, modularity,
essential components, and the main control flows.
- architecture
- The highest level concept of a
system in its environment [IEEE]. The architecture of a software system (at a given point
in time) is its organization or structure of significant components interacting through
interfaces, those components being composed of successively smaller components and
interfaces.
- artifact
- (1) A piece of information that (1) is
produced, modified, or used by a process, (2) defines an area of responsibility, and (3)
is subject to version control. An artifact can be a model, a model element, or a document.
A document can enclose other documents.
- association
- A relationship that models a
bi-directional semantic connection among instances.
- attribute
- An attribute defined by a class
represents a named property of the class or its objects. An attribute has a type that
defines the type of its instances.
- baseline
- A reviewed and approved release of
artifacts that constitutes an agreed basis for further evolution or development and that
can be changed only through a formal procedure, such as change management and
configuration control.
- boundary class
- A class used to model
communication between the system's environments and its inner workings.
- build
- An operational version of a system or
part of a system that demonstrates a subset of the capabilities to be provided in the
final product.
- change control board (CCB)
- The role of the CCB
is to provide a central control mechanism to ensure that every change request is properly
considered, authorized and coordinated.
- change management
- The activity of controlling
and tracking changes to artifacts.
- change request (CR)
- A CR is a general term for
a request to change an artifact or process. Documented in the CR is information on the
origin and impact of the current problem, the proposed solution, and its cost.
- class
- A class is a description of a set of
objects that share the same responsibilities, relationships, operations, attributes, and
semantics.
- class diagram
- A class diagram shows a
collection of declarative (static) model elements, such as classes, packages, their
contents, and relationships.
- collaboration
- Interaction among objects.
- collaboration diagram
- A collaboration diagram
describes a pattern of interaction among objects; it shows the objects participating in
the interaction by their links to each other and the messages they send to each other.
- communicates-association
- An association between
an actor class and a use case class, indicating that their instances interact. The
direction of the association indicates the initiator of the communication.
- component
- A non-trivial, nearly independent,
and replaceable part of a system that fulfills a clear function in the context of a
well-defined architecture. A component conforms to and provides the physical realization
of a set of interfaces.
- component-based development (CBD)
- The creation
and deployment of software-intensive systems assembled from components as well as the
development and harvesting of such components.
- component subsystem
- A stereotyped subsystem
(i.e. «component») representing the logical abstraction in design of a component. It
realizes one or more interfaces, and may be dependent on one or more interfaces. It may
enclose zero or more classes, packages or other component subsystems, none of which are
visible externally (only interfaces are visible). It may also enclose zero or more
diagrams which illustrate internal behavior (e.g. state, sequence or collaboration
diagrams).
- concrete
- An entity in a configuration that satisfies an end-use function and can be uniquely
identified at a given reference point. (ISO)
- configuration
- (1) general: The arrangement of a
system or network as defined by the nature, number, and chief characteristics of its
functional units; applies to both hardware or software configuration.
- (2) The requirements, design, and implementation that define a particular version of a
system or system component. See configuration
management.
- configuration item
- An entity in a configuration
that satisfies an end-use function and can be uniquely identified at a given reference
point. (ISO)
- configuration management
- A supporting process whose purpose is to identify, define, and baseline items; control
modifications and releases of these items; report and record status of the items and
modification requests; ensure completeness, consistency and correctness of the items; and
control storage,
- handling and delivery of the items. (ISO)
- control class
- A class used to model behavior
specific to one, or a several use cases.
- configuration
- (1) The arrangement of a system or network as defined by the nature, number, and chief
characteristics of its functional units; applies to both hardware or software. (2) The
requirements, design, and implementation that define a particular version of a system or
system component. (see configuration management)
- configuration item
- An entity in a configuration that satisfies an end-use function, and that can be
uniquely identified at a given reference point. (ISO)
- configuration management
- A supporting process
the purpose of which is to identify, define, and baseline items; control modifications and
releases of these items; report and record status of the items and modification requests;
ensure completeness, consistency and correctness of the items; and control storage,
handling and delivery of the items. (ISO)
- construction
- The third phase of the
Unified Process, in which the software is brought from an executable architectural
baseline to the point at which it is ready to be transitioned to the user community.
- customer
- A person or organization, internal or
external to the producing organization, who takes financial responsibility for the system.
In a large system this may not be the end user. The customer is the ultimate recipient of
the developed product and its artifacts.
- cycle
- One complete pass through the four
phases: inception, elaboration, construction and transition. The span of time between the
beginning of the inception phase and the end of the transition phase.
- deadlock
- A condition in which two independent
threads of control are blocked, each waiting for the other to take some action.
Deadlock often arises from adding synchronization mechanisms to avoid race conditions.
- defect
- A product anomaly. Examples include such
things as omissions and imperfections found during early lifecycle phases and symptoms of
faults contained in software sufficiently mature for test or operation. A defect can be
any kind of issue you want tracked and resolved.
- deliverable
- An output from a process that has a
value, material or otherwise, to a customer.
- deployment
- A core process workflow in the
software-engineering process, whose purpose is to ensure a successful transition of the
developed system to its users. Included are artifacts such as training materials and
installation procedures.
- deployment view
- An architectural view that
describes one or several system configurations; the mapping of software components (tasks,
modules) to the computing nodes in these configurations.
- deliverable
- An output from a process that has a value - material or nonmaterial - to a customer.
- design
- The part of the software development
process whose primary purpose is to decide how the system will be implemented. During
design, strategic and tactical decisions are made to meet the required functional and
quality requirements of a system. See analysis.
- design mechanism
- An architectural mechanism used during the design process, during the period in which
the details of the design are being worked-out. They are related to associated analysis
mechanisms, of which they are additional refinements. A design mechanism assumes some
details of the implementation environment, but it is not tied to a specific implementation
(as is an implementation mechanism). For example, the analysis mechanism for inter-process
communication may be refined by several design mechanisms for interprocess communication
(IPC): shared memory, function-call-like IPC, semaphore-based IPC, and so on. Each design
mechanism has certain strengths and weaknesses; the choice of a particular design
mechanism is determined by the characteristics of the objects using the mechanism.
- design model
- An object model describing the
realization of use cases; serves as an abstraction of the implementation model and its
source code.
- design package
- A collection of classes,
relationships, use-case realizations, diagrams, and other packages; it is used to
structure the design model by dividing it into smaller parts.
- design pattern
- A specific solution to a particular problem in software design. Design patterns capture
solutions that have developed and evolved over time, expressed in a succinct and easily
applied form. Generally design patterns express solutions at a lower level of granularity
than mechanisms, and may very well be used to design a design mechanism.
- design subsystem
- A design package that contains a collection of design packages and classes, and used to
structure the design model by dividing it into smaller parts. See "Design
Package."
- developer
- A person responsible for developing
the required functionality in accordance with project-adopted standards and procedures.
This can include performing activities in any of the requirements, analysis & design,
implementation, and test workflows.
- development case
- The software-engineering
process used by the performing organization. It is developed as a configuration, or
customization of the Unified Process product, and adapted to the project's needs.
- device
- A type of node which provides supporting capabilities to a processor. Although it may be capable of running embedded
programs (device drivers), it cannot execute general-purpose applications, but instead
exists only to serve a processor running general-purpose applications.
- diagram
- A graphical depiction of all or part of
a model.
- document
- A document is a collection of
information that is intended to be represented on paper, or in a medium using a paper
metaphor. The paper metaphor includes the concept of pages, and it has either an implicit
or explicit sequence of contents. The information is in text or two-dimensional pictures.
Examples of paper metaphors are word processor documents, spreadsheets, schedules, Gantt
charts, web-pages, or overhead slide presentations.
- document description
- Describes the contents of
a particular document.
- document template
- A concrete tool template,
such as a Frame or Microsoft® Word™ template.
- domain
- An area of knowledge or activity
characterized by a family of related systems.
- elaboration
- The second phase of the
process where the product vision and its architecture are defined.
- enclosed document
- A document can be enclosed by
another document to collect a set of documents into a whole; the enclosing document as
well as the individual enclosures are regarded as separate artifacts.
- entity class
- A class used to model information
that has been stored by the system, and the associated behavior. A generic class, reused
in many use cases, often with persistent characteristics. An entity class defines a set of
entity objects, which participate in several use cases and typically survive those use
cases.
- environment
- A core supporting workflow in the
software-engineering process, whose purpose is to define and manage the environment in
which the system is being developed. Includes process descriptions, configuration
management, and development tools.
- evolution
- The life of the software after its
initial development cycle; any subsequent cycle, during which the product evolves.
- evolutionary
- An iterative development strategy
that acknowledges that user needs are not fully understood and therefore requirements are
refined in each succeeding iteration (elaboration phase).
- extend-relationship
- An extend-relationship from
a use-case class A to a use-case class B indicates that an instance of B may include
(subject to specific conditions specified in the extension) the behavior specified by A.
Behavior specified by several extenders of a single target use case can occur within a
single use-case instance.
- fault
- An accidental condition that causes a
component in the implementation model to fail to perform its required behavior. A fault is
the root cause of one or more defects.
- feature
- An externally observable service provided by the system which directly fulfills a
stakeholder need.
- framework
- A micro-architecture that provides an
incomplete template for applications within a specific domain
- FURPS
- An acronym representing categories for assessing product quality: Functionality,
Usability, Reliability, Performance, Supportability.
- generalization
- A taxonomic relationship between a
more general element and a more specific element. The more specific element is fully
consistent with the more general element and contains additional information. An instance
of the more specific element can be used where the more general element is allowed.
- generation
- Final release at the end of a cycle.
- implementation
- A core process workflow in the
software-engineering process, whose purpose is to implement and unit test the classes.
- implementation mechanism
- An architectural mechanism used during the implementation process. They are refinements
of design mechanisms, and specify the exact implementation of the mechanism. For example,
one particular implementation of the inter-process communication analysis mechanism is a
shared memory design mechanism utilizing a particular operating system’s shared
memory function calls. Concurrency conflicts (inappropriate simultaneous access to shared
memory) may be prevented using semaphores, or using a latching mechanism, which in turn
rest upon other implementation mechanisms.
- implementation model
- The implementation model
is a collection of components, and the implementation subsystems that contain them.
- implementation subsystem
- A collection of
components and other implementation subsystems, and is used to structure the
implementation model by dividing it into smaller parts.
- implementation view
- An architectural view that
describes the organization of the static software elements (code, data, and other
accompanying artifacts) on the development environment, in terms of both packaging,
layering, and configuration management (ownership, release strategy, and so on). In the
Unified Process it is a view on the implementation model.
- import-dependency
- A stereotyped dependency in
the design whose source is a design package, and whose target is a different design
package. The import dependency causes the public contents of the target package to be
referenceable in the source package.
- inception
- The first phase of the Unified
Process, in which the seed idea, request for proposal, for the previous generation is
brought to the point of being (at least internally) funded to enter the elaboration phase.
- include-relationship
- An include-relationship is
a relationship from a base use case to an inclusion use case, specifying how the behavior
defined for the inclusion use case is explicitly inserted into the behavior defined for
the base use case.
- increment
- The difference (delta) between
two releases at the end of subsequent iterations.
- incremental
- Qualifies an iterative development
strategy in which the system is built by adding more and more functionality at each
iteration.
- inheritance
- The mechanism that makes
generalization possible; a mechanism for creating full class descriptions out of
individual class segments.
- input
- An artifact used by a process. See static artifact.
- inspection
- A formal evaluation technique in
which some artifact (model, document, software) is examined by a person or group other
than the originator, to detect faults, violations of development standards, and other
problems.
- instance
- An individual entity satisfying the description of a class or type.
- integration
- The software development activity
in which separate software components are combined into an executable whole.
- integration build plan
- Defines the
order in which components are to be implemented and integrated in a specific iteration.
Enclosed in the Iteration Plan.
- interface
- A collection of operations that are
used to specify a service of a class or a component.
- iteration
- A distinct sequence of activities
with a base-lined plan and valuation criteria resulting in a release (internal or
external).
- key mechanism
- A description of how an
architectural patterns is realized in terms of patterns of interaction between elements in
the system. Presented in the Software Architecture
Document
- layer
- A specific way of grouping
packages in a model at the same level of abstraction.
- logical view
- An architectural view that
describes the main classes in the design of the system: major business-related classes,
and the classes that define key behavioral and structural mechanisms (persistency,
communications, fault-tolerance, user-interface). In the Unified Process, the logical view
is a view of the design model.
- management
- A core supporting workflow in the
software-engineering process, whose purpose is to plan and manage the development project.
- method
- (1) A regular and systematic way of
accomplishing something; the detailed, logically ordered plans or procedures followed to
accomplish a task or attain a goal. (2) UML 1.1: The implementation of an operation, the
algorithm or procedure that effects the results of an operation.
- milestone
- The point at which an iteration
formally ends; corresponds to a release point.
- model
- A semantically closed abstraction of a
system. In the Unified Process, a complete description of a system from a perspective
('complete' meaning you don't need any additional information to understand the system
from that perspective); a set of model elements. Two models cannot overlap.
- model element
- An element that is an abstraction
drawn from the system being modeled.
- modeling conventions
- How concepts will be
represented, restrictions on the modeling language that the project team management has
decided upon (i.e. dictums such as do not use inheritance between subsystems, do
not use extend or include associations in the Use Case Model, do not use the friend
construct in C++). Presented in the Software
Architecture Document.
- node
- A run-time physical object that represents
a computational resource, generally having at least a memory and often processing
capability as well. Run-time objects and components may reside on nodes.
- object
- An entity with a well-defined boundary
and identity that encapsulates state and behavior. State is represented by attributes and
relationships, behavior is represented by operations and methods. An object is an instance
of a class.
- object model
- An abstraction of a system's
implementation.
- operation
- A service that can be requested from
an object to effect behavior.
- operating system process
- An unique address space and execution environment in which instances of classes and
subsystems reside and run. The execution environment may be divided into one or more
threads of control. See also process and thread.
- originator
- An originator is anyone who submits
a change request (CR). The standard change request mechanism requires the originator to
provide information on the current problem, and a proposed solution in accordance with the
change request form.
- output
- Any artifact that is the result of a
process step. See deliverable.
- package
- A grouping of modeling elements.
- pattern
- A scheme for describing design fragments or collections of class templates so that they
can be configured and reused.
- phase
- The time between two major project
milestones, during which a well-defined set of objectives is met, artifacts are completed,
and decisions are made to move or not move into the next phase.
- postcondition
- A textual description defining a constraint on the system when a use case has
terminated.
- precondition
- A textual description defining a constraint on the system when a use case may start.
- process
- (1) A thread of control that can logically execute concurrently with other processes,
specifically an operating system process. See also thread. (2) A set
of partially ordered steps intended to reach a goal; in software engineering the goal is
to build a software product or to enhance an existing one; in process engineering, the
goal is to develop or enhance a process model; corresponds to a business use case in
business engineering.
- process component
- One of seven process components in Objector 4.1: Requirements Capture, Analysis &
Design, Implementation, Test, Management, Environment, and Deployment. An abstract
business use case of the Software-Engineering Business.
- process view
- An architectural view that describes the concurrent aspect of the system: tasks
(processes) and their interactions.
- processor
- A type of node which possesses the capability to run one or more processes. Generally
this requires a computational capability, memory, input-output devices, etc. See
also node, process, and device.
- product
- Software that is the result of development, and some of the associated artifacts
(documentation, release medium, training).
- product champion
- A high-ranking individual who owns the vision of the product and acts as an advocate
between development and the customer.
- product requirements document (PRD)
- A high level description of the product (system), its intended use, and the set of
features it provides.
- project manager
- The worker with overall responsibility for the project. The Project Manager needs to
ensure tasks are scheduled, allocated and completed in accordance with project schedules,
budgets and quality requirements.
- prototype
- A release that is not necessarily
subject to change management and configuration control.
- quality assurance (QA)
- QA reports to the
Project Manager and are responsible for ensuring that project standards are correctly and
verifiably followed by all project staff.
- race condition
- A condition which occurs when two or more
independent tasks may simultaneously access and modify the same state information.
This condition can lead to inconsistent behavior of the system and is a fundamental issue
in concurrent system design.
- rank
- An attribute of a use case or scenario
that describes its impact on the architecture, or its importance for a release.
- rationale
- A statement, or explanation of the
reasons for a choice
- release
- A subset of the end-product that is the
object of evaluation at a major milestone (see prototype, baseline).
- release manager
- A release manager is responsible for ensuring that all software assets are controlled
and configurable into internal and external releases as required.
- report
- An automatically generated description,
describing one or several artifacts. A report is not an artifact in itself. A report is in
most cases a transitory product of the development process, and a vehicle to communicate
certain aspects of the evolving system; it is a snapshot description of artifacts that are
not documents themselves.
- requirement
- A requirement describes a condition
or capability of a system; either derived directly from user needs, or stated in a
contract, standard, specification, or other formally imposed document.
- requirement attribute
- Information associated with a particular requirement providing a link between the
requirement and other project elements - priorities, schedules, status, design elements,
resources, costs, hazards.
- requirements
- A core process workflow in the
software-engineering process, whose purpose is to define what the system should do. The
most significant activity is to develop a use-case model.
- requirements capture
- A process component in the software-engineering process, whose purpose is to define what
the system should do. The most significant activity is to develop a use-case model.
- requirements management
- A systematic approach to eliciting, organizing and documenting the requirements of the
system, and establishing and maintaining agreement between the customer and the project
team on the changing requirements of the system.
- requirements tracing
- The linking of a requirement to other requirements and to other associated project
elements.
- requirements type
- A categorization requirements (e.g., stakeholder need, feature, use case, supplementary
requirement, test requirement, documentation requirement, hardware requirement, software
requirement, etc.) based on common characteristics and attributes.
- result
- Synonym of output. See also deliverable.
- reuse
- Further use or repeated use of an
artifact
- risk
- An ongoing or upcoming concern that has a
significant probability of adversely affecting the success of major milestones.
- scenario
- A described use-case instance, a
subset of a use case.
- sequence diagram
- A diagram that describes a
pattern of interaction among objects, arranged in a chronological order; it shows the
objects participating in the interaction by their "lifelines" and the messages
that they send to each other.
- software architecture
- Software architecture
encompasses:
- the significant decisions about the organization of a software system,
- the selection of the structural elements and their interfaces by which the system is
composed together with their behavior as specified in the collaboration among those
elements,
- the composition of the structural and behavioral elements into progressively larger
subsystems,
- the architectural style that guides this organization, these elements and their
interfaces, their collaborations, and their composition.
- Software architecture is not only concerned with structure and behavior, but also with
usage, functionality, performance, resilience, reuse, comprehensibility, economic and
technology constraints and tradeoffs, and aesthetic concerns.
- software requirement
- A specification of an externally observable behavior of the system, (e.g., inputs to the
system, outputs from the system, functions of the system, attributes of the system, or
attributes of the system environment).
- software requirements specifications (SRS)
- A set of requirements which completely defines the external behavior of the system to be
built. (sometimes called a functional specification)
- stakeholder
- An individual who is materially affected by the outcome of the system.
- stakeholder need
- The business or operational problem (opportunity) that must be fulfilled in order to
justify purchase or use.
- state diagram (or chart)
- A state diagram shows
a state machine, that is, a behavior that specifies the sequences of states that an object
goes through during its life in response to events, together with its responses and
actions.
- static artifact
- An artifact that is used, but
not changed, by a process.
- stereotype
- A meta-classification of an element.
Stereotypes have semantic implications which can be specified for every specific
stereotype value.
- stub
- A component containing functionality for
testing purposes. A stub is either a pure "dummy", just returning some
predefined values, or it is "simulating" a more complex behavior.
- subsystem
- A model element which has the semantics of a package, such that it can contain other
model elements, and a class, such that it has behavior. (The behavior of the subsystem is
provided by classes or other subsystems it contains). A subsystem realizes one or more
interfaces, which define the behavior it can perform.
- system
- As an instance, an executable
configuration of a software application or software application family; the execution is
done on a hardware platform. As a class, a particular software application or software
application family that can be configured and installed on a hardware platform. In a
general sense, an arbitrary system instance.
- target (for test)
- A build that is an object for
testing. See build.
- task
- See operating system process, process
and thread.
- team leader
- The team leader is the interface
between project management and developers. The team leader is responsible for ensuring
that a task is allocated and monitored to completion. The team leader is responsible for
ensuring that development staff follow project standards, and adhere to project schedules.
- technical authority
- The project's technical
authority has the authority and technical expertise to arbitrate on if, and how, a change
request is to be implemented. The technical authority defines change tasks, and estimates
the effort of engineering the work tasks (corresponding to a change request).
- test
- A core process workflow in the
software-engineering process whose purpose is to integrate and test the system.
- test case
- A set of test inputs, execution
conditions, and expected results developed for a particular objective, such as to exercise
a particular program path or to verify compliance with a specific requirement.
- test coverage
- The degree to which a given test
or set of tests addresses all specified test cases for a given system or component.
- test driver
- A software module or application
used to invoke a test item and, often, provide test inputs (data), control and monitor
execution, and report test results. A test driver automates the execution of test
procedures.
- test item
- A build which is an object of
testing. See build.
- test procedure
- A test procedure is a set of
detailed instructions for the set-up, execution, and evaluation of results for a given
test case.
- thread
- An independent computation executing within an the execution environment and address
space defined by an enclosing operating system process. Also
sometimes called a 'lightweight process'.
- traceability
- The ability to trace a project element to other related project elements.
- transition
- The fourth phase of the
process in which the software is turned over to the user community.
- type
- Description of a set of entities which share common characteristics, relations,
attributes, and semantics.
- use case (class)
- A use case defines a set of use-case
instances, where each instance is a sequence of actions a system performs that yields an
observable result of value to a particular actor. A use-case class contains all main,
alternate flows of events related to producing the 'observable result of value'.
Technically, a use-case is a class whose instances are scenarios.
- use-case diagram
- A use-case diagram shows
actors, use cases, use-case packages, and their relationships.
- use-case instance
- A sequence of actions performed by a system that yields an observable result of value to
a particular actor.
- use-case model
- A model of what the system is
supposed to do and the system environment.
- use-case package
- A use-case package is a
collection of use cases, actors, relationships, diagrams, and other packages; it is used
to structure the use-case model by dividing it into smaller parts.
- use-case realization
- A use-case realization
describes how a particular use case is realized within the design model, in terms of
collaborating objects.
- use-case view
- An architectural view that
describes how critical use cases are performed in the system, focusing mostly on
architecturally significant components (objects, tasks, nodes). In the Unified Process, it
is a view of the use-case model.
- version
- A variant of some artifact; later
versions of an artifact typically expand on earlier versions.
- view
- A simplified description (an abstraction)
of a model, which is seen from a given perspective or vantage point and omits entities
that are not relevant to this perspective. See also architectural
view.
- vision
- The user's or customer's view of the
product to be developed.
- worker
- Role figure to be played by individual
members in the business.
- workflow
- The sequence of activities performed
in a business that produces a result of observable value to an individual actor of the
business.
| |
|
