Functional and non-functional requirements

1. Functional requirements
The functional requirements of a system are those that describe any activity that it must perform, in
other words, the particular behavior or function of a system or software when certain conditions are
met.

Typically, these should include functions performed by specific screens, descriptions of the workflows
to be performed by the system, and other business, compliance, security, or other requirements.

1.1. How are functional requirements described and classified?

Possible functional requirements of a system include:
• Descriptions of the data to be entered into the system.
• Descriptions of the operations to be performed by each screen.
• Description of the workflows carried out by the system.
• Description of system reports and other outputs.
• Definition of who can enter data into the system.
• How the system will comply with the sector or general regulations and regulations that apply to
it.

Like other types of software requirements, such as non- functional requirements , functional
requirements can be classified according to their purpose, such as business requirements,
requirements originating from regulatory aspects, security, among others.
Below are examples of functional requirements, classified by different areas:

Examples of functional requirements of a process or business area

• The system will send an email when any of the following transactions are recorded: customer
sales order, dispatch of merchandise to the customer, issuance of invoice to customer and
registration of customer payment.
• The registration of purchase orders with incomplete mandatory data will be allowed, which can
be completed later by modifying the order. Before the order details can be approved, they
must be complete.
• When you approve an order, the request will move to the next step of the approval workflow
configured in the system.
• The system will allow authorized users to enter project plans and schedules.
• The system will allow you to approve, change or update project plans and schedules.
• The system will allow automated sending of order delivery letters directly to the warehouse.
• Each order will be assigned a unique identifier, which will be used to identify it in all
subsequent processes carried out on it.
• When entering delivery orders, every delivery order will be associated with a sales order.

• Billing of sales orders will be done in batches, through a pending billing orders screen, which
will show uninvoiced orders. Once orders have been invoiced they will not be shown in this
list.
 • The system will also allow the registration of manual invoices not associated with orders,
however, these will require authorization from the Managers group before being posted.
• The purchasing process in the system covers the following steps and transactions: Entry of the
requisition, issuance of the quote request and issuance of the purchase order.
• The elements of the quote request will be the same as those of the associated requisition, as
well as those of the purchase order. The system will allow the issuance of quote requests and
partial purchase orders.
• The accounting of sales invoice and purchase invoice transactions can be configured to be
done automatically upon registration, or manually in batches (Batch Process).
• The software must be able to output the following financial statements: Balance Sheet, Profit
and Loss Statement, Cash Flow Statement. In addition, you must be able to issue a list of
general ledger and analytical ledger.
• Purchase orders that exceed the amounts established in the configured order release flow
must go through the approvals established in said approval flow.

Examples of graphical interface functional requirements

• The solution will automatically validate the customer associated with an order with the contact
management system.
• The amount field accepts only numerical values with two decimal places.
• The transaction date field accepts only dates before today (current day).
• The name field accepts alphabetic characters only.
• The address field accepts alphabetical, numeric, and special characters.
• The country field will consist of a preselection list. The country associated with an address
must be previously registered in the system.
• The state, province or department field will consist of a preselection list. Users will be
presented only with the states associated with the previously selected country. The
department or province to be selected must be registered in the corresponding functionality.
• The item material field on the purchase requisitions screen will be a shortlist, displaying only
the materials recorded in the material master.
• The accounting date field accepts only dates that correspond to accounting periods that are
open in the system.
• The payment registration screen can print the data on the screen to the printer.

• The name, total size, available space and format of a pen drive or flash drive connected to the
computer's USB port will be displayed.

Examples of legal or regulatory functional requirements

• The system will control access and allow it only to authorized users.
• The database will be implemented with audit trails.
• Spreadsheets secure data using electronic signatures.
• The system will allow the preparation and issuance of the XX regulatory report, according to
the requirements established in the regulations and applicable law.
 • The sales and purchase books will be issued in the format established by the tax authorities of
said matter.

Examples of security requirements

• The system will control access and allow it only to authorized users. Users must log in to the
system with a username and password.
• The system will send an alert to the system administrator when any of the following events
occur: New account registration, customer login to the system, 2 or more failed attempts to
enter the user password, and user password change.
• Members of the Analyst user group can enter requests but cannot approve or delete them.
• Members of the Manager user group can enter and approve requests, but they cannot delete
them.
• Members of the administrators user group cannot enter or approve requests, but they can
delete them.
• Any data exchange via the Internet carried out by the software will be carried out through the
https encrypted protocol.

The functional requirements must be written in such a way that the reader can understand the
operation of the system without having particular technical knowledge of its operation.

The important thing is to define a standard way to express the requirements and be consistent with it
in all documents.

Likewise, functional requirements do not necessarily have to be defined in the form of written
narratives, but diagrams or process flows can also be used, which are included in the functional
specification of the software or system to be developed.

To identify and document software functional requirements, two steps are followed. First, requirements
gathering techniques are applied, such as observation, interviews, observation, among others.

2. Non-functional requirements
2.1. Why are non-functional requirements important?

All Information Technology (IT) Services, at some point in their life cycle, need to consider non-
functional requirements and the tests associated with them.

For some projects, these requirements involve a considerable amount of work and effort, while for
others they do not.

Non-functional requirements are often ignored or underestimated in the requirements analysis phase .
The error ends up being identified in the implementation phase when remediating them involves more
work and cost, and may cause them not to be adopted by users and clients.

2.2. What are non-functional requirements?

Non-functional requirements are those that specify criteria to evaluate the operation of an information
technology service, in contrast to functional requirements that specify specific behaviors.
Functional requirements define the criteria that the software must meet for it to be suitable for its
purpose (Fitness-for-purpose), while non-functional requirements specify the criteria it must meet for it
to be suitable for its use (Fitness-for-purpose). for-use).

Other terms used for non-functional requirements can be: Constraints, Quality attributes, quality
objectives, service quality requirements.

2.2.1. Various classifications of non-functional requirements

There are various sources or frameworks to classify non-functional requirements. In fact, there is an
IEEE standard, Std 830 – 1993, that establishes 13 types of non-functional requirements that should
be included in every software specification.

Another model is the one proposed by Jacobson (1999) which is proposed for the Unified Process.

One of the most widespread models is the one established by Somerville, which we will present below.

Somerville's classification of non-functional requirements

Somerville divides non-functional requirements into three broad types: Product requirements,
organizational requirements and external requirements.

➢ Non-functional product requirements

It usually refers to limits or restrictions on the behavior of the system, so it establishes limits and
restrictions on what designers (software architects) and software engineers can do.

Some of these requirements may be easy to quantify, for example performance and reliability, but
others are more difficult, such as usability and adaptability.

Product requirements can be classified into (Sommerville):

• Usability requirements: Usability is defined as the effort a user needs to make to learn, use,
enter data and interpret the results obtained from application software. In recent times,
usability has become very important, especially given the demand for software development
for mobile phones and tablets .
• Efficiency requirements: Related to performance in terms of response time, number of
operations per second, among other measurements, as well as consumption of memory,
processor, disk space or network resources.
• Reliability requirements: Encompasses several attributes:
○ Availability: Readiness of the system to provide service correctly.
○ Reliability: Continuity of the service provided by the system.
○ Industrial safety: Absence of catastrophic consequences for the user or the
environment.
○ Integrity: Absence of inappropriate alterations to the system.
○ Maintainability: Possibility of making modifications or repairs to a process without
affecting the continuity of the service.
○ Security requirements: Functional or non-functional capabilities that a system must
have to meet attributes in the area of information technology security, data security,
logical security, information access control (access restrictions), information
authenticity , privacy, among other aspects.
Considering product requirements is vital to achieve continuous integration of applications and the
development of changes that are rapid but sustainable over time.

Examples of non-functional product requirements

❖ Efficiency
• The system must be able to process N transactions per second. This will be
measured through the SoapUI tool applied to Software Testing of web services .
• All system functionality and business transactions must respond to the user in less
than 5 seconds.

• The system must be able to operate adequately with up to 100,000 users with
concurrent sessions.

• Modified data in the database must be updated for all accessing users in less than 2
seconds.

❖ Logical and data security

• System access permissions can only be changed by the data access administrator.
• The new system must be developed by applying programming patterns and
recommendations that increase data security .
• All systems should be backed up every 24 hours. Backups must be stored in a secure
location located in a different building than where the system resides.
• All external communications between data servers, application and system client must
be encrypted using the RSA algorithm.
• If security attacks or system breaches are identified, it will not continue operating until
unlocked by a security administrator.

❖ Industrial safety
• The system will not continue operating if the external temperature is less than 4
degrees Celsius.
• The system will not continue operating in the event of fire. (Ex. An elevator).

❖ Usability
• The system learning time for a user must be less than 4 hours.
• The rate of errors committed by the user must be less than 1% of the total
transactions executed in the system.
• The system must have properly structured user manuals.
• The system must provide error messages that are informative and oriented to the end
user.
• The system must have an online help module.
• The web application must have a “Responsive” design in order to guarantee adequate
viewing on multiple personal computers, tablet devices and smartphones.
• The system must have well-formed graphical interfaces.

❖ Reliability
• The system must be available 99.99% of the time a user attempts to access it.
 • The time to start or restart the system cannot be more than 5 minutes.
• The system failure time rate may not be greater than 0.5% of the total operating time.
• The average duration of failures may not be greater than 15 minutes.
• The probability of failure of the System may not be greater than 0.05.

➢ Non-functional organizational requirements

They are derived from the organization's policies and procedures, such as process standards or
implementation requirements.

They may include software development methodologies, programming (coding) standards and
software development support tools (e.g. CASE Tools) that must be used (following the organization's
policies), also reports to management that must be provided, among others.

The tools for software development management that we know are defined as non-functional
organizational requirements.

Organizational requirements can be classified into (Sommerville):

• Environment requirements: They describe the operating environment in which the system
must operate.
• Operational requirements: Operating procedures that describe how the system will be used
within the context of the organization.
• Development requirements: Programming language to use, coding standards, design and
programming patterns (and anti-patterns), tools to manage software development, software
development environment (development environment), software testing environment
(environment testing), among other aspects.

One of the aspects that are documented as organizational functional requirements are the
environment, specifically the maintenance and administration procedures of the software development
environment.

This administration also includes procedures for managing end-to-end test environments.
Examples of organizational non-functional requirements

• The software development procedure to be used must be explicitly defined (in procedure
manuals) and must comply with ISO 9000 standards.
• The software development methodology will be Behavior Driven Development (BDD)
supported by Cucumber .
• The system must be developed using CASE XYZ tools.
• The development process will be managed through a certain web tool to manage the software
development process .
• A disaster recovery plan must be specified for the system to be developed.
• Every two weeks, management reports must be produced showing the effort invested in each
of the components of the new system.
• Software testing will be managed with a software testing management tool .
• Software tests will be executed using Selenium and Ruby as a tool and scripting language for
software testing automation.
 ➢ External non-functional requirements
These derive from the organizational environment (not technical environment) in which the system is
developed and can be done either on the product (the developed software) or also on the software
development process.

These types of requirements include economic limitations, such as the budget of the software project ,
interaction or need for the system to interoperate with other systems, regulatory requirements in the
area of health, industrial safety or data protection, legal requirements. concerning licenses, regulations
or certifications that the product needs depending on the industry in which it operates, among others.

Somerville in turn classifies these requirements into:

• Regulatory requirements: Laws and regulations that establish what the system must do and
how it must do it to comply with them. The focus of a system or new functionality may be
exclusively to comply with a regulation.
• Ethical requirements: Requirements that ensure that the system will be acceptable to the
user, the general public, and adapts to the customs of the society in which it operates or to
which it provides services.
• Legislative requirements: Characteristics that the system must meet to comply with the law,
for example in the area of accounting (accounting standards and financial standards),
industrial security requirements (for critical systems), among other aspects.

Examples of external non-functional requirements

• Medical data systems: The new system and its data maintenance procedures must comply
with medical data protection laws and regulations.
• The new system will follow the rules of general public licenses (GNU), that is, it will be free,
open source in which anyone can change the software, without patents and without
guarantees.
• The web pages to be developed must comply with the law on equal treatment for people with
disabilities.
• The system will not reveal to its operators other personal data of clients other than names and
reference numbers.
Some final considerations:

Non-functional requirements are usually expressed in a general way and without reference to any
module, transaction or characteristic of the system, otherwise they would become functional
requirements . For example:
“The system must ensure that data is protected from unauthorized access.”
It is advisable to accompany the definitions of non-functional requirements with acceptance criteria
that can be measured.
Non-functional requirements can in turn lead to functional requirements. Taking the previous one as
an example:
“The system will include a user authorization procedure, in which users must
identify yourself using a username and password. Only users authorized in this way
They will be able to access system data.”
Written this way, the requirement becomes functional.
However, not all non-functional requirements can be derived into functional requirements, which is
why it is very important to define acceptance criteria.

Source : PMOinformatica.com