Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
139 Cards in this Set
- Front
- Back
|
Activity Diagram
|
A visual representation of the sequential flow and control logic of a set of related activities or actions. A UML activity diagram uses standard shapes and naming conventions as defined in the Unified Modeling Language (UML)
|
|
|
Actor
|
A UML component that represents a resource that interfaces with software. Actors are represented as stick figures on use case diagrams
|
|
|
ANSI Diagram
|
A work flow diagram or flow chart that uses symbols developed by the American National Standards Institute (ANSI)
|
|
|
Approach
|
A development methodology (some analyst reserve the term approach for a set of informal development methods, as opposed to a highly structured, formal methodology like Spiral or IDEF)
|
|
|
Artifact
|
A tangible product of a project such as a requirements document or source code.
|
|
|
Assumption
|
In a project initiation document, a description of a project factor that is assumed to be true
|
|
|
Attribute
|
A characteristic that further descxribes an entity or class; a data element. Examples: LAST NAME, HIRE DATE for the entity EMPLOYEE. Aslo known as entity attribute or class attribute
|
|
|
Audit Requirement
|
Information that the process or system does not need in the normal course of events but must be possible to produce when required by an outside agency. An audit requirement is a type of environmental requirement
|
|
|
Business Analysis
|
The set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems. Solutions often include a systems development component, but may also consist of process improvement or organizational change.
|
|
|
Business Area
|
A group of related processes that share data (The term business area is often used interchangeably with project)
|
|
|
Business domain diagram
|
A complete description of existing and proposed organizational structures, processes, and information used by the business area
|
|
|
Business Process Analysis
|
Analysis of one or more critical business processes for the purpose of improving or optimizing the processes to meet changing requirements (perhaps brought on by a changing business environment) or to sustain organization development and growth
|
|
|
Business Requirement
|
Higher-level statements of the goals, objectives, or needs of the enterprise. They describe such things as the reasons why a project is initiated, the things that the project will achieve, and the metrics which will be used to measure it success.
|
|
|
Business Risk
|
A potential problem that may affect the mission or goals of a business area. Compare with project risk
|
|
|
Business Rule
|
A condition that governs the way work is done in a specific business area
|
|
|
Business Worker
|
A person who works within a business area
|
|
|
Cardinality
|
The number of instances of a given object or data entity that logically relate to an instance of another objecxt or entity. For example, if a business rule states that a customer can have one or more customer accounts, the cardinality for the entity ACCOUNT in its relationship to the entity CUSTOMER is "one to many"
|
|
|
Class
|
In object-oriented modeling, the definition of the abstract characteristics of a thing (object), including its characteristics (its attributes) and the things it can do (its operations).
|
|
|
Class Diagram/Model
|
Class Models, when developed by a Dusiness Analyst, are used to communicate the logical view of the requirements to the system designers to help them design the technology-specific solution. Class Diagrams, like Entity Relationshp Diagrams and class Models are static, or structureal, models that describe "what" is important to the enterprise.
|
|
|
Class Attribute
|
A description of information that may be recorded about a particular instance of a class (ie an object). Class attributes may include a description of the possible states or other data that may be of interest. Attributes are created, modified and deleted through a class's operations. Related topics: class model and class operations.
|
|
|
Consensus
|
An opinion or decision reached by a group as a whole. Note that a consensus opinion or decision is one that everyone in the group supports, even though some in the group may not agree with it entirely.
|
|
|
Context Diagram
|
see context-level data flow diagram
|
|
|
Context-Level Data Flow Diagram
|
The highest-level data flow diagram for a project, which includes the external entities that interface with the project and arrows to represent the data flows between the external entities and the project. Context-level data flow diagrams are often used by analysts to clarify and document requirements scope. Also knoiwn as context diagram, level 0 diagram, or scope diagram
|
|
|
Contingency Plan
|
A plan for reducing the potential impact or likelihood of an identified project risk or business resk. Also known as a mitigation strategy
|
|
|
Data Definition
|
A detailed description of a data element in an automated solution, including allowable values, default values, field length, etc
|
|
|
Database Definition
|
A textual or graphic description of a database's structure and content
|
|
|
Data Dictionary
|
A set of definitions for each primitive data element, with indications of how those elements combine into composite data elements
|
|
|
Data Element
|
An attribute that describes an entity or class of objects. Also known as a field
|
|
|
Data Requirements
|
See information need
|
|
|
Data Flow Diagram (DFD)
|
Provides a visual representation of how information is input, processed, stored, and output from a system.
|
|
|
Data Flow
|
Packaged information that flows through a business area. In a data flow diagram, each data flow path or pipeline is represented with an arrow. Net data flow refers to the aggregate data flowing in one direction between two objects.
|
|
|
Data Store
|
In a data flow diagram, a data store represents a location where data is not moving or being transformed but is being stored for future use.
|
|
|
Data Transformation and Mapping
|
For projects that involve existing business data records, the activities involved in gaining agreements on the names and fields and determibing how to map various systems to the new business solution names and fields. This planning is done to develop the value case needed to enforce consistency with the stakeholders
|
|
|
Design Area Scope
|
The business processes that are to be part of a software solution.
|
|
|
Design Flow
|
Diagrams and descriptions that depict how programs and other system components interface with each other such documentation helps the project team determine the best sequence of solution design activities in order to ensure that the solution design meets the stakeholders' needs within their time and cost objectives
|
|
|
Enterprise Analysis
|
The business analysis activities that take place for organization to (1) identify business opportunities, (2) build their business architecture framework, and (3) determine the optimum project investment path for the enterprise, including implementation of new business and technical system solutions.
|
|
|
Entity
|
A data modeling component that represents a class of things that the business area wants to keep information about. Common entities used by corporations include EMPLOYEE and CUSTOMER
|
|
|
Entity Relationship
|
A business rule that describes how two entities relate to each other, for example: A STUDENT enrolls in one or more CLASSes
|
|
|
Entity Relationship Diagram (ERD)
|
A structured analysis technique for graphically documenting date. It includes the entities of interest to the solution, the information that must be retained about each entity, and the relationships between entities
|
|
|
Environmental Requirement
|
A constraint imposed by the atmosphere outside of the system boundaries (such as a cultural constraint or a government regulation)
|
|
|
Event
|
An occurrence that requires a response from the business area. Events are of three basic types: an external event is an event that is triggered outside the business area; a temporal event is defined by the passing of time; an internal event is one that is initiated within the system
|
|
|
Event Identification
|
An approach to identifying the activities for a project by identifying the events that the project must respond to. Also known as event partitioning.
|
|
|
Executive Sponsor
|
Organization (or representative of the organization) that is funding the project
|
|
|
External Agent
|
See External Entity
|
|
|
External Entity
|
A person, organization, or system with which the business area interacts; a source or a destination of data. An external entity is not under the control of the business area being studied. Also known as a terminator or external agent.
|
|
|
Facilitator
|
The moderator of a group session responsible for helping the group share ideas, make decisions, or develop plans.
|
|
|
Facilitated Session
|
A meeting of individuals led by one person with the purpose of eliciting information or making decisions regarding a well-defined subject.
|
|
|
Function
|
A set of related processes that , as a group, does not have a distinct beginning and end, such as ORDER FULFILLMENT, PRODUCT MARKETING, or PRODUCT DEVELOPMENT. Compare with process
|
|
|
Functional Requirement
|
A description of the behavior and information that the planned solution will manage. Functional requirements describe system behaviors or operations
|
|
|
Geographic Diagram
|
A type of work flow diagram that shows where work is accomplished
|
|
|
Globalization and Localization Requirements
|
Environment requirements applicable to projects that must be implemented across multiple cultures or nationalities. They may include support for multiple languages, date and currency formats, number of displays, text sorting, and other considerations.
|
|
|
IDEF
|
A highly structured development methodology created by the US Department of Defense. IDEF prescribes work flow models in addition to data and process models
|
|
|
Implementation Requirement
|
A capability that a planned solution must have in order to facilitate transition from the current state of the enterprise to the desired future state, but that will not be needed once that transition is complete.
|
|
|
Information Engineering (IE)
|
A development methodology that introduced the use of models and diagrams to document business requirements and system design. The Information Engineering approach emphasizes data modeling in addition to process modeling
|
|
|
Information Need
|
Description of information that is or will be used by a business area (entities and attributes).
|
|
|
Iterative Methodology
|
A methodology that specifies the repetition (iteration) of one or more application development phases
|
|
|
Level 0 Diagram
|
See context-level data flow diagram
|
|
|
Methodology
|
A predefined approach for accomplishing a goal. A methodology prescribes a structured set of tasks that are repeatable and flexible and produce consistent deliverables and require defined roles
|
|
|
Mitigation Strategy
|
See contingency plan
|
|
|
Net (Data) Flow
|
The aggregate of all data flowing from one object to another (eg from a business area to an external agent or vice versa). Net flows are often represented in context-level data flow diagrams
|
|
|
Non-Functional Requirement
|
See quality of service requrement
|
|
|
Object
|
A specific instance of a class
|
|
|
Object-Oriented Analysis
|
The analysis of a business area (or specific problem) by modeling it as a group of interacting objects. (An object is defined by its class - that is, the type of object - its required data, and its behavior.) Related topic: class model
|
|
|
Opportunity
|
In project initiation documentation, a description of a solution, benefit., or advantage that will be provided by the planned project. An opportunity may have a corresponding problem statement
|
|
|
Peer Review
|
An activity in which one or more persons other than the author of a work product (but having the same role as the author) examine the product for defects and improvement opportunities
|
|
|
Procedure
|
Detailed step-by-step description of how a process is accomplished. Procedures usually contain a manual (non-automated) component
|
|
|
Problem
|
In project initiation documentation, a description of a business issue that the planned project will address. A problem may have a corresponding opportunity statement
|
|
|
Process
|
A business activity that transforms data. A process has a distinct beginning and end and may be high-level or low-level (detailed). Also known as an activity. Compare with function
|
|
|
Process Conflict
|
In a group setting, disagreement over the approach to reaching an objective
|
|
|
Process Decomposition Diagram
|
A diagram that depicts the parent-child relationships between business processes. Decomposition diagrams can include higher-level functions as well as processes
|
|
|
Problem
|
In project initiation documentation, a description of a business issue that the planned project will address. A problem may have a corresponding opportunity statement.
|
|
|
Product Life Cycle
|
See Project Life Cycle
|
|
|
Program Specification
|
See software requirememnts specification
|
|
|
Program Specification
|
See software requirements specification
|
|
|
Project Constraint
|
A criterion or method for evaluating a proposed solution
|
|
|
Project Initiation Document
|
A document produced at the beginning of the document that communicates the project statement of purpose, objectives, scope, schedule, participants,. and methodology or approach
|
|
|
Project Life Cycle (PLC)
|
All of the project phases/events needed to complete the project. Typical phases are definition, planning, initiation, and execution. Also known as a product life cycle or application development life cycle
|
|
|
Project Risk
|
A potential problem that may impeed the completion of a project./ Compare with business risk.
|
|
|
Project Scope
|
The scope of project tasks and deliverables. (know all parts). Compare with requirements scope. Related topic: scope definition and decomposition
|
|
|
Prototype
|
A model of a user interface in an automated system. There are different kinds of prototypes such as evolutionary, throw-away, and proof-of-concept
|
|
|
Quality of Service Requirement
|
A requirement that does not dire3cdtly relate to the behavior or functionality of the solution, but rather describes environmental conditions under which the solution must remain effective or qualities that the systems must have. Also known as quality attribute. non-functional requirement, or supplementary requirement
|
|
|
Rapid Application Development (RAD)
|
A development methodology that relies heavily on prototyping to speed up the Requirements Elicitation and analysis phases of the project life cycle
|
|
|
Rational Unified Process (RUP)
|
An iterative development methodology based on the spiral model
|
|
|
Relationship
|
See entity relationship
|
|
|
Requirement
|
A condition or capability needed by a stakeholder to solve a problem or achieve an objective
|
|
|
Requirement
|
A condition or capability needed by a stakeholder to solve a problem or achieve an objective
|
|
|
Requirement Attribute
|
Characteristic of a requirement that captures additional information about the requirements, such as the priority of the requirement or level of risk associated with it.
|
|
|
Requirements Discovery Session
|
A forum where stakeholders and subject matter experts get together to provide information about the planned system. This forum needs to be led by a business analyst who is a skilled facilitator, and assisted by a scribe whose role is to document the business requirements discovered. Also known as Requirements Elicitation session, requirements workshop, and Joint Requirements Planning Session
|
|
|
Requirements Review
|
A formal work session during which participants review a requirements package, ask questions, and make suggestions, with the goal of improving the package under review. Also known as an inspection.
|
|
|
Requirements Analysis and Documentation
|
The analysis of stakeholder needs and the structuring and specification of those needs for use in mthe design and implementation of a solution. The primary focus of this activity is to develop the analysis models and determine the gaps in the information provided by the stakeholders
|
|
|
Requirements Management
|
The process of working with a defined set of requirements throughout the project life cycle and the operational life of the solution. Includes tracking requirements status, managing changes to requirements and versions of requirements specifications,. and tracing individual requirements to other project phases and work products. Requirements management for large or complex projects usually requires software designed for requirements management.
|
|
|
Requirements Scope
|
The scope of requirements analysis required to support a project. The requirements scope documentation includes the information that drives the analysis process and establishes the boundaries for Requirements Elicitation and definition. Also known as Business area scope, scope of investigation or project scope./ Compare with project scope
|
|
|
Requirements Verification
|
Testing of system logic to ensure that it supports all business and functional requirements.
|
|
|
Reverse Engineering Requirement
|
A requirement identified by interviewing developetrs, reading code,. and/or testing applications
|
|
|
Risk Analysis
|
The process of identifying projects and business risks and for each risk,. determining the probability (high,. medium,. low) identifying potential impacts on the project or business and developing a contingency plan
|
|
|
RUP
|
See Rational Unified Process
|
|
|
Socpe Diagram
|
See context-level data flow diagram
|
|
|
Scope Definition and Decomposition
|
The activities to size the proposed project so that estimates can be made of costs, resources requirements and projext duration. Scope definition and decxomposition are traditional project management practices designed to understand the full scope of a project
|
|
|
Sequence Diagram
|
A type of diagram defined by UML that shows object interactions in time sequense. In particular it shows objects participating in interactions and the messages exchanged. This type of diagram can be used to depict use cases, by capturing the actors involved in the use case and the system under development as objects
|
|
|
SMART Objecxtive
|
An objective that is Specific, Measurable,. Achievable, Agreed-upon or Actionable (feasible), Realistic (in terms of resources), and Time-bound (a defined time line).
|
|
|
Software Requirements Specification (SRS)
|
The definition of what a computer program is expected to do. Also known as program specifications
|
|
|
Spiral Model
|
A modified version of the iterative development approach that requires the project team to perform risk analysis before each iteration and work first on the portions of the system that have the highest risks. It also involves implementing portions of the system as they are completed.
|
|
|
Stakeholder
|
A person, group, or organization that has an interest in the outcome of a project, can influence it's outcome, or is actively involved in the project. A statkehoder can be responsible for one or more project activities or deliverable and can impose constraints or boundaries on the project like time, money and resources
|
|
|
STakeholder Analysis
|
Analysis of project stakeholders to identify (1) each stakeholder's interests in the project, (2) potential conflicts in stakeholder viewpoints/interests that must be balanced, (3) the communication needs of each stakeholder throughout the phases of the project (i.e. format, level of detail, frequency).
|
|
|
State Machine Diagram
|
A graphic depiction of the sequence of states that an object goes through during it's lifetime, in response to events, and also the responses that the given object makes to those events. The state machine has one or more possible states that a transitioned or triggered by a signal
|
|
|
Storyboard
|
A diagram that shows the associations among screens/Web pages in an automated solution
|
|
|
Structured Analysis
|
A systematic approach to business and functional analysis including the use of implementation-independent graphical notation for documentation. Methoologies vary in the degree to which they specify structured-analysis techniques
|
|
|
Subject Matter Expert (SME)
|
A stakehoder who has extensive knowledge and experience in a business area and who is considered a source of information about the area. A subject matter expert may be inside or outside of the organization
|
|
|
Supplementary Requirement
|
Se quality of service requirement
|
|
|
Swim Lane Diagram
|
A type of work flow diagram that shows interactions between organizational units. Also known as a functional diagram
|
|
|
Risk
|
See project risk and business risk
|
|
|
Technical constraint
|
A hardware of software performance limit that the project team must consider in defining requirements for a software solution
|
|
|
Technical Requirement
|
A description of a technology solution designed to meet a business requirement. Technical requirements essentially describe a system from the perspective of the information technology team responsible for implementing the system. Also known as system requirement or software requirement
|
|
|
Terminator
|
See external agent
|
|
|
Test
|
A planned exercise of system functionality with clear acceptance criteria and recorded environment, procedure, inputs and outputs
|
|
|
Test Case
|
A detailed scenario for a test that will be run against the system and will be marked as passed or failed
|
|
|
Traceability
|
The characteristic of having logical links between one system component and another (for example, between a business rule and a test case)
|
|
|
UML Activity Diagram
|
See Activity Diagram
|
|
|
Unified Modeling Language (UML)
|
Step by step description of how a use case will be accomplished in the automated system. Primary components of a sue case description include the actors involved in the use case, any system preconditions that must be true before the use case can be initiated, the flow of events (both primary and alternate), and any system post conditions that result from the use case
|
|
|
Use Case Diagram
|
A graphic depiction of the actors who can interact with a system and the various use cases that each actor will perform
|
|
|
User
|
A person who interacts directly with a system or uses outputs from the system (such as reports). Aslo known as an end user.
|
|
|
Usage Model
|
Documentation that describes how a solution meets the needs of users. Components of usage models include prototypes, storyboards and user profiles
|
|
|
Technical Requirement
|
A description of a technology solution designed to meet a business requirement. Technical requirements essentially describe a system from the perspective of the information technology team responsible for implementing the system. Also known as system requirement or software requirement
|
|
|
Terminator
|
See external agent
|
|
|
Test
|
A planned exercise of system functionality with clear acceptance criteria and recorded environment, procedure, inputs and outputs
|
|
|
Test Case
|
A detailed scenario for a test that will be run against the system and will be marked as passed or failed
|
|
|
Traceability
|
The characteristic of having logical links between one system component and another (for example, between a business rule and a test case)
|
|
|
UML Activity Diagram
|
See Activity Diagram
|
|
|
Unified Modeling Language (UML)
|
Step by step description of how a use case will be accomplished in the automated system. Primary components of a sue case description include the actors involved in the use case, any system preconditions that must be true before the use case can be initiated, the flow of events (both primary and alternate), and any system post conditions that result from the use case
|
|
|
Use Case Diagram
|
A graphic depiction of the actors who can interact with a system and the various use cases that each actor will perform
|
|
|
User
|
A person who interacts directly with a system or uses outputs from the system (such as reports). Aslo known as an end user.
|
|
|
Usage Model
|
Documentation that describes how a solution meets the needs of users. Components of usage models include prototypes, storyboards and user profiles
|
|
|
User Class
|
A group of system users who have similar characteristics and requirements for the system. A description of a user class referred to as a user profile
|
|
|
User Profile
|
For a group of users of a system, a description of their common characteristics, the tasks they perform as system users, and any concerns related to supporting the group in achieving those tasks
|
|
|
User Requirement
|
A need of a particular stakeholder or class of stakeholders. User requirements serve as a bridge between business requirements and functional and quality of service requirements
|
|
|
Viewpoint
|
A perspective from which the project is or will be analyzed. Each project stakeholder has a viewpoint of the project, see stakeholder analysis
|
|
|
Waterfall Methodology
|
The first structured methology for information technology projects it specifies that the varous activities of requirements analysis, design, coding, testing and implementation are performed sequentially with litter overlap or iteration
|
|
|
Work Breakdown Structure (QBS)
|
A structured presentation of the tasks and deliverables required to complete a project
|
|
|
Work Flow Diagram
|
A diagram that details one or more bussiness processes to clarify understanding or to make process improvement recommendations. Theypes of work flow diagrams include ANSI, swim lane/function, UML activity and geography
|
