1/44
A comprehensive vocabulary flashcard set covering key concepts, methodologies, roles, requirements techniques, functional modeling, and structural modeling in Systems Analysis and Design.
Name | Mastery | Learn | Test | Matching | Spaced | Call with Kai | Chat |
|---|
No analytics yet
Send a link to your students to track their progress
Systems Analyst
A key role responsible for analyzing the business, identifying opportunities for improvement, and designing information systems to implement these ideas.
Business Analyst
A role focused on analyzing key business aspects of the system, identifying how the system will provide business value, and designing new business processes and policies.
Infrastructure Analyst
A role responsible for ensuring that the system conforms to infrastructure standards and identifying infrastructure changes needed to support the system.
Change Management Analyst
A role responsible for developing and executing a change management plan as well as developing and executing a user training plan.
Project Manager
A role responsible for managing the team of specialists, developing and monitoring the project plan, assigning resources, and serving as the primary point of contact for the project.
Waterfall Development
A structured design methodology where projects move methodically from one phase to the next, requiring a step to finish before the next one begins.
Parallel Development
A structured design methodology that breaks a project into subprojects that can be designed and implemented simultaneously before final integration.
Throwaway Prototyping
A Rapid Application Development methodology that uses design prototypes in user iterations solely to explore alternatives and clarify requirements rather than building the final system directly from them.
Project Sponsor
A key person within the organization who proposes the development or adoption of a new information technology system.
System Request
A document that initiates a project by defining the project sponsor, business need, business requirements, business value, and special issues or constraints.

Technical Feasibility
An assessment of whether the organization can successfully design and install the system, evaluating familiarity with application and technology, project size, and domain knowledge.
Economic Feasibility
A cost-benefit analysis that identifies development costs, operational costs, annual benefits, and intangible factors to determine financial viability.
Organizational Feasibility
An evaluation of how well the proposed system will be accepted by stakeholders, including project champions, organizational management, and system users.
Return on Investment
A financial performance metric calculated using the formula ROI=Total CostsTotal Benefits−Total Costs.
Net Present Value
A financial metric used to evaluate multi-year cash flows by discounting future amounts using the formula (1+interest rate)nAmount, where n equals the number of periods.
Scope Creep
A major cause of project failure where new requirements are incrementally added to the project after its scope has already been set.
Timeboxing
A project management technique that sets a strict fixed deadline and manages schedule delays by prioritizing core features and reducing functionality if necessary.

Kanban
An Agile visual management method using cards organized across swimlanes such as STORIES, TO DO, IN PROGRESS, TESTING, and DONE.
Functional Requirement
A statement specifying a process the system must perform or information the system must contain to support a user task.
Non-Functional Requirement
A statement specifying system quality attributes, operational environments, performance goals, security safeguards, or cultural and political constraints.
Root Cause Analysis
A requirements analysis technique that challenges assumptions about why problems exist and traces observed symptoms back to their true underlying causes.
Duration Analysis
A requirements analysis method involving a detailed examination of the amount of time required to perform each process in the current as-is system.
Activity-Based Costing
A requirements analysis method that calculates and analyzes the financial cost associated with each major process or step in a business workflow.
Outcome Analysis
A major improvement requirements technique focusing on desirable outcomes from the customer's perspective enabled by information systems.
Technology Analysis
A requirements technique where managers and analysts identify innovative technologies and brainstorm potential business applications and benefits for each.
Activity Elimination
A brainstorming technique where analysts examine what would happen if each organizational activity were eliminated to overcome habitual thinking limitations.

Top-Down Questioning
An interview strategy that starts with general, high-level questions (e.g., 'How can order processing be improved?') and proceeds down to specific, low-level details.
Probing Questions
Interview follow-up questions used to expand on discussed topics and obtain deeper detail (e.g., 'Why?', 'Can you give me an example?').
Use Case
A logical model representing a major piece of system functionality and user activities without specifying technical implementation details.
Actor
An entity external to the system (person or nonhuman system) that derives benefit from and interacts with the subject, depicted as a stick figure or a rectangle with <
Subject Boundary
A boundary box in a use-case diagram that encloses all system use cases and defines the scope of the subject system or process.
Include Relationship
A relationship in a use-case diagram representing mandatory execution of one use case within another, drawn as a dashed arrow from the base use case to the used use case labeled <
Extend Relationship
A relationship in a use-case diagram representing optional conditional behavior added to a base use case, drawn as a dashed arrow from the extension use case to the base use case labeled <
Action
A simple, nondecomposable piece of behavior in an activity diagram labeled by its name inside a rounded rectangle.
Activity
A set of actions in an activity diagram that can be further decomposed into sub-actions or workflows.
Decision Node
A diamond-shaped symbol in an activity diagram representing a test condition that routes control or object flow down a single path based on decision criteria.
Swimlane
A row or column partition in an activity diagram used to assign specific activities or actions to responsible roles or objects.
Concrete Class
A domain or system class that can be directly instantiated to create object instances.
Abstract Class
A class created as a useful abstraction in object-oriented modeling that cannot be instantiated directly into objects.
Derived Attribute
An attribute whose value is calculated from other attribute values, represented on a class diagram by a slash (/) preceding its name.
Generalization Relationship
An inheritance relationship ('a-kind-of') between a generalized superclass and a specialized subclass, denoted by a solid line with a hollow arrowhead pointing to the superclass.
Aggregation Relationship
A logical 'a-part-of' relationship between a whole class and its part classes, represented by an open diamond symbol at the whole end of the association line.
Composition Relationship
A physical 'a-part-of' relationship between classes where parts cannot exist independently of the whole, represented by a solid diamond symbol at the whole end of the association line.

CRC Card
A Class-Responsibility-Collaboration card used to record a class's name, responsibilities (knowing and doing), collaborators, attributes, and relationships.
Multiplicity
Notations placed on association lines in class diagrams that specify the minimum and maximum number of class instances that can relate to a single instance of another class.
