Functional Requirements and their levels of granularity

1. Introduction

User requirements for a software solution consist of two subsets: functional and non-functional ^[1]. Functional requirement (FR) concern the results of behaviour that shall be provided by a function of a system (or component or service) ^[2], ^[3]. They specify what the software shall do in terms of tasks and services for its users and may include: data transfer, data transformation, data storage and data retrieval ^[1]. These types of requirements are related to what the software should do for its users. FR refers to the software’s intended behaviour while responding to external events or causing an external event to happen. Non-functional requirements (NFR) are related to how software functions are delivered to users ^[4], and may include quality, technical, environmental and organizational constraints ^{[1] [2]}.

If we consider a system for an ATM, then the following might be examples of the two types of requirements:

• FR: The system shall query current account balance (what)
• NFR: The system shall guarantee that every transaction should be completed within a maximum of 30 seconds (how)

Although not a rule, a FR is usually of a specific nature in the software: it is possible to indicate in what part of the software the behaviour is to be found. A NFR, on the other hand, is usually of a general nature: it applies to all, or almost all, of the software.

For requirements engineering both types are equally relevant: both must be elicited, analysed, specified, modelled and managed. There are, however, some differences between these types of requirements that it is worth commenting on individually. The topic of NFR is out of scope for this article; for an extensive discussion on this subject refer to ^[12]. Here the focus will be just on FR, with the aim of presenting their levels of granularity and why this is important in requirements engineering work. It is important to notice that other authors may use terms such as “levels of abstractions”, “levels of details”, “levels of refinement”, “tier”, “view”, or even “types”.

2. Levels of Granularity

Continuing with the example of an ATM system, the following descriptions might be found in its requirements specification:

1. The system shall carry out transactions on the current account.
2. The system shall transfer a sum from one current account to another current account.
3. The system shall validate the customer’s card and password.
4. The system shall ensure that the total sum of customer transactions in a day is no greater than $5000.

Although these four examples are valid instances of FR, it is noticeable that the level of detail (or granularity) varies amongst them. The first requirement aims to span the expected behaviour through a yet unknown number of external events related to an also unknown number of user decisions. The second requirement seems to correspond to a unique external event related to a single user decision. The third and fourth examples don’t relate to a user decision at all. It is most often the case that a specification presents requirements at different levels of granularity.

The level of granularity is the greater or lesser extent in the description of the expected behaviour of the software in a functional specification. This relates to the type of goal associated with the requirement. The idea of classifying requirements per this criterion has already been proposed by various authors, some of which are referenced below.

The RAM model was proposed by ^[5] and presents fours levels of classification for requirements, and is applicable to both functional and non-functional requirements.

• Product Level: directly associated with the product strategy, or indirectly with the strategy of the organization.
• Feature Level: represents features provided by the product, without entering into the detail of the functions required to support a feature.
• Function Level: is a level of description associated with the actions that can be performed by a user.
• Component Level: is a level of description that is very near to the limit of design information; how a requirement will be solved.

The CREWS RE process ^[6] recognises three levels of abstraction for a requirement chunk:

• Contextual level: identifies the services that a system should provide to an organisation and their rationale.
• Functional level: focuses on the interactions between the system and its users to achieve the needed services.
• Physical level: deals with the actual performance of the interactions.

Another criterion widely used in projects with an agile focus classifies user stories as follows ^[7]:

• Story: describes functionality that will be valuable to either a user or purchaser of a system or software.
• Theme: is a label that groups various stories related to the same topic.
• Epic: is a large story that cannot be developed within a single iteration.

Another related concept is that of task, which is the decomposition of a story into the work packages required for its delivery. However, although this is a sub-division of a story, it is not a software requirement. In this case a task relates to the work of the development team, rather than to the work of a user supported by the software.

Although the classification relating to stories is very simple and practical for the purposes of the management and planning of delivery iterations, the classification criterion requires knowing how much effort will be involved in the implementation of the requirement, something which is not generally under the control of a requirements engineer.

^[8] presents three levels of goals for use cases, as illustrated in Figure 1:

• Summary: is a high-level requirement, for example related to a business process.
• User: is a requirement relating to a task provided by the software for a specific user.
• Sub-function: is a requirement relating to steps or rules of user tasks.

In this article the purpose of discussing the level of granularity is so that the requirements engineer, in paying attention to this topic, can carry out elicitation activities more effectively and develop a higher quality specification.

To achieve this, the idea is to use a level of granularity that represents the best reference for an unambiguous definition of software scope. All requirements at a higher level than this could mean that elicitation work is still pending. And all requirements at a lower level than this reference point could imply a waste of effort during requirements engineering or a potential opportunity to improve the organization of the specification.

For this purpose, therefore, only three levels of granularity are required, and in this case the proposal from ^[9] will be used to develop the idea in this article, generalising its original application to use cases for all types of functional requirement specification. In the following sections these levels are explained in detail.

3. Summary Goal

Requirements at this level group various user goal requirements within a single, higher level specification. The higher the level, the more general the goal, and to achieve such higher-level goals, other lower level goals must first be achieved. In this article the term goal is used in the sense of the user’s goal when using the software.

This type of requirement relates to more general goals whose extent is associated with collaborative goals or high-level business processes. They do not relate to a single task, but rather aggregate a set of tasks of one or more users. This is the granularity of example 1 (“The system shall carry out transactions on the current account.”).

What are the tasks associated with this type of requirement? Maybe these are obvious to the readers of the specification (the stakeholders), or perhaps they are still not known? It is known, however, that there are activities to be performed to elicit (refine) this type of requirement. What is important is that it is clear that the requirement is in scope for the software to be developed.

Some FR of this type, however, have templates (or patterns) which eliminate the need to provide more details. These patterns already provide the information necessary to clearly articulate which specific user tasks are meant and what is its intended behaviour. In this case, there is no need to specify each task as a separated requirement.

A classic example is a CRUD form (Create, Read, Update, and Delete) for user-maintained data in the software. It is very common for a software to have several forms like this. In that case, only one requirement for the CRUD form must be specified at the summary level. There is a tacit agreement among the stakeholders about what tasks this kind of requirement summarises. It is therefore not necessary to detail the requirement to a lower level of granularity; it is clear to all readers that the software should allow the user to perform the following tasks: add, modify, delete and inquiry product data. And no additional details are necessary.

4. User Goal

A requirement with a user goal is a FR that:

• Covers a single task under the responsibility of a single user
• Is carried out as soon as the user has all that he/she needs to complete the task within the limits of his responsibility.

At the end of the task the user achieves his aim, is satisfied and is not required to do anything further. Once the requirement has been completed, everything that should be done to deal with an external event has been done. Such a task is almost always part of a business process that has a broader workflow which might not yet be complete. However, in this case the relevant perspective is not that of the business process, but that of the task.

In general, if a job involves more than one individual it is because more than one task is present in the context. There are exceptions, such as a withdrawal from a current account in a bank branch where two individuals participate: the cashier who requests and provides data for the withdrawal, and the client who provides the pin password. In this case, there are two actors performing steps in the same task: make a withdrawal.

This is the granularity of example 2 “The system shall transfer a sum from one current account to another current account”. It is a single task (consisting, for sure, of various steps and rules) under the responsibility of a single individual who, at the end of all steps, will be satisfied with the achieved goal: a sum transferred to another current account.

5. Sub-function goal

These requirements are pieces of user goal requirements; they relate to a set of steps or rules from one or more user tasks.

A requirement at the level of sub-function that represents a set of steps describes the data exchange in both directions between the user and the software, and between the software and the storage requirements. This is the case of example 3: “The system shall validate the customer’s card and password”. Many types of current account transactions (e.g. withdrawal, transfer, payment, etc.) require the same set of steps described in example 3, which might be as follows:

• Verify that the card is valid.
• Verify that the selected transaction is compatible with the card type.
• Verify that the password provided is correct.
• Increment the password error count if the password provided is incorrect.
• Reset the password error count to zero if the password provided is correct.

Validating the customer’s card and password is not the customer’s goal in using the ATM, however they are necessary intermediate steps to achieve his goal: for example, making a withdrawal.

Requirements at the level of sub-function that relate to rules are in general linked to the policies which govern the business and describes in a complementary way the business processes. These are also known as business rules, and can describe, for example, corporate policies, government regulations or industry standards with which the software must comply.

This is the case of example 4: “The system shall ensure that the total sum of customer transactions in a day is no greater than $5000”. Business rules are often shared amongst various FR, and even amongst different software products in an organization.

6. Why is it important to pay attention to the level of granularity of functional requirements?

For a quick answer, specifying at a lower level of granularity demands more effort and time. And detailing requirements beyond what is needed is a waste of effort. On the other hand, specifying at a higher level of granularity when more detail is in fact needed may not permit appropriate decisions to be taken on scope.

In a somewhat simplified overview we could say that there are two key moments where a requirements specification is necessary:

1. Provide a broad vision of the software (and maybe not yet detailed)
2. Provide a detailed vision of the software (of one part or all)

Case A is very common during early project phases. The goal at this moment is firstly to achieve a broad vision of scope, for example to plan the project, provide a rough order of magnitude estimate of costs or duration, or perform a feasibility analysis. A vision document is an example of a document which fulfils this goal. Specifying FR at the summary level is sufficient and most appropriate in this case. The costs of obtaining information and specifying at a lower level of granularity could represent a waste of effort in detailing what is not yet required.

A requirements document for goal A will therefore have most FR specified at the summary level. It is also possible that there will be specifications at the user or sub-function level: this is not an error. It may at times be appropriate to specify the more critical FR (not all or the majority) at a more detailed level, whether this is to make the scope more comprehensible to stakeholders or to permit an estimation with less uncertainty where necessary.

The principal aim of specifying requirements at the summary level is to establish process areas which are subject to automation by the software so that business needs are met.

If the goal of the specification is to provide a detailed view of part or all of the software, for example to start development, the presence of FR at the summary level could indicate that various scope decisions are still pending. That is, that there is requirements work still to be done.

For goal B, the most appropriate level of granularity is that of user goal, as this is the only level that provides an unambiguous definition of the software scope ^[9], ^[5]; there are no doubts about what is covered. This is also the only level of process description that can be standardized and consequently it is the level used by all functional size measurement (FSM) methods adhering to the ISO/IEC 14143 standard.

FSM methods are used for several purposes, mainly for software estimations. One key concept of a FSM method is to define what a function is (which is in fact a FR at user goal level). The two currently most widely used FSM methods define this as follows:

• The IFPUG method ^[10] defines a FR at this level as an elementary process: the smallest unit of activity whose completion is meaningful to users. This is also known as a transaction.
• The COSMIC method ^[9] defines a FR at this level as a functional process: a set of data movements that represents a fundamental part of the FR for the software under analysis, that is unique within the set of FR and that can be defined independently of every other functional process. Or, in a less formal definition: a unique function that permits a user to move data to or from the software.

Consequently, for goal B requirements documents often contain most FR specified at user goal level. FR at the summary level may only be present when the tasks covered by the FR are clear to all stakeholders.

The definition of a requirement at the sub-function level is appropriate when the specified behaviour is common and shared amongst various tasks that the software delivers to its users. This makes the modification of requirements specifications in response to change easier, as the information redundancy is reduced in not having to describe a set of steps or rules more than once. It also helps in achieving greater consistency in the specification.

7. Conclusion

Though the concept of granularity levels for functional requirements is quite simple, in practice it is noticeable that many requirements engineers do not pay attention to this when producing specifications. Taking levels of granularity into consideration helps to define the appropriate effort to be dedicated to the tasks of elicitation and analysis, as well as to achieve a higher quality requirements specification.

The IEEE 830 standard ^[11] presents the following criteria for evaluating the quality of a requirements specification: correct, unambiguous, complete, consistent, modifiable, prioritised, verifiable, traceable.

When the aim of the specification is to provide a detailed view of scope, paying attention to the level of granularity of FR allows:

• Identifying when the specification is not complete, when summary FR are present or when sub-function FR are not related to higher granularity FR
• Expressing scope without any ambiguity with respect to the tasks that the software will deliver, when FR are focused around user goals
• Generating a requirements document that is easier to maintain and consequently more consistent by specifying the appropriate FR with the sub-function goal.

References and Literature

• [1] ISO/IEC. ISO/IEC 14143/1:2011 Information technology – software measurement – functional size measurement. Part 1 Definition of concepts, 2011.
• [2] IREB. International Requirements Engineering Board. A Glossary of Requirements Engineering Terminology: Version 1.6, 2014.
• [3] POHL, K.; RUPP, C. Requirements Engineering Fundamentals. Santa Barbara, CA: Rocky Nook Computing, 2011.
• [4] VAZQUEZ, C.; SIMÕES, G. Engenharia de Requisitos: Software Orientado ao Negócio. Rio de Janeiro: Brasport, 2016.
• [5] Gorschek, T. and Wohlin, C. 2006. Requirements Abstraction Model. Requirements Engineering. 11 (1), 79-101.
• [6] Rolland C., Prakash N., Benjamen A., (1999), A Multi-Model View of Process Modelling, Requirements Engineering Journal, Springer, 1999, pp.169 – 187
• [7] Cohn, M. User Stories Applied for Agile Software Development. Boston, MA: Addison-Wesley, 2004.
• [8] COCKBURN, A. Writing Effective Use Cases. Boston, MA: Addison-Wesley, 2000.
• [9] COSMIC. COSMIC Measurement Manual: 4.0.1. Common Software Measurement International Consortium, 2015.
• [10] IFPUG. International Function Point Users Group. Function Point Counting Practices Manual. Release 4.3.1. New Jersey, NJ: IFPUG, 2010.
• [11] IEEE. IEEE Std. 830–1998: IEEE Recommended Practice for Software Requirements Specifications. New York, NY: IEEE Computer Society, 1998.
• [12] GLINZ, M. On Non Functional Requirements, 15th IEEE International Requirement Engineering Conference, 2007.