1. Introduction
We can see computer science as the art of solving real-world problems through computations. So, one of the relevant abilities of a computer scientist, or a software developer in a broad sense, is abstracting the real world into computing models able to solve particular problems.
Abstract models, in turn, are built based on a series of requirements defined together with the stakeholders of the on-development software. These requirements define the desired relation between inputs and outputs, determining calculation processes to the expectations of the final product quality.
In this tutorial, we’ll study requirements in software development. First, we’ll check the definition of requirements as well as their categories. Thus, we’ll understand what functional and non-functional requirements are in detail. Next, we’ll see some techniques employed to define requirements. Finally, we’ll review the studied concepts while comparing them in a systematic summary.
2. Requirements
In short, according to the famous Business Analysis Body of Knowledge (BABOK), a requirement is a representation of a need. So, in a software development context, we see requirements as a set of demands that a software product must carry out.
However, requirements fit into several contexts and have multiple categories. The most relevant of them are:
- Business: consist of high-level statements about problems and objectives of an organization, such as increasing the revenue or cutting expenditures
- Stakeholder: refer to the expectation of a selected stakeholder group (such as the final users or the organization executives) about a product. It connects the business requirements to solution ones
- Solution: determine particular characteristics that a product must have, both in functional (what it actually does) and non-functional (what are the general properties of the product) terms
- Transition: specify actions for the stakeholders to migrate from their current scenario to a scenario adopting the developed product, such as the need or not of specific training to operate it
In the context of this tutorial, we’ll focus on investigating the category of solution requirements by exploring functional and non-functional classes of them.
3. Functional Requirements
Functional requirements are the features implemented by the programming team while developing a software product. More tangibly, we can see functional requirements as the calculations done by a software solution and the ways it consumes, processes, and generates data: they describe what software does.
Defining functional requirements is a mandatory stage of the software development process. Such requirements usually come from use cases established by the future operators of the on-development solution. So, the development team analyzes these cases, mapping them to software features and determining the necessary implementation technologies.
There are several categories of functional requirements. Among them, it is relevant to highlight the following categories:
- Authentication: regards to the manners to identify an operator, or even information, in the developed solutions and systems
- Authorization Levels: relates to the heterogeneous privileges and restrictions applied to the operators. For example, it specifies who can execute CRUD (Change, Read, Update, or Delete) operations on the solution
- External Interfaces: concerns with the external interfaces of a solution that enable its communication with other solutions, systems, and users
- Transaction Processing: regards ways to analyze and operate with transactions, such as entering, modifying, deleting, and canceling
- Compliance: related to the laws, regulations, and policies that the organization on which the software solution will work must follow
- Database: refers to the data to be stored and the formatting rules to do that
Of course, there are other categories of functional requirements, such as backup, recovery, audit, archiving, etc. However, they are employed in systems with particular characteristics that demand them. By the way, there is no absolutely mandatory functional requirement category; we should define them according to the necessities of each software project.
4. Non-functional Requirements
In summary, non-functional requirements refer to attributes and properties representing quality expectations regarding a software solution. The set of non-functional requirements highly depends on the particular execution scenarios to which the software is submitted.
Specifying non-functional requirements is not a mandatory task at all. We can develop software through only a set of functional requirements. However, the software solution will work in a best-effort model without considering any performance parameter expectation.
But to which parameters do we refer when we talk about performance expectations?
There are multiple parameters we can consider. These parameters are related to different non-functional requirements categories. Thus, let’s examine the most usual categories and their parameters:
- Usability: regards how sharp the learning curve to use the software is. This category includes parameters such as perceived workload, efficiency of use, and intuitiveness
- Security: relates to how a software solution protects data. Parameters of this category encompass permission policies, robustness, and resiliency during attack situations
- Reliability: concerns with how the software solution avoids and tackle fails. An example parameter is a maximum probability that we admit to a failure happening in a component given an execution time
- Performance: regards the responsiveness of software while users interact with it. The most common example of a parameter in such a case is the maximum admitted response time for each operation requested
- Availability: concerns with the total time that a software solution is available for use. Parameters are the maximum maintenance time and maximum time for recovering potential error scenarios
- Scalability: related to the increasing or decreasing software capabilities without affecting their performance. Defining a minimum and a maximum number of supported users is an example of a scalability parameter
Finally, we define non-functional requirements on-demand. So, we do not have a minimum or maximum set of categories and parameters.
5. Requirements Specification Strategies
We specify software solution requirements in a document called Software Requirement Specification (SRS). The SRS can include both functional and non-functional requirements and will work as a guide to the development team.
We can write SRS documents based only on plain text or even employ extra resources, such as use case diagrams and user stories. Anyway, the most relevant about an SRS is that it should be accessible and interpretable by all the people involved in the software development, from the future users to the technical team.
An SRS document must have at least three sections:
- Purpose, including a generic outline of the desired software solution as well as any background information and previous definitions
- Description, presenting assumptions, constraints, and policies adopted by the system
- Requirements, containing the specification of functional and non-functional requirements and details about them
Let’s briefly see some popular resources used in SRS documents for describing software and its requirements in the following subsections.
5.1. Use Case Diagrams
A use case diagram is tailored to determine the interactions of a software solution with its operators and administrators. We have three main entities in these diagrams:
- Actor: the representation of operators and administrators of the software solution
- System: the characterization of functional requirements as the expected behaviors of the software solution
- Goal: the description of the purposes of an actor interacting with a system
The most common presentation of a use case diagram is on a figure which defines associations between the previously presented entities. The following figure shows an example of such a diagram:
5.2. User Stories
A user story also aims to determine the desired software solution. However, it focuses on the end-user perspective, defining what they want to execute and which data they have to access in the solution.
A user story consists of free text, but they usually consider formatting as presented next:
I, as a <type of user>, aim to <goal> so that <reason>.
Furthermore, each user story may be associated with an acceptance criteria list, which presents the stakeholders’ required characteristics for implementing the user story in a software solution. Acceptance criteria are also defined as free text; the best acceptance criteria lists are very concise and testable, working as a checklist for the developers.
6. Systematic Summary
Functional and non-functional requirements represent essential resources for any software development team. Functional requirements determine all the necessary features, while non-functional requirements provide performance parameters of how such features must work in the software solution.
Taking into account the previous definition, we can say that defining functional requirements is a mandatory process. On the other hand, the non-functional requirements definition is optional but highly recommended to guarantee the quality of the final product.
As we saw throughout this tutorial, we have different functional and non-functional requirements categories, each with distinct purposes and objectives. A large software project may include requirements from all categories, but ordinary ones typically define only a subset.
The table next summarizes and compares some relevant characteristics of functional and non-functional requirements:
7. Conclusion
In this tutorial, we studied functional and non-functional requirements. Initially, we briefly reviewed general concepts regarding requirements to investigate functional and non-functional ones particularly. So, we saw some techniques to create requirement documents. Finally, we outlined the main characteristics of functional and non-functional requirements and compared them in a systematic summary.
We can state that requirements are crucial resources for designing software products and guiding their development. So, analysts and developers must employ time to define and interpret requirements, thus getting the best final product possible which covers all the stakeholders’ technical necessities.