The Requirements Engineering Magazine appears quarterly. It is cost free and provides you with up-to-date articles reflecting the activities of the RE and BA community.
Simply sign up for being notified about new issues of the Requirements Engineering Magazine.
You may unregister at any time by sending a mail to email@example.com from the e-mail address which you have registered with.
The level of granularity is the greater or lesser extent in the description of expected software behaviour in a functional specification. It defines how detailed or how generalised the description of the functionality of the software is. Different project phases require different levels of granularity in the description of functional requirements: in early project phases a broad vision of scope is required, while in later phases a deeper view is necessary. This article presents an entry level discussion about three levels of granularity that can be defined for functional requirements, according to whether their goals can be classified as summary, user or sub-function.
User requirements for a software solution consist of two subsets: functional and non-functional . Functional requirement (FR) concern the results of behaviour that shall be provided by a function of a system (or component or service) , . 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 . 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 , and may include quality, technical, environmental and organizational constraints  .
If we consider a system for an ATM, then the following might be examples of the two types of requirements:
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 . 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”.
Continuing with the example of an ATM system, the following descriptions might be found in its requirements specification:
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  and presents fours levels of classification for requirements, and is applicable to both functional and non-functional requirements.
The CREWS RE process  recognises three levels of abstraction for a requirement chunk:
Another criterion widely used in projects with an agile focus classifies user stories as follows :
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.
 presents three levels of goals for use cases, as illustrated in Figure 1:
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  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.
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.
A requirement with a user goal is a FR that:
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.
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:
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.
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:
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 , ; 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:
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.
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  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: