Requirement Life Cycle from Start to Market
What is Requirement Lifecycle?
Requirement life cycle is the process of creating, maintaining, evolving, implementing & delivering the requirements artifacts throughout the life cycle of a system or project. The nature of the process depends on the methodology we choose like Agile, Waterfall, Incremental, etc.
Requirement’s life cycle can be a critical aspect of any software development project. It is an essential step that helps assure that the final product is what the customer or user wants. In other words, requirement’s life cycle is about being able to see the big picture for a project and keeping it on track.
The phases of the requirement life cycle can be seen as follows from a 1000-foot height:
1) What to Build
2) How to Build
3) Build and Deliver
What to Build: The main focus is to understand the business demands.
How to Build: This phase mainly focuses on requirements grooming, solution design, and backlog refinement.
Build and Deliver: Essentially, this entails coding, testing, and releasing.
Taking a closer look at the phases of the requirement life cycle of a UI based application in detail now, we will see:
Although this breakdown is not a canonical way, we used it in our project, and it worked well.
1. Pre-Planning (New)
Stakeholders: Product Owner & UI designer
1) Once the IT team has received a requirement from the business, create an entry in spec document(s) for grooming. (closed → The activity should be closed in this phase)
2) Start UI wireframe. It is about creating a sample of the application to test the features, look and usability of the application before it is developed. It is the easiest way to check functionality and evaluate if the application serves the purpose. It keeps the user in mind and creates the basic skeleton of any application feature. (In-progress → The activity can span across other phases)
2. Planning (Grooming)
Stakeholders: Product Owner, UI designer, Technical Architect(s) & Tester
1) Based on our understanding of the requirement and keeping high-level UI design in mind, we’ll create relevant features and/or stories in DevOps to proceed with requirements grooming. (closed)
2) UI design & requirements grooming will supplement each other with ideas/inputs to conclude DevOps features & stories for implementation (closed)
3. Ready
Stakeholders: Product Owner, UI designer, Technical Architect(s) & Tester
1) Done with story grooming with clear acceptance criteria. (closed)
2) Done with UI design. (closed)
3) Ready to handover the business story to the DEV team for implementation & QA for test plan preparation. (In-progress)
4. Implementation
We can track implementation items such as engineering stories & builds on respective Azure DevOps Team projects and link engineering stories with the business story that’s part of the Azure DevOps Project Management dashboard.
Stakeholders: Technical Scrum Team & Tester
1) Done with handover of a business story for implementation. (closed)
2) Dev team to understand the business story, proceed with creating corresponding engineering stories for grooming and come up with a clear implementation strategy. (closed)
3) Upon complementation of engineering stories grooming, start working on coding in the sprint cycle. (closed)
4) QA to finish test plan and test cases required to verify business story implementation as per its acceptance criteria. (closed)
5. Testing
Stakeholders: Product Owner, Technical Scrum Team & Tester
1) QA to verify business story implementation as per its acceptance criteria in the staging environment. (closed)
2) QA to raise defects if any issues. (closed)
3) QA to hold defect triage meetings with stakeholders. (closed)
6. Release
Stakeholders: Product Owner, Manager & Technical Architect(s)
1) Product Owner to come up with release notes. (closed)
2) Technical Architect(s) to be ready with forward & reverse migration plans (closed)
3) Manager to supervise the release process and help the team with necessary approvals (closed)
7. Post Deployment Testing (PDT)
Stakeholders: Product Owner, Manager & Tester
1) Product Owner & Tester to perform smoke testing in the production environment. (closed)
2) Manager to make a GO/NO-GO call on release. (closed)
8. Close
1) End of business story life cycle.
2) Manager to throw a party for the team 😜
Maintaining a requirement life cycle in the form of Epics, Features, Business/Engineering stories, Test Cases, Bugs, Code Repositories, Builds and Releases in a platform such as Azure DevOps will allow us to trace work from its origin through its delivery, which is vital to traceability.
I hope you found this article useful. Thanks for reading, have a great day!