01202 006 464
learndirectPathways

Running an SDLC in Practice: Requirements to Delivery

Podcast episode 38: Running an SDLC in Practice: Requirements to Delivery. Alex and Sam explore key concepts from the Pearson BTEC Higher Nationals in Computing. Full transcript included.

Series: HTQ Computing: The Study Podcast  |  Module: Unit 7: Software Development Lifecycles  |  Episode 38 of 80  |  Hosts: Alex with Sam, Computing Specialist
Key Takeaways
  • The requirements gathering phase determines what the system must do by consulting stakeholders and documenting functional and non-functional requirements.
  • The design phase translates requirements into a system architecture, including database design, interface design, and technical specifications.
  • Implementation is where developers write and integrate the code according to the agreed design, often working in parallel on different components.
  • Testing phases including unit, integration, system, and user acceptance testing ensure the software meets requirements before release.
  • The maintenance phase begins after deployment and typically consumes more resource over the system's lifetime than the original development.
Listen to This Episode

Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.

Start learning →
Full Transcript

Alex: Today we're walking through what it actually looks like to run a full software development lifecycle from start to finish. Sam, let's take a concrete project and trace it through.

Sam: Let's use the example of building a new customer management system for a medium-sized business. They currently track customer information in spreadsheets and want a proper database-backed application. The lifecycle starts with the feasibility study we discussed in the last lesson, and assuming that returns a positive recommendation, the next major phase is requirements.

Alex: How does requirements gathering work in practice?

Sam: The team meets with stakeholders: the sales manager, the customer service team, the marketing team, the IT manager, and possibly some customers. Through interviews and workshops they document what the system needs to do: store customer contact details, track the history of interactions, generate reports, integrate with the email system, and be accessible to the sales team on mobile devices. They document both functional requirements and non-functional requirements like performance, security, and uptime expectations.

Alex: And design follows requirements?

Sam: The design phase translates requirements into a blueprint. The technical architect designs the system architecture: a web-based application, a relational database, a REST API connecting them. The database designer creates an entity-relationship diagram and schema. The UI/UX designer creates wireframes of the application screens. The security engineer specifies the authentication and authorisation model. At the end of design, there's a detailed technical specification from which developers can build.

Alex: Implementation is the coding phase?

Sam: Yes. Developers pick up components of the system and build them: the database, the API, the front end, the reporting module, the integration with the email system. In a well-run project, this work is divided into pieces that can be worked on in parallel, and there's continuous code review and version control. Developers write unit tests for their code as they go.

Alex: Testing is next?

Sam: Testing happens at multiple levels. Unit tests check individual functions and components in isolation. Integration testing checks that components work correctly together. System testing tests the complete system against the requirements. User acceptance testing, or UAT, involves actual users testing the system against realistic scenarios to confirm it meets their needs. Each level of testing catches different types of defects.

Alex: And then deployment?

Sam: Deployment moves the tested system into the production environment. In modern development this often involves a staging environment where a final round of testing happens in conditions that mirror production before the actual go-live. The deployment itself might involve data migration from the old spreadsheets, training users on the new system, and a period of parallel running where both the old and new systems operate simultaneously.

Alex: And then maintenance?

Sam: Maintenance is the longest phase, lasting for the entire operational lifetime of the system. It includes bug fixes, security patches, performance improvements, and new features as requirements evolve. The maintenance costs over a system's lifetime typically exceed the original development cost, which is why maintainability must be a design consideration from the very beginning.

Alex: A complete picture. Thanks Sam. Next we look at software behavioural design techniques.