CSI Terms and Definitions
What is CRM?
CSI, CRM, Business Process Re-engineering, Domain Model, Actors…the list of CSI terms goes on. But what do these acronyms stand for and what do these terms mean? Many of these words are used in CSI meetings, business process re-engineering sessions, newsletter articles, meeting minutes and around the team office.
To help keep you from getting lost in CSI Alphabet Soup - learn this list of terms used in conjunction with the CSI project. You may also use this list as a reference tool in CSI meetings.
Don't see a term that you've heard? Let us know and we'll add it to the list. E-mail csi@dmv.virginia.gov.
| 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) |
| Analysis Model | A model created during Requirements development that included business scenarios, related business requirements, and a common vocabulary in the form of a Domain 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. |
| 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 Process Re-engineering (BPR) | BPR is 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. |
| BPR 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 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 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 Scenario | A Business Scenario documents the steps taken to meet one or more requirements as a description of a person's (or Actor's) interaction with a system. Scenarios 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. Scenarios are written as a series of individual steps, generally in the form of "Noun (or Actor)-verb-Noun (or Actor)." Scenarios may be refined and expanded during later system and software design into one or more 'use cases' that describe interactions at a technical level. Scenarios 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. |
 |
CSI 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. |
| 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) | Customer Relationship Management (CRM) is 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 Model | The design model consists of 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. It provides direct traceability from business requirements to implemented code as well as 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 | The Domain Model represents a structured glossary of nouns and actors used in the language of the business. |
| Domain Term | A Domain Term is 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) | Sparx Systems Enterprise Architect (EA) 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) | Legislative Improvement Opportunities (LIO) are Process Improvement Opportunities that require legislative action before they can be implemented. |
| Modeling | Modeling is 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. |
| 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) | Process Improvement Opportunities (PIOs) are 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 Proof of Concept (POC) is 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 request for proposal (RFP) is 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. |
| 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. |
| 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 use case diagram is 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) | Voice of the Customer (VOC) is 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. |