Software Engineering: Requirements, Architecture, and Quality Practice Flashcards

Comprehensive vocabulary cards covering software engineering principles, lifecycle stages, and technical patterns.

Requirements

A high-level definition of what exactly the software should do.

Specifications

A rough organizational outline of how a software system might be built.

Architecture

The precise system and code-level 'how' that follows requirements and specifications.

The "-ilities"

A set of desirable system attributes, often called non-functional requirements, that represent quality-related aspects affecting long-term success and maintainability.

Usability

An '-ility' describing how user-friendly and intuitive the software is.

Maintainability

The ease with which software can be modified to correct faults, improve performance, or adapt to a changing environment.

Scalability

The ability of the software to handle growing amounts of work in a graceful manner or its potential to be enlarged to accommodate growth.

Availability

The proportion of time the system is functional and working, often measured as a percentage.

Reliability

The ability of the software to perform its required functions under stated conditions for a specified period.

Portability

The ease with which software can be transferred from one environment to another.

Interoperability

The ability of the software to interact with other systems or components.

Security

The protection of software against unauthorized access or modifications.

Performance

How the system behaves under particular conditions in terms of speed, response time, and throughput.

Accessibility

The software's ability to be used by end users with different technical, physical, and mental abilities.

Modularity

The degree to which software is composed of discrete components such that a change to one has minimal impact on others.

ISO 25010 Software Quality Model

A framework that subsets software quality into eight broad categories: Functional Suitability, Performance Efficiency, Compatibility, Usability, Reliability, Security, Maintainability, and Portability.

System Model

The developer's mental model focused on data and features to organize code.

User Model

How the user thinks of a task or product, often more function-based and less feature-based than a system model.

Spolsky’s Cardinal Axiom

The design principle suggesting that developers focus on User Model > System Model.

SSoT (Single Source of Truth)

Maintaining a repository or project wiki as the one definitive place for design and requirements to prevent data loss.

Bus Factor

A measurement of risk based on how much crucial software knowledge is shared among team members versus isolated in a few individuals' heads.

Architectural Decision Record (ADR)

A document used to capture important decisions and the reasoning behind them for future developers.

Tech Debt

The accumulated cost of fixing short-term, rushed decisions that slow down the velocity of making changes over time.

Tech Investment

Spending time and resources on research, education, or code cleaning to provide a long-term payoff.

Lambo Problem

Worrying about problems related to extreme success, such as massive scale, before the current practical problem is solved.

YAGNI

You Ain't Gonna Need It: keeping feature load and abstraction low because many anticipated needs never materialize.

KISS

Keep It Super Simple (or Keep It Simple Stupid): a focus on limiting complexity for improved robustness.

DRY

Don’t Repeat Yourself: avoiding duplication to ensure updates only need to be made in one place.

Abstraction

Hiding implementation details and showing only what is necessary to use a component, supporting 'black box' thinking.

Dependency Injection (DI)

A pattern where a component receives its dependencies from an external source rather than creating them itself.

Inversion of Control (IoC)

A design principle where the flow of a program is flipped so that a higher-level framework calls the developer's code.

Cohesion

How related and focused the elements within a module, class, or function are toward a single purpose.

Coupling

The degree of relation or dependence between components; loose coupling is generally preferred for ease of reasoning.

Negative Security Model

A strategy using a 'blacklist' of known attack styles while allowing everything else.

Positive Security Model

A strategy using a 'whitelist' of explicitly allowed actions and denying everything else by default.

DSL (Domain Specific Language)

A special file format or language defined and understood for a particular domain, such as CSS or configuration files.

Client-Server Model

A web pattern involving a client for presentation/interaction and a server for data/servicing requests.

The Localhost Effect

A developer bias where software appears more robust and faster than it actually is because network adverse conditions are invisible during local development.

CRUD

Create, Read, Update, Delete: the four basic actions performed on data resources.

REST

REpresentational State Transfer: a method of defining resources as URLs (nouns) and actions as HTTP methods (verbs).

MVC

Model-View-Controller: a pattern separating concerns into Data (Model), UI (View), and Logic/Input (Controller).

SPA (Single Page App)

A JavaScript-first application suited for long sessions where content updates within a single document.

CI (Continuous Integration)

Constantly integrating and testing software into a workable build using automated pipelines.

CD (Continuous Delivery)

The ability to get an automatically produced build into production use quickly.

Feature Toggle / Feature Flag

Introducing new functionality hidden behind a conditional statement to show it to select users for testing.

Silly Law of Bugs

$E = MC^2$: Errors = More Code Squared, representing how increased code and complexity lead to more bugs.

TETO / ABT

Test Early Test Often / Always Be Testing.

Testing Pyramid

A strategy where a foundation of small, fast unit tests supports fewer integrated tests and even fewer UI level tests at the top.

TDD (Test Driven Development)

A process involving three phases: Red (write failing test), Green (write code to pass), and Refactor (clean the code while keeping it green).

BDD (Behavior Driven Development)

An extension of TDD that ties tests specifically to user stories and behaviors.

DevOps

A cultural movement aimed at joining software creation and operations to break down organizational silos.

Five Nines

$99.999\%$ availability, which allows only $5.26$ minutes of downtime per year.

RUM (Real User Monitoring)

Monitoring software performance and errors experienced by actual users under real-world conditions.

Synthetic Monitoring

Simulated traffic or scripted scenario checks to verify availability and functionality.

Common Code Smells

Indicators of potential problems in code, such as magic numbers, poor commenting, breaking abstractions, and poor naming.

CI/CD

Continuous Integration/Continuous Delivery: practices that automate the build and testing processes, critical in Agile development.

The -ilities

A set of desirable system attributes, including usability, maintainability, scalability, availability, reliability, portability, interoperability, security, performance, and accessibility, which drive engineering and architectural decisions.

Cohesion

How related and focused the elements within a module, class, or function are toward a single purpose.

Coupling

The degree of relation or dependence between components; loose coupling is generally preferred for ease of reasoning.

Single Responsibility Principle (SRP)

A design principle that states that a module or class should have only one reason to change, meaning it should have only one job or responsibility.

Separation of Concerns

A design principle for separating a computer program into distinct sections, such that each section addresses a separate concern.

DRY (Don't Repeat Yourself)

A principle aimed at reducing the repetition of code patterns, ensuring updates only need to be made in one place.

Encapsulation

A principle in object-oriented programming that restricts direct access to some of an object's components, which can help in reducing complexity.

Abstraction

Hiding implementation details and showing only what is necessary to use a component, supporting 'black box' thinking.

Dependency Injection

A design pattern where a component receives its dependencies from an external source rather than creating them itself.

Minimalism

A philosophy in software design that aims to reduce complexity by focusing on what is essential.

Client-Server Model

A web pattern involving a client for presentation/interaction and a server for data/servicing requests.

Layered Models

Architectural patterns where components are organized in layers, allowing for separation of concerns and enhancing modularity.

Graceful Degradation

The ability of a system to continue operating in reduced functionality when part of the system fails.

Progressive Enhancement

A strategy for web development that emphasizes the baseline functionality for all devices, enhancing features for capable devices.

CRUD

Create, Read, Update, Delete: the four basic actions performed on data resources.

REST

REpresentational State Transfer: a method of defining resources as URLs (nouns) and actions as HTTP methods (verbs).

MVC

Model-View-Controller: a pattern separating concerns into Data (Model), UI (View), and Logic/Input (Controller).

SPA (Single Page App)

A JavaScript-first application suited for long sessions where content updates within a single document.

CI (Continuous Integration)

Constantly integrating and testing software into a workable build using automated pipelines.

CD (Continuous Delivery)

The ability to get an automatically produced build into production use quickly.

Feature Toggle / Feature Flag

Introducing new functionality hidden behind a conditional statement to show it to select users for testing.

Silly Law of Bugs

$E = MC^2$: Errors = More Code Squared, representing how increased code and complexity lead to more bugs.

TETO / ABT

Test Early Test Often / Always Be Testing.

Testing Pyramid

A strategy where a foundation of small, fast unit tests supports fewer integrated tests and even fewer high-level UI tests.

TDD (Test Driven Development)

A software development process involving three phases: Red (write failing test), Green (write code to pass), and Refactor (clean code).

BDD (Behavior Driven Development)

An extension of TDD that ties tests specifically to user stories and user behaviors.

Software Life Cycle

The process of software development from inception to retirement, considering how choices affect software health over time.

Documentation Forms

Various methods to maintain code and design clarity, including ADRs (Architectural Decision Records) and JSDoc comments.

Generative AI Impact

The influence of AI technologies on software engineering, affecting aspects such as tech debt, complexity preservation, and process efficiency.