Software Engineering Fundamentals

1Introduction

This lecture explains how to manage software quality and changeability throughout the lifecycle from requirements to operation and maintenance.

Producing a computed result is only one aspect of software quality. A system must also be evaluated for conformance to user requirements, reliability under failure, security against attacks, and ease of change. Software engineering treats these concerns through systematic development and operational activities rather than as isolated implementation techniques.

2Requirements and Acceptance Criteria

A requirementRequirement is a capability that a system must provide or a constraint that it must satisfy.

• A functional requirementFunctional requirement specifies behavior or functionality that the system must provide.
• A non-functional requirementNon-functional requirement specifies quality or constraints such as performance, availability, security, and usability.

An ambiguous statement such as “the system must be fast” does not determine when implementation is complete. An acceptance criterionAcceptance criterion is an observable condition for deciding whether a requirement has been satisfied. For example, “when processing 1,000 concurrent requests, return 95 percent of responses within 200 ms” makes performance measurable.

3Design and Localization of Change

DesignDesign is the activity of defining a system's components, their responsibilities, and their relationships in order to realize requirements. Its purpose is not merely to divide code into files or classes. Responsibilities should be arranged so that one reason for change does not propagate through many components.

CohesionCohesion describes how closely the responsibilities within one component belong together. CouplingCoupling describes the strength of dependencies between components. In general, grouping related responsibilities with high cohesion and limiting coupling helps localize change. Excessive decomposition, however, increases the complexity of interfaces and communication.

An interfaceInterface is the boundary of operations and information that a component exposes. Stating input preconditions, output guarantees, and failure behavior limits the effect on clients when an internal implementation changes.

4Testing and Levels of Verification

TestingTest is the activity of configuring inputs and execution conditions and comparing observed results with expected results to detect defects. A successful test does not prove that no defect exists for unexecuted inputs or states. Test coverage must therefore be designed according to requirements and risk.

• A unit testUnit test verifies a small unit such as a function or module.
• An integration testIntegration test verifies interaction across boundaries such as modules, databases, or networks.
• A system test verifies the integrated system against system requirements.
• An acceptance testAcceptance test evaluates acceptance criteria from the perspective of a user or customer.

A change that damages existing behavior causes a regressionRegression. Running automated regression tests after each change continuously checks whether established behavior remains intact.

5Change Management, Operation, and Maintenance

Version controlVersion control records the history of source code, configuration, and documentation as identifiable versions. Continuous integrationContinuous integration is the practice of frequently integrating changes into a shared mainline and obtaining automated build and test feedback for each integration. It detects inconsistencies among changes early. Review is a complementary activity that examines the content of a change.

OperationOperation is the activity of keeping a deployed system available for use. It includes managing configuration, monitoring operational state, and responding to failures and security incidents. Monitoring results and incident records inform new requirements and maintenance priorities.

MaintenanceMaintenance is the activity of correcting software, adapting it to its environment, or improving its quality after deployment. It includes not only defect correction but also new requirements, dependency updates, performance improvement, and security strengthening.

Prioritizing a short-term deadline can leave design problems that increase the cost of future change. This future cost can be described as technical debtTechnical debt. Technical debt is a metaphor; it does not imply that every imperfection must be removed immediately. Teams evaluate impact and cost to prioritize repayment.

6Quality Attributes and Trade-offs

Quality comprises multiple attributes, including functional suitability, reliability, performance efficiency, usability, security, and maintainability. These attributes cannot all be maximized without limit. Redundancy, for example, can improve availability while making configuration and operation more complex. A design decision makes the relevant requirements, risks, and costs explicit and establishes an agreed trade-off.

7Example: A Database-Backed Course Registration System

In a course registration system, “a student can register for a course” is a functional requirement. “Do not permit registration beyond capacity” and “prevent duplicate registration” can be verified as acceptance criteria. The design separates the user interface, registration rules, and SQL-based persistence as distinct responsibilities.

Unit tests verify registration rules, integration tests verify transactions between the application and database, and acceptance tests verify the user's workflow. When a requirement change introduces a lottery, separated responsibilities and regression tests clarify the affected scope.

8Key Points

• Requirements and acceptance criteria provide a shared basis for implementation and testing.
• Design defines responsibilities and interfaces to localize the effects of change.
• Testing detects defects but does not generally prove their absence.
• Version control, review, and continuous integration track change and detect integration problems early.
• Trade-offs among quality attributes are decided according to requirements, risks, and costs.

9Next Lecture

Systems spanning multiple devices or sites also require mechanisms that transmit information as signals. The next portal addresses signals, noise, modulation, and other foundations of communication.