Paul Bowden
MKS Systems, http://www.mks.com

 Abstract

The UML technique of Use Cases provides a powerful tool to elicit and document stakeholder requirements. While usually used in a traditional development context, use cases can be deployed with good effect when implementing an enterprise scale Application Lifecycle Management (ALM) system.

Application Lifecycle Management encompasses the processes and tools employed at all stages of development: from project inception and requirements gathering to deployment and maintenance. With this much broader scope we must take care when planning and deploying several complex interacting systems.

This article describes how use cases can help us plan and implement ALM processes and tools.

Introduction

Implementing an enterprise application lifecycle management system is very different from giving your developers a new version control system to put their source code in. Enterprise ALM affects processes that control the whole software development lifecycle and very likely other areas of the business. For instance an application that supports the financial management of the business will most likely be subject to corporate governance regulations and our systems must be able to demonstrate compliance. Enterprise ALM is always driven by the goal of delivering value to the business and alignment with business strategy, so we should be clear about our scope, the business stakeholders we are going to impact and how we can measure our success.

As with all activities, planning is key. What tools and techniques can we apply to reduce risk and ensure a timely implementation that delivers value? This paper will focus on an important technique in UML, use cases, which can help when eliciting requirements, documenting and planning the implementation and validating we have the systems we need.

A use case is a sequence of actions a person takes to achieve a specific goal. In more detail we can say:

We identify a set of activities, performed in a certain order

We know who performs the actions. The "doer" is usually referred to as an actor. This acknowledges the fact that we may be interested in a class of people, a particular role or indeed another system.

• There is a defined result to the actions: a goal.
• The use case has a descriptive name.
• The use case is usually summarised in a diagram linking the actors to the use cases they perform.

Use cases, being descriptive text within a more or less formal framework, we can develop, discuss and manage them with any of our stakeholders.

By way of a very simple example, thinking in terms of ALM, we can quickly come up with: Check out file. Our actor will be something like Developer, and we can describe the use case thus.

The second paragraph in our use case identifies the "post-conditions", that is, the state of the system after the use case has been completed. Where important, we can also specify pre-conditions for the use case. Pre-conditions specify things that must be true before the actor can execute the use case; for example they have logged on.

The use case can also explore alternate sequences of action or "paths". The non-exceptional path through the use case is sometimes called the happy path. It will often be instructive to explore alternate paths through the use case. The Check Out use case above provides a good illustration. What happens if the actor tries to check out the file and another developer already has it locked?

This use case expresses an important policy we will implement: developers won’t wait for the lock to be released or make changes locally; they will branch around the lock. Of course, we could choose another policy but the path through the use case has forced us to make the decision explicit.

The use cases are usually illustrated with a simple diagram showing the actors and the use cases they execute.

The diagram complements the detailed text of the use cases by giving a visual representation of the use cases we are considering. This can be useful in workshops where we want to focus discussion on a particular area of the implementation. For instance, how and when we will branch the codebase to support post-release maintenance.

Templates

There are many templates for use cases available as part of methodologies or from various web sites documenting best practice or as part of paid-for consulting. The precise form use cases take is a hotly debated topic and the best advice offered seems to be to do what works for you. However, since we are likely involving a broad range of stakeholders our guiding principles should be clarity to a wide non-technical audience.

Use cases capture functional requirements but situations may a rise where the development of requirements is separate from that of the use cases. For instance requirements may be prepared in advance by the (internal or external) customer. In this case the requirements map to use cases. This mapping will form a traceability matrix where all requirements are fulfilled by the use cases allowing us to demonstrate that we have satisfied the requirements.

Use cases and functional specifications are complementary and can be used together if the need arises. It is obviously important that they are consistent. A functional specification can capture much more detailed information (for instance all the field definitions in a workflow) that would simply cloud a use case and negate its usefulness.

If, when embarking on an enterprise implementation, we try to identify all the use cases that the developers, architects, managers, etc. will execute we’ll have an enormous job on our hands. To avoid so called "analysis paralysis" we need to focus our attention on analysis activities that deliver value. Examining routine check-ins will not be a good use of time. However, a detailed description of how a check-in triggers an automatic integration build will be. This use case is worth considering because

• It is complex in that it involves the interaction of several systems
• It is a part of the implementation that delivers significant business value
• It is important to the success of the implementation

Using these criteria we can identify the key use cases of the implementation. Investigating these use cases will feed into several aspects of the project planning process

• Scoping
• Estimation
• Security
• Documentation
• Training
• Identification of risks

The diagram below shows a set of use cases grouped into a two phase implementation. As part of the scoping exercise we have identified the use cases that we will implement first and those that will wait until a later stage (the criteria used to make this judgement may be complex. However, the analysis of the use cases will give us the information we need to make an informed choice). Irrespective of any more detailed description of the individual use cases the diagram shows the scope of the project succinctly and clearly.

The development of all use cases to some degree of detail at an early stage is useful as it allows us to verify that the set is consistent and fulfils the requirements of the project as a whole, even if implementation is phased. It also demonstrates the understanding between the team, or vendor, implementing the system and the customer or stakeholders.

The two use cases below summarise how we may integrate an enterprise help desk system with our development tracking system. A support representative raises a help request and further analysis reveals this to require a change to software by the development team. When the support representative classifies the request as a Development Problem we want to automatically raise a corresponding Defect in the development tracking system. This is then assigned to a developer and when completed we want to communicate this fact to the help desk. To improve visibility we could feed back more information about the development process to the Support Department, but for the sake of this example we’ll just communicate completion.

Notice here we’ve set the scope; for this phase we’ll only communicate completion. We could add more use cases such as Change Defect State to a later phase.

Elaborating each use case gives us help in estimating the time we’ll need for these tasks.

Later in this paper we’ll look at how we can decompose a use case in more technical detail. The use case rightly doesn’t go into technical detail about how we’re going to achieve the automatic creation of the Defect, but we do have enough information to identify interfaces with other systems and areas for automation.

Security model

Through developing the important use cases we identify the actors involved. The set of actors gives us insight into the groups of user we need to consider when we develop the security permissions for the system.

 Each use case identifies the actor(s) that can execute the operations. However, as an adjunct to our model of the key use cases we can map our actors to more fine-grained permissions:

• The ability to edit data in a form or within the repository
• Visibility of data, say specific fields on a form or areas of a repository
• The ability to perform detailed operations not expressed by the key use cases (for example the creation of a baseline by, say, Team Leaders only).

A very important aspect of the use case model we develop is that it is in non-technical language and uses the vocabulary of the business domain. As such they can be understood by everyone involved in the project.

• Stakeholders. Does the implementation fulfil the requirements of the stakeholders?
• Training materials. The key use cases usually express the more complex aspects of the system from an actor’s point of view. This feeds into the development of training materials. A technical author can elaborate the use case model to explain the system as individual interactions and as a whole.
• Technical documentation. A use case model is a central part of the development model within UML (see the 4+1 views of the Unified Process where the +1 is the use case model).

During the elaboration of our use cases we will gain a better understanding of technical and organisational complexities. This can lead us to identify risks in several areas:

• People.
  This may involve the reluctance to implement processes or the ability two groups of actors to come to a consensus.
• Process.
  We could have difficulty in reconciling the requirements of the actors or integrating new processes with existing ones.
• System.
  This can be any technical risk, for instance the integration of systems or the automation of processes.
• Time.
  A particular use case may be required by a certain date to meet regulatory requirements or a business opportunity.
• External.
  A use case may depend on the delivery of functionality within a new version of a tool. Slipping of the third-party release will introduce delay.

The use case is the focus of discussion and the mechanism to record and track the risks. The use cases can also be fed into established processes for risk management used by the business.

Execution and Testing

Armed with our use case model we understand the functions of the system that are the most important as far as delivering business value and/or the most complex in terms of implementation. The customer and other stakeholders understand the system in terms of the key use cases and can see concrete progress as each use case is demonstrated.

The implementation of the system will usually consist of system configuration and customisation, and maybe the development of custom code to integrate with other business systems. Consequently, it may be the case that a use case contains enough information to allow it to be implemented. This is rarely the case in a traditional development scenario where most of the functionality to implement the use case will have to be coded from scratch. In the situation we are describing most, if not all, of the functionality will be available in the toolset we are implementing.

Where this is not the case we need an additional level of detail to provide confidence in the technical solution; confidence in our estimates and documentation for future maintenance.

Drilling into the use cases

Again, we can look to UML to show how we can take a use case and develop its implementation. This is a large subject and it will only be explored briefly here. There are many resources available in the literature and on the web. It is common practice to decompose use cases into Sequence Diagrams. These diagrams show the interaction between system components in terms of the messages they send to each other. A Collaboration Diagram is a different way of expressing the same information. You may find one or the other more useful depending on personal preference. Sequence diagrams focus on the chronology of events and are useful when considering the synchronous or asynchronous processing of messages.

In sequence diagrams objects, subsystems or systems are represented by dashed vertical lines. The messages between systems are shown as horizontal arrows that may be annotated with message details. Time runs from the top to bottom. The left of the diagram can contain explanatory text.

The two help desk use cases above will illustrate the use of sequence diagrams.

Classify as Development Problem

Here, the Support Representative performs the operation to classify the help desk request as a development problem, probably by setting the value of a field. The help desk system (via a trigger) must then invoke an integration script that creates a corresponding issue in the development tracking system. The unique identifier of the development defect is passed back by the script to the help desk system.

 This quickly identifies the tasks and deliverables to implement the use case.

• Create a trigger in the help desk system that fires when the classification field is set.
• Create an integration script to create the development task.
• The integration script must have a mechanism to update the help desk issue with the ID of the development task.

 Close Defect

 When the developer closes the task we have a similar sequence of operations. Note that in the previous integration we have recorded the identifier of the help desk issue in the development task so the second integration script can invoke the set state operation on the correct issue.

For simplicity the diagram does not explore the failure path.

Conclusions

Although traditionally used within software development projects we can use the technique of use cases when we come to deploy Application Lifecycle Management systems. ALM systems usually touch many parts of the business within and beyond the development sphere so it is important we understand the scope of the implementation and prioritise its activities in terms of business value.

 The non-technical, problem domain vocabulary used means all the stakeholders can understand and contribute to their development aiding communication and removing ambiguity. The model also feeds into other aspects of the implementation such as the detailed design, planning, training and documentation.

 References

Doug Rosenberg & Kendall Scott. Addison Wesley. ISBN 0-201-43289-7

Developing Software with UML.

Bernd Oestereich. Addison Wesley. ISBN 0-201-75603-X

Stephen P. Berczuk, Brad Appleton. Addison Wesley. ISBM 0-201-74117-2