What's the Use of a Use Case?

Don Mills, June 2002

"Other maps are such shapes, with their islands and capes!

But we've got our brave Captain to thank:"

(So the crew would protest) "that he's bought us the best --

A perfect and absolute blank!"

- Lewis Carroll, The Hunting of the Snark

1. Background

I am a jobbing software product tester who also runs training courses. I was recently asked to develop a course on testing from use cases, a topic that had in fact come up from time to time on the courses I already ran.

On the face of it, this should be simplicity itself. Ivar Jacobson and his co-authors claimed in Object Oriented Software Engineering: A Use Case Driven Approach [JAC1993] that use cases are "the primary representation of system requirements" in OO engineering. "The collection of use cases," they wrote, "is the complete functionality of the system." It is well-suited to tests of the "basic flows" of user-system interactions, of "all other flows of events", of any line-item requirements traceable to use cases, and of features described in user documentation traceable to use cases.

But in the real world, I quickly ran into a number of difficulties.

To begin with, my personal experience with trying to test from use cases had been uniformly miserable. Almost the only commonality I'd seen between use cases from different organisations had been their serious deficiency of verifiable detail. Not that this was a problem unique to use cases: it's the general state of software specifications worldwide, and is a primary reason why 95% of all software systems brought to me for acceptance testing have failed on first try (some very miserably).

But I'd hoped for better from the OO community. However, the reality of the situation ceased to surprise me when, perusing the literature, I was unable to find a usable, consistent, rigorous description of the purposes, construction, and semantics of use cases. The UML Specification V1.3 [OMG1999] was internally inconsistent and ambiguous, as are books such as The UML User Guide [BOO1999] and OOSE itself.

(I was delighted by the insight that, in the UML, "actor" is a role played by a person; whereas in English, "role" is a person played by an actor … .)

I was able to construct, from a brief survey of the literature, a list of 27 "issues" with use cases as they were described in the UML Specification (see Appendix). Some were issues with relatively simple solutions (not provided for in the UML, however), others would require a fundamental rethink of the basis of the UML (see, e.g., Glinz, [GLI2000]).

For my immediate purposes, there were two sets of problems, both expressed by Robert Binder [BIN2000]:

Problems (1): "Standard UML specifications lack important testability elements".

Amongst these, Binder listed:

  • domain definitions for input and output variables;
  • testable specifications of input - output relationships;
  • testable specifications of conditions for alternate flows;
  • sequential constraints and dependencies among Use Cases;
  • relative frequencies of use cases;
  • other non-functional system attributes (constraints).

This list certainly seemed to account for some of my frustration with the use cases I've been given to work from. But it was merely a reflection of the second set of problems.

Problems (2): "The UML is a flexible notation with few restrictions" and with "no obligatory integrity checking on [use case] models". As a result, "it is easy to produce fragmentary, incomplete, inconsistent, ambiguous specifications while still following all of the UML's requirements".

Because of this "flexibility", Cockburn was able to describe encountering 18 different definitions of use cases [COC1999]. Hurlbut [HUR1997] summarises (from an "incomplete" literature survey) 31 different published approaches to writing use cases, and 26 different published attempts to overcome use case problems by providing formalisms.

As Constantine and Lockwood noted [CON2001]:

"If this all seems less than transparent, you are in good company because even some of the leading thinkers in the areas of object-orientation and use case analysis have struggled over agreement on the exact semantics of [use case features]. … However, as the scale of design problems rises, with larger design teams and more and more use cases, the sort of 'studied sloppiness' that can be beneficial for rapid design of modest problems begins to become a stumbling block."

2. What Are Use Cases For?

Further reflecting this "flexibility", I was unable to pin down the role of use cases in software development. Were they for eliciting and expressing "business requirements"? Or were they a system design tool? Both views could be upheld by judicious quotation from the foundational works - possibly both were true!

With all these problems, I concluded that the whole field of use cases was so "fuzzy" that I couldn't see how anyone could consider them as being any kind of engineering tool or technique. However, I had agreed to create the course, and had to deal with them, so I began a dialogue with my colleagues, which I subsequently took onto the internet, and which posed a single central question: "What are use cases for?"

I formalised this question via a couple of "propositions" and some illustrations of what I meant.

2.1. Proposition 1:

Every artefact of a software development project (every document, for current purposes) should have a well-defined purpose (or set of well-defined purposes) against which a Document Quality Control activity such as Inspection can measure it. "Cost-effective fitness for purpose" is the chief quality criterion. A technical document that's not "fit for its intended purposes" is a technical failure.

2.2. Proposition 2:

A specification is "A detailed description of the dimensions, construction, workmanship, materials, etc., of work done or to be done, prepared by an architect, engineer, etc.".

Specific means "clear and explicit; precise, exact, detailed, unambiguous; not open to assumptions or multiple interpretations with regard to meaning or use." A document that fails to fit these criteria, fails as a specification.

(These definitions are drawn from standard English dictionaries, especially the New Shorter Oxford English Dictionary [BRO1997].)

2.3. Illustrations of Specified Purposes:

As illustrations, here are proposed sets of "intended purposes" for two types of document often found in software projects. (Although, since the "intended purposes" of writing software development documents are rarely specified in verifiable detail, documents that actually fulfil them are rarely met with.)

2.3.1. Business Requirements Specification

[problem domain - business goals, rules, and context]:

  1. The business must be able to confirm that the business problem set and its business context are stated completely, consistently, and unambiguously.
  2. The solution development team must be able to propose a verifiably complete and unambiguously correct solution, or set of solutions, to the stated problem set.
  3. The product quality control team must be able to design a set of business test cases (expressed in terms of inputs and results, not system operations) that would confirm any proposed solution set as being complete and unambiguously correct.
  4. If Inspection determines that any one of these purposes could not be satisfied, then the business requirements are not expressed with sufficient clarity for an effective problem solution to be constructed.

2.3.2. System / Software / User Requirements Specification

[solution domain - system interfaces and operations]:

  1. The business must be able to confirm that the proposed solution set is a complete and unambiguously correct solution to the business problem set.
  2. The solution development team must be able to construct an internal product architecture that is a verifiably complete and unambiguously correct implementation of the proposed solution set.
  3. The product quality control team must be able to design a set of system interaction test cases that would confirm the proposed solution set as complete and unambiguously correct.
  4. The user documentation team must be able to create user documentation that describes the full user-level operation of the proposed solution.
  5. If Inspection determines that any one of these purposes could not be satisfied, then the solution is not expressed with sufficient clarity for a conforming product to be constructed. It must be understood that both the problem statement, and the solution proposal, may be only parts of a larger context. However, each must express a self-contained set of complete, not partial, functionalities.

2.4. Problem Statement (The Query):

My query was:

Is it possible to construct similar quality control criteria for use cases?

If not - if we can't define (unambiguously and verifiably) what they're supposed to be used for - then use cases cannot be subject to quality control, and are not suitable tools (or techniques) for engineering use.

3. Saved (?) by the UML

3.1. A Matter of Definition

John von Neumann wrote, "There is no point in using exact methods where there is no clarity in the concepts and issues to which they are to be applied" [VON1944].

Software engineers should take this maxim to heart. It identifies the use of words (our prime material) as precision tools, rather than blunt instruments. It also lies behind my personal preoccupation with dictionaries, glossaries, definitions, and specifications.

Do use cases describe "requirements" or "solutions"? It seems clear to me now, following a careful semantic analysis of the definitions of "use case" in the OMG UML Specification, that the answer is, "both".

In the Glossary of the current Object Management Group specification for UML, version 1.3 [OMG1999], the term use case is defined as follows:

"The specification of a sequence of actions, including variants, that a system (or other entity) can perform, interacting with actors of the system."

The draft for version 1.4 [OMG2001] provides the same definition. The wording is unchanged, too, in Section 2 ("Semantics"), which describes use cases more fully (p. 2-120):

"The use case construct is used to define the behavior of a system or other semantic entity without revealing the entity's internal structure. Each use case specifies a sequence of actions, including variants, that the entity can perform, interacting with actors of the entity. In the metamodel UseCase is a subclass of Classifier, specifying the sequences of actions performed by an instance of the UseCase. The actions include changes of the state and communications with the environment of the UseCase."

The OMG Unified Modelling Language Specification is "a precise and self-consistent definition of the UML's semantics and notation," according to its own "Preface". Let's take it at its word, and regard its use case definitions and descriptions as specifications for use, with each word chosen and applied for its specific meaning.

3.2. Requirements AND Design

Two things leapt out at me when I looked at The UML Specification in this light.

Firstly, unlike (say) Cockburn, who characterises the purpose of a use case with words such as "express" and "describe", the OMG very precisely uses the words "specify", "specification", and "define". Understood literally, these words require a use case to be "clear and explicit; precise, exact, detailed, unambiguous; not open to assumptions or multiple interpretations with regard to meaning or use" (this, according to the New Shorter Oxford English Dictionary [BRO1997]). As a "specification", a use case should be "a detailed description of the dimensions, construction, workmanship, materials, etc., of work done or to be done, prepared by an architect, engineer, etc." (NSOED again).

So the job of a use case is "specification".

The second thing was that a use case must "specify" something fairly exact: "a sequence of actions ... that the entity can perform". This is design language, as can be demonstrated from two considerations.

Firstly, "the actions" of an entity cannot be specified unless the entity itself can be described. For this to be true, either "the entity" must exist, or the specification of its behaviour must be part of the specification of the entity itself. Either way, if we are "specifying" its behaviour, then that is the way it's intended to behave. Either we are describing an existing design, or we are prescribing a new one that must be followed in building "the entity".

Secondly, "business rules" are largely independent of sequence. As long as all relevant goals have been accomplished in a timely manner, the process (sequence of actions) by which they were accomplished is irrelevant (C. J. Date, What Not How [DAT2000]). The need for process can be expressed declaratively via pre-conditions and post-conditions. "Alternate flows" (as the UML would see them) merely call for alternate pre-conditions (mostly the False state of "required" pre-conditions) and alternate post-conditions.

Defined sequences of actions are embedded in, or realised as, processes. A "business process" is an implementation of a set of business rules, within a business context, to achieve business goals. Business processes are designed; a software solution process must be also. The OMG definition, which requires us to specify a "sequence of actions", clearly requires us either to design a process (or subprocess) before or as part of the creation of a use case; or to create the use cases from an existing process design.

This is reinforced in Section 3.5.4 of the UML Specification, p. 3-317, where we read that a use case manifests "sequences of messages exchanged among the system and one or more outside interactors ... together with actions performed by the system".

A use case, then, must specify requirements either for the use of an existing process, or for the construction of a new one. But either way it must reflect or prescribe design features of that process. And if they are "specifications" in the sense that the NSOED defines the word, then a complete set of use cases must contain sufficient detail and clarity that we can use it exactly as Jacobson promised: to test the full functionality of the system.

3.3. The Solution To My Problem (sort of)

The solution to my original problem, then, seems to be for the software engineering community to do what software engineers are often loath to do: follow the published standard.

In those terms, the complete set of use cases for a software product will be equivalent to the "Functional Requirements" section of a standard IEEE Software Requirements Specification [IEE1993]. Its set of uses (specified purposes) should be those expressed above at 2.3.2, System / Software / User Requirements Specification [solution domain - system interfaces and operations]:

  1. Verification by the business.
  2. Internal architecture design.
  3. System validation.
  4. User documentation.
  5. All those variations

In summary so far:

  1. A UML use case is a specification of some part of the external behaviour of an existing or proposed entity (system, program, etc.).
  2. A software use case specifies designed features for the external behaviour of a software product.
  3. The designed features specified in a use case consist of messages between the system entity and one or more users; actions by the system entity and/or its users; and a sequence by which the messages and actions are interrelated.
  4. The specified design features constitute user requirements ("requirements for use") which must be present in the delivered product.

If we follow the UML standard, we can at least prevent an uncoordinated "sprawl" [KOV1999] of discordant definitions of what a use case is.

But unfortunately, not all problems are solved by this "resolution". The UML Specification still gives little guidance on what kind of information is required to make a use case a "specification". The standard also provides no effective guidance on how to coordinate multiple use cases; nor can we use "standard" use cases to model interactions initiated by the system, or by an environmental stimulus that cannot be allocated to an "actor".

In short, we are still stuck with the 27 use case issues outlined in the Appendix, plus any others that have been isolated.

Alistair Cockburn [COC2000] identifies five different situations in which use cases can be "put to use". They include use cases written for discussion, not intended as requirements; and also functional requirements of a system (and also system design documentation). He comments, "It's wonderful that the use case writing form can be used in such varied situations. But it is confusing. … Finding a general way to talk about use cases, while allowing all those variations, will plague us throughout the book."

But Cockburn is inconsistent. Having allowed that a use case may in some circumstances be "about requirements …, but not be the requirements description," he says a handful of pages later that use cases "really are requirements," though not all the requirements.
Could it be that a "writing form" capable of such hugely varied interpretation is really a multitude of writing forms? As I have alluded to, Cockburn (like many another) presents his own definition of use case in his "Glossary" ([COC2000] Appendix C):

"A use case expresses a contract between the stakeholders of a system about its behaviour. It describes the system's behaviour and interactions under various conditions … ."

In this version, a use case "expresses" and "describes", but (unlike the OMG version) does not "specify" or "define". This apparently allows us to write "use cases" which are not requirement specifications, but discussion documents.

Well, to each his own. I cannot say that Cockburn's view of use cases is wrong. Nor can I say that the views of (say) Constantine and Lockwood [CON1999], or Kulak and Guiney [KUL2000], are wrong. I can say that all of them conflict with the OMG UML Specification definition of "use case", and also with one another.

4. Conclusion

Multiple conflicting definitions and interpretations of "use cases" have been published ever since the term first appeared in print. Between them, they have served to obscure the very purpose of creating a set of use cases.

There is a standard, however, which (despite numerous other problems) does define the purpose of a use case. As defined in UML, this is to specify and define a sequence of interactions between a system (or a component of a system) and one or more of its users.

If it is unclear, it is not a specification. If it is inconsistent, it is not a specification. If it lacks detail, or is ambiguous, or leaves open multiple interpretations of its meaning or of how it could be applied, it is not a specification. And if it is incomplete, it is not a specification.

If it leaves unanswered questions, it's an "ification".

On the other hand, if it doesn't define the actual sequence of steps and messages by which a user will interact with the system, then it's not a use case.

All of this must be placed in context: "problem specification" or "solution specification"? It's crystal clear from the UML Specification that the role of a use case is to describe the details of a solution component (whether post facto or … "pre facto"?). If I am given a set of use cases that satisfy the definition of "specific", I can probably use them for testing the end product.

Most authors on use cases emphasise the need to avoid too much detail, to fulfil the aim of easy comprehension by all system stakeholders. But use cases as specifications for system behaviour and for testing need intensely minute attention to detail.

Please, use case authors: no more use cases that are unspecific, undetailed. The Business Rule Group has a nice term for "business rules" that are like this: they are "business ramblings" [BRG2000].

But I can't test a system on the basis of "usage ramblings": I need a set of clear, complete, consistent, detailed, and unambiguous statements of requirements and design, that are not open to assumptions or multiple interpretations with regard to meaning or use. A set that is "fit for its intended purpose" of enabling me to validate unambiguously that all its stipulations have been implemented, correctly and in full.

And this, I believe, is what the UML Specification specifies for use cases.

5. References

[AND1999] Anderson, David, "Use Cases still considered Dangerous", UI Design.net, October 1999 (http://www.uidesign.net/1999/imho/oct_imho.html)

[BIN2000] Binder, Robert V., Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison-Wesley, 2000,

[BOO1999] Booch, G., Rumbaugh, J., Jacobson, I., The UML User Guide, Addison-Wesley (Object Technology Series), 1999.

[BRG2000] Business Rules Group, The, Defining Business Rules ~ What Are They Really? (Final Report, revision 1.3, July 2000: http://www.businessrulesgroup.org/first_paper/br01c0.htm).

[BRO1997] Brown, L. (Editor-In-Chief), New Shorter Oxford English Dictionary, Version 1.0.03, Oxford University Press, January 1997 (CD-ROM edition).

[COC1999] Cockburn, Alistair, "Structuring Use Cases with Goals" (http://members.aol.com/acockburn/papers/usecases.htm)

[COC2000] Cockburn, A., Writing Effective Use Cases, Addison-Wesley, 2000.

[CON1999] Constantine, L.L., and Lockwood, L.A.D., Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design, Addison-Wesley, 1999.

[CON2001] Constantine, L.L., and Lockwood, L.A.D., "Conditional Interaction: Improvements to Use Case Notation", http://www.foruse.com/ApplicationNotes/AppNote3.htm.

[DAT2000] Date, C.J., WHAT Not HOW, Addison Wesley 2000.

[GLI2000] Glinz, Martin, "Problems and Deficiencies of UML as a Requirements Specification Language", 10th International Workshop on Software Specification and Design, San Diego, November 2000.

[HUR1997] Hurlbut, Russell R., "A Survey of Approaches for Describing and Formalising Use Cases", 1997, downloadable from http://www.iit.edu/~rhurlbut/xpt-tr-97-03.html.

[IEE1993] IEEE Computer Society, Software Engineering Standards Committee of the, IEEE Std 830-1993 Recommended Practice for Software Requirements Specifications, IEEE, December 2, 1993.

[JAC1993] Jacobson, I., Christerson, M., Jonsson, P., Övergaard, G, Object Oriented Software Engineering: A Use Case Driven Approach, Addison-Wesley, 1993 (revised).

[KOV1999] Kovitz, Benjamin L., Practical Software Requirements: A Manual of Content and Style, Manning Publications Co., 1999, p. 251.

[KUL2000] Kulak, D., and Guiney, Ea., Use Cases: Requirements In Context, Addison-Wesley, 2000.

[OMG1999] Object Management Group, OMG Unified Modelling Language Specification V1.3, June 1999: http://www.jeckle.de/uml_spec.htm.

[OMG2001] Object Management Group, OMG Unified Modelling Language Specification V1.4 Draft Revision 1, February 2001: http://www.jeckle.de/uml_spec.htm.

[VON1944] Von Neumann, J., and Morgenstern, O., Theory of Games and Economic Behaviour, Princeton University Press, 1944, 1953.

Appendix

This Appendix lists the "problems with use cases" that I found in my brief, and unscientific, survey of "the literature" (a mixture of books on my and my employer's shelves, with articles found by browsing the Internet). The first eight entries come from David Anderson [AND1999].

Solutions to all of the problems exist, but not within the RUP or the UML (or only clumsily, ambiguously, or inconsistently), while outside those strictures many competing solutions have been proposed.

Note that this is not intended as an exhaustive list ...

  1. [The precise role of use cases is defined in The UML User Guide to be the description of a set of actions performed by a system to deliver value to a user: that is, system process design (at the user interface level).] Understanding the problem -- the business and its rules -- must happen first. Defining business process, system operating procedures or lines of communication is secondary. Use Cases lead to definition of procedures without proper understanding of the problem domain.
  2. Developing Use Cases with a User Group or Business Analyst group leads to premature interaction design by unskilled practitioners.
  3. It's hard to determine the completeness of Use Cases because of their "single path" nature. This can lead to developers using their imagination to complete exception handling cases or rarely taken paths. This can quickly ruin a good Interaction Design.
  4. Use Cases do not lend themselves to OO development due to their nature as procedural descriptions of functional decomposition.
  5. The User Group defining them are required to second guess the future system operation. They find this difficult or even impossible. This leads to new systems which don't make an adequate improvement in operations procedures and can miss the opportunity to simplify a process and remove unnecessary people.
  6. Use Cases because of their procedural nature lend themselves to action-object User Interface designs. If you need or want to have an object-action UI Design (aka OOUI) then Use Cases are a poor foundation.
  7. Use Cases can end up as the repository for the whole requirements. Everything goes into the Use Cases and the Business Analyst group will claim, "the design is done already, now write the code". This is very very bad for Interaction Design.
  8. Use Cases are poor input for Object Modeling. They can lead to poor definition of classes from noun extraction as you may otherwise be hoping to eliminate some of the domain terms used within the object model.
  9. The UML Specification is so non-specific and lacking in obligatory integrity checking that it is easy to produce fragmentary, inconsistent, ambiguous use cases while still following an arguably correct interpretation of all of the UML's requirements. Cockburn identified 18 different definitions of Use Cases, yielding over 24 different combinations of Use Case semantics.
  10. Use cases do not require backward or forward traceability of requirements.
  11. Standard UML specifications of use cases, together with descriptions in the Rational Object Technology Series of publications, lack a number of important testability elements, such as domain definitions for input and output variables, testable specifications of input-output relationships, and sequential and interactional constraints and dependencies between use cases.
  12. Use cases, by definition in the UML Specification, emphasise ordering ("sequences of messages exchanged ... [and] actions performed by the system", V1.3). Physical sequence of operations is normally a process restriction, not a true requirement, and when truly required can be defined more abstractly by preconditions. Early emphasis on ordering is among the worst mistakes an O-O project can make, but is hard to avoid if use cases are relied on for analysis, since the UML Specification provides no standard way of expressing the common situation of optional or flexible sequences of action.
  13. Because the UML can neither express structure between use cases nor a structural hierarchy of use cases in an easy and straightforward way, use cases are developed as an "uncoordinated sprawl" of (by definition) discrete and unrelated functions. This creates a loose collection of separate partial models, addressing narrow areas of the system requirements, and presenting problems of relating these partial models and keeping them consistent with each other.
  14. Except by very strict interpretation, the UML Specification provides no clear semantics of what a use case really is, and no consistent guidelines on how it should be described. This "flexibility" may be seen as a good thing, but as the scale of design problems rises, with larger design teams and more and more use cases, the sort of "studied sloppiness" that can be beneficial for rapid design of modest problems begins to become a stumbling block.
  15. The UML Specification requires a use case to specify "actions performed by the system", but (despite a popular interpretation) does not restrict these to externally visible actions (though it prohibits revealing internal structure). It is not clear what kind of events we should concentrate on while describing use cases: external-stimuli and responses only, or internal system activities as well.
  16. Use cases may not overlap, occur simultaneously, or influence one another, although actual uses of a computer system may do all of these.
  17. Most authors on use cases emphasise the need to avoid detail, to fulfil the aim of easy comprehension by all system stakeholders. Use cases as specifications for system behaviour and for testing need minute attention to detail. There is little practical guidance regarding the level of abstraction of use cases, their length, or their granularity (e.g., [BOO1999], p. 219, "neither overly general, nor too specific").
  18. Furthermore, no modularisation concepts are given to manage large use case models. The include and extend concepts are presented as a means to provide extensibility, but no rigorous semantics are provided for these concepts, allowing for multiple disparate interpretations and uses.
  19. The "extend" relationship and extension points represent repeated goto and comefrom branches between blocks (vide the extraordinary UML Specification term, "behavior fragment", [OMG1999] p. 2-119). This violates the object-oriented principles of the UML and the good structuring rules established by Boehm, Jacopini, and Dijkstra.
  20. The "extend" relationship is commonly used to identify fatal exceptions (which terminate the base use case), and the commencement of alternative histories (which do not return to the base use case). The UML Specification, however, only permits an "extend" to insert a "behaviour fragment" at a specific point in the base use case, which must then resume from that point when the "behaviour fragment" has completed.
  21. Use cases in general are descriptions of specific business processes from the perspective of a particular actor. As such they do not give a clear picture of the overall business context and imperatives that actually generate the requirements for these business processes. This means that they can be quite incomprehensible to non-domain experts.
  22. For the same reasons, the important business requirements and imperatives underlying the use case model become invisible when taken out of business context and expressed in discrete use cases. Subsequent readers of the use case model may be quite unable to explain the forces and business requirements that shaped the model.
  23. Developing Use Cases with a User Group or Business Analyst group leads to a focus on how users see the system's operation. But the system doesn't exist yet. (A previous system might exist, but if it were fully satisfactory you would not be asked to change or rewrite it.) So the system picture that use cases will present is based on existing processes, computerised or not. The system builder's task is to come up with new, better scenarios, not to perpetuate antiquated modes of operation.
  24. A UML use case model can't specify interaction requirements where the system initiates an interaction between the system and an external actor.
  25. Because the UML Specification forbids interactions between actors, use cases cannot model a rich system context involving such interactions.
  26. The UML requires use cases to be independent of one another, which means that it offers no way to model persistent state across use cases, or to identify how the initial system state required by a use case (specified in Pre-conditions) is to be achieved.
  27. A use case must specify "a sequence of actions" ([OMG1999], p. 2-120), with "variants". This is traditionally expressed as a "Main Flow" with a set of "Alternative Flows". In reality, many system interactions may have multiple alternative outcomes, none of which is more likely or "main" than any other. This forces a use case designer to place false emphasis on one of the alternatives, while downplaying the importance of the others.
Software Education Associates Limited
Freecall: 0800 268 773
Software Education Australia Pty Ltd
Freecall: 1800 145 152
Proud to support World Vision