CSI Terms and Definitions
| Term | Definition / Description |
|---|---|
| Actor | Actors are human roles or systems which exist outside the system under study, and who (or which) take part in a sequence of activities in a dialogue with the system, to achieve some goal: they may be end users, other systems, or hardware devices. Sometimes, Internal System Actors are created to more conveniently aggregate behavior to more specific areas of "the system." |
| Alternate Flow | Applies to a use case or business scenario; within a Basic Flow, there are things that happen that represent exceptions to the basic flow, happen infrequently, or represent possibilities for improving the process in the future. These are alternate flows. (See Basic Flow) |
| Attribute | In computing, an attribute is a specification that defines a property of an object, element, or file; it describes the object. For example, some attributes of a person might include name, age, and date of birth. |
| Basic Flow | Applies to a Use Case business scenario. A basic flow is a step-by-step description of what happens "most of the time." (See Alternate Flow.) |
| Business Partner (BP) | A person, group, or organization that performs as a DMV agent to directly provide DMV's products and services. Examples include:
Also, a person, group, or organization that performs a service or supplies a product in support of DMV's product and services. Examples include:
|
| Business Process Area | A portion of the business which encapsulates common objectives, behavior and processes and provides a convenient organizing principle for organizational analysis, design and development. |
| Business Process Model | A model created during business process re-engineering that includes business use cases, related business requirements, and a common vocabulary in the form of a Business Process Model. This model provides the requirements and context needed to move to design level use case development and future formal software and systems design activity. |
| Business Process Re-engineering (BPR) | The discipline of first analyzing and then redesigning current business processes and their components in terms of their effectiveness, efficiency and added value contribution to the objectives of the business. The objective is to rethink and redesign business processes to achieve major improvements in measures of performance such as cost, quality, service and speed. BPR is typically the first step in any significant organization wide technology upgrade because of the potential of leveraging entirely new ways of doing things. |
| Business Process Re-engineering (BPR) Methodology | A structured framework which provides a step-by-step roadmap ensuring and documenting consistent and correct business processing re-engineering results. Methodologies are built from capturing strategies, techniques, methods and tools that constitute the principles and procedures of inquiry in a particular field. |
| Business Process Re-engineering Tools | Software packages that automate a method or methodology, enabling the correct use of a method, and aiding the user in a faster application of the method. |
| Business Requirement | A statement that describes in business terms what must be delivered or accomplished to provide value to the customer. The Business Requirement statement identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility as a business. |
| Business Rule | Specific logic that describes the operations, definitions, and constraints applied to an organization or business process to achieve its goals. Business rules can be driven by federal mandate, state legislation, DMV policy, a best practice, a lessons learned, or other regulatory forces such as AAMVA. Business rules often restrict who can perform certain functions or dictate that the system must contain compliance functionality, or specify how validations and calculations are performed. |
| Business Rule Extraction | The extraction of meaningful business data and rules from the current DMV systems, i.e. all relevant system artifacts, including source code, data definition language, batch and online control table, scripts and job control structures. |
| Business Use Case | A description of a person's (or Actor's) interaction with a system. Business use cases help focus design efforts on the user's experience in the context of a business delivering value to the customer, as well as to discern processing requirements distinct from technical or business requirements. Business use cases are written as a series of individual steps, generally in the form of "Noun (or Actor)-verb-Noun (or Actor)." They may be refined and expanded during later system and software design into one or more 'use cases' that describe interactions at a technical level. Business use cases have the advantage of being understood by people who do not have any technical background. They are suitable for use during participatory design and requirements development activities. |
| Constraint | A restriction that is imposed on the choices available for the design and construction of a product, process or system. |
| COTS (Commercial off-the-Shelf) Products | A term used for hardware or software products that are generally purchased and configurable for use "out of the box" with little or no additional programming. |
 |
The CSI logo is an acronym based upon the five characteristics to be included in the future DMV system; Customer-centric, Service Oriented, State-of-the-Art, Secure and Intelligent. |
| CSI Executive Summary | A report of BPR progress defined for a Business Process Area or as subset (Functional Group) within a Business Process Area that includes Legislative and Process Improvement Opportunities (LIO / PIO), business impact, and cost information. Executive summaries are supported by an Enterprise Architect (EA) Model Snapshot which captures all relevant BPR and requirements development data used to support the preparation of the Executive Summary at a point in time. Revisions to an Executive Summary based revisions to the model trigger subsequent EA model snapshots. |
| CSI Methodology | The set of theories, processes and associated documentation DMV is using to document the agency's future state business processes and system. |
| Customer | A person, group, or organization that directly pays for and/or receives the benefit of a DMV product or service. |
| Customer Relationship Management (CRM) | A broad business term that consists of providing employees with the information, processes, and tools necessary to know their customers, understand their needs, and effectively build relationships between the organization, its customer base, and distribution partners. It is a holistic approach that unifies all points of the customer interaction and promotes a way of thinking to maximize value from the customer perspective. CRM is also an information industry term for methodologies, software, and usually Internet capabilities that help an enterprise manage customer relationships in an organized way. |
| Design Forum | Conceptual design activities were conducted based on the results of re-engineering efforts. Conceptual architecture design artifacts and business artifacts including use cases and requirements were created. |
| Design Model | A formal collection of UML design artifacts that are consistent chosen technical architecture and usable in the direct creation of software code. This model is built and reviewed in increments during formal design and provides direct traceability from business requirements to implemented code. The model is also a vehicle for ensuring that effective collaboration takes place between analysts and developers during all design activities. It also provides an inventory of test cases for the test team and basic layout of required content for user documentation. |
| Domain Model | A structured glossary of nouns and actors used in the language of the business. |
| Domain Term | A noun that represents a thing or person or role. Domain terms represent the common language that allows people to refer to any single thing by a single name. Domain Terms are modeled in the Domain Model and are typically related as either "having" other nouns or "being" of another more generalized noun or actor type. |
| Enterprise Architect (EA) | Enterprise Architect (EA) by Sparx Systems is a general purpose UML based Computer Aided Software Engineering (CASE) tool for designing and constructing software. EA supports the UML 2.0 specification, a visual language that is used to define maps or models of a project. EA is a comprehensive tool that supports all aspects of the development cycle, providing full traceability from the initial design phase through deployment and maintenance. It also supports testing, maintenance and change control. |
| External Interface Requirement | A description of an interface between a software system and a user, another software system, or a hardware device. |
| External Stakeholder |
A person, group, or organization with a significant and defined interest and/or influence in DMV's products, services, policies, or business processes. Examples include:
|
| Functional Group | A cohesive set of packages within a Business Process Area that is reported as a BPR Increment using a Functional Group BPR Executive Summary. |
| Functional Requirement | A statement of a piece of required functionality or behavior that a system will exhibit under specific conditions. Functional requirements specify the software functionality that the developers must build into the system to enable users to accomplish their tasks (i.e., "The system shall…"). |
| ICONIX Software Design Process | An open, well-documented software engineering process that has the goal of taking development from requirements to code in an effective, yet disciplined, "low ceremony," four step process using the smallest possible subset of UML as the basis for documentation. Key features of the ICONIX Process are scenario based use cases, full requirements traceability throughout the process, and a unique shared cooperative understanding of requirements by an analyst-developer team through a technique called Robustness Analysis. |
| Lean Thinking | A customer-centric process management philosophy focused on reducing waste and optimizing customer value. By definition, a lean improvement is the systematic elimination of waste from any aspect of an organization's operations, where waste is viewed as any use or loss of resources that does not lead directly to creating the product or service a customer wants when they want it. |
| Legislative Improvement Opportunity (LIO) | Process Improvement Opportunities that require legislative action before they can be implemented. |
| Modeling | A term used to describe the process of representing objects in a computer system. Models are used to show relationships between processes and may be used to predict the effects of changes. |
| Non-functional Requirement | Requirements that focus on the operation of the system rather then specific or functional behavior. Non-functional requirements focus on areas such as maintainability, reliability, efficiency, usability and so on. |
| Organizational "Silo" | The term "Silo" implies the isolation of a Business Process Area having dysfunctional organizational consequences manifest as redundancy, lack of communication, unresponsiveness and misunderstanding that adversely impacts the delivery of product and service to the customer. |
| Package | A way of grouping related elements within the Enterprise Architect Tool. Packages are basically hierarchical containers that can contain almost any UML constructs, including other packages. |
| Process Coordinator | The individual(s) responsible for requirements gathering, the overall process design and performance, identifying future improvement opportunities for a DMV process area, and cross-process area coordination to ensure that all "silo-busting" improvements are identified and clearly explained. |
| Process Improvement Opportunity (PIO) | Identified changes to current business practice that reduce cost and/or improve effective operations. They come in three forms: changes that can be made immediately without software change are evaluated immediately as Lean opportunities; changes that can be applied only with new system development are identified as PIO requirements for the new system, and changes that require legislative action (LIOs). |
| Proof of Concept (POC) | A pre-defined set of activities used to test whether a particular idea, concept, or technology is feasible and effective. |
| Quality Attribute | Augmented descriptions of the system's functionality that address characteristics that are deemed important to users and/or developers. Quality attributes include usability, portability, integrity, efficiency, and robustness. |
| Request for Proposal (RFP) | A document that an organization posts to elicit bids from potential vendors for a product or service. |
| Requirement | A statement that describes in business terms what or why something must be delivered or accomplished to provide value. Requirements can be of various types including: business, user, reporting, statutory, functional, system and analytical. |
| Robustness Analysis and Diagramming | A graphical depiction of a software use case script using standard Unified Modeling Language (UML). The diagram is used to analyze and clarify the steps in the software use case. |
| Scenario | A scenario documents the steps taken to meet one or more requirements as a description of a person's interaction with a system. Scenarios help focus design efforts on the user or customer experience, which are distinct from technical or business requirements. Scenarios are written as a series of individual steps, generally in the form of "Noun/Actor-verb-noun/actor. Scenarios may be refined during later design into one or more 'use cases', which describe interactions at a technical level. Scenarios can be understood by people who do not have any technical background. They are suitable for use during participatory design and requirements development activities. |
| Scenario Driven Process Design | A process design approach in which the initial focus is on the required outcomes or outputs and the specific steps needed to achieve them. Desired products are identified by identifying scenario names. Steps are analyzed for improvement, consolidation, and/or elimination in comparison to similar processes as the analysis evolves. This approach is particularly useful for combining the systems and software requirements development with Business Process Re-engineering in a single activity, whether comprehensive, or focused on a particular individual mission outcome. |
| Scenario Name | A scenario name is written in verb-noun format (e.g., Borrow Books, Withdraw Cash), and describes an achievable goal (e.g., Register User is better than Registering User). A correctly formed name clearly states the product or business result of performing the use case. Scenarios co-exist with a requirement realized in the performance of the scenario. |
| Subject Matter Expert (SME) | The individual who understands the business process or area and is generally knowledgeable in the overall operation of business processes. |
| System Model | The System Model contains all of the Classes (and their associated attributes and operations) with links to all of the software use cases and requirements linked to each Class. The System Model will also contain diagrams illustrating the relationship among the classes. This Model will be the most significant deliverable of the Design Forum, providing the road map for development of the system. |
| Use Case | Use Cases provide a structured way of capturing the behavioral requirements of a system, so that you can create a design from them. A Use Case is a technique used in software and systems engineering to capture the functional requirements of a system. Use cases describe the interaction between a primary actor-the initiator of the interaction-and the system itself, as well as other actors and external systems. Use Cases are typically written in scenarios as sequences of simple steps. Design use cases are often derived from Business Scenarios and are used to bring the requirements developed through those scenarios into a more rigorous formal software design process. |
| Use Case Diagram | A standard UML graphical construct that describes how a user of a proposed system will interact with the system. It captures the Use Case and Actors interactions. It shows the grouping of services provided by the system to the users. The diagram includes actors (stick figures) the use case or transaction, and a link between an actor and each use case to show relationships/ associations to perform a function. |
| Voice of the Customer (VOC) | A communication tool used to help an organization create a common understanding of what its customers value most. This is important to Customer Relationship Management (CRM) because an organization or team cannot effectively design and manage its business products, services, processes and interactions without a good understanding of what its customers value. |