Requirements Workshop

 
An insurance client required a system to gather insurance policy information for a limited cohort of private school students. This is to replace an existing system where the contract is expiring, and where the client does not hold the rights to the software. With multiple deadlines to meet and increasing complexity, Headforwards proposed a requirements workshop to help ascertain what the minimum looked like to meet each deadline and when to most efficiently develop features in addition to old behaviour.  

This was a fact-finding workshop, where Headforwards sit down with the client and establish what needs to be built, why, how, when and for whom. 

The workshop outcome is a proposal covering the requirements, the estimated timescales, and a suggested development strategy. This was presented to, and accepted by, the client, paving the way for a team to start work on Phase One of development in early February 2024. 

Workshop process 

The requirements workshop employed a Miro virtual whiteboard to map out the project elements. It started by looking at the existing system to see what functionality currently exists, what needs to be replaced or what can be improved. Next, the categories of user were established, such as parents/guardians, school bursars, and the client staff who deal with admin and who potentially handle the insurance claims; the required system activities of each user type were then mapped.  

This was used to create a grid of user stories that follow the BDD (Behaviour-driven Development) method of employing non-technical language to help communication between developers and the business people, including the client, and to feed into automated testing routines. 

Also considered were the non-functional requirements that do not fit the user story grid directly, such as how performant the system needs to be, how many users it needs to support, its security requirements and its auditing requirements. 

The workshop now gauged the priority of each user story and non-functional requirement, to decide where it should fit in the planned project phases. 

Project phases 

Typically, projects that employ an Agile methodology plan to deliver an MVP (Minimum Viable Product), and then build on to this with subsequent code deliveries.  

However, with 4 discrete release dates, including a final deadline in September 2024, this work was divided into 4 phases. With Phase One delivery the system displays a notice to parents that the service is coming; with Phase Two parents can fill in an online form for their child and thus data is gathered; with Phase Three the data can be downloaded and processed by the client; finally, with Phase Four the insurance policy system is fully operational. 

The timescales estimated in the workshop, and shown in the proposal, are all well within the required dates for each phase, allowing leeway if some areas take longer than planned, and are based on our experience of architectures of the type we expect the system to have, and of the technologies we plan to build it with. 

The team 

The workshop also estimated that the team required to complete the project would comprise 2 developers, a delivery manager, plus support as required from a UX designer and QA testers. 

Development progress 

As this case study is being written, Phase One is about to be released, a little later than our planned date, but well within the required timescale. 

As development progresses details of the solution must be fleshed out, for example where action buttons should be displayed in the user interface and what messages should be returned in different scenarios. The communication process during development keeps the client informed of any changes or blockers that may affect our estimates for phase delivery and ensures we continue to develop the product that the client requires.