Foundations of Software Engineering

Introduction

Software is no longer a specialised tool used only by technical organisations. It controls financial transactions, medical devices, transportation systems, communication networks, education platforms, public services, and nearly every modern business process. Because software is deeply embedded in social and economic activity, developing it is not merely a matter of writing instructions for a computer. It requires the disciplined application of engineering knowledge to discover needs, manage uncertainty, construct dependable systems, and sustain them over time.

Software engineering is the systematic, disciplined, and measurable approach to the development, operation, maintenance, and retirement of software. The discipline combines computing knowledge with requirements analysis, design, project management, quality assurance, human factors, security, ethics, and organisational decision-making.

This chapter establishes the conceptual foundation for later study. It explains what makes software different from physical products, why the software crisis emerged, how engineers think about systems and complexity, who software stakeholders are, how products evolve through life cycles, and why technical debt must be managed deliberately. It also distinguishes programming from software engineering: programming is essential, but software engineering addresses a much larger socio-technical problem.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the distinctive characteristics of software as an engineered product.
2. Describe the origins and continuing relevance of the software crisis.
3. Use fundamental software engineering terminology accurately.
4. Apply systems thinking and abstraction to software problems.
5. Analyse sources of software complexity and explain their consequences.
6. Identify stakeholders and distinguish their different interests.
7. Compare common software product life-cycle approaches.
8. Explain technical debt, its causes, benefits, and risks.
9. Distinguish programming from software engineering.
10. Relate foundational principles to professional practice and employability.

1. What Is Software?

Software consists of programs, data, configuration, documentation, and related artefacts that enable a computing system to perform useful functions. A program is an ordered set of instructions, but a software product normally includes much more than source code. It may include application programming interfaces, database schemas, deployment scripts, user manuals, test specifications, monitoring rules, and legal or operational documentation.

A useful distinction is between a software product and a software service. A product is an artefact delivered for use, whereas a service includes the continuing operation, support, hosting, updating, and monitoring of that product. Contemporary cloud applications blur this distinction: users consume a service while engineers continuously change the underlying software.

1.1 Distinctive Characteristics of Software

Software has characteristics that make its engineering different from the engineering of bridges, machines, or buildings.

Software is intangible. Its behaviour cannot be inspected directly in the same way as a physical component. Diagrams, code, tests, and operational observations provide indirect evidence of its structure and quality.

Software is developed, not manufactured. Once a software system has been created, the cost of producing another identical copy is usually very small. Most expenditure occurs in analysis, design, implementation, testing, deployment, and maintenance rather than in copying the product.

Software does not wear out physically. A program does not become mechanically weaker through use. However, it may become less suitable as its environment changes, defects are discovered, requirements evolve, dependencies become obsolete, or modifications make its structure harder to understand. This is sometimes called software deterioration, although it is caused by change and maintenance rather than physical fatigue.

Software is highly changeable. Stakeholders can often request changes after development has begun. This flexibility is valuable, but it also creates risk. A local change may affect interfaces, data, security assumptions, performance, tests, documentation, and other systems.

Software is often invisible and complex. The important relationships in software are logical rather than spatial. A small source file may depend on thousands of other components, external services, policies, and data assumptions.

Software is frequently unique. Organisations often build systems for particular processes, regulations, customers, or combinations of technologies. Reuse is possible and desirable, but exact duplication of context is uncommon.

1.2 Software Quality as a Multi-Dimensional Idea

Quality is not a single property. A system can be functionally correct but difficult to maintain, secure but unusable, or attractive but unreliable. Common quality attributes include:

• Functional suitability: whether the system provides required functions.
• Reliability: whether it performs consistently under specified conditions.
• Usability: how effectively and satisfactorily users can interact with it.
• Performance efficiency: how well it uses time, memory, network, and other resources.
• Security: protection of confidentiality, integrity, availability, authenticity, and accountability.
• Maintainability: how easily the system can be analysed, modified, and tested.
• Portability: how readily it can operate in different environments.
• Accessibility: whether people with diverse abilities can use it.
• Safety: whether it avoids unacceptable harm in its operating context.

These attributes can conflict. Strong encryption may introduce performance overhead; extensive logging may increase storage costs; a highly flexible design may be more difficult for novice users. Engineering therefore involves explicit trade-offs rather than the pursuit of an abstract, perfect system.

2. The Software Crisis

The expression software crisis became prominent during discussions in the late 1960s about the difficulty of producing large software systems. Projects were frequently late, over budget, unreliable, difficult to maintain, or unable to satisfy their actual users. The problem was not that programmers lacked intelligence or effort. Rather, the size and complexity of systems had grown faster than the methods used to develop them.

Typical symptoms included:

• estimates that were consistently optimistic;
• requirements that were incomplete or changed without control;
• systems that passed limited demonstrations but failed in real operation;
• poor visibility of progress and quality;
• duplicated or inconsistent data;
• high defect rates;
• dependence on a few individuals who understood critical code;
• maintenance costs that exceeded development costs;
• projects cancelled after substantial expenditure.

The crisis was not a single historical event that ended when a particular methodology appeared. It describes a recurring class of challenges. Modern systems are larger, more distributed, more interconnected, and more socially consequential than earlier systems. Consequently, the underlying concerns remain relevant.

2.1 Causes of Software Project Failure

Failure is usually multi-causal. Technical causes may include inadequate architecture, uncontrolled dependencies, weak testing, insecure design, and poor configuration management. Organisational causes may include unrealistic schedules, unclear authority, weak communication, and conflicting incentives. Human causes may include misunderstanding, cognitive overload, inadequate training, and exclusion of important users. Environmental causes may include changing regulations, market disruption, or dependence on unavailable suppliers.

A narrow explanation such as “the developers made mistakes” is therefore inadequate. Software engineering treats the development environment as a socio-technical system in which tools, people, processes, incentives, and technology interact.

2.2 Responses to the Crisis

The discipline developed practices intended to improve control and learning, including:

• structured requirements engineering;
• modular design and information hiding;
• version and configuration management;
• formal and informal reviews;
• systematic testing;
• risk management;
• incremental delivery;
• automated builds and deployment;
• measurement and monitoring;
• professional codes of conduct.

No practice eliminates uncertainty. The purpose of engineering is to make uncertainty visible, reduce avoidable risk, and support informed decisions.

3. Essential Engineering Terminology

Terminology provides a shared language for teams. The following distinctions are particularly important.

Verification and validation are often summarised as “building the product right” and “building the right product.” The distinction is useful, although real practices overlap. Automated tests may verify a specified behaviour, while user research and acceptance evaluation help validate whether that behaviour solves a genuine problem.

4. Systems Thinking

A system is a set of interacting elements organised to achieve one or more purposes. In software engineering, the elements may include code, databases, devices, networks, people, organisations, procedures, laws, and external services. Systems thinking requires engineers to examine relationships and feedback rather than viewing a component in isolation.

4.1 Boundaries and Context

Every system model has a boundary. The boundary identifies what is inside the system of interest and what is treated as part of its environment. Boundaries are analytical choices, not natural facts. For example, an online payment system may include a web application and database in one analysis, but a broader safety or compliance analysis may also include banks, customers, fraud analysts, regulators, and telecommunications providers.

A boundary that is too narrow can hide important dependencies. A boundary that is too broad can make analysis unmanageable. Engineers should state the purpose of the model and choose a boundary appropriate to the decision being made.

4.2 Feedback and Emergent Behaviour

System behaviour can emerge from interactions among components. A single service may appear reliable, yet failures can occur when retries from many services overload a shared database. A user-interface change may alter user behaviour, which changes data patterns, which then affects performance. Such feedback means that system properties cannot always be inferred by adding the properties of individual components.

Systems thinking encourages questions such as:

• What assumptions does this component make about other components?
• What happens when an external service is slow or unavailable?
• Which users or groups may be affected indirectly?
• What feedback loops could amplify a small change?
• Which properties belong to the whole system rather than one module?

4.3 The Socio-Technical Perspective

Software operates within organisations and communities. A technically elegant system can fail if it conflicts with work practices, incentives, accessibility needs, or legal obligations. For example, an employee-monitoring system may be accurate but unacceptable if it violates privacy expectations or encourages harmful behaviour. Engineering decisions must therefore consider social consequences, not only computational efficiency.

5. Abstraction and Decomposition

Abstraction is the deliberate suppression of detail so that a problem can be considered at an appropriate level. A software engineer may view an online store as a business capability, as a set of services, as classes and interfaces, or as machine instructions. Each view is useful for a different question.

Abstraction is not simply ignoring detail. It involves selecting relevant detail and defining a clear model. A good abstraction exposes essential behaviour while hiding unnecessary implementation decisions.

Encapsulation groups data and operations and restricts direct access to internal representation. Information hiding conceals design decisions likely to change. Interfaces define how components interact without requiring consumers to know their internal implementation.

Decomposition divides a large problem into parts that can be understood, developed, tested, and changed with limited impact on other parts. Effective decomposition aims for high cohesion within components and low coupling between them.

• Cohesion measures how strongly the responsibilities of a module belong together.
• Coupling describes the degree of dependence between modules.

High cohesion and low coupling are useful design goals, but they are not absolute laws. Excessive decomposition can create communication overhead, distributed failure modes, and operational complexity.

6. Understanding Complexity

Complexity is not merely the number of lines of code. It includes the number of concepts, states, dependencies, interactions, exceptions, constraints, and possible changes that engineers must understand.

6.1 Essential and Accidental Complexity

Essential complexity arises from the problem itself. A tax system must represent complicated legal rules; a hospital system must manage patients, clinicians, privacy, emergencies, and clinical workflows. Better tools cannot remove all such complexity.

Accidental complexity is introduced by the chosen technology, design, process, or implementation. Examples include duplicated logic, unclear interfaces, unnecessary configuration, inconsistent naming, and obsolete dependencies. Good engineering reduces accidental complexity so that attention can be directed toward the essential problem.

6.2 Sources of Complexity

Important sources include:

• changing and conflicting requirements;
• concurrency and distributed communication;
• state management;
• legacy integration;
• security and privacy constraints;
• multiple platforms and versions;
• data quality and migration;
• regulatory obligations;
• performance and availability requirements;
• diverse users and accessibility needs.

Complexity creates risk because it increases the number of relationships that may be misunderstood. It also increases the cost of change and the effort required for testing and verification.

6.3 Managing Complexity

Engineers manage complexity through clear boundaries, simple designs, domain modelling, consistent conventions, automated tests, documentation of important decisions, observability, and incremental delivery. The aim is not to make every system simple; it is to make complexity explicit, localised, and manageable.

A useful professional question is: “What is the simplest design that satisfies the current requirements while preserving reasonable options for future change?” This avoids both under-engineering and speculative over-engineering.

7. Stakeholders and Requirements

A stakeholder is an individual, group, organisation, or institution that can affect, be affected by, or perceive itself to be affected by a system. Stakeholders may include customers, direct users, administrators, developers, operations staff, managers, owners, suppliers, regulators, auditors, citizens, and people indirectly affected by automated decisions.

Stakeholders do not necessarily agree. A customer may prioritise speed, a security officer may prioritise controls, a finance manager may prioritise cost, and a regulator may prioritise evidence and accountability. Requirements engineering must therefore discover, analyse, negotiate, document, validate, and manage competing needs.

7.1 Functional and Non-Functional Requirements

A functional requirement describes a service or behaviour, such as “the system shall allow a customer to reset a password.” A non-functional requirement describes a quality, constraint, or condition, such as response time, availability, accessibility, auditability, or legal compliance.

Non-functional requirements should be made testable where possible. “The system must be fast” is weak because it lacks a measurable context. “For 95% of requests under the stated workload, the search response shall be returned within 2 seconds” is more useful because it identifies a measure, population, and condition. The precise threshold must come from the actual business and technical context rather than being invented arbitrarily.

7.2 Ethical Stakeholder Analysis

Stakeholder analysis must include people who have limited power. A system may affect children, people with disabilities, low-income users, workers, or communities that are not represented in procurement decisions. Ethical engineering asks who benefits, who bears risks, whose data is collected, and what mechanisms exist for correction or appeal.

8. Software Product Life Cycles

A software life cycle describes the activities through which a system is conceived, developed, released, operated, changed, and retired. It is not necessarily a single rigid sequence. Common activities include feasibility analysis, requirements, architecture, implementation, integration, verification, validation, deployment, operation, maintenance, and retirement.

8.1 Plan-Driven Development

In a plan-driven approach, substantial requirements and design are established before implementation. This can be appropriate when requirements are stable, contractual evidence is important, or safety and regulatory controls demand extensive traceability. Its risk is that assumptions may remain untested until late in the project.

8.2 Iterative and Incremental Development

Iterative development revisits understanding and design through repeated cycles. Incremental development delivers usable subsets of capability over time. Feedback from each increment can reveal misunderstood requirements and technical risks earlier than a single final delivery.

8.3 Agile Approaches

Agile approaches emphasise frequent delivery, collaboration with stakeholders, adaptation to change, and working software as evidence of progress. Agile is not an excuse to avoid architecture, documentation, testing, governance, or professional discipline. Effective agility requires technical practices such as automated testing, continuous integration, code review, backlog refinement, and clear product ownership.

8.4 DevOps and Continuous Delivery

DevOps extends collaboration across development and operations. Continuous integration frequently integrates and tests changes; continuous delivery keeps software in a releasable state; continuous deployment automatically releases changes when appropriate controls are satisfied. These practices require reliable automation, monitoring, rollback strategies, security controls, and organisational trust.

8.5 Choosing a Life-Cycle Approach

No life cycle is universally superior. Selection should consider requirement volatility, risk, regulatory demands, team capability, system criticality, deployment constraints, customer access, and the cost of feedback. Hybrid approaches are common: a project may use formal approval gates for safety-critical components and iterative delivery for user-facing features.

9. Technical Debt

Technical debt is the future cost created when a present technical choice makes later change, operation, or understanding more difficult. The metaphor is useful because some shortcuts are deliberate investments: a team may accept temporary duplication to learn quickly or meet an urgent deadline. However, debt creates an obligation that must be repaid through refactoring, documentation, migration, testing, or redesign.

Technical debt may arise from:

• rushed implementation;
• obsolete libraries or platforms;
• missing automated tests;
• duplicated or tangled code;
• undocumented decisions;
• architectural limitations;
• manual deployment procedures;
• data-quality problems;
• deferred security improvements.

Not all debt is visible in source code. A fragile release process, inadequate monitoring, or unclear ownership can also create operational debt.

9.1 Managing Debt

Debt should be recorded, prioritised, and discussed in terms of risk and business impact. Useful questions include:

1. What problem does the debt create?
2. Which users, services, or teams are affected?
3. How likely is failure or delay?
4. What is the cost of repayment?
5. What is the cost of leaving it in place?
6. Can the debt be reduced as part of planned feature work?

A simplistic rule that all debt must be eliminated immediately is impractical. A better policy is intentional debt: make it visible, assign ownership, define a review point, and prevent it from accumulating beyond the organisation’s ability to control it.

10. Programming and Software Engineering

Programming is the activity of expressing algorithms and data structures in a programming language and making them execute correctly. It is a central software engineering skill, but software engineering encompasses a wider set of responsibilities.

A programmer may successfully implement a sorting function without considering deployment, data protection, accessibility, monitoring, or long-term maintenance. A software engineer must consider whether the function belongs in the system, how it will be tested, how it interacts with other components, what happens when inputs are invalid, and how future engineers will modify it.

The distinction is not hierarchical or dismissive. Skilled programming is necessary for engineering, and engineering judgement is strengthened by practical coding. The difference lies in scope, responsibility, and the time horizon of decisions.

11. Applied Case: An Illustrative University Assessment Platform

Background

Consider a fictional university developing an online assessment platform. The platform allows students to submit assignments, enables instructors to grade them, and provides administrators with reports. It integrates with identity management, the learning-management system, and a notification service.

Problem

The initial team builds a prototype quickly. It works for a small demonstration, but during the first major submission deadline students experience slow responses and duplicate uploads. Instructors cannot reliably see the latest submission, and administrators have limited evidence about access and changes. The team has also copied authentication logic into several modules.

Analysis

The immediate symptoms are performance, data consistency, and usability failures. The underlying issues are broader:

• requirements were collected mainly from administrators, not students and instructors;
• concurrency during deadlines was not modelled;
• the system lacked a clear definition of the submission record and its states;
• authentication responsibilities were duplicated;
• testing used small, unrealistic workloads;
• auditability and accessibility were treated as late additions;
• delivery pressure created technical debt.

Systems thinking reveals that the platform is not merely a web page and database. It is a socio-technical system involving academic rules, student anxiety, staff workflows, identity services, storage, notification, privacy, and institutional policy.

Approach and Solution

The team begins stakeholder workshops and maps the submission process. It defines explicit states such as draft, submitted, withdrawn, and superseded, with rules for transitions. A central identity service replaces duplicated authentication logic. The architecture separates submission handling, file storage, grading, and notifications through documented interfaces.

The team adds automated tests for state transitions, accessibility checks for user interfaces, load tests representing deadline conditions, and audit records for significant actions. Deployment is staged so that a small group of courses can validate the revised workflow before broader use. Known debt is recorded, including a planned migration away from an obsolete storage interface.

Outcome

The revised system makes submission status visible, prevents ambiguous duplicate records, and provides staff with audit information. Performance under realistic workload improves because file processing is separated from immediate user interaction. The platform is not “finished” in an absolute sense; monitoring and feedback identify further improvements. However, the team now has a maintainable foundation and a controlled process for change.

Learning Points

1. A prototype that works for one user is not evidence that a system works under real conditions.
2. Requirements include quality attributes and operational constraints, not only visible features.
3. Explicit domain models reduce ambiguity.
4. Stakeholder participation exposes problems that code inspection cannot reveal.
5. Technical debt is easier to manage when it is visible and assigned.
6. Engineering quality includes accessibility, security, auditability, and maintainability.

12. Professional, Ethical, and Contemporary Considerations

Software engineers have responsibilities to users, employers, clients, colleagues, and society. They should communicate risks honestly, protect confidential information, avoid discriminatory designs, respect intellectual property, and refuse to conceal serious safety or security concerns. Professional codes of ethics commonly emphasise public welfare, competence, honesty, privacy, and accountability.

Security should be considered throughout the life cycle rather than added after implementation. Privacy principles such as data minimisation, purpose limitation, transparency, and controlled access are relevant wherever personal data is processed. Accessibility should be addressed during requirements and design, not treated solely as a final compliance test.

Artificial intelligence tools can assist with code generation, testing, documentation, and analysis, but they do not remove engineering responsibility. Generated code may contain defects, insecure patterns, licensing problems, hidden assumptions, or inaccurate explanations. Engineers must review, test, attribute, and govern such outputs. AI systems also raise questions about bias, data provenance, privacy, explainability, and human oversight.

Contemporary software engineering increasingly involves cloud infrastructure, open-source dependencies, platform engineering, observability, secure development, and continuous delivery. These developments make foundational ideas more important, not less: systems have more dependencies, stakeholders have greater expectations, and failures can propagate rapidly.

Best-Practice Principles

The following principles provide a practical foundation:

• Understand the problem before optimising the implementation.
• Make assumptions explicit and test important assumptions early.
• Treat quality attributes as requirements.
• Prefer clear boundaries and stable interfaces.
• Automate repeatable checks, builds, and deployments.
• Review code and design decisions collaboratively.
• Design for failure, recovery, monitoring, and change.
• Keep technical debt visible and intentional.
• Involve representative and less powerful stakeholders.
• Protect security, privacy, safety, and accessibility throughout the life cycle.
• Use evidence rather than optimism to assess progress.
• Document decisions that future maintainers will need to understand.

Chapter Summary

Software engineering is a disciplined approach to developing, operating, maintaining, and retiring software systems. Software is intangible, highly changeable, logically complex, and embedded in social and organisational contexts. Its quality includes functionality, reliability, usability, performance, security, maintainability, accessibility, portability, and safety.

The software crisis describes recurring difficulties in delivering large, dependable systems within time and resource constraints. Its causes are technical, organisational, human, and environmental. Software engineering responds through requirements practices, architecture, modularity, testing, configuration management, risk management, incremental delivery, automation, and professional judgement.

Systems thinking examines software together with users, organisations, infrastructure, external services, regulations, and feedback relationships. Abstraction, encapsulation, information hiding, and decomposition help engineers manage complexity. Stakeholder analysis and requirements engineering reveal competing needs and make quality expectations explicit.

Life-cycle approaches range from plan-driven to iterative, agile, and DevOps-oriented models. The appropriate approach depends on uncertainty, risk, regulation, system criticality, and the cost of feedback. Technical debt represents future cost created by present shortcuts or constraints; it should be made visible, prioritised, and deliberately managed.

Programming is essential but narrower than software engineering. Programming implements computational behaviour, while software engineering addresses the complete system, its stakeholders, quality attributes, risks, operation, maintenance, governance, and long-term evolution.

Key Terms

Software: Programs, data, configuration, documentation, and related artefacts that enable computing functions.

Software engineering: A systematic, disciplined, and measurable approach to software development and maintenance.

Software crisis: Recurring difficulty in delivering large software systems that are reliable, affordable, timely, and fit for purpose.

Quality attribute: A non-functional property such as security, usability, reliability, or maintainability.

Requirement: A needed capability, condition, or constraint.

Verification: Checking whether a work product conforms to specified conditions.

Validation: Checking whether a system satisfies actual needs and intended use.

Architecture: Significant system structures, relationships, and guiding design principles.

Abstraction: Selective representation that suppresses unnecessary detail.

Encapsulation: Grouping data and operations while controlling access to internal representation.

Cohesion: The degree to which responsibilities within a module belong together.

Coupling: The degree of dependence between modules or components.

Systems thinking: Analysis of components, relationships, context, feedback, and emergent behaviour.

Stakeholder: A person, group, or organisation that affects or is affected by a system.

Life cycle: Activities through which software is conceived, developed, operated, changed, and retired.

Technical debt: Future cost or constraint created by a present technical decision.

Maintenance: Post-delivery modification to correct, adapt, or improve software.

DevOps: Collaborative practices integrating development, operations, automation, and feedback.

Review Questions

Short Answer Questions

1. Why is software described as developed rather than manufactured?
2. Distinguish verification from validation.
3. What is the difference between essential and accidental complexity?
4. Define technical debt and give two examples.
5. Why is programming only one part of software engineering?

Long Answer Questions

1. Explain the main characteristics of software and analyse how they influence engineering practice.
2. Discuss the causes of the software crisis and evaluate the practices introduced to address it.
3. Explain how systems thinking, abstraction, and decomposition help engineers manage complex software systems.
4. Compare plan-driven, iterative, agile, and DevOps-oriented life-cycle approaches.
5. Discuss software quality as a multi-dimensional concept, including trade-offs among quality attributes.

Analytical / Application Questions

1. A team delivers a feature on schedule by omitting automated tests and deployment documentation. Analyse the decision using the concept of technical debt and propose a management plan.
2. Design a stakeholder analysis for a university attendance-monitoring system. Identify at least six stakeholders, their interests, and one possible conflict between them.
3. A distributed shopping application works correctly in development but fails during a major sale. Use systems thinking to identify possible interactions, feedback effects, and engineering practices that could reduce the risk.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes software from many physical products?

A. Software cannot be changed after delivery.

B. Software is developed rather than physically manufactured in copies.

C. Software always has lower maintenance costs than hardware.

D. Software quality depends only on source-code length.

Correct Answer: B. Software is developed rather than physically manufactured in copies.

Question 2

Which activity is primarily concerned with determining whether a system satisfies actual user needs?

A. Validation

B. Compilation

C. Configuration management

D. Syntax checking

Correct Answer: A. Validation

Question 3

What is essential complexity?

A. Complexity caused only by poor naming

B. Complexity that arises from the problem domain itself

C. Complexity caused by a programming-language compiler

D. Complexity that disappears when more developers are added

Correct Answer: B. Complexity that arises from the problem domain itself

Question 4

Which design goal generally promotes maintainability?

A. High coupling and low cohesion

B. Low coupling and high cohesion

C. Duplicated business rules in every module

D. Direct access to all internal data

Correct Answer: B. Low coupling and high cohesion

Question 5

Who is a stakeholder?

A. Only the person who writes the source code

B. Only the organisation that pays for development

C. Any person or group that can affect or be affected by the system

D. Only users who log in daily

Correct Answer: C. Any person or group that can affect or be affected by the system

Question 6

Which life-cycle approach is particularly suited to frequent feedback and changing requirements?

A. Iterative and incremental development

B. A process with no testing

C. Permanent suspension of requirements analysis

D. Manufacturing-based replication

Correct Answer: A. Iterative and incremental development

Question 7

Which example best represents technical debt?

A. A documented design decision that has no future consequence

B. A temporary shortcut that increases the future cost of change

C. A successful automated test

D. A user requirement stated clearly

Correct Answer: B. A temporary shortcut that increases the future cost of change

Question 8

Which statement best describes systems thinking?

A. It examines only individual functions in isolation.

B. It focuses on relationships, context, feedback, and emergent behaviour.

C. It replaces all requirements with source code.

D. It assumes external services cannot affect a system.

Correct Answer: B. It focuses on relationships, context, feedback, and emergent behaviour.

Question 9

A functional requirement primarily describes:

A. A service or behaviour the system must provide

B. The colour of a developer’s editor

C. The personal preference of one programmer

D. The age of the hardware used by the team

Correct Answer: A. A service or behaviour the system must provide

Question 10

Which statement most accurately distinguishes programming from software engineering?

A. Programming is unnecessary in software engineering.

B. Software engineering concerns only project budgets.

C. Programming implements computational behaviour, while software engineering addresses the broader system life cycle and risks.

D. Programming and software engineering are unrelated disciplines.

Correct Answer: C. Programming implements computational behaviour, while software engineering addresses the broader system life cycle and risks.