Systems Analysis and Design – Chapter 3: Requirements Determination (Vocabulary)

40 flashcards summarizing essential vocabulary from Chapter 3 on Requirements Determination in Systems Analysis and Design.

Analysis Phase

SDLC phase focused on fully understanding the new system’s requirements by studying the current (as-is) system, identifying improvements, and defining the future (to-be) concept.

As-Is System

The current way an organization’s processes and information systems operate before any changes are made.

To-Be System

The envisioned future system that incorporates improvements and fulfills identified requirements.

System Proposal

The final deliverable of the analysis phase; compiles the requirements definition, models, feasibility analysis, and work plan for approval.

Requirement

A statement of what the system must do or the qualities it must have (business, user, functional, nonfunctional, or system).

Business Requirements

High-level statements describing why the project is proposed and what business needs the system will satisfy.

User Requirements

Descriptions of tasks users must be able to perform with the system in order to accomplish their work.

Functional Requirements

Specific processes the system must perform or information it must provide to support user tasks.

Process-Oriented Functional Requirement

A requirement defining a process the system must execute (e.g., "The system must check orders for inventory availability").

Information-Oriented Functional Requirement

A requirement specifying information the system must store or produce (e.g., "The system must retain order history for 3 years").

Nonfunctional Requirements

Quality attributes and constraints such as operational environment, performance, security, and cultural or political factors.

Operational Requirement

A nonfunctional requirement describing the physical/technical environment in which the system will operate (e.g., device, browser compatibility).

Performance Requirement

A nonfunctional requirement specifying speed, capacity, or reliability targets (e.g., response time <2 seconds).

Security Requirement

A nonfunctional requirement that defines who may access the system and under what conditions, plus needed safeguards.

Cultural and Political Requirement

A nonfunctional requirement addressing legal, cultural, or corporate policy constraints (e.g., data privacy laws, vendor preferences).

Requirements Definition Statement

A numbered outline listing all functional and nonfunctional requirements; also defines project scope and priorities.

Requirements Determination

The process of transforming high-level business needs into a precise, detailed list of system requirements.

Requirements Elicitation

Activities used to discover and gather system requirements from stakeholders (interviews, JAD, questionnaires, etc.).

Interview (Elicitation Technique)

Face-to-face fact-finding method in which analysts question stakeholders to gather detailed information.

Closed-Ended Question

Interview question that seeks a specific, limited answer (e.g., numbers, yes/no).

Open-Ended Question

Interview question inviting a broad, exploratory response to gather opinions or explanations.

Probing Question

Follow-up question used to gain deeper insight into a previous answer (e.g., “Why?” “Can you give an example?”).

Top-Down Interview Strategy

Questioning approach that starts broadly and progressively drills down to detailed specifics; most common.

Bottom-Up Interview Strategy

Questioning approach that begins with detailed questions and works up to broad issues; useful for collecting specifics.

Joint Application Development (JAD)

Facilitated workshop where project team, users, and managers collaborate intensively to define system requirements.

Electronic JAD (e-JAD)

JAD conducted with groupware tools that allow anonymous input and overcome group dynamic issues.

Questionnaire

Written set of questions distributed to many respondents to collect facts and opinions uniformly and efficiently.

Document Analysis

Fact-finding technique that reviews existing documentation to learn about the as-is system’s processes and data.

Observation

Elicitation method involving watching people perform processes to understand actual workflows and identify issues.

Problem Analysis

Strategy where users list problems and possible solutions, usually yielding small, incremental improvements.

Root Cause Analysis

Technique that traces reported problems back to their underlying causes to discover the real issues to address.

Duration Analysis

Method that measures how long each step in a process takes to identify bottlenecks and efficiency gains.

Activity-Based Costing

Analysis that assigns costs to each process or step to pinpoint expensive activities in need of improvement.

Informal Benchmarking

Studying how other organizations perform a process to identify ways to improve one’s own practices.

Outcome Analysis

Brainstorming approach that focuses on the results customers desire and how information systems can enable them.

Technology Analysis

Examination of emerging or relevant technologies to identify innovative ways they can benefit the business.

Activity Elimination

Brainstorming technique that questions what would happen if each activity were removed, encouraging radical redesign.

Critical Thinking Skills

Analyst abilities to objectively evaluate information, identify true problem causes, and devise effective solutions.

Stakeholder

Any person who can affect or is affected by the system, including users, managers, and external parties.

Business Value

The expected benefit or worth that a new system brings to the organization, reviewed before moving to design.