Functional Vs Non-functional Requirements

Functional and non-functional requirements definition is the key for an organization or a business that is accountable for designing the future applications using information technology. 

What is a functional requirement?

In software engineering, a functional requirement describes system behavior and defines the function of a system or its component. It defines how a system or its component functions.

Functional requirements include a system’s functional and technical details, processes and other functionality of the system that describes what a system is expected to perform and how it is supposed to accomplish. Functional requirements also state specific outcomes of a system, as described in requirements engineering. 

Functional requirements are captured in use cases and reinforced by non-functional requirements. In most of the cases, a Requirement or a Business Analyst collects and validates the functional requirements before creating the use cases. One or more functional requirements are demonstrated with the help of a use case. 

• Functional requirements explain the functionality of a system or a product.
• Dependent on the type of system or the product and the expected users.
• Functional user and system requirements are the high-level statements to explain what a system must do and describe the system in detail.

Types of Functional Requirements

• Business Rules
• Transaction Corrections, Adjustments and Cancellations Requirements
• Authentication Functions
• Authorization Levels
• Audit Tracking
• External Interfaces Requirements
• Certification Requirements
• Searching/Reporting Requirements
• Historical Data
• Archiving Requirements
• Compliance, Legal or Regulatory Requirements
• Database Requirements
• Backup and Recovery Requirements

Capturing Functional Requirements

Functional requirements are captured in various formats and documents that include:

• Software Requirement Specification

Functional requirements can be captured in a Software Requirement Specification (SRS). The Software Requirement Specification (SRS) consists of the description of features and functions of a system or a product. The Software Requirement Specification (SRS) can be an only specification that contains the complete functional requirements or it can be represented as a supportive document for the documentations such as Use Cases and User Stories. An SRS (Software Requirement Specification) consists of various sections that include:

• Purpose of a system or a product to be developed
• Description of the system or product
• Features and functionality of the system
• External interfaces such as software, hardware or other applications to interact with
• Design constraints and the environmental limitations in which the system will operate

An SRS (Software Requirement Specification) template consists of the following parameters:

• Introduction
• Objective
• Intended Audience
• Scope
• Overall Description
• User Needs
• Assumptions and Dependencies
• Functional Requirements
• Non-functional Requirements
• External Interface Requirements
• System Features

• Use Cases

A Use Case states the interaction between a system and various actors to achieve specific objective. A Use Case consists of three major parameters:

• System

A system consists of several use cases in it surrounded by a system boundary.

• Actor

An Actor is a user who interacts with the system.

• Goal

The goal is a use case with respect to the system and it defines how a system can benefit an organization.

A Use Case can be represented by two formats that include:

• Use Case Diagram

A Use Case diagram usually represents a relationship between a user and different use cases. A Use Case diagram identifies multiple users that interact with the system. In a Use Case diagram, a use case is represented by an ellipse and the system is represented by a system boundary that consists of all use cases. A Use Case diagram consists of 4 major elements that include:

• Use Case

A use case is represent by an oval or an ellipse in a system.

• Actor

An actor is represented by a figure that interacts with the system.

• System Boundary

A system boundary is an outlined box that consists of various use cases in a system.

• Association

An association is represented by a line showing different relationships between an actor and a use case. 

• Use Case Specification

A Use Case specification is basically written in textual format and represents the sequence of events corresponding to the use case. A use case specification consists of the following elements:

• Use Case Name

This element defines the use case name and a brief description of the use case that describes the use case purpose.

• Events Flow

This element represents the flow of events and it starts when an actor initiates something. In this flow of events, the use case describes the action initiated by an actor and the response by the system. This is called a dialogue between an actor and the system.

• Pre-condition

A pre-condition is a state of a system that a system must satisfy before performing a use case.

• Post-condition

A post-condition is a state of a system that a system will acquire post performing a use case.

• User Stories

A User Story describes a system or a product feature from an end user perspective. In Agile, user stories are arranged in an ordered list in project backlog. The format of a User Story is as follows:

AS A “Type of User” I WANT TO “Perform an Action” SO THAT “Achieve an Objective”.

For example, AS A Registered User I WANT TO Login to the application SO THAT I can access all features of the application.

A User Story is complete only when it is accompanied by an Acceptance Criteria. An Acceptance Criteria is a condition that a system or a product must satisfy for user acceptance. An Acceptance criteria has always to be attached with a User Story to make it meaningful and useful. The format of an Acceptance Criteria is as follows:

Verify that “Condition”.

For example, Verify that the user has valid login credentials to login to the application.

• Work Breakdown Structure

Work Breakdown Structure is a visual documentation of functional requirements. A Work Breakdown Structure elaborates on how a complex process can be broken down into simple pieces of information or sections. Work Breakdown Structure is also referred to as functional decomposition in which a function is decomposed in a sub function and a sub function is again decomposed to the next level. The functions are decomposed to a level from where they cannot be decomposed any further.

For example;

“Registration” can be broken down into:

• Fill Information
• Submit

• Design Documents

Design Documents are the visual representation of a system or a product. There are various types of design documents that include:

• Wireframes

A wireframe is a blueprint of a system or an application that is being implemented and gives a clear picture of overall structure of the system or application to various teams such as Design, Development etc. Wireframes are created before the visual designs are created and any code is written. Wireframes give an idea of how the visual designs of a system or an application will look like.

Creating wireframes is less time consuming and they are mostly black and white. Wireframes give a rough feel of the real designs and ensure the users that these have scope of improvement and users can freely give their feedback for any changes.

• Mockups

Mockups are the prototypes that are created when the wireframes are ready. Wireframes are converted into the mockups that provide the look and feel of the visual design of the system or application to be developed.

• Design Prototypes

Once the mockups are ready, they are converted into the visual designs by incorporating the interface interactions. The design prototypes allow the user to interact with the visuals and navigate through the designs.

What is a non-functional Requirement?

In software engineering a non-functional requirement is a requirement that specifies a basis or measure to determine a system’s performance or its function. Non-functional requirements are generally referred to as the “quality attributes” of a system. Non-functional requirements are the standard to evaluate a system’s functioning and make sure that the system possesses specific “quality attributes” in order to accomplish non-functional requirements. Non-functional requirements that is the quality attributes or qualities are divided into two categories that include:

• Execution Qualities such as:
  • Safety
  • Security
  • Usability

• Evolution Qualities such as:
  • Testability
  • Maintainability
  • Extensibility
  • Scalability

If non-functional requirements are not defined properly, the system might become useless.

Types of Non-functional Requirements

1. Product Requirements

Product requirements specify how a system or a product must behave in a particular way in order to satisfy system characteristic. Product requirements include the following requirements:

• Usability Requirements

Usability refers to how useful the system will be for a user and how will he learn and operate the system. 

• Security Requirements

Security requirements make sure that the system is accessed only by the authorized users who are given access to the system and its data. Authorization has different levels of authentication for different user roles. Different users have different access permission to view/edit/delete data and more.

• Reliability

Reliability ensures that a system or a product is going to work for how much time without any fail. The major issues that reduce the reliability of a system include:

• Hardware Failure
• Issues with the Code

• Availability

Availability refers to the duration for which the system is available to use with all its features and functionality in fully operational state. One of the most important parameters that impacts the availability of a system or a product is scheduled maintenance. By understanding the impact of scheduled maintenance in advance, the impact of it can be reduced to some extent.

• Efficiency Requirements

• Performance Requirements

Performance is an attribute that is measured in terms of the system’s reaction to multiple user interactions. Performance is directly proportional to the user experience. Weak performance always leads to a bad user experience and better performance leads to a good user experience.

• Scalability

Scalability requirements define a system’s progress with time whenever it’s needed. For example, more users, memory and servers can be added to process more data and transactions.

2. Organizational Requirements

Organizational requirements are a sequence of organization’s procedures and policies such as implementation requirements, process standards etc. Organizational requirements include the following requirements:

• Environmental Requirements
• Operational Requirements
• Development Requirements

• External Requirements

External requirements are the requirements that emerge from the factors external to the system such as ethical requirements, legislative requirements and regulatory requirements.

Capturing Non-functional Requirements

Non-functional requirements are captured in an SRS (Software Requirement Specification) along with the functional requirements. Non-functional requirements can also be captured as backlog item in user stories. These requirements can be made visible by creating an independent backlog items list.

For example; AS AN Online Shopper I WANT the website to be available 99% times I access it SO THAT I can buy my products online without redirecting to other portal.

Non-functional requirements can also be made available by adding those to the Acceptance Criteria of the user stories. A user story consists of multiple acceptance criteria and that can include non-functional requirements.

For example; Verify that the system shows transactions that meet the search parameter in 10 seconds.

Comparison between Functional and Non-functional Requirements

Recommendations to Document a Non-functional Requirement:

• Make the requirements testable and measurable
• Put the requirements for system components instead of setting them up for the whole system
• Appraise architectural and third party limitations
• Associate the requirements with business goals