Challenges in the elicitation and determination of precise requirements from animal stakeholders

Introduction

Requirements elicitation is the process of seeking, uncovering, acquiring, and elaborating requirements for a system ^[1] (we will be using the terms system and product interchangeably). The process of requirements elicitation is generally accepted as one of the critical activities in the requirements engineering process, and the selection of appropriate elicitation techniques is a critical factor for the success of the requirements elicitation ^[2]. Elicitation of precise requirements can be a long and hard process when dealing with human stakeholders. Imagine having to go through the same process with stakeholders who cannot verbally state what they want, really do not have any idea of what they want, or may not really want anything at all.

The fact that requirement elicitation methodologies are human-oriented is strongly reflected in assumption made in the requirements engineering literature that stakeholders are human ^[3]. Whether dealing with an animal computer interaction, or with an animal interacting with a physical object, "taking a user-centric approach in the design of animal technologies can have many benefits for both animals and humans. It could support dogs with occupations on their missions, such as search and rescue and seizure alert. It could lead to further insights into animal cognition, for example, by informing the design of interactive technology for behavioral studies that affords optimal usability and creative appropriation for the animals ^[3]."

Elicitation of precise requirements from an animal stakeholder (animal) presents unique challenges. These challenges are similar to eliciting requirements from infant stakeholders. Like an infant stakeholder, an animal cannot verbalize what it is they require, nor can they tell you exactly what is wrong with the current design. They can only express, in very basic terms, if they like, dislike, or can tolerate your current iteration. Based upon their reaction, we only know if we need to change or not change the current iteration, not how or why it should be changed. We must change our point of view to that of the dog, which can be a hard thing to do since how a dog thinks is foreign to us. It is much easier to put ourselves in the position of what another person is thinking as we have a common frame of reference and the person can provide verbal feedback to adjust our thinking to more closely match his or her way of thinking.

For example, when Jeri Ryan first appeared on Star Trek: Voyager she was required to wear a stiff rubber suit that contained many prosthetics. When they designed the suit, the designers did not take into account how the suit and prosthetics would affect the actor. They just wanted it to look good on camera. Once she had the suit on, everything seemed ok, until she turned her head. Whenever she would turn her head just the right way, the prosthetics in her collar would press on her carotid artery hard enough that she passed out. Twice. Since she could verbally explain what was going on, it was a simple matter of adjusting the suit so that it did not press on her carotid anymore ^[4].

Now, let’s say you are constructing a harness with embedded electronics to assist a rescue dog perform their duties by allowing the handler to guide the dog using different tones, and to assist in the retrieval of the animal if they become incapacitated. You design the harness system, place it on the dog, and let them acclimate to wearing it. After a little while, the dog begins to chew through the harness. Why does the dog do this? Is it because it is hurting them or restricting their movements, emitting an irritating tone, or because it smells and tastes too good to not chew it? We cannot know the exact reason because the dog is incapable of verbalizing their opinion. We must observe the dog’s behavior and infer from their actions what might be happening.

Processes for Elicitation of Requirements from an Animal Stakeholder

The normal processes best used to elicit requirements from a human stakeholder (interviewing, surveying, workshopping, brainstorming, etc.) involve verbal communication which will not work with an animal stakeholder. While these methods, relying on the use of language, cannot be applied directly with animal users, they have been shown useful with respect to owners, keepers, handlers and animal experts ^[3]. These methods might include communicating with the handlers that work with the animal on a regular basis, running through possible scenarios the animal may encounter while doing their job, utilizing specialists who are experts in the behavior of the animal, and observation of the handlers and animals in action. Once we have completed these steps, we will have enough data to begin designing a prototype to test and further refine the product requirements.

Communication with Handlers, Owners, Keepers, and Experts

The best place to begin to get a good outline of the basic requirements needed would be by communicating with the animal handlers. In communicating with the handlers, we can utilize the normal verbal elicitation techniques to gather the basic requirements. We can interview the handlers to find out the basics of what they, and the animal, require from the product: what it should or should not do, standards it might need to meet, etc. We could interview a couple of specific handlers to get these basic requirements, send out a survey to the handler community at large, or review on-line forums for current products to see what the handlers like and don’t like about an existing product that is similar to the product we are designing. Since these handlers interact with the animals on a frequent basis, they are a good source of knowledge of what the animal will require, as well as what the animal can or cannot tolerate. Semi-structured interviews with search and rescue experts were used in ^[5] for the development of a wearable computer interface for working search and rescue dogs that communicates with their handler via a mobile application ^[3].

During this stage we should discuss with the handlers what the exact job the animal performs is, and what the environment is like where this job will be performed. For example, if we are constructing a retrieval harness with an imbedded electronic guidance system for a rescue dog, we need to know if they will be climbing over rubble or will they be operating in water rescues, as these environments will produce different requirements. Additionally, we can have the handler list all of the possible tasks the animal might perform on a daily basis while using the product.

These processes are similar to when you are dealing with human stakeholders as you are actually dealing with humans. They can communicate verbally, you can usually determine what it is they want, and you both have a similar frame of reference from which to begin communicating. The problem that you run into when relying upon what the trainers think the animal might need, or can tolerate, is that the best they can provide is a second-hand view for some of the requirements. In other words, they can only tell you what they think will work for the animal and not what will actually work. Additionally, in interviewing only a select few individuals, you might only get requirements that will work for their animal specifically and not all animals in the field in general. This can often happen when dealing with human stakeholders. They often supply the best requirements for them and not everyone who will interact with the product. To get a more general overview of requirements that will work better for more animals, you would want to additionally mail a survey or questionnaire to further handlers in the field to generate a more comprehensive list of product requirements and tasks the animal would need to perform. While these lists might become fairly expansive fairly quickly, the remaining requirement elicitation techniques will be used to narrow down the lists to the most basic and important requirements and tasks.

Scenario Determination and Expert Evaluation of Possible Scenarios

The next two steps, running through possible scenarios the animal may encounter while doing their job, and utilizing specialists who are experts in the behavior of the animal, can be combined. Combining these two steps should help to shorten the process of running through different possible scenarios that the animal might encounter during their use of the harness system, as the experts can eliminate any scenarios they know the animals would either never tolerate or never encounter.

Throughout this stage of requirement elicitation we will probably want to utilize different types of experts to help with how the animal would react during the envisioned scenarios. The kind of expert required will depend upon the job for which the product will be used. If the product will be used for a rescue animal, you will want to deal with people who work with these animals on a regular basis, whether they do the actual rescue work with the animal or train the animals to perform their work. You would not want to use these experts for a product for a service dog or a pet. They might be able to provide some general advice, but would not be nearly as helpful as someone used to working or training service animals or a general pet trainer. Each of the experts would provide a different point-of-view; a trainer/animal relationship is different from an owner/pet relationship. For example, a trainer might be willing to push an animal harder and longer than an owner would be willing to push his pet. In addition to these more specific experts, a general animal behaviorist would also be beneficial, as they often are skilled at understanding the verbal and non-verbal cues that the animal would exhibit. Another type of expert to consider is one that has knowledge of the physical aspects of the animal. This includes knowing the physical limitations of the animal, as well as how the animal moves and can move (kinesiology). I initially overlooked this type of expert when writing my paper. After looking at current papers written on the subject of how animals might physically interact with a system ^{[1], [6], [7]}, I realized that these experts were as important as the behavioral experts.

No matter how good these experts are at interpreting animal behavior, it is impossible for them to predict perfectly what will happen. The best they can hope to achieve is to provide a possible reason why the animal is doing what it is doing, or the probability of what an animal will do in certain situations. While their experience in dealing with animals may be vast, they cannot always predict what any animal will actually do in any situation. They can provide probabilities of what could happen, but not what will actually happen. Even though their evaluations are not perfect, they are still extremely valuable. They can provide the most probable outcomes that can help focus the work on addressing the most likely issues dealing with those outcomes. As an example of this, when I was younger we had a dog that we had trained to ring a bell when he needed to go out. Now, when the dog rang the bell, you could safely assume that the dog needed to go out. When we first trained the dog, this was true. After about week, the dog learned that if he rang the bell, we would come to let him out. When we would appear, he would then walk across the room and sit in front of the refrigerator. Our perfectly valid assumption of what the dog wanted was no longer true and we had to adjust to the new behavior (we removed the bell).

Running through the different possible scenarios with the experts will help to narrow down the design requirements to those that cover the widest range of possible tasks. They would also be able to modify the requirements to those that will better suit the animal while also still allowing the maximum number of tasks to be completed. We might also learn at this stage that no single one product will cover every task and that multiple variations of the product might be required.

Another aspect that I overlooked when initially writing this paper was the welfare of the animal. When designing a harness to enable a rescue animal to do its job in a safer manner, the harness is being designed in order to increase the welfare for the animal. When designing a product for a pet, it might be a little trickier to decide if we are making a product with the animal’s best interest in mind. Will the product help, or at the very least, not hurt the animal or animal’s quality of life in some way? This question can be a little tricky to answer. We should only "build what they want and need ^[8]" and what we want to "avoid is researcher self-deception, also known as the unconscious projection of personal design priorities and enthusiasms onto voiceless’ co-designers ^[8]". In other words, build only what the animal shows you that it wants and needs and not what you think it wants and needs. Additionally, ^[9] argues that most technology currently being designed is exploitative and focuses more on what the owners want rather than what the animal wants, or even needs.

Observation of Animal Stakeholder and Handler in Action

After eliciting as precise requirements as possible from the handler, and using the experts to determine how the animal might react during the imagined scenarios, we can then move onto dealing with the animal directly. We can watch the animal in action to see firsthand exactly what the animal does. This process is similar to observing a human in their work environment. Additionally, we can film and monitor the animal’s vitals to see the effects of doing their job on the animal. These recordings can be used while designing the product to help visualize what exactly the animal does and get an idea of how a change to the product might affect the animal or the animal’s ability to do their job. The mere act of actually seeing the animal in action might even bring about a realization that a requirement needs to be changed, because it was not possible to accurately visualize what the animal would be doing until you could see it.

Finally, before moving onto the construction of a prototype, "species-specific physical characteristics useful for requirement elicitation should be collected ^[3]". As I mentioned above under the heading Scenario Determination and Expert Evaluation of Possible Scenarios, when writing this paper, I initially overlooked this aspect of requirements determination. It was only after looking over the research that I realized how important that information was to creating a successful system. Since the stakeholder is an animal, it is safe to assume that they sense the environment differently than us. An example of this is the perception of movement while observing a film: "while humans need 16-20 images per second to perceive what we see as continuous film, dogs need about 70 images per second ^[6]. Interestingly, for many years scientists believed dogs do not perceive TV images, until modern TVs with a high-enough flicker rate emerged. A dog-centric study of attention to audio and video stimuli from TV has been carried out in ^[7]." In our case, in order to design the embedded electronics, we would need to evaluate the dog’s range of hearing in terms of frequency range, frequency differentiation, and volume levels relative to background noise.

Prototyping – Designing, Testing, and Modifying

Once we have gathered as clear a picture as possible of the product’s requirements, we can then begin formulating a design of the prototype. In the case of dealing with an animal, we are starting with a mostly complete picture provided by the handler, the animal experts, viewing the animal in action, and those designing the product. Since we cannot know exactly what the animal is thinking, wants, or will tolerate, we are really starting with our "best guess". With that being the case, we will, more likely than not, be making changes to the product as we have the animal try out different versions. This would lead us to an iterative prototype process. Providing the animals with prototypes of the system to support the investigation of possible solutions is an effective way to gather detailed information and relevant feedback ^[1].

Once the first prototype has been designed, it can be tested upon different animals. To compensate for the lack of verbal feedback from the animal, we could have our experts interact with the animal in simulated scenarios. These scenarios must be constructed to control conditions as much as possible. Any variation in the testing procedure or environment could affect the outcome of the test. Ensuring repeatability of the same test over different runs is extremely important to troubleshooting any issues that may arise. For example, you have the animal complete an obstacle course while wearing a new safety harness. The animal completes the test without any issues with the physical harness and follows all the prompts given by the handler through the electronics embedded in the harness. During the second run, however, the animal notices a squirrel in the distance during the test and takes a step to the left towards the squirrel before following the prompt given by the handler to go to the right. If the animal is the only one who noticed the squirrel, we do not know what happened differently during the second test to cause the animal to initially head in the incorrect direction. Any conclusions drawn from the second test could be invalid and could affect the design process going forward. To the designers, a single misstep, such as this, might be considered acceptable to the designers of the system. To the handler, a single misstep could be the difference between navigating the animal safely through a minefield, or not.

Once we have designed our test and testing environment to control variations in conditions between different test runs, we can then begin to run our scenarios. The experts could then provide behavioral analysis of how the animal performed during the scenarios, how the animal interacted with the prototype, and how their performance differed from when they were not interacting with the prototype. Additionally, we could have other animal trainers and behaviorists observe the scenarios, in person or using pre-recorded footage, and interpret how they believe the animal is reacting to the prototype based upon its actions. Based upon these observations, we can determine how well the prototype meets the requirements and how well the animal interacts with the prototype. The current requirements would then be modified and changes made to the prototype to reflect those modifications. The process is then repeated until a set of final requirements has been achieved, which would also result in the completion of the final design.

Conclusion

When dealing with animals, it is necessary to rely almost exclusively upon the handlers who interact with the animal to determine the basic design requirements, as verbal communication is not possible. We need to utilize other methods including communicating with the handlers that work with the animal on a regular basis, running through possible scenarios the animal may encounter while doing their job, utilizing specialists who are experts in the behavior of the animal, and observation of the handlers and animals in action. In addition to these methods, prototyping and extensive testing and redesign become extremely important because the animal cannot verbalize what is wrong or missing from the current design. Since the animal cannot tell you what it likes, observation of the animal running through different scenarios, with and without the prototype, become extremely important, as it is really the only way the animal can "voice" their opinion about the design of your product.

While it can be challenging to get precise requirements from animals, if you are willing to put in the extra effort and time, you can elicit requirements that may not be as precise as those you get from a human stakeholder but will be close enough to enable you to design your product effectively.

References

• [1] D. Zowghi and C. Coulin, "Requirements elicitation: A survey of techniques, approaches, and tools," in Engineering and managing software requirements. Springer, 2005, pp. 19–46.
• [2] B. Nuseibeh and S. Easterbrook, "Requirements engineering: a roadmap," in Proceedings of the Conference on the Future of Software Engineering. ACM, 2000, pp. 35–46.
• [3] A. Zamansky, D. van der Linden, and S. Baskin, "Pushing Boundaries of RE: Requirement Elicitation for Non-Human Users," 2017 IEEE 25th International Requirements Engineering Conference, 2017.
• [4] Mitchell, Nigel G. "5 Horrifying Facts About Seven of Nine's Uniform." The Geek Twins, Nigel G. Mitchell, 5 Nov. 2014, 09:40 PM
• [5] C. Zeagler, C. Byrne, G. Valentin, L. Freil, E. Kidder, J. Crouch, T. Starner, and M. M. Jackson, "Search and rescue: dog and handler collaboration through wearable and mobile interfaces," in Proceedings of the Third International Conference on Animal-Computer Interaction. ACM, 2016, p. 6.
• [6] C. DC, P. CH, and S. JC, "Behavioral determination of critical flicker fusion in dogs," Physiological Behavior, pp. 1087–1092, 1989.
• [7] I. Hirskyj-Douglas, J. C. Read, and D. Fitton, "Animal computer interaction (aci) investigation on canine visual and audio attentiveness while interacting with video stimulus in a human computer interaction (hci) framework," Ph.D. dissertation, MSc Thesis. Preston, Lancashire, England, 2013.
• [8] A. Zamansky, A. Roshier, C. Mancini, S. North, C. Hall, E. Collins, K. Grillaert, and A. Morrison, "A report on the first international workshop on research methods in animal-computer interaction," in CHI’17 Extended Abstracts. ACM, 2017.
• [9] S. Lawson, B. Kirman, C. Linehan, T. Feltwell, and L. Hopkins, "Problematising upstream technology through speculative design: the case of quantified cats and dogs," in Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems. ACM, 2015, pp. 2663–2672.