Imagine a trivial developing process: a simple idea, simple implementation. The developer evaluates the requirements of the customer and declares that he will cope with the task in such and such a time frame with such and such a budget … and gets to work. But suddenly things don’t go according to plan. Deadlines are missed, budgets are wasted, both sides are nervous, and finally all this leads to the failure of the project. How did it happen?
Many projects fail even before they start, but both the developer and the customer may not even be aware of this. It’s all about the wrong writing of functional requirements and non functional requirements This is what causes most development project failures (60-70% according to sundry sources). Below we talk about what exactly they are in practice, what’s the main difference between functional and non functional requirements (with examples and also learn how to word them correctly in order to avoid unforeseen waste of time and money.
The Concept of Functional and Non Functional Requirements
By functional requirements, we mean the actual functions of the software product. That is those features of the software or its individual components that are necessary for the user to complete the tasks. Any function of any program fits into a simple scheme: data input → system response → data output. This includes any calculations, starting or stopping business processes, interacting with users, automating management control systems, interface (response to pressing a certain button), and much more.
Simply put, functional requirements are WHAT the system must be able to do.
Non functional requirements definition is HOW the system should work in certain situations. For example, how fast the program processes data or how many users can simultaneously work in the system.
Non-functional requirements improve usability but do not define the capabilities of the software. At the same time, nonfunctional requirements may relate not only to the software system itself: some may relate to the technological process of creating software, and others contain a list of quality standards imposed on the development process. In addition, the non functional requirements template may state that system design should only be performed by certain CASE tools, and describe the design process to be followed.
Some argue that meeting non functional requirements is not necessary for the program to work correctly, but it is desirable. Based on this, it can be assumed that non functional requirements in software engineering are not as important as functional ones. This is true, but only if your software has no analogs at all. Otherwise, you will just look for a more convenient option. In addition, there is another reason to take a closer look at non functional requirements. And we will talk about it now.
The Blurred Line Between Functional and Non Functional Requirements?
So, we have already understood what is the difference between functional and non functional requirements. However, is it always so obvious? For example, you would most likely classify system security requirements as non functional because security is not a function of the software. However, to ensure security, the developer needs to prescribe the functionality of user authentication, assigning roles and access to them. All this will be implemented in the form of functions that users will have to work with.
Another example is the interface, which we referred to as functional requirements above. You may have noticed the note in brackets, which says that the function itself is implemented here as a button, and the requirement is put forward for the program’s response to pressing it. At the same time, the external interface is often referred to as a non functional requirement, because in itself it is not a function, and only affects the usability of the program.
That is, the line between functional and non functional requirements is clear in some cases and blurred in others. This is the second reason why non functional requirements should be taken as seriously as possible.
To put an end to this issue, we propose to consider a generalized classification of function and non function in order to better understand their essence.
So, Types of Functional Requirements:
- Business Requirements for software. These are the requirements that define the business goals and what functions the program should have in order to achieve these goals;
- User Requirements. User requirements definition is the goals of specific users and a set of tools to achieve them when working with the program;
- Functional Requirements. Define the very “system response” (the second step in the function scheme described above), the correctness of which will allow users to perform tasks using the developed program.
Non Functional Requirements List:
- Business Rules are corporate policies, accounting practices, internal regulations, as well as any external rules, such as legislation, that the software must comply with;
- External Interfaces are customary to refer to non functional requirements because the interface does not directly affect the functionality of the software;
- Quality Attributes are requirements for the characteristics of a software product, which determine the possibility of porting, scalability, capacity, reliability, etc;
- Constraints – a list of conditions aimed at reducing the number of program scenarios to optimize resource costs.
How to Prepare Functional and Non Functional Requirements?
Most often, the functional requirements of a system are submitted by the customer in the form of a text description, which describes in detail what and how the system should do under certain conditions and to achieve certain goals. However, this is far from the only and perhaps not the most demonstrative way to convey to the performer what you want from the software.
Infographics
Usually, the form of diagrams and models is chosen. When forming the requirements for the project, you must be aware of the importance of their clarity for the contractor. Diagrams and models can often be more descriptive than long text descriptions. In addition, they allow you to quickly and simply explain how processes should work inside the system.
Use Cases
Use cases are one of the most common (after textual descriptions) ways to form requirements. Use cases can also be designed as text or infographics, but their main difference and feature are that the requirements are described from the point of view of the end user of the software product. This option is often used because it allows you to describe the requirement in detail without having special technical knowledge.
Use cases contain three required components:
- System user (Actor)
- The system and its “responses” under a certain scenario (System)
- The goal of the user working in the program (Goal).
Use Stories
A more complex version of use cases. These show not only what your software must do from a particular user’s point of view, but also specify the acceptance criteria. For example, when a system administrator sets up access rights for a new employee, that employee should receive an email.
Prototypes
A kind of demo of the program or its components, which clearly demonstrates how certain program functions should work. A properly working prototype can later become an MVP (minimum viable product).
Functional decomposition
Also known as Work Breakdown Structure (WBS). It is a way of formulating requirements by breaking down a complex process into several simple functions. That is, to explain how this or that complex process should work, we consider its stages separately, and put them together like a puzzle to understand the big picture.
On a Final Note: Requirement Documentation in Software Engineering
Thus, the proper formulation of requirements can be the solid foundation on which a successful developing process will be built. The functional requirement analysis in software engineering is a really important stage. It is necessary to document the list of functional requirements and non functional requirements correctly, as this will allow you to clearly outline the scope of the budget and implementation deadlines, convey to the contractor all your wishes regarding the final result and carefully work out all the points before starting work, as well as minimize risks.
It is also appropriate to clarify here that documentation is only one of the stages of working with requirements. It is preceded by the collection and analysis of requirements, for which special working groups are involved (they include users, developers, architects, testers, support engineers, and other employees of the customer and contractor involved in the development). However, in practice, these processes often go hand in hand.