Using Evolutionary Prototypes To Formalize Product Requirements
Upcoming SlideShare
Loading in...5
×
 

Using Evolutionary Prototypes To Formalize Product Requirements

on

  • 442 views

Boundary objects are artifacts that facilitate ...

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 humancomputer
interaction methods to proceed concurrently
without the need for well-defined interaction points.

Statistics

Views

Total Views
442
Slideshare-icon Views on SlideShare
439
Embed Views
3

Actions

Likes
0
Downloads
3
Comments
0

1 Embed 3

http://www.linkedin.com 3

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Using Evolutionary Prototypes To Formalize Product Requirements Using Evolutionary Prototypes To Formalize Product Requirements Document Transcript

    • 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 new software features. Though MED knew what high-level features should be built for the demo, they found it difficult Boundary objects are artifacts that facilitate to formalize how the features, the user interface (UI) andcommunication and interaction between people or groups the task flows should work. Software engineers andfunctioning in different domains. Software engineers, user usability specialists needed to collaborate due to a stronginterface designers and usability specialists have different focus on the UI look and feel, use of new technology, and adomain knowledge, different terminologies, and shared very tight timeline. To facilitate communication andterms with different, distinct meanings. Boundary objects interaction between the two groups and the client, SCRcan help assist the process of designing software by used an evolutionary prototype as a boundary object.providing a common interface for communication between This paper reports on our success of first usingprofessionals in different domains. The Software storyboards—followed by an evolutionary prototype—toEngineering department and User Interface Design Center act as a common interface between software engineers, UIat Siemens Corporate Research used an evolutionary designers, usability specialists, and the client. Storyboardsprototype as a boundary object to help elicit product are used to brainstorm and capture some initialrequirements from their client, Siemens Medical Solutions. requirements by aiding communication between differentThis enhanced communication with the client and between domain experts. The storyboards are then replaced by thegroups at SCR. This paper describes how the evolutionary prototype for the remainder of the project. We found thatprototype functioned as a boundary object and how it tools such as Microsoft PowerPoint or Macromediaallowed software engineering processes and human- Director did not provide an artifact with a high enoughcomputer interaction methods to proceed concurrently fidelity to allow for sufficient communication betweenwithout the need for well-defined interaction points. group members. The evolutionary prototype used J2EE application technologies similar to the real product to help software engineers determine implementation feasibility of1. Introduction requested features based on the real product’s software architecture constraints. Our experience with traditional Siemens Corporate Research (SCR) is the Siemens prototyping tools and the need for using real productresearch and development facility in the U.S. chartered to technologies drove us from storyboards to an evolutionarydeliver advanced technology solutions to Siemens business prototype.units worldwide. SCR is comprised of several groups indifferent domains including Software Engineering (SE) 2. Backgroundand the User Interface Design Center (UIDC). Quite oftencustomer requests require collaboration between the In most cases the purpose of prototyping is to quicklydifferent groups at SCR. Therefore it is beneficial to create an artifact that demonstrates behavior of an intendedattempt to find methods that allow for these collaborations product [1]. However, the purpose of our prototypeto occur in a timely and efficient manner. extended beyond simply demonstrating the product’s One such attempt started with a request from Siemens intended behavior. A number of members expressedMedical Solutions (MED). MED produces software concerns about how to appropriately translate language andpackages for managing clinical, administrative and artifacts from one domain to another—UI designers usuallyfinancial hospital business processes. The new visionary do not understand UML models, and only a few softwaresoftware features are demonstrated annually at major engineers are familiar with human-computer interactionindustry conferences. For one such conference, MED (HCI) methods, to mention a few examples. The prototyperequested help from SCR to demonstrate some of these as a boundary object resolves this issue by providing an
    • artifact understood by all team members, ensuring effective perform tasks such as checking a patient in, assigningcommunication of ideas in addition to helping facilitate facility resources such as beds and doctors, and handlingdiscussion and creating estimates for development. delinquent billing. The software needed to adhere to new UI standards based on an unfinished, still evolving style2.1 Prototypes as Boundary Objects guide. The success of their software relies heavily on its usability due to the wide range of potential users, and the Boundary objects are used as a means of coordination environment in which it is used. For this reason, it wasand alignment [2]. They serve as translators between imperative that usability specialists at UIDC be included indisciplines and are malleable enough to adapt to changing the process from the start.needs. They are working arrangements and are adjusted as The very short amount of time available (about 10needed, and they are neither imposed by one community, weeks) to complete the requested features put a heavynor by appeal to outside standards [3]. constraint on this project. The absolute deadline set by the Conventional boundary objects used in software date of the industry conference meant that softwaredevelopment include UML and storyboards. UML can engineering and user-centered design cycles needed to runshow interaction between different components of in parallel.software. Storyboards can demonstrate progression of atask and describe user interaction on a screen. Both of 3. Benefits of an Evolutionary Prototypethese types of boundary objects typically abstract softwareat high enough levels to transcend the boundaries of To demonstrate conceptual versions of the product,disciplines, but they each lack benefits the other provides. initially MED and SCR created a storyboard that definedUML lends itself to use by software engineers since it functions to be implemented. SCR asked MED questionssupports their standard needs and processes, while about the state of the system in hypothetical situations. Itstoryboards lend themselves to use by HCI specialists for quickly became evident that the behavior and logic of thesimilar reasons. system could not be expressed adequately with a McDaniel, Olson and Olson at the University of storyboard. A storyboard can be updated to reflect changesMichigan studied combining SE processes and HCI in requirements, but it is difficult to foresee themethods through rapid prototyping and iterative design and implications of those changes when the boundary object isanalysis, but this combination of the processes created not interactive. The prototype needed to evolve, along withdifficulties. Software engineers tended to “respond to user the requirements, in order for it to be a valuable artifact insuggestions in preference to design team suggestions.” facilitating communication throughout the entire durationAdditionally, “the interface designer’s suggestions were of the project. An evolutionary prototype is interactive andimplemented, although not the way they were suggested.” it allows us to experiment with the real technologies used[4] Arguably, these problems could be avoided by in the actual product. Interactivity allows us to betterimproving project management or with more frequent demonstrate usability problems to the client. Use ofcommunication. Though some communication problems technology from the actual product shows the clientexisted, this attempt shows the potential of a prototype to implementation constraints in software architecture.work as a boundary object. Finally, interactivity and use of technologies from the In contrast to the study at the University of Michigan, actual product allows MED to demonstrate advancedsome members of our UIDC staff had formal background functionality at conferences.in both software development and usability. Also, SCR SCR met with MED in design review meetings everycommunicated with MED on a weekly basis to give project one to two weeks using the prototype as a discussion piece.status reports and participate in design review meetings, As MED requested changes on the features underand at SCR, SE and UIDC communicated on a daily basis. implementation, software engineers assessed the impact ofSince the two departments are down the hall from each the changes on the architecture and design and laterother it is not difficult to have development or usability incorporated the changes into the prototype. As SEquestions answered quickly. All of these factors helped developed the prototype, UIDC ran usability tests on thecommunication through the prototype, and the evolving prototype. Usability specialists searched thedevelopment process. prototype for inconsistencies in the UI. UI designers looked for areas where the prototype’s UI did not conform2.2 SCR’s Role in MED Projects to the style guide. Issues communicated to SE through the prototype included button placement, icon use, and when MED’s suite of programs is used for managing to give feedback to the user after a task or operation ishospitals, supporting both clinical and business-related completed. UIDC constantly received feedback from theworkflows. It is intended for use in medical facilities to client and software engineers about UI limitations.
    • Feedback to software engineers happened throughout SE’s bed information. The initial requirements, captured in aand UIDC’s processes without the need for well-defined storyboard, are a collection of several screens representinginteraction points since discussion revolved around the the different states of zooming. The storyboard misleadprototype. While SE and UIDC ran their processes, MED MED and UIDC by appearing to capture all featurestarted validation testing to make sure the prototype requirements. When software engineers tried to implementevolved in the intended direction. This permitted the storyboard they often raised questions MED and UIDCrequirements to mature quickly and kept client did not consider. Using the storyboards as the boundaryexpectations in sync with what was going to be delivered. object between groups left some details lost in the During design review meetings software engineers gain translation of one group’s terminologies to other groups’a greater appreciation of usability by seeing the client terminologies.struggle through tasks. Since usability specialists are The storyboard lacked sufficient information foravailable in design review meetings they provide feedback software engineers to implement the zooming feature. SCRon potential improvements. This gives usability specialists used the prototype to demonstrate to MED how the poorlya simple way to convey usability problems to both the defined zooming behavior requirement created usabilityclient and software engineers without use of formalized problems. If a user clicks the zoom in button, thedocuments. Since software engineers and the client application zooms in on the open hospital. If a user clicksparticipate in meetings with usability specialists, HCI the zoom in button and there is no open hospital, nothingmethods such as think aloud techniques, cognitive happens and there is no feedback provided to the user.walkthroughs, and heuristic evaluation are implicitly SCR found this to be a problem, and only by seeing thepracticed without having to extensively educate software problem manifested in the prototype did MED perceive itengineers and the client about the methods. The client is as a problem too.asked to complete a task in a style similar to cognitivewalkthrough. User interface problems in the task are 3.2 Prototyping Bed Filteringdocumented by both software engineers and usabilityspecialists in heuristic evaluation style. The client and Beds in a hospital have a variety of characteristics thatsoftware engineers are not immediately aware that they are restrict their use. For example, a bed in a maternity unit ofperforming a cognitive walkthrough or heuristic a hospital is only available to a woman. Additionally, bedsevaluation, but through the act of using the prototype as a have different states such as being empty, occupied, dirty,discussion piece they participate actively in the HCI or reserved for a future patient. A bed manager typicallymethods. has to check the status of hundreds of hospital beds in After the initial requirement definition, SCR order to find one that is appropriate for a particular patient.implemented the first version of the prototype, but Use of a bed filtering mechanism can dramatically speedcontinued to maintain storyboards as an alternate form of up the time it takes to find a bed by only displayingspecifications. MED preferred using the prototype as the appropriate beds.boundary object because of its strength of communication Defining the bed filter feature’s behavior began as aover the storyboards. The prototype became the de facto sequence of storyboard screens and quickly moved to astandard for defining product requirements. The prototype. After completing the initial implementation ofstoryboard—initially driving the requirement definition— filtering, MED met with SE and UIDC to discuss changes.became dated and superfluous. Change requests from meetings were made to the prototype The prototype’s implementation of hospital resource and then discussed in the next meeting. Through suchviews and filtering beds are two examples of how the meetings SE and UIDC refined the filtering rules for bedprototype served to bridge communication gaps in the selection. MED did not explicitly state some rules for bedsoftware development process among SE, UIDC and filtering in the original storyboard. Only after using the bedMED. filtering feature in the prototype did MED realize specific behaviors needed to be implemented. SE and UIDC3.1 Prototyping Hospital Resource Views collected a number of bed selection rules as a result of eliciting requirements through the prototype. For example, One feature of the prototype is the ability to navigate when a bed manager searches for an empty semi-privatethrough the hierarchical structure of an Integrated Health bed, sometimes the state of the adjacent bed determinesNetwork (IHN) to view hospital information. In hospital whether it is suitable. If a female occupies the adjacentresource views a user can navigate the IHN and see a bed, the empty bed is only suitable for a female. MED alsolisting of hospitals. In the hospital a user can see different did not specify initially that when an adjacent bed has aunits, rooms and beds within that hospital. It is possible to hazard indicator, the empty bed cannot be assigned andzoom in and zoom out on hospitals to view unit, room, and must be blocked until the hazard is cleared. Such rules
    • could not be collected without the prototype. The other at any point in their processes. The evolutionaryprototype demonstrated to MED the importance of creating prototype provided a union of the two sets of benefits fromwell-defined bed filtering rules, forced MED to fill in gaps UML models and storyboards and permitted early testingwhere rules were not complete, and it helped software of interaction sequencing. This allowed us to quickly findengineers refine bed filtering logic. problems with usability and functionality, which in turn allowed us to quickly discover and implement solutions.4. Lessons Learned Through use of an evolutionary prototype as a boundary object SCR quickly gathered a mature set of requirements At the end of our project with MED we ran a process to create a high quality deliverable.improvement workshop to determine what worked well,and what did not. We learned that the prototype worked 7. Referencesextremely well to facilitate communication between thegroups, but we did not make use of its full potential. We [1] K. Schneider, “Prototypes as assets, not toys: why andhave since come up with new methods to handle change how to extract knowledge from prototypes”, Proceedings of the 18th International Conference on Software Engineering, IEEErequests coming from the client. Our new methods use the Computer Society, Berlin, Germany, 1996, pp. 522-531.boundary object to capture the details surrounding thechange request. In a change request, the client or usability [2] Star, S.L., and Bowker, G., Sorting Things Out:specialists are forced to explicitly state how to navigate to Classification and Its Consequences, MIT Press, Cambridge,a screen or dialog box in a specific module in the MA, 1999.prototype. Software engineers, on the other hand, mustreference specific modules in the prototype when changing [3] A. Ernesto, H. Eden, G. Fischer, A. Gorman, E. Scharff,underlying code. This is important because both SE and “Transcending the individual human mind—creating sharedUIDC need to do impact analysis, but the information the understanding through collaborative design”, ACM Transactions on Computer-Human Interaction, Vol. 7, No. 1, March 2000, pp.two groups need to analyze requests often differs. By using 84-113.the right boundary object, we ensure that the necessaryinformation for both groups is correctly captured, [4] S.E. McDaniel, G.M. Olson, and J.S. Olson, “Methods incommunicated and disseminated. Search of Methodology—Combining HCI and Object Orientation”, Proceedings of the Conference for Computer-5. Next Steps Human Interaction 1994, Boston, MA, 1994, pp. 145-151. [5] R. Chatley, J. Kramer, J. Magee, and S. Uchitel, “Model- This project proved that a prototype can be used very based Simulation of Web Applications for Usabilityeffectively as a boundary object between SE, UIDC, and Assessment”, Proceedings of Bridging the Gaps Betweenour client when developing a J2EE application in the Software Engineering and Human-Computer Interaction atHealth Services domain. We intend to apply the same ICSE’03, Portland, OR, 2003, pp. 5-11.techniques to future projects with different technologies indifferent domains such as embedded systems, and [6] X. Ferre, “Integration of Usability Techniques into thecommunication equipments and services. Software Development Process”, Proceedings of Bridging the Gaps Between Software Engineering and Human-Computer Interaction at ICSE’03, Portland, OR, 2003, pp. 28-35.6. Summary and Conclusion [7] K.S. Sousa, and E. Furtado, “RUPi – A Unified Process Typically, for HCI methods to be beneficial they must that Integrates Human-Computer Interaction and Softwarebe run very early in the software lifecycle, before Engineering”, Proceedings of Bridging the Gaps Betweendevelopment starts [5]. This increases the time it takes to Software Engineering and Human-Computer Interaction atget a product to market. The time to market can be ICSE’03, Portland, OR, 2003, pp. 41-48.dramatically shortened by running software engineeringprocesses and HCI methods concurrently, with welldefined interaction points for the teams to re-sync andcommunicate [6,7], but the problem with this approach isthat time is wasted as one team waits at one or moreinteraction points for the other team to catch up. Using an evolutionary prototype as a boundary objectallowed for the client, SE, and UIDC to proceed with theirspecialized tasks in parallel and to communicate with each