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-todate 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:

1
2
3

Requirements can be further captured as:

Functional
Non-Functional
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 lowerlevel 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 im
Assumptions

<Assumptions made while stating the requirements>

Persona

<User Persona>

Impact

<choose priority: MUST HAVE, SHOULD HAVE, COULD HAVE o

Primary Actor

<Identify groups of people who will use the product and desc

Input

<Define the event(s) that trigger this function and data requ

Action

<Define each function that the system must be able to do. T

Output

<Define the state of the system and any data changes or ou

Business Rules

<Rules that supplement the system behaviour described in t

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 cours
Assumptions

<Assumptions made while stating the requirements>

Impact

<choose priority: MUST HAVE, SHOULD HAVE, or NICE TO H

Source System
Target System

<Define each function that the system must be able to do.

Input Data

<Define the event(s) that trigger this function and data req

Output Data

<Define the event(s) that trigger this function and data exp

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.