Requirement analysis or conceptualisation captures details of what functions the app should provide to whom and in which circumstances. It includes considerations of associated data input, output, processes, and the identification and handling of associated data validation requirements and potential errors.
A common example of an app functionality: Self registration
Most apps require an initial self-registration by users and the mechanism for this generally requires data input from a given user such as an email address or age. User input may require verification or validation, for example to ensure an email address is valid. The app may be required to send a registration message to the user-specified email that requires a response to confirm registration. Alternatively, app-use may be restricted to adults, in which case handling of under-age users needs to be specified.
TIP: It is possible to delegate login and authentication to third-party services such as Google, Facebook . The advantage of delegation is the user does not need a new account but the disadvantage is they may not have an account and may not want app data (e.g. health information) linked to a third-party account.
In this step it is important to define the following. Although they may have been considered in previous steps - this is where they need to be more defined:
- The target population (all users) and any groups who would be excluded.
- Primary intended use or desired clinical outcome of the product. What is the theoretical model you are using to design the intervention and how to translate this to mechanisms of action? How will the product bring about the desired change in the primary outcome? It is useful to refer to the NIHR and MRC guidance for developing complex interventions and published papers which outline development of theory based digital interventions.
- User journey
- Which phase is targeted (e.g. Awareness, Screening, Diagnosis, Treatment, Long-term management)?
- What are patient needs at this phase (e.g. psychoeducation, support, communication with healthcare professionals)?
- Country(s) of launch - are there any specific data hosting and data sharing requirements?
- The outcomes and data that will be collected within the product and potential externally. Consider what data you need to collect to understand day-to-day usage, adherence to the intervention and other research purposes and evaluation criteria. Do not assume that when the product is built for you it will routinely collect data.
- Intervention structure, i.e. how often will it be used, what is the order of use, how will it be used? Will push notifications, text messages, emails or other prompts be needed to encourage people to use the intervention.
- Content and its medium
- Safety considerations, e.g. how will risk be managed?
Important Considerations
When defining these different aspects it's important to think about the following:
- Accessibility for the target population. Consider issues of colour blindness, visual impairment lack of digital literacy, finger dexterity, cognitive impairment etc.
- What is the ‘Intended Use’? Does it fall in Software as Medical Device category?
- What is the app’s ‘hero feature’ - i.e. the thing that keeps people coming back to use it?
When conducting a requirement analysis it is important to form a user testing group (see Patient and Public Involvement and Engagement). Alongside this it can be helpful to conduct an Intervention mapping and talk to potential users and healthcare professionals in that space - this can help to find out pain points and to gain feedback to initial ideas.
In addition to functional requirements, app development involves the specification of non-functional requirements, which relate to expected conformance to security, performance, usability, technical, industry standards, regulatory requirements, and/or laws.
