CORE: Cognitive Organization for Requirements Elicitation

How to get out of a mess:Use the CORE methodology

Cognitive Organization for Requirements Elicitation

Scott M. ConferInformation Architect

Author contact: [email protected] 312.260.8274

Joanna Wiebe Information Architect

Creative Commons license. Wiebe & Confer, 2007.

3

CORECORE overview

Integrates two analytical methodologies:• Conceptual graphing (Gordon, Gill, Schmeier, 1993) • Collaborative soft systems inquiry framework (Checkland, 1981).

4

COREWhat is the CORE Method?

• CORE– An emerging methodology and conceptual toolkit at Orbitz

• Allows the IA to lead the team to– Clarify– Elicit– Iterate the initial vague requirements.

5

COREAdvantages of the CORE method

Centers on the user, drawn as a key actor in Rich Picture. Cross-disciplinary teams can work collaboratively to define

quality requirements. Other advantages include:• Scalable for large or small projects

• Is domain-agnostic

• Rules-based formal grammar for cognitive graphing ensures a thorough approach

• Based on empirically validated methods

• Ecologically valid combination of two methods widely used in industry and business today

Above all, CORE is a driver for innovation

6

CORECORE has seven steps

Step 1: Unstructured situation

Step 2: Rich Picture

Step 3: Relevant systems

Step 4: Conceptual Graph Structures (CGS)

Step 5: Preliminary requirements

Step 6: Requirements consensus

Step 7: Translation to Information Architecture

7

COREThe scenario

Final details of the contract with the third party had not yet been resolved, one reason that the requirements were not complete at kickoff …

Sound familiar?

8

CORESo, you find yourself needing better requirements?

What to do next?

• The IA didn’t have a formal organizational method for requirements development.

• The ‘flat’ organizational structure at Orbitz demanded team consensus for the project to move forward

9

COREWhat to do?

Add structure!

10

COREStep 1: The Unstructured Situation

Also known as the “MessTM” in soft systems

In an unstructured situation, “…human perceptions, behavior or actions seemed to be the dominating factors…goals, objectives and even interpretation of events are all problematic.” (Naughton, 2005)

11

CORESome attributes of a requirements “mess”

• Undefined or implicit features• Featuritis• Speed to market is the driver• “We don’t need no requirements!”• “Requirements” are:

– Voluminous (i.e. have Featuritis)– Solutions-focused– Vague– Disorganized– Missing– Conflicting– Interdependent– Not prioritized (or all=HIGH)

• Too little, incomplete, or missing:– User research– Functional requirements– Use cases

• Magically coordinate with other projects / dependencies

12

CORESome attributes of requirements with “quality”

• Correct• Unambiguous• Complete• Consistent• Prioritized for importance

and stability

Reference: Leffingwell, D. and Widrig D. (2000). Managing Software Requirements - a Unified Approach

• Verifiable• Modifiable• Traceable• Understandable

13

CORETo structure an “unstructured situation” . . .

1. Identify key roles– investigator– subject matter expert – client– problem-owner – problem-solver (one person may wear many hats)

2. Form your team

3. Do the research– What is this thing? – What’s happening?– What to do?– Where is it?– Where can I find out more? (more question probes, next slide)

14

COREQuestion probes for primary research

Questions from: Gordon et al., & San Diego State University http://coe.sdsu.edu/EDTEC544/Images/probes.gif

What is this

thing?

What’s

happening?

What to do?

Where is it?

Where can I find out more?


Information

What to do?

Goal / Action

What to do?

Goal

What to do?

Style

Where is it?

Location

What’s happening?

State

What’s happening?

Event

What is this thing?

Concept

What to do?

What does a person do after _____?

What to do?

What states of events cause or enable a person to _____?

What to do?

How does a person _____?

What to do?

What does a person do before _____?

What to do?

What prevents you from being able to _____?

What to do?

What are the consequences of _____?

What to do?

Why does a person _____?

What to do?

What happens if you do not _____?

What to do?

How _____?

What to do?

What causes or enables _____?

What to do?

What are the consequences of _____?

What to do?

What happens if not _____?

Where is it?

Where is _____?

Where is it?

What is above _____?

Where is it?

What is below _____?

Where is it?

What is to the left of _____?

Where is it?

What is to the right of _____?

Where is it?

What contains _____?


Is there anyone else who I should talk to about _____?


Where can I find out more about _____?


Can you recommend any books?


Can you recommend any web sites?


Are there any journals dealing with _____?


Is there a manual dealing with _____?

What is this thing?

What is _____?

What is this thing?

What are the parts of _____?

What is this thing?

What are the types of _____?

What is this thing?

What are the properties of _____ that distinguish it from _____?

What is this thing?

What are specific instances or examples of _____?

What’s happening?

What causes of enables _____?

What’s happening?

Why does _____ occur?

What’s happening?

What happens before _____?

What’s happening?

What happens after _____?

What’s happening?

What are the consequences of _____ occurring?

What’s happening?

Why does _____ occur?

What’s happening?

What happens before _____?

What’s happening?

What happens after _____?

What’s happening?

What are the consequences of _____ occurring?

What to do?

What happens before having the goal of _____?

What to do?

What happens after having the goal of _____?

What to do?

How is the goal of _____ attained?

What to do?

What state or event initiates the goal of _____?

What to do?

What is the outcome of _____?

What to do?

What is the goal of _____?

15

COREStep 2: Create a “Rich Picture”

Rich Picture v 0.03 Event travel project

A system to enable Travelport for Business to act as the travel booking engine for events managed through a third party online system. New features include: * Single-sign-on for registered and non-registered users * Communication of travel information to third party system for reporting and tracking. * Travelport travel policy to be associated with event travel * Customer Service Agent enablement * Split form of payment * Fees for high-touch and general event services

PRIMARY TASKS

§ Develop long-term vision for user interface integration§ Develop laundry list of features/functions§ Pick “low-hanging fruit” for Phases 0 and 1§ Measure resource impact § Pinpoint all the issues and assign responsibility for resolution§ Develop Project Plan

Travelport for Business

Third party event site(with our brand for our customers)

LEGENDKey actors

Users

User interactions

HARD INFO: Individual event participants login

to event site, register for event and then are passed (with event

ID, participant type, user info, hotel, car, arrival info etc.) to our

booking path which is prepopulated with their info

SME

Consultancy

SME

PROJECT TEAM

Event Manager User Interface§ Manage event travel bookings§ Confirm traveler itinerary§ Single sign-on

Users coming in from event site

HARD INFO: Policy for each event ID is associated with participants in this order:- Trip purpose- User group- default

USER HARD INFO:

§ Users are categorized by participant types and user groups

§ Some are registered Travelport users, some are not; event site can’t distinguish between our registered and unregistered users

Booking path for events

Travelport

Registration

Event Site

LOGIN ISSUES:§ Will there be an on-the-fly registration process for unregistered users?

§ What data travels with them from the event site?

§ What data do we store on their activity?

§ What data can user or administrator see, edit, delete?

§ What happens if a user tries to log in but no policy has been set up for their event?

§ Will registered users be constrained to book event travel only by logging in through event site?

§ If registered user finishes booking, how will the system “know” they are finished? If they want to book non-event travel, do they have to log out first?

PARTICIPANT TYPE ISSUES:· Where to set up participant types?

· How to make sure they match on both sites?

· Can address book be developed?

EVENT TRAVEL POLICY SETUP ISSUES:§ When setting up policy (name, ID, description, dates, location, status, flag, and existing air,

car and/or hotel policy rules), can event iD be passed from event site and associated with event name? If not, how to handle errors?

§ Resource cost of building templates and address books of participant types, event types, etc.

Event travel summary

Travelport

THIRD PARTY EVENT SITE HARD INFO:

§ Event registration and approvals workflow process§ Create participant types, manage participant lists etc§ Global view of all event activity, costs, benefits§ Preparing, updating and analyzing event costs§ Email invites and notifications§ Hotel and car default reservations

EVENT MANAGER HARD INFO:

§ Turn Event Manager on/off by company§ Air reservations for event travel§ Hotel and car res (if not in event site)§ Advanced policy for Car, Hotel (if not in event

site) and Air

POLICY ISSUES:§ Who sets policy for this travel? Implementation managers? Travelport administrators? Special

event planner role?

§ Can policy be set up in such a way that the person doing it can edit specific event policy across sessions, save it in an inactive state, save it in an active state, activate it, delete it, review past policy, resuse past policy?

§ What are implications of changing who does this from phase to phase of the project?

§ What is best solution if during search, date range is picked that is out of range? Halt message?

Corporate Travel Administrator

Customer Service Agent

ROLES:

Email confirmation

Our serversEvent site servers

Client: Product ManagerInvestigators: IAs

Problem owner: Corporate Travel exec

ROLES

Other Travelport users

Travel administrator

ROLES

Travel manager (with or without admin)

Registered Travelport user

Unregistered user

Features/functions

Functional requirementsData requirements

Content requirementsCreative requirements

Process flows

Data safety requirements

Localization requirementsTechnical requirements

Resource requirementsManagerial requirements

Performance requirementsTesting requirements

UI requirements

SOFT INFO:

· Stakeholders value project differently· Contract pending· Shifting cast of stakeholders· Distributed leadership of project· Release schedule issues

16

CORECase study example: Rich Picture

Drawing the picture is a way to methodically walk through some or all of key aspects of the project.

A Rich Picture is Checkland’s term for a visual capture of: • Structure• Function• Process • Environment.

The IA worked from her raw interview notes, whiteboard sketches and assumptions, to create the Rich Picture, using Visio.

17


PRIMARY TASKS







SME

Consultancy

SME

PROJECT TEAM




USER HARD INFO:




Travelport

Registration

Event Site











EVENT TRAVEL POLICY SETUP ISSUES:§ When setting up policy (name, ID, description, dates, location, status, flag, and

existing air, car and/or hotel policy rules), can event iD be passed from event site and associated with event name? If not, how to handle errors?



Travelport





site) and Air

POLICY ISSUES:§ Who sets policy for this travel? Implementation managers? Travelport administrators?

Special event planner role?






ROLES:

Email confirmation




ROLES



ROLES



Unregistered user

Features/functions



Process flows





UI requirements SOFT INFO:


18

CORERich Picture elements

1. Key actors 2. Structure of actor interactions 3. New Features

– Integration with existing ones

4. Process flow5. Environmental factors

6. “Hard” or “soft” information– Hard information: verifiable data and knowledge– Soft information: feelings, perceptions, opinions, values—often key to project success or failure

7. Types of requirements: – functional, data, content, creative, data safety, testing performance, user interface, localization,

technical, financial, temporal, managerial

8. Tasks involved in understanding each requirement type


A system to enable Travelport for Business to act as the travel booking engine for events managed through a third party online system. New features include: * Single-sign-on for registered and non-registered users * Communication of travel information to third party system for reporting and tracking . * Travelport travel policy to be associated with event travel * Customer Service Agent enablement * Split form of payment * Fees for high-touch and general event services

PRIMARY TASKS




LEGENDKey actors

Users

User interactions





SME

Consultancy

SME

PROJECT TEAM




USER HARD INFO:




Travelport

Registration

Event Site













§ Resource cost of building templates and address books of participant types , event types, etc.


Travelport





site) and Air


event planner role?


§ What are implications of changing who does this from phase to phase of the project ?




ROLES:

Email confirmation




ROLES



ROLES



Unregistered user

Features/functions



Process flows





UI requirements

SOFT INFO:


1

2

4

66

3

87

5

19

CORE

1

Key Actors

20

CORE


A system to enable Travelport for Business to act as the travel booking engine for events managed through a third party online system. New features include: * Single-sign-on for registered and non-registered users * Communication of travel information to third party system for reporting and tracking. * Travelport travel policy to be associated with event travel * Customer Service Agent enablement * Split form of payment * Fees for high-touch and general event services

PRIMARY TASKS




LEGENDKey actors

Users

User interactions





SME

Consultancy

SME

PROJECT TEAM




USER HARD INFO:




Travelport

Registration

Event Site















Travelport



site) and Air


event planner role?






ROLES:

Email confirmation




ROLES



ROLES



Unregistered user

Features/functions



Process flows





UI requirements

SOFT INFO:


2

Structure of actor interactions

21

CORE

3

New Features

22

CORE

4

Process flow

23

CORE

5

Environmental factors

24

CORE

6

“Hard” or “soft” information

6

25

CORE

7

Types of requirements

26

CORETasks to understand the requirements

8

27

COREStep 3: Write root definitions of relevant systems

How X does Y to accomplish Z.

The definition for each relevant system describes the Rich Picture elements of structure, function, process and environment.

28

CORECase study example: Relevant Systems

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.

29

COREStep 4: Create conceptual graphs

CGS method is broadly applicable to human endeavors

The grammar is based on the cognitive psychology and story comprehension research by Arthur Graesser.

Goal: Manage event travel

Goal: Confirm traveler itinerary

Goal - Action: Apply travel policy

Means

Means

Goal - Action: Create participant

types

Goal - Action: Create policy

Before

After

Event: Make policy reservations

Goal: Display traveler itinerary

Before

Means

Means

Means

Goal: Change/cancel traveler

itinerary

Before

Means

State: Restricted path for meeting

travel

Has part

Concept: Archived policy

Goal - Action: Read operational e-mails

Goal - Action: Use purchase confirmtn

Has consequence

Implies

30

COREConceptual graphing phase

1. Primary and secondary goals and goal-actions are broken out from the root definition of each relevant system. 2. Relevant system(s) are then graphed.




Means

Means

Concept: Third party event site

Has co nse que nce

Event: User data enters system


types


BeforeAfter


Goal - Action: Enter Meeting ID

After

Taxonomy Goal hierarchyCausal network

Has property

Concept: Email address

Refers-to

Concept: Third party database


Before

Means

Means

Means


itinerary

Before

Means

State: data validated

Has

consequence


travel

Has part


Goal - Action: Single sign on

Concept: RolesHas part



Style: behind the scenes

Manner

Event: user passed to

system Initiates

Refers-to

Has consequence

Has consequence

Implies

31

COREConceptual Graph Structures (CGS)

Key elements define the grammar

• Six types of nodes graphically represent one piece of knowledge.• Eighteen arc types connect the nodes, indicating the relationship

between the nodes.

• Templates for CGS structure contain “legal” arc-node combinations.

• There are four types of knowledge substructures for a conceptual graph:– Goal hierarchy– Taxonomy– Causal network– Spatial relationship

32

COREProcess flows vs. conceptual graph with a grammar

• Unlike process flows, conceptual graphs can be non-linear yet show procedures at the same time. – You can see concepts, goals, and procedures. Spatial relations are possible for actual interface layout or physical products.

• Could be called “Concept Goal Procedure” networks since those sub-structures are depicted.




Means

Mea ns


Has con sequ enc e



types


Before

After

Goal - Action: Enter meeting name



After

After


Has property


Refers-to



Before

Means

Means

Means


itinerary

Before

Means


Has

consequence


travel

Has part







Manner


system Initiates

Refers-to

Has consequence

Has consequence

Implies

33

COREExamples of concept mapping found online…

1 2

3

theyrule.net Network Diagrams of Conspiracy Mark Lombardi

Internet SearchDubberly Design Office

4

The Budget Graph Jesse Bachman

…enable discovery but don’t necessarily show user goals or use formal grammar

http://www.theyrule.net/

http://en.wikipedia.org/wiki/Mark_Lombardi

http://www.dubberly.com/images/downloads/DDO_Search.pdf

http://www.thebudgetgraph.com/

http://en.wikipedia.org/wiki/Mark_Lombardi

http://www.theyrule.net/

34

COREFour types of CGS substructures

Substructures are created from templates – The template provides basic form of substructure– Cohesive and predictable unit with prototypical node-arc-node

triplets

Types of CGS templates:1. Goal hierarchies2. Taxonomic substructures3. Causal network substructures4. Spatial relations

35

COREGoal hierarchy example




Means

Means


types


Before

After




After

After

Goal hierarchy


Before

Means

Means

Means


itinerary

Before

Means


travel

Has part


Concept: Prepopulated fields

Concept: Policy restrictions

Concept: Other UI restrictions

Concept: Product restrictions



Has consequence

Implies

Refers-to

Refers -to

Refe

rs-to

Refers-to

36

CORESubstructure 1. Goal hierarchy example




Means

Means


types


Before

After




After

After

Goal hierarchy


Before

Means

Means

Means


itinerary

Before

Means


travel

Has part








Has consequence

Implies

Refers-to

Refers -to

Refe

rs-to

Refers-to

Goal Hierarchies

are our ‘bread and butter’ for

system design.

37

COREProcedure for creating a graph

1. Identify the document to be graphed

2. Read for content and context

3. Note types of knowledge (taxonomic, goal, spatial, causal)

4. Finish reading. Go back and start the studying and creation.

5. Study each sentence and break into phrases

• Identify nodes and links

6. Create nodes and links using judgment to cover these cases:

• Easy: Both nodes and arc are in the phrase or sentence

• Linkage may be clear in your mind, but more nodes/arcs required on the graph to represent it than in the doc

• Hard: Ambiguous situation

6. As each sentence is read, associate a substructure to it that will contain node-arc-node triplets

• By using the template you will see gaps in the structure to be filled.

Each entry in the graph is attached to something else. Islands show what is unanswered, unrelated or out of scope.

38

CORECGS Construction Kit with Visio stencils

• CGS creation is supported by the custom Visio stencil – A notable feature is that when a ‘Smartarc’ is attached to two nodes, the legal arc types are suggested from a

contextual menu on the arc (right click).• Question probes for conducting your own SME interviews

Download visio tools at

onemind.wetpaint.com

http://onemind.wetpaint.com/

39

COREKey question probes for primary research

Start with goals, add in supporting concepts. For innovation, focus on manual and machine-aided tasks that are difficult, time intensive, repetitive, and pet peeves.

40

CORE

Step 5 Iterate graphs/develop preliminary requirements

The process of analysis that is encouraged to find and develop new solutions serves as a scaffolding for the “a-ha” moment.

41

CORECase study example: Preliminary requirements

CGS process led to cognitive breakthroughs, discoveries and innovations to meet user goals.• The CGSs were iterated between team meetings• CGSs capture, clarify, and relate concepts as well as goals

Concept: registered user role

Concept: unregistered user

role

State: temp profile created for

unregistered role

Has co

nseq

uenc

e


Concept: customer service agent role



Means

Mean s


Concept: Travel Arranger role

Has cons eque nce


State: registered role profile

prepopulated

Has consequence


types


Before

After




AfterAfter


Has

con seq ue nceEvent: Unreg profile

displaysConcept: My Stuff

profile

Spatial relations

Concept: Payment module

Concept: Service fees

Has part

Has property

Has part

Has part

Has

part

Has pa rt

Concept: Split fee payment

Has

part

Before


Refers-to



Before

Means

Means

Means


itinerary

Before

Means


Has

consequence


travel

Has part


Concept: Reservation page

Has pa rt







Refe r s -to

Refers-to



Above


Manner


system Initiates

Refers-to

Has consequence

Has consequence

Implies

Refers-to

Refers -to

Refe

rs-to

Refers-to

42


CGS process led to cognitive breakthroughs, discoveries and innovations to meet user goals.• The CGSs were iterated between team meetings• CGSs capture, clarify, and relate concepts as well as goals

Concept: registered

user role

Concept: unregistered user

role

State: temp profile created for

unregistered role

Has co

nseq

uenc

e


Concept: customer service agent role



Means

Mean s


Concept: Travel Arranger role

Has cons eque nce


State: registered role profile

prepopulated

Has consequence


types


Before

After




AfterAfter


Has

con seq ue nceEvent: Unreg profile

displaysConcept: My Stuff

profile

Spatial relations

Concept: Payment module

Concept: Service fees

Has part

Has property

Has part

Has pa

rt

Has

part

Has part

Concept: Split fee payment

Has

part

Before


Refers-to



Before

Means

Means

Means


itinerary

Before

Means


Has

consequence


travel

Has part


Concept: Reservation page

Has pa rt







Refer s -to

Refers-to



Above


Manner


system Initiates

Refers-to

Has consequence

Has consequence

Implies

Refers-to

Refers -to

Refe

rs-to

Refers-to

43

CORERequirements drafted

• Analysis and synthesis from concept graphing– Served dual purposes for analysis of both macro and micro

perspectives from the CGS itself. – Highlighted inconsistencies and/or problems with the existing

situations/systems. • Issues were managed in an Issues Log.• New requirement issues logged; brought back to team for clarification.

– Implicit relationships were revealed 1.Visualize what was known and2.Missing items in the CGS via the templates

• (e.g. goals, taxonomies, and causal networks.)

• Preliminary requirements drafted and walked through with individual team members

After iteration cycles, the IA was able to make a list of preliminary requirements.

44


Thirty-five pages of a “requirements doc” were transformed into succinct, prioritized requirements

45

COREStep 6 Reach team agreement on requirements

By Step 6 in the CORE methodology, a project team usually can efficiently reach requirements consensus.The requirements now have

– Total team buy-in– Documented – Stored with version control– Shared

Requirements are developed iteratively, published and are accessible to all project participants.

– Online wiki (open source) – MS Word documents

At this point stakeholders are invested in the process and it will not be too difficult to reach agreement on the final requirements.

46

COREStep 7 Translate to Information Architecture

47

COREImplementing IA changes software and environment

Whether it is a new or enhanced system, the changes are seen in:– Software

• Structure• Function• Process

– Environment• Business intelligence• Third-party agreements• Partnerships• Contracts• Work processes• Attitude and policy change consequences

The result is a set of changes of the original situation as collaboratively defined

48

COREConclusion

CORE has broad utility for all types of design contexts: • physical products• services• training program design• software development

CORE method helps designers define:– what information and inputs are needed,– at what time they are needed,– in order for users to make decisions.

49

CORELather, rinse, repeat

And now you have a new “mess” …

To do a new project, this current situation is to be cognitively structured anew, these cognitive structures have to be agreed on, and crystallized

into the form of new requirements

50

COREReferences

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.

51

COREAcknowledgements

Authors acknowledge the following contributors:• Albert “big Al” Ellenich – Proposal design and concepting • Andrew Day – Design • Natasha Fountain-Fernandez – Design • Andrew Rice – Visio Magic

With behind-the-scenes support from:• Matt Hanson – Information Architecture• Mark Hines – Information Architecture• Brian Hoyt – Public Relations• Melissa Moore – Design

Creative Commons license. Wiebe & Confer, 2007.

Text and illustrations, unless otherwise noted, © 2007 Joanna Wiebe, Scott ConferSee also http://onemind.wetpaint.com for stencils, job aids and updates.

http://onemind.wetpaint.com/

CORE: Cognitive Organization for Requirements Elicitation

Business

Transcript of CORE: Cognitive Organization for Requirements Elicitation