SDLC Foundations and Systems Thinking

Introduction

Software is not merely a collection of program statements. It is a socio-technical product created, operated, maintained, and governed within an organisational and technological environment. A payroll application, for example, includes source code, databases, user interfaces, infrastructure, operating procedures, documentation, support arrangements, security controls, and the people who use and administer it.

The Software Development Life Cycle (SDLC) provides a structured way to plan, analyse, design, build, test, deploy, operate, and improve software systems. It does not prescribe one universal method. Instead, it provides a life-cycle perspective that can be implemented through approaches such as predictive, iterative, incremental, agile, DevOps, or hybrid development.

This chapter establishes the vocabulary and systems perspective needed for later study of requirements engineering, architecture, project management, testing, maintenance, and software quality.

Learning Objectives

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

1. Explain the purpose and principles of software engineering.
2. Describe systems thinking and apply it to software development.
3. Define major SDLC terms and distinguish life-cycle stages from development methodologies.
4. Identify typical SDLC deliverables and explain their value.
5. Classify stakeholders and analyse their interests and influence.
6. Explain project, product, process, and service relationships.
7. Discuss constraints, trade-offs, governance, ethics, and professional responsibilities.
8. Apply SDLC concepts to a realistic software-development case.

1. Software Engineering as a Discipline

Software engineering is the systematic, disciplined, and measurable application of engineering principles to the development, operation, maintenance, and retirement of software. The phrase “engineering” emphasises the controlled transformation of needs into dependable solutions, rather than simply writing code.

A software engineer must address at least four dimensions:

• Functionality: What should the system do?
• Quality: How well should it perform, remain secure, and respond to change?
• People: Who uses, manages, funds, supports, and is affected by it?
• Context: What legal, organisational, technical, and social environment surrounds it?

Important software-engineering principles include:

Abstraction

Abstraction focuses attention on essential characteristics while hiding unnecessary detail. A class interface, for example, may expose an operation without revealing its internal algorithm.

Modularity

A system is divided into understandable components with defined responsibilities and interfaces. Modularity can reduce complexity and make testing or replacement easier, although excessive decomposition can increase integration effort.

Separation of concerns

Different concerns—such as user interaction, business rules, persistence, security, and logging—should be distinguishable. This reduces the likelihood that a change in one concern will produce uncontrolled effects elsewhere.

Traceability

Traceability links needs to requirements, designs, source code, tests, releases, and operational evidence. It supports impact analysis, assurance, auditing, and defect investigation.

Verification and validation

Verification asks, “Are we building the product correctly?” Validation asks, “Are we building the correct product?” A system can conform to its documented requirements and still fail to solve the user’s real problem.

Continuous quality responsibility

Quality is not created only during a final testing phase. It is influenced by requirements clarity, architecture, coding practices, review, automation, deployment, operations, and feedback throughout the life cycle.

2. Systems Thinking

2.1 What is a system?

A system is a set of interacting elements organised to achieve one or more purposes. A software system normally includes technology, information, people, procedures, external services, and rules. Its boundaries define what is considered part of the system and what is treated as its environment.

Systems thinking examines relationships, interactions, feedback, dependencies, and emergent behaviour. It differs from a purely component-oriented view. Analysing a database table in isolation may reveal local correctness, but it will not show how a policy, user workflow, network delay, or third-party service affects the whole outcome.

A useful conceptual representation is:

Figure: A software system within a wider organisational and regulatory environment.

2.2 Boundaries, interfaces, and environment

A boundary specifies what the development team controls and what it must treat as an external dependency. Interfaces define how elements exchange information or services. For example, an online shop may control its catalogue and order database but depend on an external payment gateway and delivery provider.

Poorly defined boundaries create omissions. A team may design a technically correct application while ignoring identity management, data migration, customer support, or business continuity. Systems thinking therefore encourages questions such as:

• What inputs enter the system, and who provides them?
• What outputs are produced, and who relies on them?
• Which assumptions must remain true?
• What feedback indicates success or failure?
• What happens when an external dependency is unavailable?
• Which behaviours emerge when many users or components interact?

2.3 Feedback and emergence

Feedback is information about system performance or outcomes that influences future decisions. User complaints, monitoring data, defect reports, security alerts, and financial results can all provide feedback.

Emergent properties arise from interactions among components rather than from one component alone. Security, usability, resilience, and reliability are often emergent. A secure encryption library cannot guarantee system security if credentials are poorly managed. Similarly, fast individual services may still produce a slow user experience when network calls are excessive.

3. SDLC Terminology and Life-Cycle Stages

The life cycle is the complete existence of a software product or system, from initial concept through retirement. An SDLC model is an organised representation of activities and relationships used to manage that life cycle. A methodology is a more specific set of principles, practices, roles, rules, and techniques used by a team.

These terms should not be treated as synonyms. For example, requirements analysis and testing are life-cycle activities; Scrum is a framework for organising certain development work; and a project plan is a management artefact.

3.1 Initiation and feasibility

The life cycle often begins with an opportunity, problem, regulatory need, or strategic objective. Initiation clarifies the purpose, potential users, scope, expected value, and major risks.

A feasibility assessment may consider:

• Technical feasibility: Can the solution be built and integrated with available technology?
• Economic feasibility: Are expected benefits proportionate to costs and risks?
• Operational feasibility: Can the organisation adopt and operate the solution?
• Legal and regulatory feasibility: Can it comply with applicable obligations?
• Schedule feasibility: Can it be delivered when it is needed?

Feasibility is not a guarantee of success. It is a decision aid based on available evidence and assumptions.

3.2 Requirements analysis

Requirements describe capabilities, constraints, qualities, and conditions that the system must satisfy. Functional requirements specify behaviour, while non-functional requirements specify qualities or constraints such as performance, accessibility, privacy, maintainability, or availability.

Requirements work includes elicitation, analysis, prioritisation, specification, validation, and management of change. Ambiguous requirements create rework because different stakeholders interpret them differently.

3.3 Design and architecture

Architecture describes significant structures, components, relationships, interfaces, and principles governing the system. Detailed design refines these decisions into implementable solutions. Design must address data, interfaces, security, error handling, deployment, and quality attributes—not only screen appearance.

Architecture decisions are often difficult to reverse. Consequently, teams should record significant decisions, alternatives considered, assumptions, and consequences.

3.4 Implementation

Implementation transforms approved designs into executable software and associated configuration. Professional implementation includes source control, coding standards, code review, dependency management, automated checks, and documentation. “Finished coding” does not necessarily mean that a feature is complete; integration, testing, security review, documentation, and operational readiness may remain.

3.5 Verification and validation

Testing provides evidence about whether the system behaves acceptably. Common levels include unit, integration, system, and acceptance testing. Other forms include usability, performance, security, compatibility, recovery, and accessibility testing.

Testing cannot prove that software has no defects. It samples behaviour under selected conditions. Strong assurance combines testing with reviews, static analysis, monitoring, risk analysis, and user evaluation.

3.6 Deployment and transition

Deployment makes a system available in its target environment. Transition may involve data conversion, training, configuration, communication, support preparation, and changes to business procedures. Deployment strategies include direct cutover, phased release, pilot operation, parallel operation, and controlled feature release.

3.7 Operation and maintenance

Operation includes monitoring, support, incident handling, backup, security administration, and capacity management. Maintenance may be:

• Corrective: fixing discovered defects.
• Adaptive: modifying software for a changed environment.
• Perfective: improving performance, usability, or maintainability.
• Preventive: reducing the likelihood of future failures.

Maintenance commonly consumes substantial effort because software operates for years, requirements change, integrations evolve, and technical debt accumulates.

3.8 Retirement

Retirement is the controlled withdrawal of a system. It may require data archiving, migration, contract termination, user communication, removal of infrastructure, secure deletion, and retention of evidence required by law or policy. Retirement is a life-cycle responsibility, not an afterthought.

4. SDLC Models and Methodologies

Predictive approaches

In a predictive or plan-driven approach, major scope, schedule, and design decisions are made early and work proceeds through controlled stages. This can be appropriate where requirements are stable, regulation requires formal evidence, or physical dependencies make late change expensive. Its weakness is that users may not see useful working software until late, making misunderstood requirements costly.

Iterative and incremental approaches

An iterative approach revisits and improves understanding or solution elements. An incremental approach delivers the product in separate usable portions. The two ideas can be combined: each increment may be developed through repeated analysis, design, construction, and testing.

Agile approaches

Agile approaches favour early delivery of value, close stakeholder collaboration, adaptation to change, and frequent feedback. Agile does not mean lack of planning or documentation. It means that plans and documents are treated as useful instruments rather than substitutes for working outcomes and informed communication.

DevOps and continuous delivery

DevOps integrates development and operations through shared responsibility, automation, monitoring, and rapid feedback. Continuous integration frequently combines and verifies code changes. Continuous delivery keeps software in a releasable state; continuous deployment automatically releases suitable changes when organisational controls permit it.

Hybrid approaches

A hybrid life cycle may use formal approval and compliance gates while delivering software iteratively. The appropriate choice depends on uncertainty, risk, regulation, team capability, architecture, supplier relationships, and the cost of change. No methodology eliminates the need for judgement.

5. Deliverables and Evidence

A deliverable is a work product submitted or made available to fulfil an objective. Some deliverables are documents; others are executable software, test results, configurations, models, training materials, or operational records.

A deliverable has value only when it is accurate, usable, current enough for its purpose, and connected to decisions or evidence. Producing documents merely to satisfy a checklist can create administrative waste.

6. Stakeholders and Governance

A stakeholder is a person, group, organisation, or system that can affect, be affected by, or perceive itself to be affected by an initiative or product. Stakeholders may include customers, end users, sponsors, product owners, developers, testers, operations staff, suppliers, regulators, auditors, accessibility advocates, and members of the public.

Stakeholders differ in power, interest, knowledge, urgency, and risk exposure. A sponsor may control funding but use the system rarely. A frontline user may have little formal authority but possess essential operational knowledge. Effective analysis identifies these differences rather than assuming that one representative speaks for everyone.

Governance establishes decision rights, accountability, controls, escalation routes, and evidence requirements. It may cover architecture review, privacy impact assessment, security approval, change control, procurement, risk acceptance, and release authorisation.

Stakeholder engagement should be purposeful. Interviews, workshops, observation, prototypes, surveys, demonstrations, and usability sessions each reveal different evidence. Engagement must also address power imbalances: users should not be pressured to approve unsafe or unsuitable functionality merely because a deadline is approaching.

7. Constraints, Trade-offs, and Quality

A constraint limits available choices. Typical constraints include budget, schedule, staffing, legacy technology, legal duties, data residency, interoperability, accessibility, procurement rules, and organisational policy.

Constraints interact. A compressed schedule may reduce testing or increase staffing costs. A highly customised design may improve local fit but increase maintenance burden. Strong security controls may introduce additional user effort, but weak controls may expose people and the organisation to serious harm.

A practical decision should make trade-offs explicit. Teams can record alternatives, evaluation criteria, assumptions, risks, and the decision owner. Common quality attributes include:

• reliability and availability;
• performance and scalability;
• security and privacy;
• usability and accessibility;
• maintainability and testability;
• portability and interoperability;
• safety and recoverability.

Quality attributes require measurable or testable acceptance conditions where possible. “The system must be fast” is weak; a statement such as “95% of search requests shall receive a response within two seconds under the agreed workload” is more useful, provided the workload and measurement method are defined.

8. Projects, Products, Processes, and Services

These four concepts are related but distinct.

• A project is a temporary endeavour undertaken to create a unique product, service, or result. It has a beginning and an end, even if the resulting product continues operating.
• A product is a solution or outcome that provides value to users or customers. It may evolve through many releases.
• A process is a repeatable set of activities that transforms inputs into outputs. The SDLC is a family of processes and practices, not one single universal sequence.
• A service is a means of enabling value through outcomes customers want to achieve, often without owning or managing all underlying resources. Cloud hosting and online banking are examples.

A project may create or significantly change a product. The product may then be operated as a service. Processes guide both the project and ongoing product work. Confusing these concepts causes management problems: a team may declare success when a project delivers software, even though the product has no support model, users cannot adopt it, or the service cannot meet availability obligations.

9. Applied Case: Community Clinic Appointment Platform

The following is an illustrative fictional case.

Background

A group of community clinics uses telephone calls and spreadsheets to schedule appointments. Patients experience long waiting times, staff duplicate records, and managers lack reliable information about missed appointments.

Problem

The sponsor proposes an online appointment platform. Initial discussions focus on a booking screen, but systems analysis reveals additional concerns: different clinics have different opening hours, some patients have limited digital access, health information requires protection, and the platform must integrate with an existing patient-record system.

Analysis

Stakeholders include patients, reception staff, clinicians, clinic managers, the information-security officer, the existing-record-system supplier, and a health regulator. Their interests differ. Patients want accessible booking and reminders; reception staff need correction and exception-handling functions; managers need accurate reports; regulators require appropriate privacy and audit controls.

The project team identifies external dependencies: identity verification, text-message delivery, and the patient-record interface. It also identifies a key emergent risk: a technically reliable booking function could still increase inequality if it becomes the only way to obtain an appointment.

Approach and solution

A hybrid approach is selected. Formal privacy, security, accessibility, and integration decisions require approval, while user-facing functions are developed incrementally. The first increment supports staff-assisted booking and a limited patient search function. Prototypes are tested with patients who have different accessibility needs.

Deliverables include a stakeholder register, prioritised requirements, architecture decision records, a privacy assessment, interface specifications, automated tests, a migration plan, training material, and an operational runbook. Acceptance criteria include correct handling of appointment clashes, audit logging, accessible navigation, and a defined response-time target under an agreed workload.

The team uses a pilot clinic before wider deployment. Monitoring measures failed bookings, response times, support requests, and missed appointments. Feedback leads to larger text options, clearer cancellation rules, and a telephone fallback process.

Outcome

The pilot reduces duplicate appointments and gives managers more timely information. However, the project also exposes the continuing cost of integration and support. The platform is therefore treated as a product requiring a funded service team, not as a project that ends at launch.

Learning points

1. The initial requested feature may not represent the complete system problem.
2. Stakeholder diversity affects requirements and adoption.
3. Privacy, accessibility, and operational support must be designed early.
4. Incremental delivery reduces uncertainty but does not remove governance obligations.
5. A successful project must produce an operable and supportable product or service.

10. Ethics, Regulation, and Contemporary Practice

Software decisions can affect employment, access to services, safety, privacy, and personal dignity. Professional responsibility therefore extends beyond satisfying a customer’s immediate request. Engineers should identify foreseeable harm, protect confidential information, report serious risks, and avoid misleading claims about system capability.

Relevant obligations vary by jurisdiction and sector, but commonly include data-protection law, intellectual-property law, accessibility requirements, records-retention duties, cybersecurity controls, and sector-specific safety or financial regulation. Compliance should be considered throughout the life cycle because retrofitting controls is expensive and may be ineffective.

Artificial intelligence can support requirements analysis, code assistance, test generation, documentation, monitoring, and defect classification. Its use introduces risks including inaccurate output, insecure generated code, hidden bias, leakage of confidential data, unclear ownership, and overreliance on automation. AI-generated artefacts require human review, suitable testing, provenance awareness, and compliance with organisational policy. AI is a tool within an SDLC, not a replacement for stakeholder judgement, accountability, or engineering evidence.

Contemporary development also emphasises secure-by-design practice, infrastructure as code, automated pipelines, observability, platform engineering, accessibility, sustainable computing, and software supply-chain security. These practices should be selected because they address real risks or improve value, not because they are fashionable.

Best-Practice Guidance

1. Define the system boundary and external dependencies before detailed design.
2. Involve representative stakeholders, including affected non-users and vulnerable groups.
3. Make requirements testable and record assumptions.
4. Deliver feedback early, but retain proportionate governance and evidence.
5. Treat security, privacy, accessibility, and operability as design concerns.
6. Maintain traceability for high-risk or regulated functions.
7. Automate repeatable checks, while reviewing automation outputs critically.
8. Record important decisions and the reasons behind them.
9. Measure outcomes, not merely activity or document completion.
10. Plan operation, maintenance, and retirement before deployment.

Chapter Summary

Software engineering applies systematic and measurable principles to the creation and operation of software. The SDLC provides a life-cycle view encompassing initiation, feasibility, requirements, design, implementation, verification, deployment, operation, maintenance, and retirement. These stages may be organised through predictive, iterative, incremental, agile, DevOps, or hybrid approaches.

Systems thinking places software within a wider environment of people, processes, organisations, regulations, data, and external services. Boundaries, interfaces, feedback, dependencies, and emergent properties are essential to understanding real outcomes. Deliverables provide communication, control, and evidence when they are purposeful and current. Stakeholder analysis supports better requirements and more legitimate decisions.

Projects are temporary efforts, products provide continuing value, processes organise repeatable work, and services enable ongoing outcomes. Effective software development recognises constraints and makes quality, ethical, security, privacy, accessibility, and operational responsibilities explicit. A project is not truly successful merely because code has been delivered; the resulting product or service must be useful, dependable, supportable, and responsibly governed.

Key Terms

Software engineering: Systematic, disciplined, and measurable application of engineering principles to software.

Software Development Life Cycle (SDLC): The organised life-cycle activities through which software is conceived, developed, operated, maintained, and retired.

System: Interacting elements organised to achieve a purpose.

Systems thinking: Analysis of relationships, boundaries, feedback, dependencies, and emergent behaviour in a whole system.

Stakeholder: A person, group, organisation, or system that affects or is affected by an initiative or product.

Requirement: A needed capability, quality, constraint, or condition.

Functional requirement: A requirement describing behaviour or a service the system must provide.

Non-functional requirement: A quality attribute or constraint on the system or its development.

Architecture: Significant structures, components, interfaces, relationships, and principles of a system.

Deliverable: A work product produced to fulfil an objective or provide evidence.

Verification: Evaluation of whether the product was built according to specified requirements.

Validation: Evaluation of whether the product addresses the intended need.

Predictive life cycle: An approach that plans substantial work and scope in advance.

Iterative development: Repeated refinement of understanding or solution elements.

Incremental development: Delivery of a product through separate usable portions.

Agile: A family of approaches emphasising collaboration, feedback, early value, and adaptation.

DevOps: Practices integrating development and operations through shared responsibility, automation, and feedback.

Technical debt: Future cost or risk created by expedient technical decisions or deferred improvement.

Project: A temporary endeavour producing a unique product, service, or result.

Service: A means of enabling desired outcomes without requiring the customer to manage all underlying resources.

Review Questions

Short Answer Questions

1. What is the difference between verification and validation?
2. Define a stakeholder and give two software-project examples.
3. Name four typical stages of the SDLC.
4. What is meant by an external dependency?
5. Distinguish a product from a project.

Long Answer Questions

1. Explain how systems thinking improves software requirements and architecture decisions.
2. Compare predictive, iterative, incremental, and agile approaches, including a suitable context for each.
3. Discuss the purpose of SDLC deliverables and the dangers of producing documentation only as a compliance exercise.
4. Explain how security, privacy, accessibility, and operability should be addressed throughout the life cycle.
5. Describe the relationship among projects, products, processes, and services using a software example.

Analytical / Application Questions

1. A university plans an online examination system. Identify at least six stakeholders, their interests, and two conflicts that the team may need to manage.
2. A team delivers a technically functioning mobile application, but users cannot complete key tasks and support staff have no operating procedures. Analyse the failure using validation, systems thinking, and product-service concepts.
3. For a hospital appointment system with strict privacy requirements and changing user needs, recommend a life-cycle approach. Justify your choice using uncertainty, governance, risk, stakeholder feedback, and operational considerations.

Multiple Choice Questions with Answers

Question 1

Which statement best describes the purpose of the SDLC?

A. To provide an organised view of activities from conception through retirement

B. To guarantee that software contains no defects

C. To replace stakeholder participation with technical design

D. To restrict all projects to sequential development

Correct Answer: A. To provide an organised view of activities from conception through retirement

Question 2

Which example best illustrates systems thinking?

A. Examining only the source code of a booking feature

B. Considering users, regulations, integrations, procedures, and feedback together

C. Measuring developer productivity without examining outcomes

D. Selecting a programming language before identifying the problem

Correct Answer: B. Considering users, regulations, integrations, procedures, and feedback together

Question 3

What is the primary distinction between verification and validation?

A. Verification concerns cost, while validation concerns schedule

B. Verification asks whether the right product was chosen, while validation checks coding style

C. Verification checks conformity to specifications, while validation checks fitness for intended need

D. Verification occurs after retirement, while validation occurs during initiation

Correct Answer: C. Verification checks conformity to specifications, while validation checks fitness for intended need

Question 4

Which is a non-functional requirement?

A. The system shall create a customer account

B. The system shall calculate the invoice total

C. The system shall send a password-reset message

D. The system shall display 95% of search results within two seconds under the agreed workload

Correct Answer: D. The system shall display 95% of search results within two seconds under the agreed workload

Question 5

Which deliverable primarily communicates significant structures, interfaces, and relationships in a software solution?

A. Architecture description

B. Defect record

C. Training attendance sheet

D. Retirement notice

Correct Answer: A. Architecture description

Question 6

What is an increment in software development?

A. A rejected requirement

B. A separate usable portion of a product

C. A legal approval document

D. A type of production incident

Correct Answer: B. A separate usable portion of a product

Question 7

Which statement about a project and a product is correct?

A. A project continues indefinitely, while a product always ends at launch

B. A project and a product are identical terms

C. A project is temporary, while the resulting product may continue evolving

D. A product exists only during feasibility analysis

Correct Answer: C. A project is temporary, while the resulting product may continue evolving

Question 8

Which activity is an example of adaptive maintenance?

A. Correcting a calculation defect discovered in production

B. Improving code readability without changing behaviour

C. Adding a faster search algorithm for user convenience

D. Modifying software to operate with a new external platform

Correct Answer: D. Modifying software to operate with a new external platform

Question 9

Why is a pilot release useful in the clinic appointment case?

A. It removes the need for testing

B. It provides controlled operational feedback before wider deployment

C. It guarantees that all stakeholders will agree

D. It allows privacy controls to be postponed permanently

Correct Answer: B. It provides controlled operational feedback before wider deployment

Question 10

Which statement is a responsible principle for using AI in software development?

A. AI-generated code requires no human review if it compiles

B. AI tools eliminate the need for stakeholder validation

C. AI output should be reviewed, tested, and handled according to confidentiality and governance requirements

D. AI-generated documentation is automatically legally authoritative

Correct Answer: C. AI output should be reviewed, tested, and handled according to confidentiality and governance requirements