Agile requirements analysis and specification for a mobile application

In my role as an Equinox IT Senior Consultant specialising in business analysis, I often work on client projects with the goal of modernising and digitising their business processes. In a recent assignment, I was asked to work as part of an Agile project team for a regulatory body to analyse and specify the business requirements and system requirements for the development of a mobile application. In this article, I cover the requirements analysis activities that I performed to ensure we delivered an application that successfully met the business’s needs.

Client situation

The client provides assessment services for the purposes of accreditation. The service relied on paper-based forms completed by the assessor at the point of assessment. Information from the paper records was later manually entered into a system. The paper copies were then kept by two organisations for auditing and other purposes, with at least one copy being kept for 75 years. I was tasked with eliciting, analysing and specifying the business and systems requirements for moving from the paper-based assessment approach to a mobile assessment application.

Eliciting and analysing the business process requirements

Working in short Agile iterations I analysed the existing paper-based business process to understand regulatory and business constraints that needed to be accommodated. My analysis uncovered several complex scenarios where an assessor’s subjective interpretation needed to be recorded. This complexity was not evident at the start of the project, and gradually surfaced during my analysis activities. These findings along with others from the requirements elicitation activities highlighted the need to rethink aspects of the design and implementation. I worked directly with the development team to incorporate the new requirements into the mobile application solution.

Liaising between the business and IT

The assignment required me to undertake a great deal of workshopping, prototyping and cross-team collaboration to ensure that the complex requirements met the regulatory and end user needs of the business stakeholders and could be delivered within the technical constraints faced by the IT team.

Using Agile analysis techniques to specify the system requirements

The specification of both functional (what the system will do) and non-functional (how well the system will do it) requirements was achieved using the Agile technique of Specification by Example. I documented User Stories to capture the goal of the requirement and Acceptance Criteria to describe what a successfully implemented User Story looked like. Regular production releases were scoped through User Story Mapping to ensure that each release delivered genuine business value.

To learn more about Specification by Example, read my article Using Specification by Example to become a better business analyst.

Result

Using the techniques described I created unambiguous requirements that clearly defined the business outcome required. This allowed the project team to concentrate on delivering that outcome, rather than trying to meet requirements that needed lengthy interpretation or that encouraged ‘gold plating’ of the solution.

The short iterations compressed the feedback loop between the business and the delivery team, allowing the business to see value being added every iteration. Once a delivered piece of functionality was deemed to have met the business’s definition of done, then this in turn allowed the business to switch focus onto the next area of business benefit.

The close collaboration of the delivery team meant that there was shared understanding which encouraged creative problem solving, without stepping outside of the true business outcome being delivered.

Additionally, moving this system to a digital environment introduced several immediate benefits. It removed the need to double handle the work by entering the assessment data directly into a mobile application. It eliminated the need to store paper records for up to 75 years. It also allowed greater access to the information gathered during the process and the sheer amount of new information on a usable scale is a gold mine to the regulatory body.

Kirsten Eriksen is a Senior Consultant specialising in business analysis, based in Equinox IT’s Wellington, New Zealand office.