Use Case Fragments

A previous IRM article Event Based Analysis and Modelling described how business functionality in a requirements package can be broken down into a table with column headings - Event, Trigger, Initiator, Use Case name, etc. Each business function is a seperate event and has a unique number.

A typical business function might contain several unique events each of which we want to end up as a component of a larger software application.

So how do we go from a table containing textual information to a specification which a developer can use?

The first step is to turn each business event into a model - either a use case fragment, a DFD fragment or any modelling language you might be working with. 

The following event table describes three typical interactions a customer would have with their bank:

Use Case - Event Table

Each of these events can be drawn as a separate use case:

These individual use cases (fragments) are only half the picture however. Today developers don't write individual software programs for each event, particularly when multiple events will have numerous common components e.g. database enquiry, ID validation, etc.

What we do want is to be able to combine use case fragments into a single use case. We do this by identifying and sharing common actors (in this example the customer):

While we still need to write individual descriptions for each use case, we've given the developer a concise package of functional requirements, offering them the best opportunity to write efficient and effective code.

For an example of writing formal use cases see the paper How to use Use Cases.

Author: Jan Kusiak, Training Services Manager, IRM Training Pty Ltd

Like this article:
  18 members liked this article


Putcha posted on Wednesday, December 10, 2014 12:06 AM
May I know what definitions of the following you are using and how they are different?

Event, Trigger, Input, activity process.

I am asking this because I take that event is "an occurrence" or "something that happens". It's duration may be small (lightening, earthquake) or long (storm, war, development, growth etc.). If it is accepted, then it is NOT different from an activity or a process (which happen). For all events one may not be able to identify the performer or performers who make the event or activity or process happen.

Similarly trigger and input are also equivalent. They may be physical stimuli that can be detected or logical (messages involving data and information)

I am seeking clarification on these points.

Thanks and regards,
[email protected]
Putcha posted on Wednesday, December 10, 2014 12:16 AM
I see that there are many UseCases in which

1: There is NO identification of System under Development SuD for which a UseCase Diagram is prepared

2: A single UC is associated with two or more Actors.

Many professionals and publications also use UML this way but they are serious errors / flaws.

Those interested may see: and related PPTs and PDFs on slideshare.

Readers may disagree with my proposals. I would like to know the reasons for disagreement.

Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC