The following table outlines the key steps in the Software Development Lifecyle (SDLC).
Table: SDLC
Category | Description | Supporting Workflows | Relevancy to a project |
| Business Requirements | Business goals, Business case, Stakeholder goals, Budget, Timelines, Client input | Business Plan, Project Management, Interviews, Questionnaires, Project Document | Business purpose (return on investment), timeframes, Business workflows, fully understand stakeholder objectives including details |
| Technical Requirements | Functionality, reporting, managing, system behaviour | Same, elicit technical flows, add to Project Document | Understand the technical process and functional, non-functional requirements, Security |
| Software and System Specifications | Based on requirements, identify components, the software modules, platform | Technical Design, Modelling and creation of High-Level Design | Detailed models and functional concepts including code, OS, database, platform, system behaviour, Security |
| Prototyping | Iterative build of first design, based on objectives | Agile, Scrum, Project Management, High Level Design to Low-Level Design | Identify functionality, skills, team members, approach, environments, testing, client-input, Security checks |
| Pilot | Iterative improve prototype | Same, End to End Design | Same |
| Deployment including testing | Implementation, testing, deployment plans for usage | Same | Checklists of Functional, Non-Functional Requirements |
| Operations | Management of the system | Operations Run Books, Support, Trouble Ticket management and Resolution | Dev-Ops, tools, monitoring, troubleshooting, on-going support, ideas for improvement |
The first document we need to produce or ask the stakeholders to produce, is the Business Plan or rationale to build this system or software. The business plan will be used by business and project management to manage the expectations around revenues and costs; timelines; milestones (project work), stakeholder objectives and risk management. If the business-case is not justifiable, and based on a proper assessment of market demand, revenues, and profits, the project cannot proceed.
Assuming that the business plan is sensible, supported and there is a budget from the client, we need to build a second document ‘The Requirements’. This needs to be signed off by the stakeholders. It outlines the specifications which the system will develop to fulfil the business objectives and requirements. This document creates the basis for our prototype.
Clear requirement’s documentation is often done iteratively with the stakeholders, including in this case, potential clients. Iteration is preferred given that the original scope is vague. The ‘requirements documentation’ will eventually become a High-Level and Low-Level (end to end) design and this informs the prototype and the pilot to implementation phases. The diagram below illustrates this process.
Diagram: SDLC
Prototype
For any project, we will need to determine a ‘target model’ or system. An example would be a cloud-platform satisfying business and technical functionality and characteristics. This will inform our prototype and satisfy the general requirements. It gives us a clear direction of travel in the SDLC.
An example could be vending machine software to dispense drinks, on a public transport system.
Category | General Requirements |
| Business Requirements |
|
| Technical Requirements |
|
We will need to produce system and software modelling, High Level Designs which will lead to a prototype and a Low-Level Design, a Test strategy and plan, Operational Run Books and a Security model and management using Agile-Scrum processes.