What Is Destructive in a Requirements Loop?

Why is a Requirements Loop a loop, and why is it a destructive loop? Any Requirements Loop has three explanations: an explanation of requirements, of a solution to these requirements, and of how to show that the solution satisfies requirements. Simply put, if an explanation gives the mechanism generating some events of interest (as in the causal-mechanical model of explanation), then there is a loop: we have an explanation of events called requirements, then an explanation of how these requirements events will be removed, and this already is a loop; the third explanation is there to ascertain that that loop is in fact there, that the solution, once implemented, in fact destroys the mechanism that leads to requirements. It’s a destructive loop.

Let’s think this through using the example decomposed in a separate text. There, the example is called RL1, and it is a Requirements Loop, and the first two explanations in it are below; the one that explains requirements is labeled RL1.1, and the one explaining the solution is labeled RL1.2.

RL1.1: How did observed events in the environment lead to requirements?

1. Student receives an email message from the university.
2. Student decides if the email is relevant or not.
3. If the student decides that the email message is irrelevant, then, at least for some such email messages, the student complains to other students and staff. 
4. Staff decides that complaints should be addressed, and therefore, there is a requirement to do so.

RL1.2: How to change the environment in order to satisfy the requirements in the future

1. Administrative staff of the university define distribution groups; some distribution groups are such that the students can enroll in them by themselves, while others require the administrative staff to enroll the student.
2. At any time, administrative staff can enroll a student to one or more distribution lists, and students can enroll themselves into distribution lists for which they are authorized to do so.
3. When sending an email to students, they do so by selecting one or more of the distribution lists. 

Note that the purpose of RL1.2 is precisely to destroy the mechanism described in RL1.1, hence the loop. If you read RL1.1 in isolation, it is a narrative on how a problem comes about, and hence is an explanation of requirements that are a reaction to the problem. (Perhaps it is a simplistic explanation, but let’s leave explanation quality for another text and focus on the relationship between RL1.1 and RL1.2.) 

If you read RL1.2 in isolation, it describes a process that will be applied, or a mechanism that will be running, but there is nothing to say why we need it. RL1.2 isn’t particularly interesting without RL1.1. 

Together, though, RL1.2 and RL1.1 are much more interesting, since the reason RL1.2 should be put in place is because of RL1.1, in order to reduce the frequency at which students conclude (proposition 2 in RL1.1) that the email message they received is irrelevant. The less frequent that is, the better, as it means fewer complaints, and more importantly, that relevant information is being emailed. 

If we call RL1.1 the explanation of requirements, and RL1.2 the explanation of a solution, then it is useful to see them as a loop, where the explanation of the solution should explain how it breaks the mechanism that generates the problems, and therefore requirements.