Requirements Loops: Definition & Purpose

A “Requirements Loop” is an evidence-supported explanation of 

1. How observed events in an environment have led or are leading to the creation and persistence of those requirements,
2. How to change the environment in order to satisfy the requirements in the future, and
3. How to measure the change in the environment, in order to evaluate the extent to which requirements are satisfied.

In short, a Requirements Loop is a combination of three evidence-supported explanations of why there are some requirements, how they are meant to be satisfied, and how to test how much they are.

Requirements are usually defined as needs, expectations, desires, that is, something that should be satisfied, but isn’t (yet) [1,2,3,4,5,6,7,8,9,10,11,12]. It is often assumed that the standard way to “get” requirements is to “elicit” them, that is, to identify someone who may know what they want, and spend time trying to understand what it is they want. I wrote in various papers in the past why this is a rather limited way of seeing requirements, and that they are actually much more interesting than what people may say they need, when you ask them to do so.

Requirements Loops are very interesting to me because they bundle together a few pieces of information that are usually overlooked:

• In a Requirements Loop, you must have the explanation of reasons, ideally causes, of requirements – this is, curiously, rarely required: in mainstream modeling languages, or more broadly formalisms that may be used to represent requirements (e.g., something specific such as KAOS, i-star and Tropos, workflow and process modeling languages, class diagrams, even User Stories) there is no rule that says that you need to explain why the requirements are there in the first place. In requirements engineering methods, it is certainly assumed that requirements being worked on are relevant, there is no obligation to give an explanation of why requirements are there. This is a problem, one, because we cannot blindly take any requirements and invest effort to solve them, and two, the less clear the causes of requirements, the more uncertainty around their relevance, and if in fact they are based on a loose rationale, then it is reasonable to expect them to change easily. 
• The second piece of information you must have in a Requirments Loop, is an explanation of how the environment needs to be changed, in order to satisfy requirements. Now this is important, because by asking for an explanation, I am asking you to explain the mechanism in the environment that you want to change, and how you will change it, in order to satisfy requirements. It is hard to meet criteria for good explanations, but the fact that this is hard does not make it less useful or important.
• Finally, you may give an explanation of how the changes you will do to the environment will satisfy requirements, but perhaps you are wrong, so we want to have a way to ascertain, to confirm that what you thought would in fact work to address requirements really does address, solve, satisfy them. Therefore, the third piece of information is an explanation of how to measure what changed in the environment, and use these measurements as evidence to support the claim that requirements are being satisfied, including to help think of ways in which we can satisfy them better.

Requirements Loops are therefore interesting because they confront practicing requirements engineers, business analysts, anyone dealing with requirements, with these hard questions, of how to explain requirements, their satisfaction, and how to ascertain their satisfaction. 

With the Requirements Loop concept, explanations become central to requirements; we need to explain why requirements are there, explain how to satisfy them, and explain how to measure satisfaction. Moreover, we want to have explanations supported by evidence. It does not matter if you think of requirements in terms of, say, entities and relationships, workflows, activities, tasks, goals, agents, and so on – use whatever works for you, as long as you are able to build convincing explanations. 

Another important consequence of using Requirements Loops is that it shift emphasis away from thinking about requirements through the lens of static data abstractions (“entities”, “properties”, and “relationships”) and abstractions tied to unobservable mental phenomena (“goal”, “intention”), towards concepts needed to produce explanations of observable environment dynamics (such as observable events, actions, outcomes, time, correlation, causality, uncertainty) and of observable social dynamics (authority, accountability, ownership, commitment, and quality).

Using Requirements Loops as intended is a tall order, but just like formal methods are only costly if the benefits are not high enough, this too, the use of the Requirements Loop concept will only make sense in some cases. And, most explanations are neither very bad, nor very good, but are in-between and yet asking for them is better than having none. If you look at requirements models, requirements documentation, requirements specifications, it is rare to find explanations for requirements, explanations for why they will in fact be satisfied, and explanations for how to measure them. Instead, the frequent attitude coming from requirements documentation is assertiveness, that requirements are a given, and that all we have to do is work to satisfy them [12].

So if we accept variously rigorous explanations, then the following is actually an example of a Requirements Loop; this one was made by my students in my lecture 2019-2020 Decision Analysis & Requirements Engineering at University of Namur. Sentences are numbered so we can reference them easily later.

RL1:

1. Students informally complain that they receive irrelevant mass email messages from the university. 
2. Through a workshop with 10 randomly selected students, an email message was defined as irrelevant when it does not concern the faculty where the student is enrolled and her current year of study. 
3. The same 10 students all said that they do not want to receive irrelevant email messages. 
4. In response, all email messages that are sent from the university will be placed in categories, staff who are sending email messages will select applicable categories for each message when or prior to sending, and each student will be allowed to select (and subsequently change, as needed) the categories to which she is subscribed. 
5. In the 7th week of every semester, for the two years following the implementation of the changes above, all students will receive an optional online survey to evaluate the relevance of mass email messages from the university.

Sentence (1) in RL1 describes events which lead up to the need to make the change described in sentence (4). Sentences (2) and (3) provide evidence for the need to make that change. The change itself, as described in (4), is the requirement. Sentence (5) describes how to measure the effects of the change. 

Here’s another Requirements Loop.

RL2: At our University, each faculty has a student ‘circle’. It is managed by students and organizes various events, many of which require registration. Currently, the only way to register is in person. This causes queues, which in turn leads students to miss classes. A survey of students gave the following results: 74% consider in-person registration a waste of time; 71% of students who queued missed at least one class to remain in the queue; 92% of surveyed students waited in the queue at least once in the past. Events are organized twice a week throughout the year. In response, the University’s largest student body will produce, rollout, and manage a mobile application available to all enrolled students, which will allow them to see events and register through the application. The student organization will collect feedback on the app from a random sample of students twice a year, in addition to any feedback that students provide on their own within the application.

Below, The first paragraph in RL3 is the explanation of why there is a need to make changes. It explains what the issues are, and mentions results of a survey as evidence collected to support the need for change. The second paragraph explains what will be changed to avoid these issues in the future. The last paragraph says what will be done to measure the outcomes of planned changes. RM3 below has this same structure.

RL3: When a student group wants to work together at the Faculty of Economics, at University of Namur, one of them needs to send a request to book a meeting room at the Faculty. The request is reviewed by a member of the administrative staff, who then books the room for the group. One of the students in the group needs to pick up the key, and they can only then use the meeting room. With the increase in team projects in courses, students need an easier way to know which rooms are available and when, and book them. Following interviews with 10 randomly selected students, representing 25 different student project teams, they all indicated that the current process is slow and has too many steps to book a meeting room. In response, an online form will be made available for booking, the current schedule will be accessible to all students, and the schedule will be updated automatically and without the involvement of administrative staff. Rooms will be unlocked in the morning, locked in the evening, and will otherwise remain open. A sample of students who booked rooms will be selected randomly once per semester, and invited to complete an online survey about their experience in booking and viewing schedules of the meeting rooms.

In summary, using the Requirements Loop concept means making explanations for why there are requirements, how they will be satisfied, and how to evaluate if they are. This implies investing much more effort than if requirements are taken as a given (i.e., no need to explain why they are relevant), for example. To try to explain what leads to requirements should help understand if they are relevant, what may lead to their change, and therefore, to a more robust set of requirements to satisfy. Then, by explaining how they are satisfied, you are showing how changes to the environment are causally related to the satisfaction of requirements, and by doing so, you are presenting theories of how the environment works – these theories can be tested. Finally, by explaining how to measure satisfaction, you give confidence that course can be confirmed or changed depending on observations of consequences of changes to the environment.

References

1. Betty HC Cheng and Joanne M Atlee. “Research directions in requirements engineering”. In: 2007 Future of Software Engineering. IEEE Computer Society. 2007, pp. 285–303.
2. Martin Glinz and Roel J Wieringa. “Guest editors’ introduction: Stakeholders in requirements engineering”. In: IEEE software 24.2 (2007), pp. 18–20.
3. Pei Hsia, Alan M Davis, and David Chenho Kung. “Status report: requirements engineering”. In: IEEE software 10.6 (1993), pp. 75–79.
4. Michael Jackson. “The meaning of requirements”. In: Annals of Software Engineering 3.1 (1997), pp. 5–21.
5. Ivan Jureta, John Mylopoulos, and Stephane Faulkner. “Revisiting the core ontology and problem in requirements engineering”. In: 2008 16th IEEE International Requirements Engineering Conference. IEEE. 2008, pp. 71–80.
6. Gerald Kotonya and Ian Sommerville. “Requirements engineering with viewpoints”. In: Software Engineering Journal 11.1 (1996), pp. 5–18. 
7. John Mylopoulos, Lawrence Chung, and Eric Yu. “From object-oriented to goal-oriented requirements analysis”. In: Communications of the ACM 42.1 (1999), pp. 31–37.
8. Ian Sommerville. “Integrated requirements engineering: A tutorial”. In: IEEE software 22.1 (2005), pp. 16–23.
9. Axel Van Lamsweerde. “Goal-oriented requirements engineering: A guided tour”. In: Proceedings fifth ieee international symposium on requirements engineering. IEEE. 2001, pp. 249–262.
10. Eric SK Yu. “Towards modelling and reasoning support for early-phase requirements engineering”. In: Proceedings of ISRE’97: 3rd IEEE International Symposium on Requirements Engineering. IEEE. 1997, pp. 226–235. 
11. Pamela Zave. “Classification of research efforts in requirements engineering”. In: Proceedings of 1995 IEEE International Symposium on Requirements Engineering (RE’95). IEEE. 1995, pp. 214–216. 
12. Pamela Zave and Michael Jackson. “Four dark corners of requirements engineering”. In: ACM transactions on Software Engineering and Methodology (TOSEM) 6.1 (1997), pp. 1–30.