Using Evolutionary Prototypes to Formalize Product Requirements

Junius Gunaratne, Beatrice Hwong, Christopher Nelson, Arnold Rudorfer Siemens Corporate Research, Princeton, NJ

{junius.gunaratne, beatrice.hwong, christopher.nelson, arnold.rudorfer}@siemens.com

Abstract

Boundary objects are artifacts that facilitate communication and interaction between people or groups functioning in different domains. Software engineers, user interface designers and usability specialists have different domain knowledge, different terminologies, and shared terms with different, distinct meanings. Boundary objects can help assist the process of designing software by providing a common interface for communication between professionals in different domains. The Software Engineering department and User Interface Design Center at Siemens Corporate Research used an evolutionary prototype as a boundary object to help elicit product requirements from their client, Siemens Medical Solutions. This enhanced communication with the client and between groups at SCR. This paper describes how the evolutionary prototype functioned as a boundary object and how it allowed software engineering processes and human-computer interaction methods to proceed concurrently without the need for well-defined interaction points.

1. Introduction Siemens Corporate Research (SCR) is the Siemens

research and development facility in the U.S. chartered to deliver advanced technology solutions to Siemens business units worldwide. SCR is comprised of several groups in different domains including Software Engineering (SE) and the User Interface Design Center (UIDC). Quite often customer requests require collaboration between the different groups at SCR. Therefore it is beneficial to attempt to find methods that allow for these collaborations to occur in a timely and efficient manner.

One such attempt started with a request from Siemens Medical Solutions (MED). MED produces software packages for managing clinical, administrative and financial hospital business processes. The new visionary software features are demonstrated annually at major industry conferences. For one such conference, MED requested help from SCR to demonstrate some of these

new software features. Though MED knew what high-level features should be built for the demo, they found it difficult to formalize how the features, the user interface (UI) and the task flows should work. Software engineers and usability specialists needed to collaborate due to a strong focus on the UI look and feel, use of new technology, and a very tight timeline. To facilitate communication and interaction between the two groups and the client, SCR used an evolutionary prototype as a boundary object.

This paper reports on our success of first using storyboards—followed by an evolutionary prototype—to act as a common interface between software engineers, UI designers, usability specialists, and the client. Storyboards are used to brainstorm and capture some initial requirements by aiding communication between different domain experts. The storyboards are then replaced by the prototype for the remainder of the project. We found that tools such as Microsoft PowerPoint or Macromedia Director did not provide an artifact with a high enough fidelity to allow for sufficient communication between group members. The evolutionary prototype used J2EE application technologies similar to the real product to help software engineers determine implementation feasibility of requested features based on the real product’s software architecture constraints. Our experience with traditional prototyping tools and the need for using real product technologies drove us from storyboards to an evolutionary prototype.

2. Background In most cases the purpose of prototyping is to quickly

create an artifact that demonstrates behavior of an intended product [1]. However, the purpose of our prototype extended beyond simply demonstrating the product’s intended behavior. A number of members expressed concerns about how to appropriately translate language and artifacts from one domain to another—UI designers usually do not understand UML models, and only a few software engineers are familiar with human-computer interaction (HCI) methods, to mention a few examples. The prototype as a boundary object resolves this issue by providing an

artifact understood by all team members, ensuring effective communication of ideas in addition to helping facilitate discussion and creating estimates for development.

2.1 Prototypes as Boundary Objects

Boundary objects are used as a means of coordination

and alignment [2]. They serve as translators between disciplines and are malleable enough to adapt to changing needs. They are working arrangements and are adjusted as needed, and they are neither imposed by one community, nor by appeal to outside standards [3].

Conventional boundary objects used in software development include UML and storyboards. UML can show interaction between different components of software. Storyboards can demonstrate progression of a task and describe user interaction on a screen. Both of these types of boundary objects typically abstract software at high enough levels to transcend the boundaries of disciplines, but they each lack benefits the other provides. UML lends itself to use by software engineers since it supports their standard needs and processes, while storyboards lend themselves to use by HCI specialists for similar reasons.

McDaniel, Olson and Olson at the University of Michigan studied combining SE processes and HCI methods through rapid prototyping and iterative design and analysis, but this combination of the processes created difficulties. Software engineers tended to “respond to user suggestions in preference to design team suggestions.” Additionally, “the interface designer’s suggestions were implemented, although not the way they were suggested.” [4] Arguably, these problems could be avoided by improving project management or with more frequent communication. Though some communication problems existed, this attempt shows the potential of a prototype to work as a boundary object.

In contrast to the study at the University of Michigan, some members of our UIDC staff had formal background in both software development and usability. Also, SCR communicated with MED on a weekly basis to give project status reports and participate in design review meetings, and at SCR, SE and UIDC communicated on a daily basis. Since the two departments are down the hall from each other it is not difficult to have development or usability questions answered quickly. All of these factors helped communication through the prototype, and the development process.

2.2 SCR’s Role in MED Projects

MED’s suite of programs is used for managing

hospitals, supporting both clinical and business-related workflows. It is intended for use in medical facilities to

perform tasks such as checking a patient in, assigning facility resources such as beds and doctors, and handling delinquent billing. The software needed to adhere to new UI standards based on an unfinished, still evolving style guide. The success of their software relies heavily on its usability due to the wide range of potential users, and the environment in which it is used. For this reason, it was imperative that usability specialists at UIDC be included in the process from the start.

The very short amount of time available (about 10 weeks) to complete the requested features put a heavy constraint on this project. The absolute deadline set by the date of the industry conference meant that software engineering and user-centered design cycles needed to run in parallel.

3. Benefits of an Evolutionary Prototype To demonstrate conceptual versions of the product,

initially MED and SCR created a storyboard that defined functions to be implemented. SCR asked MED questions about the state of the system in hypothetical situations. It quickly became evident that the behavior and logic of the system could not be expressed adequately with a storyboard. A storyboard can be updated to reflect changes in requirements, but it is difficult to foresee the implications of those changes when the boundary object is not interactive. The prototype needed to evolve, along with the requirements, in order for it to be a valuable artifact in facilitating communication throughout the entire duration of the project. An evolutionary prototype is interactive and it allows us to experiment with the real technologies used in the actual product. Interactivity allows us to better demonstrate usability problems to the client. Use of technology from the actual product shows the client implementation constraints in software architecture. Finally, interactivity and use of technologies from the actual product allows MED to demonstrate advanced functionality at conferences.

SCR met with MED in design review meetings every one to two weeks using the prototype as a discussion piece. As MED requested changes on the features under implementation, software engineers assessed the impact of the changes on the architecture and design and later incorporated the changes into the prototype. As SE developed the prototype, UIDC ran usability tests on the evolving prototype. Usability specialists searched the prototype for inconsistencies in the UI. UI designers looked for areas where the prototype’s UI did not conform to the style guide. Issues communicated to SE through the prototype included button placement, icon use, and when to give feedback to the user after a task or operation is completed. UIDC constantly received feedback from the client and software engineers about UI limitations.

Feedback to software engineers happened throughout SE’s and UIDC’s processes without the need for well-defined interaction points since discussion revolved around the prototype. While SE and UIDC ran their processes, MED started validation testing to make sure the prototype evolved in the intended direction. This permitted requirements to mature quickly and kept client expectations in sync with what was going to be delivered.

During design review meetings software engineers gain a greater appreciation of usability by seeing the client struggle through tasks. Since usability specialists are available in design review meetings they provide feedback on potential improvements. This gives usability specialists a simple way to convey usability problems to both the client and software engineers without use of formalized documents. Since software engineers and the client participate in meetings with usability specialists, HCI methods such as think aloud techniques, cognitive walkthroughs, and heuristic evaluation are implicitly practiced without having to extensively educate software engineers and the client about the methods. The client is asked to complete a task in a style similar to cognitive walkthrough. User interface problems in the task are documented by both software engineers and usability specialists in heuristic evaluation style. The client and software engineers are not immediately aware that they are performing a cognitive walkthrough or heuristic evaluation, but through the act of using the prototype as a discussion piece they participate actively in the HCI methods.

After the initial requirement definition, SCR implemented the first version of the prototype, but continued to maintain storyboards as an alternate form of specifications. MED preferred using the prototype as the boundary object because of its strength of communication over the storyboards. The prototype became the de facto standard for defining product requirements. The storyboard—initially driving the requirement definition—became dated and superfluous.

The prototype’s implementation of hospital resource views and filtering beds are two examples of how the prototype served to bridge communication gaps in the software development process among SE, UIDC and MED.

3.1 Prototyping Hospital Resource Views

One feature of the prototype is the ability to navigate

through the hierarchical structure of an Integrated Health Network (IHN) to view hospital information. In hospital resource views a user can navigate the IHN and see a listing of hospitals. In the hospital a user can see different units, rooms and beds within that hospital. It is possible to zoom in and zoom out on hospitals to view unit, room, and

bed information. The initial requirements, captured in a storyboard, are a collection of several screens representing the different states of zooming. The storyboard mislead MED and UIDC by appearing to capture all feature requirements. When software engineers tried to implement the storyboard they often raised questions MED and UIDC did not consider. Using the storyboards as the boundary object between groups left some details lost in the translation of one group’s terminologies to other groups’ terminologies.

The storyboard lacked sufficient information for software engineers to implement the zooming feature. SCR used the prototype to demonstrate to MED how the poorly defined zooming behavior requirement created usability problems. If a user clicks the zoom in button, the application zooms in on the open hospital. If a user clicks the zoom in button and there is no open hospital, nothing happens and there is no feedback provided to the user. SCR found this to be a problem, and only by seeing the problem manifested in the prototype did MED perceive it as a problem too.

3.2 Prototyping Bed Filtering

Beds in a hospital have a variety of characteristics that

restrict their use. For example, a bed in a maternity unit of a hospital is only available to a woman. Additionally, beds have different states such as being empty, occupied, dirty, or reserved for a future patient. A bed manager typically has to check the status of hundreds of hospital beds in order to find one that is appropriate for a particular patient. Use of a bed filtering mechanism can dramatically speed up the time it takes to find a bed by only displaying appropriate beds.

Defining the bed filter feature’s behavior began as a sequence of storyboard screens and quickly moved to a prototype. After completing the initial implementation of filtering, MED met with SE and UIDC to discuss changes. Change requests from meetings were made to the prototype and then discussed in the next meeting. Through such meetings SE and UIDC refined the filtering rules for bed selection. MED did not explicitly state some rules for bed filtering in the original storyboard. Only after using the bed filtering feature in the prototype did MED realize specific behaviors needed to be implemented. SE and UIDC collected a number of bed selection rules as a result of eliciting requirements through the prototype. For example, when a bed manager searches for an empty semi-private bed, sometimes the state of the adjacent bed determines whether it is suitable. If a female occupies the adjacent bed, the empty bed is only suitable for a female. MED also did not specify initially that when an adjacent bed has a hazard indicator, the empty bed cannot be assigned and must be blocked until the hazard is cleared. Such rules

could not be collected without the prototype. The prototype demonstrated to MED the importance of creating well-defined bed filtering rules, forced MED to fill in gaps where rules were not complete, and it helped software engineers refine bed filtering logic.

4. Lessons Learned At the end of our project with MED we ran a process

improvement workshop to determine what worked well, and what did not. We learned that the prototype worked extremely well to facilitate communication between the groups, but we did not make use of its full potential. We have since come up with new methods to handle change requests coming from the client. Our new methods use the boundary object to capture the details surrounding the change request. In a change request, the client or usability specialists are forced to explicitly state how to navigate to a screen or dialog box in a specific module in the prototype. Software engineers, on the other hand, must reference specific modules in the prototype when changing underlying code. This is important because both SE and UIDC need to do impact analysis, but the information the two groups need to analyze requests often differs. By using the right boundary object, we ensure that the necessary information for both groups is correctly captured, communicated and disseminated.

5. Next Steps This project proved that a prototype can be used very

effectively as a boundary object between SE, UIDC, and our client when developing a J2EE application in the Health Services domain. We intend to apply the same techniques to future projects with different technologies in different domains such as embedded systems, and communication equipments and services.

6. Summary and Conclusion Typically, for HCI methods to be beneficial they must

be run very early in the software lifecycle, before development starts [5]. This increases the time it takes to get a product to market. The time to market can be dramatically shortened by running software engineering processes and HCI methods concurrently, with well defined interaction points for the teams to re-sync and communicate [6,7], but the problem with this approach is that time is wasted as one team waits at one or more interaction points for the other team to catch up.

Using an evolutionary prototype as a boundary object allowed for the client, SE, and UIDC to proceed with their specialized tasks in parallel and to communicate with each

other at any point in their processes. The evolutionary prototype provided a union of the two sets of benefits from UML models and storyboards and permitted early testing of interaction sequencing. This allowed us to quickly find problems with usability and functionality, which in turn allowed us to quickly discover and implement solutions. Through use of an evolutionary prototype as a boundary object SCR quickly gathered a mature set of requirements to create a high quality deliverable.

7. References [1] K. Schneider, “Prototypes as assets, not toys: why and

how to extract knowledge from prototypes”, Proceedings of the 18th International Conference on Software Engineering, IEEE Computer Society, Berlin, Germany, 1996, pp. 522-531.

[2] Star, S.L., and Bowker, G., Sorting Things Out:

Classification and Its Consequences, MIT Press, Cambridge, MA, 1999.

[3] A. Ernesto, H. Eden, G. Fischer, A. Gorman, E. Scharff,

“Transcending the individual human mind—creating shared understanding through collaborative design”, ACM Transactions on Computer-Human Interaction, Vol. 7, No. 1, March 2000, pp. 84-113.

[4] S.E. McDaniel, G.M. Olson, and J.S. Olson, “Methods in

Search of Methodology—Combining HCI and Object Orientation”, Proceedings of the Conference for Computer-Human Interaction 1994, Boston, MA, 1994, pp. 145-151.

[5] R. Chatley, J. Kramer, J. Magee, and S. Uchitel, “Model-

based Simulation of Web Applications for Usability Assessment”, Proceedings of Bridging the Gaps Between Software Engineering and Human-Computer Interaction at ICSE’03, Portland, OR, 2003, pp. 5-11.

[6] X. Ferre, “Integration of Usability Techniques into the

Software Development Process”, Proceedings of Bridging the Gaps Between Software Engineering and Human-Computer Interaction at ICSE’03, Portland, OR, 2003, pp. 28-35.

[7] K.S. Sousa, and E. Furtado, “RUPi – A Unified Process

that Integrates Human-Computer Interaction and Software Engineering”, Proceedings of Bridging the Gaps Between Software Engineering and Human-Computer Interaction at ICSE’03, Portland, OR, 2003, pp. 41-48.