Requirements Loops: Examples

Several examples of Requirements Loop concept instances (actual Requirements Loops) are given below. Each example is represented simply as text. No specific modeling language is used. This is because the Requirements Loop concept ignores the specifics one or of the language mix that may be best suited to represent the information which makes up an instance.

It may be relevant to use a mathematically formal modeling language, natural languages, or some technical language, but no such recommendation is embedded in the Requirements Loop concept. Examples RL1, RL2, and RL3 come from student projects of the 2019-2020 edition of my lecture ELOIM423 Decision Analysis & Requirements Engineering at University of Namur. Students were asked to identify a problem that they or other students experience, collect data to support that the problem is real and to describe its severity, then recommend what to change – processes, rules, software, or otherwise – to address the problem.

RL1: Students informally complain that they receive irrelevant mass email messages from the university. 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. The same 10 students all said that they do not want to receive irrelevant email messages. 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. 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.

RL2: At University of Namur, 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 introduce 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.

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. RL3 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, 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.

RL4 and RL5 were inspired by situations I experienced while collaborating with Fr8Hub, a brand of FreightHub Inc., a US-based startup company that makes and manages an online over-the-road freight marketplace service. I held the Head of Product role there from 2015 to 2019. The Requirements Loop concept was not used there. The approach we used there did inspire to some extent the concept, in the sense of how we worked to identify requirements, collect evidence for (and against) them, define changes in response, and measuring the outcomes of implemented changes.

RL4: Every day, the freight broker needs to know which carriers want to transport which (same day or future) freight, for what price. The broker employs staff who focus on sending available freight to carriers via email, then get their bookings from their email replies and via phone calls. This may involve back and forth communication, in case the broker wants to negotiate. The freight broker wants to increase the number of bookings per staff. The broker is convinced, although having collected no evidence to support this, that carriers would be willing to view available freight on a protected website, provide rates there on freight they want to transport, and thereby book loads. This should increase the number of bookings per staff who handles bookings at the broker. To collect evidence under a manageable level of risk, no complete online booking service will be made. Instead, a trial will run for three months. In the trial, all freight on selected lanes will be made available in a lightweight online service to a sample of handpicked carriers. In the first month, broker booking staff will provide training to these carriers and support them in bookings, then gradually aim to reduce their involvement to exception-handling only. The results of the trial will be assessed against a target number of bookings per broker booking staff member.

RL5: On average, 7% of shipments executed in a calendar month did not have accurate actual pickup
and drop-off times in historical data. This resulted in inaccurate pickup and drop-off performance measures,
and missed targets with customers whose shipments fell in those 7%. This in turn led to questions from
them, which generated unnecessary waste of time for everyone involved, and a loss of confidence that
reports were accurate not only on pickup and drop-off performance, but in other measures as well.
In response, one member of the operations staff will review all pickup and drop-off times at end of every
week, and make corrections of all inaccuracies in data. Operations staff will have one week to handle,
and staff will rotate. To understand the effect of these changes, the following will be measured: number of inaccuracies spotted during subsequent weeks in data of already verified prior weeks, and the number of customer complaints on pickup and drop-off inaccuracies.

RL6 and RL7 are based my collaboration with an Israel-based startup company, Parachute, which was designing a
professional services marketplace. Note how RL6 is broader in scope, and therefore limited in detail, relative to RL7, which focuses on one of many issues we observed during design, prototyping, and prototype trials.

RL6: According to the company founders’ prior experience, small and medium-sized high-technology businesses in Israel have no structured, predictable, and controllable approach to identify trustworthy experts who can help these companies build a presence in countries where these companies are not present. In response, founders selected a small sample of Israeli companies, one geographical market they are interested in, and one set of founders’ contacts. A pilot phase will be set up, during which founders’ staff will be matching companies from the sample to relevant contacts in the new market. To evaluate effects of changes, time to match, criteria used to match, and outcomes of the match in the first 6 and then 12 months of the pilot will be documented, before further investment is made in automating the matching process, and expanding the pilot to additional companies and experts.

RL7: When an expert and company are negotiating conditions of their collaboration, in which the company expects the expert to bring in sales to key customers in a new country, the contracting process is long (months, not weeks), and often fails according to the founders. It is necessary to find a way to shorten the negotiation process, and to keep the pace throughout, and to ensure either party exits if dissatisfied earlier, rather than later. In response, the software which will support the negotiation process should show to each party the predefined phases of the negotiation process, and have a fixed maximal duration for each phase. To evaluate effects of this, the following will be tracked: number of requests from negotiating parties, to extend any of the negotiation phases, and their overall satisfaction via net promoter score, of the negotiation process.