Software Engineering (CSC291) - Complete Notes

Vocabulary practice flashcards covering core software engineering topics: Process Models, Requirement Engineering, Use Case Diagrams, Class Diagrams, Activity Diagrams, Requirement Types, and Architecture Styles.

Process Model

A plan for how software will be built, determining the order in which development activities occur and when each part will be completed.

Sequential Model (Waterfall)

The oldest and simplest process model where work flows in one strict downward direction, requiring each phase to finish completely before the next begins.

Iterative Model

A process model where the full development cycle repeats over multiple rounds, with each round taking feedback to produce an improved version of the same system.

Incremental Model

A process model where a system is broken into separate parts (increments) that are fully built and delivered one by one, allowing users to use earlier parts while subsequent ones are built.

Agile Process Model

A family of process models built for changing requirements, utilizing short development cycles called sprints and continuous customer collaboration.

Sprint

A short, fixed work cycle in Agile development (typically lasting 2 weeks) that produces and delivers a small working piece of software.

Scrum

The most widely used Agile methodology, in which tasks are organized into a backlog, developed in short sprints, and reviewed in daily stand-up meetings (daily scrums).

Extreme Programming (XP)

An Agile methodology focused primarily on software and code quality through practices such as pair programming, test-first development, continuous integration, and refactoring.

Kanban

An Agile method focused on continuous improvement and workflow transparency by visualizing tasks across columns (such as To Do, Doing, and Done) on a board.

Spiral Model

A risk-driven process model structured in repeating loops, where every single loop begins with identifying and mitigating potential risks.

Prototype Model

A process model where an early, preliminary version of the system is built for users to view and interact with when requirements are initially unclear.

V-model

A structured variant of the Waterfall model that maps and plans a corresponding testing phase directly alongside each building phase.

Requirement Engineering

The disciplined process of identifying what users need, analyzing those needs, documenting them clearly, and managing changes before system construction begins.

Stakeholder

Any individual or group connected to a system who will use it, pay for it, or be affected by its deployment.

Requirement Elicitation

The initial phase of Requirement Engineering that focuses on gathering system requirements directly from stakeholders using various discovery techniques.

Requirement Analysis

The phase of Requirement Engineering where raw needs are evaluated to resolve conflicts, eliminate redundancies, address gaps, and prioritize features.

Software Requirements Specification (SRS)

The formal document containing all agreed, unambiguous, and testable requirements that serves as the baseline for designers, developers, and testers.

Observation (Elicitation)

An elicitation technique where the analyst quietly watches users perform their actual daily work to capture processes that users struggle to articulate verbally.

Use Case Diagram

A behavioral diagram that provides an external view of a system, illustrating the external actors and the specific actions or goals they can execute.

Actor

An external entity, drawn as a stick figure outside the system boundary, that interacts directly with the software system (can be a human or another software system).

Use Case

A specific user action or goal, drawn as an oval inside the system boundary and named using an active verb phrase.

<>

A mandatory relationship between use cases where the base use case always executes the behavior of the included use case every single time.

<>

An optional relationship between use cases where an extending use case inserts additional behavior into the base use case only if a particular condition is met.

Preconditions

The specific state or set of conditions that must be completely true before a use case is permitted to execute.

Alternative Flow

The documented branch of steps within a tabular use case that defines what happens when an error, exception, or non-standard condition occurs.

Class Diagram

A structural diagram that reveals the internal design of a system by showing its classes, their data attributes, their operations, and their relationships.

Class

A blueprint or template representing a collection of similar objects, partitioned into three compartments: name, attributes, and operations.

Multiplicity

Numerical values placed at the ends of an association line that define exactly how many objects of one class can link to objects of another class.

Aggregation

A weak has-a relationship depicted by a hollow diamond, where a class is assembled from parts that can continue to exist independently if the whole is deleted.

Composition

A strong has-a relationship depicted by a filled diamond, where constituent parts are owned by the whole and are automatically deleted if the whole is destroyed.

Dependency (UML)

A temporary relationship drawn as a dashed arrow showing that one class uses another class for a specific task, meaning changes in the used class can affect the caller.

Activity Diagram

A behavioral UML diagram functioning like a flowchart to depict the sequential flow of actions, decisions, and concurrent branches within a single process.

Decision Node

A diamond-shaped symbol in an activity diagram representing a branching question where every outgoing path must have a distinct condition label.

Fork (Activity Diagram)

A thick horizontal or vertical bar that splits a single incoming activity flow into two or more parallel streams running concurrently.

Join (Activity Diagram)

A thick horizontal or vertical bar where multiple concurrent flows must all complete before allowing the process to merge and continue into a single path.

Swimlanes

Vertical or horizontal columns in an activity diagram that explicitly partition tasks to show which actor or component is responsible for each action.

Functional Requirement (FR)

A requirement that details a specific service, behavior, computation, or output the system must actively execute, typically expressed using action verbs.

Non-Functional Requirement (NFR)

A requirement that specifies an overall quality attribute or operational constraint (such as speed, security, or reliability) describing how well a system performs.

Domain Requirement

A requirement derived directly from the fundamental rules, legal statutes, or operational characteristics of the field (domain) to which the system belongs.

Architecture Style

A proven, high-level pattern that determines the overall organizational structure of a software system and dictates how its major subsystems coordinate.

Pipe and Filter Style

A data-flow architectural style where information travels through a linear sequence of processing units (filters) connected by channels (pipes).

Repository Style

A data-centered architectural style where independent subsystems coordinate exclusively by accessing, writing to, and reading from one shared central data store.

Layered Architecture

A hierarchical architectural style where components are separated into distinct stacked layers, with each layer strictly serving the layer above and consuming the one below.

Model-View-Controller (MVC)

An interactive architectural style that decouples core business logic and data (Model), the graphical display (View), and the user input handler (Controller).

Client-Server Style

A distributed architecture dividing work between clients (devices issuing requests) and a central server (providing services and managing shared data).