Mobile Apps | Requirements

Functional and Non-Functional Requirements for Mobile App: What’s the Difference?
Lvivity Team | February 20, 2021

Functional requirements for mobile applications describe what specifically needs to be implemented in a particular system or product and what actions users have to take to interact with the software. They determine what the system should do.

Non-functional requirements for mobile app show what properties and features a particular solution has, namely, how the system will work and why.

What do Functional Requirements Include?
We can highlight three main groups of functional requirements:
Business requirements. These define the high-level goals set by the customer’s company that is ordering the software development and stipulate what the system is to solve in terms of their business. Example: an application allowing potential customers to browse through the company’s product catalog and to purchase products.
User requirements. These describe the system goals/objectives the users may reach when using the created system (UseCases). Simply put, this is what a user can do: sign up, view certain content, recalculate data using a specific algorithm, and other functions.
Functional requirements. These define a list of actions the system has to perform. In addition, they have to specify how the system responds to various input data, how it behaves in particular situations, and so on.
This group also includes system requirements describing hardware and software environment features necessary for correct operation.

Non-Functional Requirements in Simple Words

As a rule, the non-functional requirements primarily include various product quality attributes determining system quality features, most often as examples below:
Availability – requirements for app continuous running, for example, 24/7, minimum idle time, etc.
Reliability – app behavior in case of alarm status, for example, automatic restart and operation recovery.
Scalability – ways to expand the system and avoid adversely affected performance.
Performance – how many simultaneous users or transactions the system is to service and its response time.
Security – app operation and use of safety requirements related to access control, private data processing, and external attack risk reduction.
Usability – ease of use and user-friendly interface, that allow users to seamlessly interact with the product.
Extensibility – requirements for app extensibility in case there is a need to add new functional requirements.

Wikipedia = Non-functional requirement


Author = Lvivity Team


User Stories | User Story (+ Tool)

Glossary = User Story
ProductPlan | Undated

User Story
Definition: A user story is a small, self-contained unit of development work designed to accomplish a specific goal within a product. A user story is usually written from the user’s perspective and follows the format: “As [a user persona], I want [to perform this action] so that [I can accomplish this goal].”

What is a User Story?
In agile software development, a user story is a brief, plain-language explanation of a feature or functionality written from a user’s point of view. Many agile experts also describe a user story as the smallest unit of product development work that can lead to a complete element of user functionality.

Product teams choose to break development work into user stories instead of product features or product requirements for several reasons.

User stories:
Are easy for anyone to understand
Represent bite-sized deliverables that can fit in sprints, whereas not all full features can.
Help the team focus on real people, rather than abstract features
Build momentum by giving development teams a feeling of progress

What Does a User Story Look Like?
Most product teams use a similar user story template, typically just a sentence or two written according to the following formula:
As a [description of user], I want [functionality] so that [benefit].

User Story vs. Use Case: What’s the Difference?
Like user stories, a use case describes how a user might interact with a product to solve a specific problem. But the two are not interchangeable; they are different tools used in product development.

Ivar Jacobson, who is credited with developing the use-case concept, explains that use cases document both a user’s goal and the functional requirements of the system. In other words, use cases are designed to capture much more detail than a user story about the process a user goes through to achieve the desired outcome from interacting with a product.

Whereas a user story is written as a very brief statement describing only the user’s end goal, a use case often describes several additional steps, including:
The preconditions required before the use case can begin
The main flow of events (also called the basic flow) describing a user’s path, step by step, to completing an action with the product
Alternate and exception flows, meaning variant paths a user might take with the product to complete the same or similar goal
Possibly a visual diagram depicting the entire workflow

How Do You Write a User Story?
Here’s a simple, six-step process for crafting user stories:
Step 1: Decide what “done” will look like = definition of done
Step 2: Document tasks and subtasks.
Step 3: Determine your user personas.
Step 4: Create stories as ordered steps.
Step 5: Seek user feedback.
Step 6: Draft stories that can be completed in one sprint.

Product Teams, Why Wouldn’t You Write with Your Users in Mind?
Aside from the fact that they’re designed to fit on index cards and can be easily understood by anyone, one of the biggest advantages of user stories is that they can help you from getting lost in the technical details of your product’s backend or from becoming enamored with a UX you believe is elegant but that isn’t actually structured in a way your users prefer to work.

User stories help your team accomplish all of this — and build better products — by forcing you to make one simple change to your approach to development planning. Rather than writing up your plans from the product’s point of view (which features to build), user stories force you to draft each proposed idea for new functionality from the point of view of the actual people who will be using that functionality.

Tool = ProductPlan
Share your product story
ProductPlan is a roadmap platform that aligns your team so you can build what matters.


User Stories | User Stories & Epics

How to Write Epics and User Stories
Nov 16, 2018


As a product manager/owner while creating an epic include the following four things as the very basic structure.
Product requirement
Technical requirement
Design requirement

In short, your introduction can include:
summary of what the features you’re building are for and why you’re building them
what metrics you are trying to improve
links to specific documentation
marketing plans, legal requirements (if any)
early wireframes

Product requirement
An essential part of the epic where you provide with an explanation for the whole team working on it to understand what are they going to design, build, test or release. For example, if you are building a feature that the feature has to be fast or should be available in multiple languages, or should work on multiple devices like mobile, tablet and desktop should be mentioned in the product requirement section of your epic.

Design requirement
While writing the design requirement collaborate with your UX designer as much as you can. Take their input as there might be things that a designer thinks is important in order to have a better user experience which wouldn’t cross your mind. For example, a designer might think the preview should be of a certain size and the profile picture should always maintain certain resolution in order for a good experience than those kinds of requirement should be written here.

Technical requirement
Similar to the design requirement in this part of the epic try to involve the engineers or tech lead as much as possible. Their inputs in the early stage will be very useful while estimation and building it correctly. For example, the engineering team might want to build an API to integrate with some other system in order to fetch and maintain the quality of an image, those kinds of specifications and requirements should be mentioned under engineering requirements.

User Stories

User stories are basically the break down of an epic in a more user-focused way for the engineering team to understand the product requirement. In agile methodologies, everything that we build should be focused around users and hence the main purpose of the user story should be to shift the focus around a feature in a more human conversation manner.

Here is a simple template that is widely used while creating user stories:
As a (type of user), I want (some goal), so that (reason).

The point of the user story is to clearly state the feature desired from the point of view of the user.
A user story must have just the right level of detail. It should be a high-level requirement with additional detail added to the accustomed acceptance criteria.
The acceptance criteria are the clear picture for the engineering team to understand ‘what’ they are building and for the QA to clearly state the acceptance test.
The components to be included are:
User story
Acceptance Criteria
Design attached to the user story

Author = Bindiya Thakkar