Sign in or 
Share this
Orbitz Worldwide Case Study
How to get out of a mess:
seven steps when requirements are vague or missing
In late 2006, a team of people from various software development disciplines at Orbitz met around the table to kick off a project to integrate a third party meeting and events registration site. Initial requirements were presented, but the Information Architect (IA) judged that they were not complete, organized and coherent enough to begin the design work.
The third party site was to be integrated with Travelport for Business, a complex, evolving web application licensed by Orbitz to large corporations for managed employee travel. A second quarter 2007 launch date had already been set, so it was important to quickly define a “buildable” set of requirements.
Final details of the contract with the third party had not yet been resolved, one of the reasons that requirements were not complete at kickoff (sound familiar?).
The IA could not turn to any standardized method of requirements definition, for Orbitz had not bought into any. Finally, in the flat organizational structure at Orbitz, it would be critical to achieve team consensus to ensure that team members would be committed to the same goals.
CORE (Cognitive Organization for Requirements Elicitation), an emerging methodology at Orbitz, was used by the IA to lead the team to clarify, elicit and iterate the initial vague requirements. CORE, a conceptual toolkit, integrates two analytical methodologies:
- an empirically-validated conceptual graphing method from the field of cognitive task analysis (Gordon, Gill, Schmeier, 1993), which includes a formal grammar for diagramming goals, spatial relationships, taxonomies, and causal networks in a collaborative process and
- a collaborative soft systems inquiry framework (Checkland, 1981).
CORE has broad utility for all types of user experience practitioners, in design contexts including physical products, services, training, and software. It helps designers define:
- what information and inputs are needed,
- at what time they are needed,
- in order to make decisions.
The CORE process which was followed is outlined in the seven steps, below.
Step 1: Unstructured situation
The IA began by pointing out that the project team was in an unstructured situation; it was deemed “unstructured” because it had not been analyzed and no cognitive models had been applied to it.
In an unstructured situation, “…human perceptions, behavior or actions seemed to be the dominating factors and…goals, objectives and even interpretation of events are all problematic.” (Naughton, 2005)
It is understood that all “problems” are subjectively interpreted, and so the definition of the problem basically answers the question, “What shall the problem be deemed to be?” – not “what is the problem?” A soft systems approach also realizes that these problems are organic, evolving, and open-ended, and that every “solution” is again just the perception of a solution, which in turn may reveal new aspects of a “problem”.
The IA then analyzed the existing project team to determine who was playing the roles of investigator, subject matter expert, client, problem-owner and problem-solver. Playing the role of investigator, the IA recognized that she was a part of the situation. If no team would have existed, she would have assembled one. Ideally, by project kickoff, existing applications and business processes have been captured as functional requirements documents and use cases. In this case, in their absence, the IA conducted secondary and primary research, including interviewing project team members following a taxonomy of question probes under the headings:
- What is this thing?
- What’s happening?
- What to do?
- Where is it?
- Where can I find out more?
Step 2: Rich Picture
Research was next organized into a rough “Rich Picture”, which was Checkland’s term for a visual capture of the elements of structure, function, process and environment. The IA worked from her raw interview notes, whiteboard sketches and assumptions, to create the Rich Picture, using Visio.
Many Rich Pictures are simply drawn on a whiteboard or notepad. Drawing the picture is a way to methodically walk through some or all of key aspects of the project.
The Rich Picture depicts:
- Key actors impacted by or involved in developing the new features
- Structure of actor interactions
- Functions of new features and how they integrate with existing functions
- Process flow for new features
- Environmental factors such as resource availability and time
- “Hard” or “soft” information. Hard information includes verifiable data and knowledge; soft information includes feelings, perceptions, opinions, values—often key to project success or failure
- Types of requirements, for example: functional, data, content, creative, data safety, testing performance, user interface, localization, technical, financial, temporal, managerial
- Tasks involved in understanding each requirement type
This Rich Picture may or may not be shared with the entire team, but it allows the IA and team members to create a preliminary mental model of the situation. In this case, the Rich Picture was not shared, but from analysis of the Rich Picture, an Issues Log was created (at Orbitz, in Excel, stored on the project wiki) to permit team members to log, track and resolve issues in a coordinated way.
Step 3: Relevant systems
Once the Rich Picture had provided a visual overview of the situation, goal/action models, or root definitions of “relevant systems” were written by the IA. The definition for each relevant system attempted to describe Rich Picture elements of structure, function, process and environment.
In this case, three different systems could be considered relevant to finding an acceptable solution to the problem situation:
- System A (Customer perspective): A system to enable customers to book and manage travel online at the same time that they register for meetings without having to log into another application
- System B (Business perspective): A system to provide incremental transactional revenue and revenue share offerings for Orbitz and third parties
- System C (Development perspective) A system to add features to the online travel booking web application.
The first step in building a conceptual model was to tease out the primary and secondary goals and goal-actions from the root definition of each relevant system. The investigator then began to graph the relevant system(s) as Conceptual Graph Structures (CGSs). These structures use a formalized grammar and templates for CGS structure, arcs and nodes. There are six types of nodes, which are graphical representations of one piece of declarative knowledge (i.e., vehicle type, number of travelers). Eighteen types of arcs, or directional arrows, connect the nodes, indicating the kind of relationship that exists between the nodes. There are four types of knowledge substructures for a conceptual graph:
- Goal hierarchy
- Taxonomy
- Causal network
- Spatial relationship
The CGS method is inherently applicable to human endeavors since Gordon’s grammar is based on the cognitive psychology and story comprehension research by Arthur Graesser (1991).
The IA built her CGS iterations by analyzing the definitions of the Relevant Systems, the Rich Picture, the Issues Log, research notes, and other documents, then identifying which knowledge substructures needed to be addressed. Nodes and links were identified and linked using Visio templates that guided the IA in selecting valid node-arc-node combinations.
Step 5: Preliminary requirements
A completed CGS affords macro and micro views. A CGS makes information explicit and clear by organizing concepts and procedures. The CGS process led to cognitive breakthroughs, discoveries and innovation to meet user goals. Implicit relationships were revealed as the IA was able to visualize what was known, and what was missing in the CGS.
The key benefit to creating a CGS is the process of analysis that is encouraged. This process yields twotypes of knowledge:
- Inconsistencies or problems with the existing situations/systems and
- Potential new solutions/innovations for the means of accomplishing user goals.
The IA may or may not share the CGSs with the project team. However, the process of developing Cognitive Graph Structures builds a conceptual framework for dynamic conversations and debate with the rest of the team. Issues continued to be brought back to the team for clarification, via the Issues Log, and through this process, the IA was able to make a list of preliminary requirements.
Step 6: Requirements consensus
By Step 6 in the CORE methodology, a project team usually can efficiently reach requirements consensus.This is a key benefit of the CORE methodology, that team members are invested collaboratively in the requirements, because they have been integral to requirements definition. At Orbitz, requirements are captured in Word documents, and stored and shared on an open-source wiki.
Step 7: Requirements translated to IA
In the final step, these agreed-on requirements are translated into information architecture. Once a system is implemented, whether software, a product, a service or a curriculum, the result is a set of changes to structure, function, process and environment of the original situation as collaboratively defined. Changes in attitude and policy also may result for the larger organization.
The result is a set of changes to structure, function, process and environment of the original situation as collaboratively defined.
Advantages of the CORE method |
References
Atlantic Systems Guild Limited (2006). Volere Method Requirements Specification Template, Edition 11. Available at http://www.systemsguild.com and http://www.volere.co.uk.
Beyer, H. & Holtzblatt, K. (1998). Contextual Design: A Customer-Centered Approach to Systems Designs. Morgan Kaufmann.
Carroll J.M., Rosson M.B., Chin G., Koenemann J. (1997). Requirements Development: Stages of opportunity for collaboration needs discovery. Proceedings of the conference on Designing interactive systems: processes, practices, methods, and techniques. ACM Press. New York, NY, USA.
--> 5 stages of Requirements Development instead of gathering (Genesis & Types) on p.63
Checkland, P B (1972). Towards a Systems-based methodology for real-world problem-solving. Journal of Systems Engineering, vol. 3, no. 2.
Checkland, P.B. (1981). Systems Thinking, Systems Practice. John Wiley & Sons.
Constantine, L. & Lockwood, L. (2000). Usage-Centered Design: Practical Abstract Modeling with Use Cases. ACM CHI 2000 Tutorial.
DuFour, R., & Eaker, R. (1998). Professional Learning Communities at Work: Best Practices for Enhancing Student Achievement. National Educational Service.
Gordon, S. E. & Gill, R. T. (1997). Cognitive Task Analysis. In C. Zsambok & G. Klein, (Eds.), Naturalistic Decision Making (pp. 131-140). Hillsdale, NJ: Lawrence Erlbaum.
Gordon, S.E., Schmierer, K.A., & Gill, R. T. (1993). Conceptual graph analysis: Knowledge acquisition for instructional system design. Human Factors, 35, 459-481.
Graesser, A.C., Golding, J.M., & Long, D.L. (1991). Narrative representation and comprehension. In R. Barr, M.L. Kamil, P. Mosenthal, and P.D. Pearson (Eds.), Handbook of Reading Research (pp.191-205). White Plains, NY: Longman.
Hackos, J. and Redish, J. (1998). User and Task Analysis for Interface Design. John Wiley and Sons. Bloomington, IN: National Educational Service.
Holtzblatt, K. & Beyer, H. (1995). Requirements gathering: the human factor. Communications of the ACM. Volume 38, Issue 5. Available at http://doi.acm.org/10.1145/203356.203361.
Hutchings, F. & Knox, S. (1995). Creating Products Customers Demand. Communications of the ACM. Volume 38 , Issue 5, Pages: 72 - 80.
Leffingwell, D. & Widrig D. (2000). Managing Software Requirements - a Unified Approach. Object Technology Series (Series editors Booch, Jacobson, & Rumbaugh). Addison-Wesley.
Lengler R., Eppler M. (2007). Towards A Periodic Table of Visualization Methods for Management. IASTED Proceedings of the Conference on Graphics and Visualization in Engineering (GVE 2007), Clearwater, Florida, USA. Available at http://www.visual-iteracy.org/periodic_table/periodic_table.pdf.
Naughton, J. (2005). Soft systems analysis: An introductory guide. Milton Keynes: The Open University.
Robertson S. & Robertson J. (2006). Mastering the Requirements Process—Second Edition. Addison-Wesley. Available at http://systemsguild.com/GuildSite/Robs/RMPBookPage.html.
Senge, P. M. (1990) The Fifth Discipline. The art and practice of the learning organization. London: Random House.
This wiki is licensed under a Creative Commons Attribution-Share Alike 3.0 License.
joannawiebe |
Latest page update: made by joannawiebe
, Mar 15 2007, 3:57 PM EDT
(about this update
About This Update
Edited by joannawiebe
3 words added 1 word deleted view changes - complete history) |
|
Keyword tags:
case study
Orbitz
Orbitz worldwide
More Info: links to this page
|
There are no threads for this page.
Be the first to start a new thread.
