Tag: Planning

Generalization and Use Case Models, Part 2

Written by Willem Van Galen on September 2, 2013. Posted in Articles. 1 Comment on Generalization and Use Case Models, Part 2

Introduction

The article’s first part set the stage with an object-oriented example of generalization (and specialization) of classes and then discussed generalization of use case actors. This second part continues with generalization of use cases and concludes with generalization of systems to which use cases apply.

GENERALIZING USE CASES

Why use cases can be generalized

In [1], UseCase is a subclass of BehavioredClassifier, which is a subclass of Classifier. Because generalization is a feature of Classifier, UseCase inherits this feature from that class. In other words, use cases can be arranged in a use case hierarchy.

An example

Imagine producing a use case model for a travel website and finding out that the concrete use cases Book a Car, Book a Flight and Book a Hotel are all based on one core booking process and only differ in certain details. How can you define the core booking process once and address the unique details for each concrete use case?

By using use case generalization, of course! See next diagram (i) (ii).

Use case generalization (and specialization) results in a use case hierarchy.

What a use case hierarchy means

Because we’re generalizing three already existing concrete use cases, the resulting generalization use case is ‘completely partitioned’ (entirely subdivided into sub use cases) and therefore abstract (no use case instances can be created in it).

As with any generalization, type correspondence between the sub and super use cases is a must. The statements ‘Book a Car is a type of Book a Trip Component’, ‘Book a Flight is a type of Book a Trip Component’ and ‘Book a Hotel is a type of Book a Trip Component’ are all true, so the use case hierarchy is appropriate.

When a concrete use case has a generalization relationship with a generalization use case, it means that at run time the generalization use case’s specification and the concrete use case’s specification are combined into a single use case specification that governs the behavior of each use case instance in the concrete use case.

The behavior of a concrete Book a Car use case instance is governed by the combined use case specifications of the Book a Trip Component and Book a Car use cases.
There will never be a Book a Trip Component use case instance.

The use case specifications

The generalization use case’s specification:

Defines the initiating actor, provided this is common to all of the specialization use cases.
Defines the supporting actor(s) common to all of the specialization use cases.
Defines the steps that are common to all of the specialization use cases.
May define default steps that apply to some but not all of the specialization use cases (*).
May define empty placeholders for steps that are to be defined by one or more of the specialization use cases (**).

A specialization use case’s specification:

Defines the initiating actor, provided this is not defined by the generalization use case specification.
Defines any supporting actor(s) needed by the specialization use case and not defined by the generalization use case specification.
May override default steps of the generalization use case’s specification, by defining its own version of those steps (*).
May fill in empty placeholders of the generalization use case’s specification, by defining its own steps for those placeholders (**).
May delete steps of the generalization use case’s specification.
May add its own steps, which aren’t in any way anticipated in the generalization use case’s specification (***).

(*) Similar to the object-oriented example’s ‘method override’ pattern in [2].
(**) Similar to the object-oriented example’s ‘method deferral’ pattern in [2].
(***) Similar to the object-oriented example’s ‘operation addition’ pattern in [2].

In the end, both specifications must be written so that when they’re combined, the result represents the complete specification for the specialization use case.

The two specifications are always “textually combined”, similar to the way some included use case specifications are “textually included” in a base use case specification, as outlined in [3] and [4].

Object-oriented use case implementation

Specifying use case steps this way foreshadows an object-oriented implementation of the use cases involved, where the steps of the use cases map to operations on underlying classes.

Just like the steps are defined for generalization and specialization use cases, the operations can be defined on generalization and specialization classes, as illustrated in the object-oriented example in [2].

GENERALIZING SYSTEMS

What is a system, again?

According to 16.3.2 (iii) in [1], a UseCase has:

An ‘owning classifier’. This is the ‘namespace’ of which the UseCase is an ‘owned member’. It is the unique location in a model where the UseCase is defined (iv).
Zero or more ‘subjects’. These are the Classifiers to which the UseCase applies (for a given ‘subject’, the UseCase “specifies some behavior […] that the subject can perform”).

Section 16.3.2 in [1] states that “the owning classifier typically represents the subject to which the owned use cases apply”, but adds that “this is not necessarily the case.”

Since a Classifier (and therefore, a UseCase) can be a PackageableElement, and a PackageableElement is owned directly by a Package, a UseCase’s ‘owning classifier’ can be a Package.
Obviously, a UseCase doesn’t represent behavior that a Package can perform, because a Package is merely “used to group [model] elements, and provides a namespace for the grouped [model] elements.”

So, if and when a UseCase’s ‘owning classifier’ is a Package, the UseCase’s ‘subject’ defines the system (or its ‘subjects’ define the systems) to which the UseCase applies. But why can there be multiple subjects?

Although [1] doesn’t seem to state it outright, I suspect this is meant to support UseCase reuse.

In any event, a UseCase “specifies some behavior […] that [a system] can perform”, where ‘system’ is either the UseCase’s ‘owning classifier’ or one of the UseCase’s ‘subjects’ (if the ‘owning classifier’ is a Package). The article’s remainder uses the generalized term ‘system’, which covers both alternatives.

Section basis

The contents of this section are based on the following assertions.

A use case is to a ‘system‘ what an operation is to a class.
A ‘classifier behavior’ is to a use case what a ‘method’ is to an operation.

UML metamodel summary

These statements are based on the next diagram, which summarizes the classes and associations from [1] that are essential to these points. The diagram shows how the pattern of a Classifier (‘system’) and its UseCases mirrors the pattern of a Class and its Operations, and how the pattern of a UseCase and its ‘classifier behavior’ mirrors the pattern of an Operation and its ‘method’.

Classifier diagram

Because of the above, and using the default Classifier notation (7.3.8), we can show Classifiers (‘systems’) and their UseCases in a “classifier diagram” like the one below, similar to how we can show Classes and their Operations in a class diagram like the one in [2].

Imagine a consumer electronics retailer with two branded distribution channels, and a website for each channel. In the next diagram, the abstract channel website system represents what the concrete channel website systems have in common (v).

Justification

I don’t recall reading about a system hierarchy elsewhere, but it strikes me as valid, for the following reasons.

A UseCase’s ‘system’ is a Classifier, and as such is concrete or abstract (7.3.8).
Since they are Classifiers, ‘systems’ can be arranged into a hierarchy, using generalization relationships (7.3.8).
Since a UseCase is to a ‘system’ what an Operation is to a Class, a UseCase can be shown in the “use cases compartment” of a ‘system’, similar to how an Operation is shown in the operations compartment of a Class (7.3.8).
Because a UseCase is also a type of RedefinableElement “defined in the context of a classifier” (7.3.47), it can be “redefined more specifically or differently in the context of another classifier that specializes (directly or indirectly) the context classifier.” In other words, a UseCase of a super ‘system’ can be redefined by a sub ‘system’, similar to how an Operation (also a type of RedefinableElement) of a super Class can be redefined by a sub Class.

Type correspondence

As is the case for a class hierarchy, ensuring type correspondence is a must for a system hierarchy.

In this case, the statements ‘the Red Channel Website is a type of Channel Website’ and ‘the Blue Channel Website is a type of Channel Website’ are true, so the system hierarchy is appropriate.

Class diagram and method specification

Based on the earlier class diagram, the diagram below illustrates the scope of:

A class diagram.
What I know as a “method specification”.

Use case diagram and use case specification

Along similar lines, the following diagram illustrates the scope of:

A use case diagram.
What I habitually refer to as a “use case specification”.

Note:

Since the earlier diagram doesn’t include actors, neither does this one; however, actors are part of both scopes, as applicable.
While [1] specifies that both an Operation and a Behavior specify preconditions and postconditions, it makes no such statement about a UseCase, which is why these conditions are in square brackets in the above diagram.
However, given this comparison of a UseCase to an Operation, it stands to reason to expect a UseCase to specify preconditions and postconditions as well.
In fact, this is a must for a UseCase whose system doesn’t provide a Behavior for it, but defers this to its sub systems (like the object-oriented example’s ‘method deferral’ pattern in [2]).
See also the discussion on contravariance (of superclass and subclass preconditions) and covariance (of superclass and subclass postconditions) in chapter 11 of [5].

Use case parameters

Using the use case stereotypes I mentioned in earlier articles, use cases and parameters relate as follows.

A <> use case (short for ‘application function’; initiated by a person) typically has no parameters, because data is exchanged between user and system as a use case execution unfolds.
A <> use case (initiated by an electronic entity) typically has input and output parameters, because that’s the nature of a service. This kind of use case is most like an operation of a class.
A <> use case (short for ‘scheduled process’; initiated by a schedule or time) typically has no parameters, because it knows by design where to get its input and where to put its output.

Use case reuse

A system hierarchy enables use case reuse within the hierarchy, where there is type correspondence between the systems. Assigning a use case to multiple ‘subjects’ accommodates use case reuse without a system hierarchy, so there isn’t necessarily type correspondence between the systems.

Use case polymorphism

Both reuse approaches contribute to polymorphism, where different systems can respond to the same kind of message requesting the execution of a certain use case.

Scope of polymorphism

The scope of polymorphism for a given use case is the set of systems to which the use case applies (directly or indirectly) and can be one of the following.

When using a system hierarchy, the top-level system that defines a certain use case and the lower-level systems that inherit it, form what [5] calls a ‘cone’ of polymorphism, because the scope of polymorphism is (a branch of) the inverted tree structure of a system hierarchy, which is shaped like a cone.
When assigning a use case to multiple ‘subjects’, those systems end up forming what [5] calls a ‘ragged’ scope of polymorphism, because the scope doesn’t necessarily correspond to (a branch of) the inverted tree structure of a system hierarchy, and therefore doesn’t necessarily form a cone shape.

Implementation considerations

The table below summarizes for the hierarchy types discussed in this article to what degree they’re directly supported in the physical (technology-specific) domain.

Since these constraints do not apply to the logical (technology-neutral) domain to which use case models belong, we can use actor, use case and system generalization in use case models without reservation.

In conclusion

Actor, use case and system generalization (and specialization) are special tools we can add to our use case modeling toolbox. We may not use them all that often (they are listed in most-to-least-likely-to-use order), but it’s good to know they’re there, just in case we encounter those special circumstances where they’re just what we need to get the job done right.

Don’t forget to leave your comments below.

Notes

(i) To convey the fundamentals as clearly as possible, the example is purposely kept simple and excludes additional trip components (e.g., a cruise), trip component bundles (e.g., flight + hotel), and the use of external systems (supporting actors).

(ii) Associating the initiating actor with an abstract use case is notational shorthand for associating the initiating actor with each of the concrete use cases instead. As such, it upholds the rule that a concrete use case is a use case that has an initiating actor. See also the inherited association in the object-oriented example in [2].

(iii) Throughout the article, 2- or 3-part numbers refer to sections in [1] (e.g., 13.3.2) and UML role names are enclosed in single quotes (e.g., ‘classifier behavior’).

(iv) The ownership association between Classifier and UseCase is a specialization of the ownership association between Namespace (‘namespace’) and NamedElement (‘owned member’). While ‘owned member’ is specialized to ‘owned use case’, no specialization for ‘namespace’ is given. This article uses ‘owning classifier’ as that specialization, which [1] uses throughout the text but not in the formal model.

(v) A “classifier diagram” introduces a clash of terms, because in such a diagram:

An abstract use case is a UseCase for which the system doesn’t provide a Behavior, not a UseCase that cannot be instantiated.
A concrete use case is a UseCase for which the system does provide a Behavior, not a UseCase that can be instantiated.

To avoid this clash, alternative terms in a “classifier diagram” could be:

An ‘abstract as operation’ UseCase.
A ‘concrete as operation’ UseCase.

References

[1] Object Management Group (OMG), OMG Unified Modeling Language^TM(OMG UML), Superstructure, Version 2.4.1.

[2] Willem Van Galen, Generalization and Use Case Models, Part 1, 12 August 2013, http://www.batimes.com/articles/generalization-and-use-case-models-part-1.html

[3] Willem Van Galen, Putting The Inclusion Use Case In Focus, 21 August 2012, http://www.batimes.com/articles/putting-the-inclusion-use-case-in-focus.html

[4] Willem Van Galen, The Include Relationship’s Other Use, 18 June 2013, http://www.batimes.com/articles/the-include-relationships-other-use.html

[5] Meilir Page-Jones, Fundamentals of Object-Oriented Design in UML, 4th Printing, September 2000, Addison-Wesley.

Generalization and Use Case Models, Part 1

Written by Willem Van Galen on August 12, 2013. Posted in Articles.

INTRODUCTION

Starting with an object-oriented example to set the stage, this article explores generalization (and specialization) in use case modeling. Part one outlines key concepts and addresses generalization of use case actors. Part two covers generalization of two additional use case model elements.

SETTING THE STAGE

The best way to promote a common understanding of generalization is through a simple object-oriented example, especially since use case models are founded on object-oriented principles (i). Most of the concepts encountered in the example trace back to [1] and [2], which strike me as highly informative books.

An object-oriented example

Imagine an object-oriented inventory system for an organization’s tables and chairs. In the real world, each table and each chair is a physical object. In the electronic world of the inventory system, each physical table is represented as an electronic object of type Table and each physical chair is represented as an electronic object of type Chair, so that:

Each object’s type indicates what the object is in and of itself (independent of any context), for its entire existence (the type doesn’t change during the object’s lifetime).
An object’s type corresponds to the concrete class in which it is created (ii), so that an object of type Table is created in the concrete class Table and an object of type Chair is created in the concrete class Chair.

The Table and Chair classes are defined beforehand and specify the kinds of characteristics (e.g., particular attributes and associations) for which an object created in the class has individual characteristics (e.g., specific attribute values and links). For example, a Chair object has a True or False value for the Chair class’s hasArmRests attribute.

In defining these concrete classes, we may notice that they have certain kinds of characteristics in common (e.g., they both have the ‘color’ attribute). This is a clue that we can generalize these classes to a superclass, like Furniture Piece, to represent what tables and chairs have in common.

Since each object that belongs to the Furniture Piece class is either a Table or a Chair, the Furniture Piece class is said to be abstract, to indicate that it cannot be instantiated (there will be no objects of type Furniture Piece).
Another way to express this is that the Furniture Piece class is ‘completely partitioned’ (it is completely subdivided into subclasses).

Furniture Piece represents a ‘generalization’ of (the objects in) its subclasses, as depicted in the following diagram.

Class hierarchies

Generalizing classes creates a class hierarchy. In this example, it starts with a flat structure of two concrete classes that reflect what their objects are in and of themselves, which is then expanded into a hierarchy by adding an abstract superclass that represents what objects in the two subclasses have in common.

The class hierarchy in the diagram above is represented below as a class diagram, expanded with some attributes (iii), an association, and some operations (see later).

Inheritance

A key feature of a class hierarchy is inheritance, in which kinds of characteristics defined for a superclass are inherited by its subclasses.

Inheritance is a class construct, not an instance one.

This means that, for example, the Table and Chair classes inherit the color attribute from the Furniture Piece class, such that each Table and Chair object must be assigned a value for the color attribute at the time of the object’s creation.
It does not mean that each Table and Chair object inherits its particular color (a color attribute value) from a corresponding Furniture Piece object, because there are only Table and Chair objects, no Furniture Piece objects.

Likewise, the Table and Chair classes inherit the association with the Location class from the Furniture Piece class, such that each Table and Chair object may have a link to an ‘assigned location’.

Specialization

A class hierarchy can also result from specialization. This means introducing a subclass, and representing how it differs from its superclass by defining kinds of characteristics that apply to the subclass but not to the superclass (iv).

To a superclass, a subclass is a ‘specialization’ of the superclass.
To two or more subclasses, a shared superclass is their ‘generalization’ (v).

In the earlier class diagram, Table and Chair are specializations of Furniture Piece, where Table has the maxNumberOfPeople attribute (but Furniture Piece doesn’t) and Chair has the hasArmRests attribute and the getSeatingPosition operation (but Furniture Piece doesn’t).

The following three sections describe additional examples of specialization.

Deferring methods to subclasses

Apart from inheriting attributes and an association, Table and Chair also inherit the getCapacity operation (vi). An operation on a class represents that an object in the class is capable of a named behavior, in this case, getting its capacity.

Capacity represents the number of people the corresponding physical object can accommodate.
A Table’s capacity is indicated by the maximum number of people that can sit around it, while a chair’s capacity is always equal to one.

The Furniture Piece’s operation is shown in italics to indicate that it’s abstract. This means that Furniture Piece doesn’t provide a method for this operation but leaves it up to its subclasses to do so (vii). In contrast, Table and Chair show the operation in straight font to convey that it’s concrete. This means that each subclass provides its own method for the operation.

Thus, when a Table object is asked to perform the operation, the Table class’s method is to return the Table object’s value for the maxNumberOfPeople attribute, and when a Chair object is asked to perform the operation, the Chair class’s method for this operation is to return 1.

So, providing a method for the superclass’s operation is deferred to the subclasses.

Overriding a method

An alternative pattern for modeling the getCapacity methods is as follows.

Furniture Piece’s getCapacity operation is concrete and its method is to return 1 (i.e., this is the default method).
Chair inherits the method from Furniture Piece, but Table defines its own method, which is to return a Table object’s value for the maxNumberOfPeople attribute.

Thus, Table’s own method overrides Furniture Piece’s default method.

Adding an operation and its method

Chair has an operation over and above the one it inherits.

The getSeatingPosition operation returns “in” or “on” for a given Chair object.
The corresponding method gets the Chair’s hasArmRests attribute value, and returns “in” or “on” based on whether this value is True or False, respectively.

The added operation helps to define Chair as a specialization of Furniture Piece.

Type and class

In philosophy, there is a difference between a type (which represents a certain concept, like chair) and a class (which is a collection of objects, such as tables and/or chairs).

In class diagrams, these two aspects are combined, such that a class represents both a concept (through the kinds of characteristics that characterize it) and a collection (of objects that have individual characteristics for those kinds of characteristics).

Even so, there is still a linguistic distinction, because an object ‘is of’ a certain type but ‘belongs to’ (is a member of) a class. At minimum, an object that is of a certain type belongs to the concrete class in which it is created; if that class has any superclasses, the object belongs to those as well, albeit indirectly.

Type correspondence

A key measure of the correctness of a class hierarchy is type correspondence. This means that the statement ‘ is a type of ’ must be true for each combination of subclass and superclass (representing the subtype and the supertype, respectively, keeping in mind that a class represents both a type and a collection).

For example, ‘a Table is a type of Furniture Piece’ and ‘a Chair is a type of Furniture Piece’.

Let’s now turn to generalization (and specialization) in use case modeling.

GENERALIZING ACTORS

Why actors can be generalized

In [3], Actor is a subclass of BehavioredClassifier, which is a subclass of Classifier. Because generalization is a feature of Classifier, Actor inherits this feature from that class. In other words, actors can be arranged in an actor hierarchy.

An example

A concrete use case has one and only one initiating actor (viii), but what if some of a system’s use cases can be initiated by users of different kinds, such as Contact Centre Specialists and Customer Statement Specialists? Actor generalization solves that problem, as illustrated in the following diagram.

Actor generalization (and specialization) creates an actor hierarchy.

What an actor means

The earlier object-oriented example deals with electronic objects internal to a system, each of which comes into existence by being created in a concrete class. In contrast, the notion that actor instances are created in concrete actors doesn’t apply, because:

An actor represents actual entities that can use a system (e.g., actual people, actual systems, actual functions), which already exist in their own right.
An actor represents a role some entity may play, not what the entity is in and of itself.

When an actor is concrete, it means that entities are assigned to it, not that they are created in it.

Two patterns

In fact, we need to be aware of two modeling patterns, for which I use the following terms and definitions.

Classification: arranging entities in classes based on what the entities are in and of themselves, such that an entity belongs to one and only one concrete class that reflects the entity’s type, and belongs to that class for its entire existence (ix).
Categorization: assigning entities of one or more types to categories, based on point-in-time rules, judgment or preference, such that an entity may belong to multiple categories at once, and may belong to a category for part(s) of its existence.

Thus, the earlier class hierarchy reflects classification, while the above actor hierarchy represents categorization. The next diagram shows the latter (x).

Like the Furniture Piece class in the object-oriented example, the Customer Service Specialist actor is abstract, because it is completely partitioned (i.e., completely subdivided into subactors).

Unlike the Furniture Piece class, the Customer Service Specialist actor is not ‘disjoint’, but ‘overlapping’ (as [3] calls it), because a given person can in principle belong to multiple subactors at once (a clue we’re dealing with categorization, not classification).

Type correspondence

As for a class hierarchy, ensuring type correspondence is a must for an actor hierarchy, albeit that here the types are strictly the actor names themselves, rather than the types (conceptual or otherwise) of actual users (e.g., Person).

In this case, ‘a Contact Centre Specialist is a type of Customer Service Specialist’ and ‘a Customer Statement Specialist is a type of Customer Service Specialist’ are true, so the actor hierarchy is appropriate.

Actor hierarchy antipattern

Sometimes, use case texts advocate adding a generalization relationship between two concrete actors. This is only appropriate when any and all members of the subactor are always members of the superactor as well. If not, this kind of actor hierarchy is a misrepresentation, as the following diagram illustrates.

Below are two more examples of an actor hierarchy.

To avoid an inappropriate actor hierarchy, add an abstract superactor as shown earlier, and let the overlapping nature of the concrete subactors handle the scenario where a person can belong to both subactors, through individual assignment.

NOTES
(i) To keep it simple, the example only deals with one abstract superclass and two concrete subclasses.

(ii) Some refer to instantiating an object, which seems inappropriate. Instantiation means representing a concept (e.g., chair) by an instance (e.g., a chair), so it’s the concept that is instantiated, not the instance. In object-oriented terms, a concrete class can be instantiated (can have objects created in it), but an abstract class can’t.

(iii) While most attributes have a data type like Boolean, Integer or String, the data type of each of the remaining attributes refers to an enumeration, which is a list of the attribute’s allowed values.

(iv) Specialization isn’t necessarily the opposite of generalization. You can’t generalize a single class to a superclass, but you can specialize a class to a single subclass. The latter means that:

The class is concrete to begin with (objects are or can be created in it).
A subset of the class’s objects are moved to the subclass (i.e., they’re deleted from the class and created in the subclass with a new type that equals the name of the subclass).
The class retains its remaining objects (whose type equals the name of the class).
In other words, the class is not completely partitioned.

(v) This article avoids ‘generalized’ and ‘specialized’ as qualifying terms, because they’re ambiguous (e.g., does ‘generalized’ apply to the two or more classes being generalized, or to the class that represents the generalization?); the unambiguous qualifiers ‘super’ and ‘sub’, as well as ‘generalization’ and ‘specialization’, are used instead.

(vi) Class operation: to be performed by a class as a whole (e.g., create an instance). Instance operation: to be performed by a specific object in a class. In this article, each operation is an instance operation.

(vii) Method: a representation of how a class or an object will respond when asked to perform a given operation.

(viii) The examples in 16.3.6 of [3] where “more than one actor instance is involved in initiating the use case” can be represented more simply as one initiating actor and one supporting actor.

(ix) There are entities that change types during their existence (e.g., a caterpillar changes to a butterfly), but such type changes are outside the scope of this article, because they usually don’t have to be dealt with in a typical system.

(x) See 16.3.1 in [3], “Actors may represent […] multiple different instances.”

Don’t forget to leave your comments below.

REFERENCES

[1] Meilir Page-Jones, Fundamentals of Object-Oriented Design in UML, 4th Printing, September 2000, Addison-Wesley.

[2] Bruce F. Webster, Pitfalls of Object-Oriented Development: A Guide for the Wary and the Enthusiastic, 1995, M&T Books.

[3] Object Management Group (OMG), OMG Unified Modeling LanguageTM (OMG UML), Superstructure, Version 2.4.1.

Business Case Clarified – Vision-Schmision Part 5

Written by Marcos Ferrer on July 9, 2013. Posted in Articles. 1 Comment on Business Case Clarified – Vision-Schmision Part 5

Motivation:
“If you are going to be incomplete, at least nail your most important business process! 

Ingredients:
Business Need
Any Enterprise Architecture not limited to:
Organization (Business) Goals & Objectives
Performance Metrics
Organizational Process Assets
All Solutions [Constructed, Deployed]
Ten Stakeholder Types (and all their ideas)
All Information Available on Risks
Business Analysis Resources As Needed

“Danger, Will Robinson!” If you are wearing a PM hat, your sense of “scoperiety” is about to be violated, but try to relax. This is business analysis, not project analysis.

Welcome to Part V of our series on Enterprise Analysis, AND the use of these tasks are not “sequential” as presented, but highly iterative. ALSO, I remind myself (my readers need no reminder) that we have a gentleperson’s agreement that we don’t have time to be “complete”. All we are doing is trying to improve on “Go Paperless for $10,000,000” (see the Schmision Part 1 for more details).

A good way to get a higher quality “scope” out of the initial vision is to play “what if” with a quality business case. This is because any significant project represents something new to the enterprise “consciousness”. The newness implies risk, uncertainty and many assumptions. Even the constraints are assumptions, especially if the constraints are not analyzed for their impact on potential outcomes. “What if” thinking is one route to making higher quality decisions given uncertainty. * This is especially important if formal feasibility studies will not be done before full project commitment. **

Enterprise Analysis (which includes Requirements Analysis work) led us to Define the Business “Knead”, Assess Capability (and other) Gaps, and Define Solution Approach(es) and Solution Scope(s). We pluralize the solutions on purpose. First of all, we wish to present as professional BAs, offering choices, pros and cons, not opinions, attitudes and personal preferences. Second of all (a major point of this series), the rush to solution” is a key failure mode of large projects. By examining alternatives (see Part IV last month), we begin to understand the true impacts of the solution choices, and the tradeoffs inherent in choosing a specific project scope and set of priorities.

This is great “pre-project” stuff – you know – requirements as its own “pre-project project”. This kind of practice could maybe improve the quality of the Project Management Office’s “triage”. It might also (my favorite) give the next analyst in line a head start on next analysis steps. There is ALWAYS a next analyst in line, because there are always next analysis steps – pay us now, pay us later). If no professional analyst is assigned, it means that the end users step into the role with a vengeance. Example analysis by end user experts: “This stinks, can’t use it.”

To minimize the need for such expert analysis, we imagine starting the project on the right foot by presenting a high quality business case instead of a weakly analyzed cost justification. In case you forgot, click here for a glance at the “cost justification” from Schmision Part 1.

Now, let’s compare the “just costs” analysis to a business case that resembles the actual business we are in. Notice the beginnings of (and one of the primary purposes of) traceability.

We start by “cleaning up” (analyzing) the Business’ goals and objectives. We do this by reconciling their relationships with each other and with the problems and the opportunities as understood so far (the “Knead” itself). In return we get guidance for how to organize the business case, better understanding across the high level requirements, PLUS feasible “summary” potential.

This analysis following (once again, with the gaps???) immediately suggests gaps. We do this analysis by figuring out that “Some of these things belong with the others”. We continue to add gaps that we (all stakeholders) see, and fill them where we know how.

Goals/Objectives/Issues/Opportunities and their relationships:

Increase 2013 Undergraduate enrollment from 37,213 in Fall 2012 to 41,500 for Fall 2013. DO THIS BY:
1. Increasing applications from around 49,000 to over 55,000 (how??? How many of the new applicants will be qualified? How many will then accept our offer to attend??? Can we )
2. Reducing lost applications/applicants (see issues 1, 2 below).
3. Reducing dropouts (and transfers???) from 3723 per semester to 1500 or fewer. This should result in Undergraduate enrollment levels of at least 38,500 at end of Spring 2014 (relate this to goals above???). DO THIS BY:
1. 1. Improving student satisfaction from 82% (2012 results) to 90% as measured by the 2013 annual “Student Satisfaction” survey to be given 12/1/2013 (see issues 1, 2, 4 below).
  2. Increase summer school enrollment 10% from 9833 in 2012 to 10,816+ by 2013 (how???).
  3. Attracting more undergraduate students to stay with us in anticipation of continuing their education within our expanding Graduate programs (see Goal B, below):
  4. Increase Fall Graduate enrollment from 12,360 in Fall 2012 to 13,500, to be split between academic departments. Goals are as follows:
1. 1. 1. Law – 200+
    2. Business – 430+
    3. Media / Arts – 120+
    4. Public Safety (new department) – 320 plus
    5. PhD Programs – 70 plus
Reduce costs even as business grows. DO THIS BY:
1. Reducing employee turnover from 10% per year to 5% (???How???).
2. Freezing hiring at 2012 levels (1017 employees) except for:
  1. Except for one new Dean for the new Public Safety department.
  2. While adding 20 contract faculty for new teaching workload (S
  3. While adding 20 contract faculty to offset expected contract attrition (we assume that contract employees and regular employees have the same impact on paper workloads).
3. Improving employee productivity by XX%??? (see issues 1, 2, 6 below)
  1. By reducing time spent paper (information) handling
  2. ???With improved systems (integrated faculty scheduling, online student registration and class scheduling)???
  3. ???With other system initiatives??? (see issues 4 & 6 below)
4. Cutting annual document archival costs by 90% for FY 2014 (see issue 5 below).
Improve community relations, as indicated by the annual community feedback session plus a (new) formal survey of the community and trends in feelings and attitudes.: DO THIS BY:
1. Expanding English as a second language outreach classes from 4 to 16.
2. Improving student satisfaction??? – See above – students are community members too???). (see issues 1, 2, 4 below)

Known problems and opportunities related to the use of paper include, but are still not limited to:

Specific Issues:

Bottlenecks / slowdowns in the student admission process due to sharing the paper application file (see Admit Student process in Appendix A). Our biggest competitor can give a prospective student an admission decision in less than two weeks, while our average is currently 5 weeks (???This average seems low given some of the delays given below – is this our average when everything goes well???). While we do not know how many students we lose because of delay, surveys show that over 30% of our applicants complain about the delays. Reasons given by applicants for not attending included:
1. Missing financial aid, acceptance by other colleges, family or health issues, inability to provide a complete (Surveys were limited to applicants in our systems. We are not sure if we lose prospects that never applied on line, because they knew they were too late???).
Lost or misplaced student transcripts delay financial aid. Estimated as around 250 per year never found, new transcript requested, and around 4000 that are stuck in inboxes, new transcript requested, original transcript later found (what happens???) student transcripts delay financial aid. There are other reasons that delay financial aid (missing information from students), which we believe is the cause of half of our 3723 student dropouts last semester. Financial aid delays can stretch for months instead of weeks, and always contribute to admissions decision delays.
To hire faculty requires that anywhere from 10-20+ persons and 3+ academic departments (undergraduate, graduate and professional, and any “related” graduate programs???) examine the prospect’s academic transcripts. Confidentiality & privacy considerations discourage or forbid photocopying or e-mailing the transcripts. It can take from 2 to 12 weeks for the official paper transcript to pass from hand to hand, group to group.
Grades are being computed and delivered by faculty on paper, for entry into a grade reporting system by each department (Dean’s Office). When questions arise about the grade, there is no detail to explain how the grade was awarded. Faculty explains that the criteria for grading are explained and written on the board at the beginning of each semester (every faculty does this???), student complaints to the ombudsman notwithstanding. The student must fill out a form to formally request explanation from the faculty member. The student ombudsman receives about 200 grade related complaints every semester. The number of formal forms submitted each year is less than 5. The reasons for the difference are unclear? There are approximately 37K students enrolled).
Archival costs total $453,000 per year as of 2013. Almost half of these costs seem out of control due to repeated need to access already archived documents. These documents are often related to students who are taking longer than 4 years to finish their degrees. We need policies and electronic search to reduce this repeated manual paper archive searching.
General Issues:
Departmental managers recently estimated from their own observations that employees spend anywhere from 10% (executives) to 50% of their time finding, moving and re-filing paper documents in support of their more expert administrative and academic work. These include, but are not limited to (are there estimates of quantities, time impacts per document?):
1. Health care
2. Counseling
3. Housing
4. Part-time work
5. Recruiting, hiring, firing, benefits administration (and other HR functions)
6. Regulatory compliance
7. Legal work
8. Grading
9. Ombudsman cases
10. Veteran’s educational benefits
11. Fraternity & student organization oversight
12. Faculty mentoring and counseling
13. Preparation and follow-up for management meetings
It is anticipated that more specifics are to be discovered if a decision is made to further analyze and detail requirements for a business case.

=================================

We will use the above reconciliation (highest level business viewpoint) to trace an electronic document based solution alternative (AS-IS vs. TO-BE) that we imagined in Schmision Part 4. When we are done, we will (imagine that we) have enough “dough” to imagine a business case, at last. This usually takes the form of a spreadsheet, not provided here . Let me know if you get the idea. I have mostly limited myself to the CRITICAL elapsed time for applicants in the analysis that follows, but could have added in more level of effort and personnel impacts as well.

Admit Student – “Potential Happy” Path(s):

Step #	Step Description AS-IS	New Step TO-BE(s)?
01	Applicant (potential student) fills out an accurate and complete application package.	Applicant fills package on line, System verifies it is complete and accurate, so applicant can correct it before submitting – skip to step 13 (this choice seems out of scope for e-docs, yet maximizes impact on goals and objectives)
02	Applicant mails application package to Admissions	Applicant scans & emails package to Admissions – skip to step 9 (in scope for e-docs)
03	U.S. Post Office provides delivery service to Campus Mail Processing twice per day	Eliminated 1-7 days elapsed time in most cases.
04	Campus Mail Processing sorts application packages into Admissions delivery box	Eliminated 1-2 days elapsed time in most cases. Campus Mail Processing scans and emails package to Admissions – skip to step 9 (in scope for e-docs)
05	Admissions sends a Mail Pickup Person to Campus Mail Processing twice per day to: Pick up Admissions mail and bring to Admissions department. Deliver Evaluated Applications for copying and distribution to multiple departments	Eliminated 1/4-day elapsed time on average. Elapsed time lost (10 mins to 1/2 day???) Level of effort (20 mins to 40 mins???)
06	Admissions time stamps all received mail.	Eliminated. Level of effort (1 hour to 10 hours each day???)
07	Admissions Clerk distributes mail to Application Evaluators.	Eliminated. Elapsed time lost (10 mins to 1/2 day???) Level of effort (1/4 day to 1/2 day???)
08	Application Evaluator time stamps all received application packages before working on any particular package.	Eliminated. Elapsed time lost (10 mins to 1/2 day???) Level of effort (10 mins to 3 hrs???)
09	Application Evaluator selects the application package with the oldest time stamp.	Time creating and maintaining an accurate paper queue is estimated at approximately 5-10% of Application Evaluator’s time.
10	Application Evaluator determines that the application package is complete.	Elapsed time lost (10 mins to 1 hr???) Level of effort (10 to 15 mins???)
11	Application Evaluator determines that the application package is accurate.	Elapsed time lost (1 hr to 10 hrs???) Level of effort (10 mins to 3 hrs???)
12	Application Evaluator passes the application package to Campus Mail Service inbox for twice daily delivery.	Time and effort guesstimated above.
13	Campus Mail Service copies application package for distribution to multiple departments: Academic Advisor’s Office (Verify Academic Qualifications) Financial Aid Office (Coordinate Financial Aid) Veteran’s Aid Office (Coordinate Veteran Aid) Prospect Marketing Office (Coordinate Prospective Student Events) Admissions Office (Communicate Acceptance to Prospect) Housing, Cafeteria, Infrastructure (Prepare for Student Arrival) Student Orientation Office (Prepare for Student Onboarding)	Elimination of manual error and delays before delivery to academic departments may save from 4 to 24 days elapsed time. Electronic copies will ease sharing of data with agencies and may eliminate as much as 1 day to – 3 weeks elapsed time (Veteran’s takes 3 weeks to scan any unscanned financial aid apps).
	Student Onboarding
WHEW!	I AM REALLY OUT OF TIME.	ESTIMATES BELOW OFFER BENEFITS FROM REDUCED ELAPSED TIME:
	Lost prospects that were lost due to clumsy Administrative processes.	Estimated by Academics as 15-25%??? of the lost (not all) prospects.
	Prospects lost due to slow Academic processes.	Estimated by Administrators as 15-25%??? of the lost (not all) prospects.
	ETC.	🙂

NEXT MONTH:

Something easier and more fun, we hope 🙂

==============================================================

*Bayes’ Theorem is another, and it allows us to measure our beliefs against emerging evidence. Unfortunately Bayes’ Theorem is much easier to apply to search and rescue missions than to complex business projects, which don’t even allow building robust business cases most of the time. The “retrospective” (lessons learned) in Agile is a mild attempt to apply “evidence” to beliefs. We set some priorities (prior beliefs), do some work (experiment and gather data), we learn what happens (“facts”, “evidence” and opinion), and then we update our beliefs (new priorities).

** The full project becomes the feasibility study, with the usual results. One way to make every project work better is to do small pilots (you knew that) before full speed ahead (ready, aim, fire, instead of fire, ready, aim). This makes the “feasibility” attribute of the full project more manageable and less likely to cost the moon.

*** Uh huh 🙂

Don’t forget to leave your comments below.

TARDIS – Time and Relative Dimensions in Scoping

Written by David Morris on March 4, 2013. Posted in Articles. 1 Comment on TARDIS – Time and Relative Dimensions in Scoping

One of our biggest concerns as business analysis practitioners is scope: how do we define scope, how do we guarantee that we can deliver everything that satisfies the scope, and how do we ensure that we don’t stray outside the scope?

In other words, how do we place our hand upon the BABOK and swear that the analysis we give will be the scope, the whole scope, and nothing but the scope?

How wide is it?

When most people think about scope, they think about the boundaries of an area or domain, constraining the breadth of what we look at so that we focus more sharply on those processes and activities that require change.

This definition is inherently two-dimensional.

Imagine an episode of Doctor Who, where he and his trusty sidekick have to work out how they can get across a puddle. If the Doctor thought about problems in just two dimensions, he might think he can solve the problem of crossing the puddle by looking only at how long and wide it is; because this tells him whether he can step or jump across it.

This perspective is probably sufficient early in a project where we want to define the business scope, but the real world is not just two-dimensional.

How deep is it?

Within and below the business scope is the solution scope. Most problems I have seen with scope are with the solution scope; that is, how simple or complex will the solution be, are we happy with manual processes alone, with some minimal technical support of the main scenario, or do we need full automation of every possible scenario.

This takes the definition into the third dimension, i.e. how deep it is.

So now Doctor Who could use his sonic screwdriver to gauge how deep the puddle is; which tells him at least whether he can easily walk across it, wade through it up to his waist, or that he’ll need a boat.

The deeper it is the more expensive or time-consuming it will be; but we need to know that before we start, right? Too many projects are approved to go before the solution options have been considered, and this is one of the most common reasons for cost and time blow-out.

The only thing constant is change

And of course, one of the biggest issues for our projects is that they assume the scope is fixed at the outset and work to deliver that; only discovering toward the end that the scope has shifted or grown so that they will struggle to get sign off or worse still, the business will sign it off and never use it.

Of course, this is about the state of something over time, and so introduces the fourth dimension: time.

Back to our puddle; if the Doctor looked at it in the morning, then popped off for a few hours, when he came back the puddle may have dried up, run somewhere else, or grown in area or depth if the rain continued. He cannot then hope to get across it the same way, and if it’s gone completely he doesn’t need to bother at all.

We should never assume the scope stays fixed; and how can we deal with that?

Denial: Some organisations seek to constrain this by enforcing strict change control, in effect putting brakes on change. While this means the scope stays the same during the life of the project, it doesn’t mean it will be fit for purpose when it’s ready for delivery – so we get cost and time blow-out as we redress that.

Acceptance: Smarter organisations accept that scope will change; they baseline the business scope, and work in smaller chunks to elaborate the solution scope on an ‘as needed’ basis. They can continuously check that the scope is still sound, and if it has changed, avoid doing work that will be unnecessary. Although this could end up with only delivering 80% of the original solution scope, the project can still end on time and within budget … or they can choose to continue if that final 20% is really needed.

At the end of the episode, as Doctor Who vanishes off on his next adventure, we’re faced with what’s left and have to ask:

What has been your experience of problems with scope?
How does your organisation seek to cope with changes in scope?
Are there any other approaches that you have seen work?
And, most importantly, what was so important about the puddle and couldn’t the Doctor just have used the TARDIS to reappear on the other side?

Don’t forget to leave your comments below.

The Science of Business Analysis

Written by Cathy Brunsting on January 29, 2013. Posted in Articles.

This is the second of a four-part series exploring whether ‘Business Analysis’ is art or science. In the first article, Business Analyst, Greg Kulander, discussed how his career has taught him both the science and art of Business Analysis. This week we’ll look at the case for Business Analysis as Science.

“Is Business Analysis art or science?”

The Merriam-Webster dictionary defines art as “a skill acquired by experience, study, or observation” and science as “the state of knowing: knowledge as distinguished from ignorance or misunderstanding.” Dictionary.com further defines science as “a branch of knowledge or study dealing with a body of facts or truths systematically arranged and showing the operation of general laws.”

Business Analysis in the 80s

When I first started out in IT back in the early 80’s, we didn’t have any business analysts at the company I worked for. However, there was still a need to understand what the business wanted in order to develop the right products / solutions for our clients. I fell into the ‘art’ of business analysis mostly because I was the developer who wanted to know why we were doing what we were doing for the project. And, I was the only developer who was eager to talk to the users to find out that information. I definitely acquired my business analysis skills by experience, learning what worked and what didn’t the hard way.

However, while the field of Business Analysis may have been more art than science in the past, over the past decade it has evolved into a science. Business Analysis now has a defined knowledge base, defined procedures and tools for accomplishing the business analysis tasks, and new, defined ways of measuring both an organization and an individual Business Analyst’s (BA’s) competency levels.

IIBA is established in 2003

A large part of the evolution into science was the emergence of a formal association dedicated to the business analysis profession – the International Institute of Business Analysis (IIBA), which was established in 2003. The IIBA organization created:

The Business Analysis Body of Knowledge (BABOK) which formalizes the knowledge of the profession, as defined by practitioners in the field.
Tools, such as the IIBA Business Analysis Competency Model and the Self-assessment Tool, which can be used to evaluate and measure the effectiveness of an organization’s business analysis practices and the competency level of their Business Analysts.
The independent, internationally recognized certification programs – the CBAP (Certified Business Analysis Professional) and the CCBA (Certification of Competency in Business Analysis) – which evaluate and test the experience level and knowledge of individuals in the business analysis field.

With the advent of the IIBA, the business analysis profession entered the ‘state of knowing.’

Tools and Templates

In addition to the industry standards established by the IIBA, there are other signs that the business analysis profession has become a science. Most companies today either have or are developing a Business Analysis process as part of their system/product life cycle. They have a defined process for initiating projects, eliciting and analyzing requirements, managing requirements and change control, and evaluating the quality of requirements. Companies often have established metrics for measuring the effectiveness of their business analysis process and practitioners.

There are also well-defined requirements templates that can be used to capture business, functional, technical and non-functional requirements. While these templates can vary from company to company, they are being defined and followed by most organizations. Business analysts can easily get example templates via the Internet or from professional business analysis books .

Finally, there are now a number of commercial tools available to aid BAs in their job:

Prototyping tools (iRise , Serena Prototype Composer, Axure RP, Balsamiq, etc.)
Requirements Management tools (Requisite Pro, DOORS, TestTrack RM, etc.)
Requirements Definition tools (UML, Rational Composer, etc.)
Business Process Management tools (Appian, BEA Systems, IBM, etc.)
Agile requirements tools (Mingle, Rally, etc.)

When the Business Analysis profession first began to emerge, it took a lot of creativity and “art” on behalf of the practitioners to understand requirements and the Business Analysis role. We all had to learn a skill that did not have a defined knowledge base, proscribed approaches or tools to help us practitioners. But, today, the field has well-defined best practices, systematic ways of gathering and analyzing business needs, and recognized ways of measuring competency of practitioner’s competency levels.

The Business Analysis field is now a recognized science.

Don’t forget to leave your comments below.