SDLC vs STLC: What's the Difference?

Requirements Gathering

Once a gap or opportunity in the organisation’s application landscape has been identified, there is a need to understand and document exactly what that business requirement is in order to select the correct solution. It is important to resist the urge of jumping directly to a solution in this phase and stakeholders may need coaching and support to take an open mind about any solution preferences they may already have.

It is important at this stage to ensure that the requirements are not met, or could be closely met, by existing applications. Solution architects, business analysts or those with similar skill sets can help in this phase by gathering requirements and examining the existing application portfolio.

It is often wise at this stage to speak more widely across the organisation to determine if the identified or similar requirements exist as a need in other areas, to prevent duplicate systems being built or procured and allow reuse of the system.

The key output of this phase will be a business requirements document (BRD) which should contain a list of all required functionality, possibly prioritised using a technique such as MoSCoW (Must have/Should have/Could have/Won’t have now) with appropriate traceability by business area.

Design

Once the requirements for the new software have been sufficiently documented and signed off, the design work can begin. At this point, organisations should decide if their effort is best spent on building a new bespoke system or purchasing something off the shelf. This may require a tender process such as a request for proposals (RFP) or a request for information (RFI).

Generally speaking, where capabilities are being met that are highly standardised (for example; payroll, appointment booking, electronic point of sale) it is often better to purchase an off the shelf system for these so-called “systems of record” or “systems of differentiation”. Where requirements exist that are unique to the industry or organisation or provide capabilities that are of competitive advantage the systems are known as “systems of innovation” and are more likely to be suited to a bespoke build.

At the design stage, business analysts and UX designers may work together to create wireframes or mock-ups of what the system would look like. Technical architects and solution designers may begin to design the architecture of the system and make selections around tech stack, hosting and programming languages, keeping in mind the organisation’s current skillset and vendors.

The key output of the design phase will vary by system but are likely to include a set of wireframes, a systems architecture diagram, a decision on tech stack and an indication of resourcing capabilities required.

Build

In the build phase, the output of the “requirements” and “design” phases are transformed into working software by software developers. This could consist of various things such as building front ends, back ends, databases, microservices or many other components.

The software will be built in such a way that it provides the functionality specified in the requirements document and the best projects will ensure continuing engagement with end-users throughout this phase to ensure that the things being built are closely aligned with the originally stated requirements, as sometimes what is built can deviate from this.

Test

In the testing phase, test analysts will conduct a number of validation checks on the software such as performance testing, load testing and exploratory manual testing. The main objective is to ensure that the quality of the work implemented in the build phase is sufficiently robust to meet the demands that will be placed on the system during normal operating conditions and determine what happens when those conditions are exceeded.

User acceptance testing may now begin to confirm that the way in which the system operates matches the stated expectations in the requirements gathering phase although close alignment between users and the build team during the build phase can help to minimise the rework which might be required and ensure there are no surprises.

Deployment

During the deployment phase, the software is loaded into the relevant production environments & platforms from which it will be run. These environments may be physical servers located in the businesses data centre, or more increasingly, a cloud-hosted platform.

Training of end-users is likely to begin in this phase, in order to ensure that people are familiar with how to use the new system and if any data migration is required from the previous legacy system this will be completed to prevent the need for “double keying”.

Discussions should already have begun with the teams who will be supporting and sustaining the system in its “business as usual” state and these teams should also be considered during the training phase to allow them to be able to support the system once the project team is disbanded.

Maintenance

During the maintenance phase, the system is handed over to the team who will be supporting it for the remainder of its life at the organisation. Correct documentation and helpfiles will need to be prepared for service desk operatives so that they know how to direct user support requests to the correct team.

Enhancements and changes may be made to the system over its lifetime, for instance, if new requirements are discovered or if external factors such as regulatory changes occur and the approach for this will need to be considered, i.e. whether internal resource will be retained to make such changes, or will the changes be farmed out to an external provider on an ad-hoc basis.

For more details on the software development lifecycle and how to build on this in order to ensure security is built-in throughout.

Requirements Analysis

During the requirements analysis phase, the business requirements document (BRD) created in the SDLC requirements phase is analysed by the testing team so that they understand the key outcomes and functionality that are required from the new system.

The testing team will discuss the BRD with key stakeholders and business analysts so that they have a good grasp of what is being built and how it should function. They should also consider the business criticality of the system, along with relevant regulatory requirements to ensure that any compliance aspects are adhered to.

Test Planning

Once the functionality and outcomes are understood, the testing team will be able to start planning how they are going to implement their tests. They will write a test strategy document for the initiative, detailing how they will make use of the various technologies at their disposal such as manual, automated, integration and unit tests. They may start to list out the specific test cases or scripts that will need to be created to ensure a robust and complete test of the system.

Test Development

Once the specific test cases and approaches have been identified at a high level, the work can then begin on fleshing the test scripts out with more details such as the specific user journeys that will need to be tested, both from a happy path and an edge case perspective.

Test Environment Setup

Once a usable version of the system has been built, the test team can begin to build a suitable test environment, separate from the production and development environments. In this test environment, they will ensure they have appropriate user personas set up with the correct user login accounts and sufficient test data in order to execute their scripts.

Test Execution and Closure

Finally, once a stable environment exists, the test team takes the time to execute the scripts they designed and then feeds back to the project team and stakeholders with their findings. This step and others may need to be repeated many times as the findings are dealt with by the project team and then require retesting.