Mobile App Requirements Specification Creation

[former_member202810]

This document is intended to serve as a practical guide that explains the significance of generating concise requirements for a mobile application as well as describes the process of requirement definition. The intended audience for this document is anyone with pre-sales and/or business analysis duties, including those who are responsible for definining requirements.

Requirements Specification

A requirement specification document lists and describes all the key features of an application and explains the functions that the target application/system should be able to perform. The importance of having a proper requirement specification cannot be overrated-it is a known fact that many applications fail because the requirements for the application have not been properly planned and because they lack a well defined user interface specification. A requirement aims at identifying specific characteristics, qualities, or capabilities that represent a need of the customer. A requirement answers to the following questions: What does the application do? What qualities does the application possess?

A specification is a document that provides a complete description of the functionality (user interface specifications) or the technical solution (technical specifications). A specification answers the following questions: How does the application work? How is the client/consumer need addressed in the application? . The most important objective of the requirement specification exercise is to clearly define the client/consumer problem so that the UI design and development team can commence application design & build activities.

The main input needed to create a requirement specification is up-to-date data extracted from the consumer/client: the client's current needs, problems that require solutions, consumer trends, and so forth. Since the requirement specification is such an essential element in application creation, it is used by almost everyone involved in the project: user experience/interface designers, the implementation team, the marketing team, and the testing team, to name a few stakeholders.

Typically a mobile application lifecyle would consist of the following phases:

  

Requirements can be further captured as:

1. Functional
2. Non-Functional
3. Interfacing

Functional Requirements

Functional requirements describe the features and functionalities of the application. It is generally a good idea to start with relatively high-level functional requirement that can be broken down into several lower-level requirements. Use case headings can usually be utilized as titles for high-level functional requirements

Functional Requirement ID<id>
Description:  <Summarize the basic flow of events,  actors, and goals, providing context and impact of the requirement>
Assumptions	<Assumptions made while stating the requirements>
Persona	<User Persona>
Impact	<choose priority: MUST HAVE, SHOULD HAVE, COULD HAVE or NICE TO HAVE>
Primary Actor	<Identify groups of people who will use the product and describe how each would use it.  >
Input	<Define the event(s) that trigger this function and data required by the system to perform the action.  Note that event(s) are system events, not user motivations.>
Action	<Define each function that the system must be able to do.  This description should be made in full sentences and typically starts with “The system should”>
Output	<Define the state of the system and any data changes or outputs that result from the Action>
Business Rules	<Rules that supplement the system behaviour described in the use cases>
Exceptions	<Any exception conditions>
Dependencies	<Dependencies>

Non-Functional Requirements

Non-functional requirements do not describe the functions offered by the application. Instead, they represent important, quality-related issues. Due to the inherent characteristics of the mobile context of use, the following requirements should, at minimum, be taken into consideration when listing non-functional requirements:

Non Functional Requirements

Volumetric

Performance

Audit Requirements

Business Security and Data Protection

Disaster Recovery Requirements

Usability

SLA Requirements

Implementation Considerations

Operational Reporting Requirements

Interfacing Requirements

Interfacing requirements constitute a separate category for requirements. These requirements differ from functional requirements in one crucial aspect: they are usually defined in a very detailed level already in the requirement specification (in terms of technical implementation).

Interfacing Requirement ID<id>
Description:  <Describe the interaction that occurs in this use case.  Summarize the basic course/flow of events,  actors, and goals, providing context and impact of the requirement>
Assumptions	<Assumptions made while stating the requirements>
Impact	<choose priority: MUST HAVE, SHOULD HAVE, or NICE TO HAVE>
Source System
Target System	<Define each function that the system must be able to do.  This description should be made in full sentences and typically starts with “The system should”>
Input Data	<Define the event(s) that trigger this function and data required by the source system to interface with the target system>
Output Data	<Define the event(s) that trigger this function and data expected  by the target system>

User Personas & User Interface Design

User personas are descriptions of ideal, stereotypical users. In the absence of user personas, engineers start designing applications and features for themselves — and these applications fail.  The requirement specification is the main input for the user interface specification and implementation processes. The user interface design relies on the requirement specification to provide a thorough list of the desired application functionalities and other qualities. The user interface designer refines the requirements into a more detailed form that specifies how the application solves the consumer need.

The implementation team can use the requirements to start the preliminary planning of the technical implementation. In practice, the implementation team needs the user interface specification before they can start the actual coding work, but the requirements can be used to create system architecture and other basic building blocks for the application.