The software development lifecycle (SDLC) is a structured process for building software, typically involving distinct stages: gathering and analysing requirements (what the software needs to do), designing the system's architecture and interface, implementing (writing the actual code), testing (checking it works correctly and meets requirements), deployment (releasing it to real users), and ongoing maintenance (fixing bugs and adding improvements after release). Different development methodologies structure these stages differently — a traditional 'waterfall' approach moves through each stage once, in strict sequence, while an 'agile' approach cycles through smaller versions of all these stages repeatedly, releasing and refining incrementally rather than all at once.
Example
A team building a new app using waterfall would fully complete requirements gathering, then move entirely to design, then entirely to coding, and so on — with each stage finished before the next begins — whereas an agile team might build and release a very basic working version in two weeks, then repeat the whole cycle (requirements, design, code, test) multiple times, adding and refining features incrementally based on real user feedback along the way.
Key terms
Requirements gathering:
The stage of identifying what a piece of software needs to do.
Waterfall methodology:
A development approach moving through each SDLC stage once, in strict sequence.
Questions
1. The software development lifecycle includes stages like:
Requirements, design, implementation, testing and maintenance
Only writing code, with no other stages involved
A single unstructured stage with no distinct steps
Only marketing and sales
2. Requirements gathering involves:
Identifying what the software needs to do
Writing the final code directly, with no prior planning
Testing the software after it is already released
A stage that is always skipped entirely
3. Waterfall methodology moves through SDLC stages:
Once, in strict sequence
Repeatedly, in short overlapping cycles
In a completely random, unordered way
Without any defined order at all
4. Agile methodology cycles through SDLC stages:
Repeatedly, releasing and refining incrementally
Only once, in strict sequence with no repetition
Never; agile skips all defined stages entirely
In a way completely unrelated to the SDLC
5. Software maintenance occurs:
After release, fixing bugs and adding improvements
Only before any code is written
Never, once software is released
Only during the design stage
6. Testing in the SDLC checks that software:
Works correctly and meets requirements
Has no connection to whether it functions properly
Should always be skipped to save time
Is only relevant after the software is deployed
7. Deployment refers to:
Releasing software to real users
Writing the very first line of code
Deleting a finished software project entirely
A stage that occurs before requirements gathering
8. Why might a waterfall approach be considered risky for a project where requirements are likely to change during development?
Since each stage is completed fully before moving to the next, discovering a needed change partway through can be costly and disruptive to address
Waterfall is always the most flexible and adaptable approach for any project with rapidly changing requirements
Requirements never actually change during a waterfall-managed software project
The order in which SDLC stages are completed has no bearing on how easily a project can adapt to change
9. Why might an agile approach be well-suited to a project where user needs aren't fully known at the very start?
Releasing and testing smaller increments allows real user feedback to inform and refine later stages, rather than committing to a full design upfront
Agile requires knowing every single requirement in complete detail before any development work can begin
Incremental releases in agile provide no useful information for refining a project's direction
Uncertain or evolving user needs have no bearing on which development methodology might be more suitable
10. Why is testing considered an essential stage of the SDLC, rather than something that can be skipped to save time?
Without proper testing, bugs or requirement mismatches may not be caught until after release, when they are typically more costly and disruptive to fix
Testing has no real bearing on whether software actually works correctly once it is released
Skipping testing always produces exactly the same quality outcome as thoroughly testing software
Bugs and requirement mismatches are always caught automatically without any need for a dedicated testing stage
11. Why might requirements gathering involve talking to actual stakeholders or users, rather than a development team simply assuming what is needed?
Direct input helps ensure the software actually addresses genuine needs, rather than the assumptions of people who won't necessarily use it themselves
A development team's own assumptions always produce exactly as accurate a set of requirements as direct stakeholder input
Talking to stakeholders during requirements gathering provides no additional useful information for a software project
Requirements gathering never actually involves any input from the people who will eventually use the software
12. Why might ongoing maintenance be considered just as important as the initial development of a piece of software?
Software needs continued bug fixes, security updates and improvements to remain functional, secure and useful well after its initial release
Once software is released, it never actually needs any further attention or updates of any kind
Maintenance work after release is always considered less important than the initial stages of development
Bugs and security vulnerabilities never actually emerge in software after its initial release
13. Why might a software design stage typically produce diagrams or wireframes before any code is written?
Visual planning tools let a team communicate and refine a proposed structure or interface cheaply, before investing time in the more costly process of writing and changing actual code
Diagrams and wireframes provide no genuine value compared to simply beginning to write code immediately
Design stage planning tools are never actually used in real, practical software development projects
Visual planning always takes exactly as much time and effort as writing and later modifying the actual code
14. Why might a hybrid approach (combining some waterfall-style upfront planning with agile-style iterative development) sometimes be used for large, complex projects?
Some upfront planning can establish essential structure and major requirements, while iterative development still allows flexibility to adapt within that broader plan
Combining these two methodologies always produces a completely disorganised, ineffective project with no genuine benefit
Waterfall and agile approaches can never actually be meaningfully combined in any real software project
Large, complex projects always benefit exclusively from one single methodology, with no room for any hybrid approach
15. Why might a company building safety-critical software (like for medical devices or aviation) lean more heavily toward a waterfall-style approach with extensive upfront design and testing, rather than a rapid, iterative agile approach?
The high stakes of getting the system wrong make thorough upfront planning, documentation and rigorous testing especially important before any release, even at the cost of slower development
Safety-critical software always benefits most from the fastest possible iterative release cycle, regardless of the stakes involved
The consequences of a software failure have no bearing on which development methodology is most appropriate for a project
Waterfall and agile approaches are always considered equally suitable for any type of software, including safety-critical systems
16. Why might "technical debt" (shortcuts taken during development that create future maintenance burden) be a genuine risk of moving too quickly through the SDLC without careful design?
Rushed implementation decisions can create code that is harder to maintain, extend or fix later, effectively borrowing time now at the cost of more time needed in the future
Technical debt is a purely theoretical concept with no genuine, real-world impact on software projects
Moving quickly through development stages never actually creates any additional future maintenance burden
Careful design at each SDLC stage has no bearing on how much technical debt accumulates in a project
17. Why might user feedback gathered after a software product's initial release sometimes reveal requirements that were completely missed during the original requirements-gathering stage?
Real-world use can surface needs, edge cases or usability issues that weren't anticipated during earlier planning, however thorough that planning attempted to be
The original requirements-gathering stage always captures absolutely every possible future need with complete accuracy
User feedback gathered after release never actually reveals anything that wasn't already fully anticipated beforehand
Real-world software use provides no genuinely useful information beyond what was already captured during initial planning
18. Why might understanding the SDLC be valuable even for someone who won't personally write code, such as a product manager or business stakeholder?
Understanding the stages and trade-offs involved helps non-technical stakeholders communicate effectively with developers and make more informed decisions about scope, timeline and priorities
The SDLC is only ever relevant to people who will personally write code, with no value for any other role
Non-technical stakeholders never actually need to understand anything about how software development is structured
Understanding the SDLC provides no genuine benefit to communication or decision-making on a software project
19. Why might a team using agile still benefit from documenting key architectural decisions, even though agile emphasises flexibility over exhaustive upfront planning?
Recording the reasoning behind significant structural decisions helps future team members understand the system, even while day-to-day development remains iterative and flexible
Agile teams should never document any decisions at all, since this would contradict the entire methodology
Documentation of architectural decisions provides no genuine value to a team using an agile approach
Flexibility in an agile approach always means avoiding any form of documentation about how a system was actually built
20. Why might a project that skips the requirements-gathering stage entirely, jumping straight into coding, be more likely to result in wasted effort later on?
Without a clear understanding of what is actually needed, developers may build features that don't genuinely address the real problem, requiring significant rework once the mismatch becomes clear
Skipping requirements gathering entirely always leads to exactly the same outcome as thoroughly completing that stage first
Jumping straight into coding without any requirements analysis is always the fastest and most effective way to build software
The requirements-gathering stage has no genuine bearing on whether a software project results in wasted development effort
21. Understanding the software development lifecycle mainly helps you to:
Explain the structured stages of building software and how different methodologies organise them
Assume software development involves no distinct stages or planning of any kind
Ignore the importance of testing and ongoing maintenance after a software release
Treat waterfall and agile methodologies as always producing identical development outcomes
Answer key (parent copy)
1. Requirements, design, implementation, testing and maintenance
2. Identifying what the software needs to do
3. Once, in strict sequence
4. Repeatedly, releasing and refining incrementally
5. After release, fixing bugs and adding improvements
6. Works correctly and meets requirements
7. Releasing software to real users
8. Since each stage is completed fully before moving to the next, discovering a needed change partway through can be costly and disruptive to address
9. Releasing and testing smaller increments allows real user feedback to inform and refine later stages, rather than committing to a full design upfront
10. Without proper testing, bugs or requirement mismatches may not be caught until after release, when they are typically more costly and disruptive to fix
11. Direct input helps ensure the software actually addresses genuine needs, rather than the assumptions of people who won't necessarily use it themselves
12. Software needs continued bug fixes, security updates and improvements to remain functional, secure and useful well after its initial release
13. Visual planning tools let a team communicate and refine a proposed structure or interface cheaply, before investing time in the more costly process of writing and changing actual code
14. Some upfront planning can establish essential structure and major requirements, while iterative development still allows flexibility to adapt within that broader plan
15. The high stakes of getting the system wrong make thorough upfront planning, documentation and rigorous testing especially important before any release, even at the cost of slower development
16. Rushed implementation decisions can create code that is harder to maintain, extend or fix later, effectively borrowing time now at the cost of more time needed in the future
17. Real-world use can surface needs, edge cases or usability issues that weren't anticipated during earlier planning, however thorough that planning attempted to be
18. Understanding the stages and trade-offs involved helps non-technical stakeholders communicate effectively with developers and make more informed decisions about scope, timeline and priorities
19. Recording the reasoning behind significant structural decisions helps future team members understand the system, even while day-to-day development remains iterative and flexible
20. Without a clear understanding of what is actually needed, developers may build features that don't genuinely address the real problem, requiring significant rework once the mismatch becomes clear
21. Explain the structured stages of building software and how different methodologies organise them