Step Two : Capture & Document Required Functionality

Stakeholder Audit
The first step in this process is a stakeholder audit wherein we talk to all associated stakeholders of the application to understand their requirements and expectations of the application. Although it is tempting to start to gather feedback around the performance and challenges with the application at this stage, the primary goal is to understand how the application ought to work (not how it does work) so that we can document the desired functionality.

Through a series of conversations and or workshops with various stakeholders such as customers, users, product owners, technical representatives and commercial or wider business leadership, we build a picture of not only the high-level requirements of the application but also the key performance indicators by which its success will be measured. Finally we begin to understand the tactical functional requirements of the application.

Functional Specification
The next step is to build a functional spec wherein we attempt to document the required functionality of each screen within the application. Sometimes this documentation is available to us and we are able to update and repurpose it but often we are required to build a functional specification from scratch.

This step is required as it serves as a single source of truth moving forward and allows us to conduct a functionality audit in step 4 to benchmark the application’s current state versus it’s intended state.

Test Script & Matrix
The next step is to take the functional spec described above and start to build a series of test scripts. A test script is traditionally a spreadsheet with various user requirements and journeys expressed as rows and then each line item is categorised as critical, major or minor functionality.

We can then build a matrix of which user journeys ought to be tested more frequently than others. For example we may choose to conduct only critical functionality tests during a hot fix of a typo whereas when a major OS update occurs we will opt to perform a full minor level test of the application, validating each component of functionality.

Having this script allows us to not only conduct diligent quality assurance checks of future releases, but also allows us to report regularly to the wider business and give assurances to external stakeholders that quality performances are being met as we move forward. It can also serve as the basis for improving automated test coverage over time.

We find this test script essential in the world of app development particularly as the release cycles tend to be quicker as the ecosystem evolves with new OS updates, new handsets and new app store rules requiring constant tweaking and adjustment to our applications outside of the regular release cadence.

Key Performance Indicators
The final step in our capturing and documenting of functionality is to formally describe and document the key performance indicators by which the app will be measured. This will vary from application to application but usually consists of metrics such as percentage of revenue, crash rate, time to onboard, new signups and other such metrics.

Having agreed which metrics are important to measure and monitor over the long and short term we proceed to build a simple dashboard to use as a reporting tool into the business but also to allow us to start considering what we ought to be measuring within the application.