“Life is really simple, but we insist on making it complicated”

Here I have simplified the actual end-to-end process of the Software Development Lifecycle.

After reading this article, you should be able to absorb the SDLC concepts.

Detailed phase-wise SDLC diagram Download here

Phase 1: Requirement

The requirement phase isn’t completed till the signoff is taken from the client/stakeholders.

Crystal clear requirements a needed for clarity and confidence in the project.

Requirement Gathering

Input	Output
User & stakeholder inputs Market research Requirement meetings	Documented requirements

In this phase, the product team gets all application requirements.

The project team prioritizes the requirement based on the short to mid-term priorities.

Project teams can also raise new requirements as a part of process improvement or performance optimizations.

Requirement Inventory Creation

Input	Output
Documented requirements	Inventory with version management & access management

The project team then has to manage all the requirements and set up access management.

All the subsequent changes will be version managed.

Feasibility and Impact analysis

Input	Output
Managed requirement inventory	Analyzed & finalized requirement

The requirement team will now analyze the requirement for their feasibility & impact on the system.

An analysis is needed to check if requirements are deliverable within the given budget and timeframe.

If the requirement is for an existing system change then the feasibility and impact are calculated.

If the requirement is for a new system then only feasibility is checked.

Feasibility analysis

A low budget CRM that can create all reports in 2 seconds is non feasible.
OR 
A voucher handling system which may handle 1 million transaction per second is a non-feasible requirement if hosted on a budget server.

So, such requirement will be re-sent to the client and further negotiations will start.
Either requirements are modified or infrastructure budget will be increased.

Note: Main point of feasiblity analysis is cost of the project.

Impact analysis

Changing the core algorithm of a dynamic cost calculation system of stock market has a high impact.
All graphical changes for a site are low impact.
Impact of a change in the system is decided by how critical or how often user users the changed module.

if a requirements needs to be changed, the team will do the meetings with the stakeholders.

Meetings will keep happening till we have final & agreed requirements.

Prepare BRD, Use Cases & RTM

Input	Output
Finalized requirement	Use Cases, Document Tracker, RTM, BRD.

After completing the initial analysis of the requirement, the requirement team will start preparing documents.

Business requirement document: BRD document talks about the business & user perspective of the requirement.

The ultimate aim of any software is to serve a business and its customers and bring profit to the company, that is why BRD document is an important document.

The application team will not start working on any requirement without the signed-off BRD.

In case the requirement is small then the project team can incorporate the multiple requirements into one BRD.

Use Cases – The project team has to create the use cases for the application team. Uses cases should be detailed which will help the technical team in implementing the requirement. There has to be the use case for every requirement. If the BRD is referring to the multiple requirement the multiple use cases needs to be prepared.

Requirement traceability matrix – RTM: RTM is the master document which do the content mapping of the all the documents. Team needs to link the (associated ids) of the different documents in the RTM. All content mapping should be updated at the Requirement traceability matrix RTM all the time. There will be one RTM for one project.

Requirement Sign-Off

Input: BRD, Use Cases, RTM.

Process:

After the BRD, Use cases and other required documents are finalized the Project team will require the sign-off from the department (IT-Operations) and Stakeholders.

Sign-Off should be either in email or the scan copy of the hard document duly signed by the approver (Dept. Head / Project team Manager/Stakeholder).

Output: Signed-Off BRD and Approval Form.

Phase 2: Design Phase

Prepare HLD, High-level Test scenario& RTM

Input: BRD, Use Case

Process:

Application IT team will prepare the High-level design document on the basis of the BRD and Uses cases. There should be at least one HLD for every BRD.

Application IT team will prepare the high-level test scenario on the basis of the BRD and Uses cases.

Output: HLD, HTLO & RTM

8. Review HLD & Test cases.

Input: HLD, BRD and test cases.

Process:

Application IT team will do peer review of the HLTO prepared and ensure that all the require details are taken care in the document.

Application IT team will do walkthrough of the test scenario with Product team and stakeholders and responsible to take the sign off for the test scenario.

Output: Reviewed HLD, HLTO and Requirement traceability matrix (RTM).

Phase 3: Development Phase

9. Programming, HLD, Document tracker & RTM

Input: BRD, Use Case, HLD and Coding Guidelines

Process:

Application IT team (developer) will start working on the development. Developer will ensure that the code is written with the best practices and under the defined coding guidelines. Developer will also perform the unit testing to ensure the correctness of code.

Phase 4: Testing Phase

Application IT team (QA) will start writing detailed test cases on the basis of approved HLTO. The test cases should be detailed and needs to capture all the possible positive and negative test conditions.

Application team will also update the HLD if required due to technical change while developing the applications. In case the HLD is updated the corresponding changes needs to be updated into the RTM also.

Output: Programmed Feature, HLD, RTM.

10. Code Review / Unit testing/Test Cases Review (Technical Lead / Peer)

Input: Programmed Feature, BRD, Use cases, HLD

Process:

Application team will review all the code items and will ensure the code is written within the defined coding guidelines. Technical lead will also look for the optimization of the code and improve the performance of the code. Application IT team will conduct walkthrough for the detailed test cases and take approval from product team/stakeholder.

Application Team will update the requirement traceability matrix.

Output: Technical review document and Requirement traceability matrix (RTM).

12. Functional/Integration testing

Input: Test case, BRD, Use cases.

Process:

Application team will perform the functional/integration testing of the features and requirements. Team will also update the test cases if required. Team will ensure the new feature works as per the requirements define in the BRD.

Application team will share Test execution report on weekly basis to product team and stakeholders.

Output: Test Execution report/Defect report

13. UAT testing

Input: Test case, BRD

Process:

UAT testing will be coordinated by the Product team. They will execute the high level test case along with testing team. Testing team will also take sign-off from the impacted stakeholders before signing-off the UAT testing.

Output: UAT testing – Test Incident Report and Requirement traceability matrix (RTM).

Phase 5: Deployment Phase

14. Release Checklist

Input: BRD, Use Cases & HLD.

Process:

Release checklist is the document which list down all the technical and configuration aspects which needs to be considered before making any application go-live. Application teams will maintain the one release checklist for one application.

Output: Update Release checklist

15. Prepare Release Tracker, Release Note & RTM

Input: RTM, BRD, Use case and HLD

Process:

Both the team (Product& Application) team will prepare the release tracker and release note at their end. Product team release note will be targeting the stakeholders and take care of the functional aspect of the release. On the other hand Application team will capture both the technical and functional details of the release.

IT Application team will also require to update the requirement traceability matrix.

Output: Release Tracker.

16. Release approval (Application Manager/Product Manager/Stake Holder)

Input: RTM, Release Checklist

Process:

All the release needs to be approved by the application manager. Application manager will ensure that all the features are working fine the new requirement is working in sync with the requirements defined in the BRD. On the other hand Application team will ensure that all the required documents are prepared as per defined process.

Release will be on-hold till it gets the approval from the application manager.

Output: Approval Form.

17. Go-live

Input: Feature / Requirement

Process:

Application team will upload the code to the production and will do the quick round of testing on the production. The production release sign off will be provided by the test team and product team.

Output: Feature / requirement went live.

18. Post Release Analysis

The post release analysis will be conducted by the product team and IT team focusing on the high lights/ low lights of the project

Output: Post release document having details of high light and low lights and action items for improvement if any

19. Close requirement

Input: Release Note

Process:

Product team will send the notification (Release notes) to all the stakeholders and close the requirement. There will be warranty period of 30 days. Any issue found after warranty will be consider as CR for the new build and won’t be consider as fallout.

Output: Requirement traceability matrix (RTM).