|
A use case shows the behaviour or functionality of a system. It consists of a set of possible sequences of
interactions between a system and a user in a particular environment that are
related to a particular goal.(Hoffer, George & Valacich, 2008).
In Software Engineering,a use case is used to describe the steps between an user and
a software system which guides the user to useful output.
The user (also called an actor) could be a human user, an external hardware,software sysytems,or other
subjects.
Technically speaking use cases are software modeling technique which helps Architects and Analysts to put
together the features to implement and how to fix the errors in simple pictures. Due to its simplicity in conveying
its ideas to customers, technical gurus and executives a like it is very popular and often considered powerful.
A use case can identify,clarify and organize system requirements in simple steps and can help avoid scope creep.
Systems Analysts tries to put a set of all possible sequences of interactions between systems and actors in
a particular environment related to a specific goal.It consists of a group of elements that can be used together
in such a way that will have an effect larger than the sum of the separate elements combined.
A use case can be thought of as a collection of all possible scenarios related to a specific goal.
No wonder why use cases are so popular but use case modeling, when used in isolation and performed incorrectly,
may lead to certain types of problems.(Armor & Miller, 2000)
One of the argument behind the popularity of use cases is that it is easy to read. People may mistake that
easy-to-read also means easy-to write, but that is a mistake.It could be terribly hard to write easy-to-read
stories.Use cases are stories, prose essays, and so bring along all the associated difficulties of story writing
in general.(Adolph, Bramble, Cockburn & Pols, 2002).
When Ivar Jacobson came up with this concept in 1986 it was based upon many years of work in component based
system development. There were many different techniques then but they were overlapping or had
gaps.(Armor & Miller, 2000). Tweny five years after though although Use cases are still
relevant but it has evolved and being used with a lot of help from web based technology.
Now a days Computer aided project planning & management tools, computerized system diagraming tools,
data dictionary, code generators and data bases for software changes make us wonder that are we using use cases
concept as it was developed by Ivan twenty five years ago ? There are several methodologies like Structured design
techniques, Structured coding standards, Object Oriented design techniques,object oriented Languages, Prototyping
and of course Traditional System Development Techniques(IRMA,1992 ). This paper dives deep and
tries to find out how effective use-cases are in system Analysis and software development today.
Back to top
The software development process used by a company today would highly be dependent upon the development methodology
being used in the company. Similarly the degree to which Use case is exploited would also depend upon the
"the belief level" of the Systems Analyst and the Architect in use cases technology itself.
In certain development methodology, only a brief use case usage could be limited to a simple survey for requirements
gathering whereas in other development methodologies,use cases evolve in complexity and remarkable change in
character as the development process moves forward. Moreover,there are some methodologies that may begin as brief
business use cases but that could evolve into more detailed system use cases,and then finally develop into highly
detailed and exhaustive test cases.
It is the ability of use cases to unite the development activities that makes them such a powerful tool for the
planning and tracking of software development projects.In order to understand the power of use cases, it is worth
considering the life cycle in detail. Use cases can play a part in the majority of the stages directly associated
with systems and software development life cycle. Let us have a close glance on some of those cycles:
Requirements Gathering: A requirement is something that a computer application must do for its users.
(Kulak & Guiney, 2000).Requirements are generally categorised into functional and non-functional requirements.
The functional requirements specify the input and output behaviour of a system. Nonfunctiona requirements specify
the other qualities that the system must have, such as those related to the usability, reliablity, performance, and
supportability of the system.(Bittner & Spence, 2003).
Use-case model is widely used in requirements gathering and is very popular.
In fact the use-case model is the result of the requirements discipline. Requirements gathering utilizes this model
from Identified to Agreed upon and it also works out the domain model which defines the terminology used by the use
cases. But let us take a pause and focus on other techniques of gathering functional requirements because no
technique is foolproof. There is a section of people who would like the "visual approach" while others might prefer
abstract. Yet another section of people would have faith only in concrete and they need somthing which would engage
them. They would get distracted by simple use cases which is partly visual.Therefore some Systems Analysts would
uses as detailed model as Storyboard is. This gives the analysts and the architect an oppurtunity to visualize and
identify the problems before significant investment is undertaken in developing the system. This is almost like
developing sketches of major events as done in TV and film industry. This also provides an oppurtunity for customer
experience by visualizing the "whole" picture. This is something use case model can not provide because use case
model focuses on specific user interfaces and are descrete. Where as storyboards can describe whole business process.
On the other hand there are certain industry in which working model would be necessary as a protytypes of the actual
system to make sure that system we are targetting would fulfill our requirements. Again our use case model may not
compete there as well. But of course developing a prototype would incur some cost and this could be challenging in
the current economic situations.
Analysis and Design: Use cases are realized in analysis and design models. Use-case realizations are created
that describe how the use cases are performed in terms of interacting objects in the model. This model describes the
different parts of the implemented system and how the parts need to interact to perform the use cases. Analysis and
design of the use cases matures them through the states of Analyzed and Designed. These states do not change the
description of the use cases, but indicate that the use cases have been realized in the analysis and design of the
system.
The use-case suggest large-scale partitioning of the problem domain. It also provides structuring of analysis objects
(i.e. actors and sub-systems).It clarifies system and object responsibilities & captures new features as they are
added to the system.
Implementation: During implementation, the design model is the implementation speci-fication. Because use
cases are the basis for the design model, they are implemented in terms of design classes. Once the code has been
written to enable a use case to be executed, it can be considered to be in the Implemented state. It suggest
iterative prototypes for spiral development.
Testing: During testing, the use cases constitute the basis for identifying test cases and test procedures;
that is, the system is verified by performing each use case. When the tests related to a use case have been
successfully passed by the system, the use case can be considered to be in the Verified state. The Accepted state
is reached when a version of the system that implements the use case passes independent user-acceptance testing.
Back to top
As we compare the use case with other councurrent models and try to establish its' relevance in concurrent development
techniques it is important to reflect on the way use cases are structured today.Most popular model today UML provides
generalization, include and extends as three possible relationships.A generalization relationship between use cases implies
that the child use case contains all the
attributes, sequences of behavior, and extension points defined in the parent use case, and participates in all
relationships of the parent use case. The child use case may define new behavior sequences, as well as add behavior
into and specialize existing behavior of the parent use case.
An include relationship between two use cases means that the sequence of behavior described in the included (or sub)
use case is included in the sequence of the base (including) use case.
The extends relationship provides a way of capturing a variant to a use case. Typically extensions are used to
specify the changes in steps that occur in order to accommodate an assumption that is false
(Coleman,1998). The extends relationship includes the condition that must be satisfied if the extension is to
take place, and references to the extension points which define the locations in the base (extended) use case where
the additions are to be made.Use-case extensions permit us to describe additional behaviors that can be inserted into
an existing use-case. (Jacobson & Ng,2005).
Back to top
Alistair Cockburn identified three levels of detail in writing use cases-
- Brief use case
It consists of a few sentences which summarize the use case. It can be easily inserted in a spreadsheet cell, and
allows the other columns in the spreadsheet to record priority, duration, a method of estimating duration, technical
complexity, release number, and so on.
- Casual use case
It consists of a few paragraphs of text, summarizing the use case. A casual use case should be conversational in
nature, written in terms of a generic user role rather than specific people. They should have a title identical to
what is listed in the user/task table. The casual use case should be two paragraphs. The first paragraph starts
"An X wants to do Y in order to achieve Z. They have already done W." The casual use case continues with sentences
that describe the interaction and information flow between actors.The paragraph ends with the successful achievement
of the goal.
- Fully dressed use case
Fully dressed use cases show more detail and are structured they are useful order to obtain a deep understanding of
the goals, tasks, and requirements.
Some software development processes do not require anything more than a simple use case to define requirements.
However, some other development processes require detailed use cases to define requirements. The larger and more
complex the project, the more likely that it will be necessary to use detailed use cases.
The level of detail in a use case often differs according to the progress of the project. The initial use cases may
be brief, but as the development process progresses the use cases become even more detailed. This reflects the
different requirements of the use case. Initially they need only be brief. However, later in the process, software
developers need far more specific and detailed guidance.
Back to top
The Use case diagram is used to define the core elements and
processes that makeup a system. The main purpose of a use case diagram is to show what system functions are performed
for which actor.
This image was taken from: "Use Case Diagrams Examples," UMLdiagrams.org: http://www.uml-diagrams.org/use-case-diagrams-examples.html#pos-checkout undated, viewed December 5, 2011.
There are two types of actors in use case diagram viz. active actors & passive actors.Active actors initiate
interaction with the system. This can be shown by placing an arrow on the association from the actor pointing
toward the use case.Interaction with passive actors is initiated by the system. This can be shown by placing an
arrow on the association from the use case pointing toward the actor.
Where an actor, either active or passive, depending on circumstances, the arrow may be omitted.The use of arrows on
associations is referred to as the navigation of the association.
Checkout use case involves Customer, Clerk and Credit Payment Service as actors and scanning items, calculating
total and taxes, payment are use cases. This is an example of large and complex use case split into several use
cases each describing some logical unit of behavior
Payment use case is represented using generalization relationship which means that only one specific type of payment
is accepted - either by cash, or by credit, debit, or with check.
Back to top
A key attitude in use case work is to focus on the question"How can using the system provide observable value to the user
, or fulfill their goals ?", rather than merely thinking of system requirements in terms of a "laundry list"
of features or functions.(Larman,2005).So if the system usages is unique then Use-cases could be
unique as well. And may be that's why although use cases are part of UML, there is no template for writing use
cases. There cannot be just one template for a use case. Some teams will do just fine with a short use case style,
in which the main story is presented in a simple paragraph of prose, and the failure handling is in a few follow
ing paragraphs. Other teams will need detailed templates and careful writing conventions.(Cockburn,2002)
The following is the guidelines for standards from
Derek Coleman around use case template (Coleman, 1998), with some minor m
odifications.
- Use case
Each use case should have a unique name suggesting its purpose. The name should express what happens when the
use case is performed. It is recommended that the name be an active phrase, e.g. complete order. It
is convenient to include a reference number to indicate how it relates to other use cases. The name field should also
contain the creation and modification history of the use case preceded by the keyword history.Each use case should
have a description that describes the main business goals of the use case. The description should list the sources
for the requirement,preceded by the keyword sources.
- Actors
Optionally, an actor may be indicated as primary or secondary. Actors are characterized not by the identity of the
user or other, but rather by the role played by the actor. One person can be several different actors in different
roles.One actor can be played (at different times) by several different persons .An entire committee could be one
actor. An actor need not be a living thing; it could be another subsystem.
- Assumptions
Assumptions are conditions that must be true for use case to terminate successfully.
Each assumption should be stated in a declarative manner, as a statement that sums to either true or false.
- Steps
Steps are the interactions between actors and system that are necessary to achieve the desired goal.
The interactions between the system and actors are structured into one or more steps which are expressed
in natural language.Conditional statements can be used to express alternate paths through the use case. Repetition
and concurrency can also be expressed
- Non-functional
Non-functional keywords include, but are not limited to Performance, Reliability, Fault Tolerance, Frequency,
and Priority .
- Issues
Issues include list of issues that remain to be resolved & list of issues awaiting resolution.
Back to top
Use case techniques has been extended to be used in several purposes during the software development cycle.
Use Case Points(UCP) method is a software sizing and estimation based on Use Case document.(Koirala,2004).
UCP method has been proposed to estimate software devlopment effort in early phase of software projects and used
in a lot of software organizations.(Kusumoto,2004).There are several steps involved during the
estimation. Following are the major steps:
To Determin Unadjusted Actor Weight(UAW):In order to determine UAW (Unadjusted Actor weight)for which we classify all
the actors in to classify the actors into simple, average and complex. Then assign a value of 1,2 or 3 depending
upon the classification,as shown in Table2 (Koirala,2004). in Appendix it also includes litmus test which detrmines the class
it is going to fall.
To Dtermine Unadjusted Use Case Weight:This is done by counting Use Cases and assigning weights
depending on number of scenarios and number of transactions. Table3 (Koirala,2004) shows an example.
To determin Unadjusted Use Case Point(UUCP):
This is calculated using sum of UAW and UUCW i.e.
Total UUCP = Total UAW + Total UUCW.
Technical complexity factor:The final step is to take into account the technical complexity.
All technical factors are assigned a value from 0 to 5 depending on complexity as shown in the table4.
Determine environmental factors:This could include factros like trained staff, motivation of programmers
and several others as shown in table5.These could have quiet a decent impact on the cost estimate.
Calculate Technical Factor, Environmental factor and Adjusted use case point factr :
Each factor is assigned a value between 0 and 5 depending on its assumed influence on the project. A rating of
0 means the factor is irrelevant for this project; 5 means it is essential.
The Technical Factor (TCF) is calculated multiplying the value of each factor (t1.... t13) by its weight and then
adding all these numbers to get the sum called the TFactor. Finally, the following formula is applied:
TCF = 0.6 + (.01*TFactor)
The Environmental Factor (EF) is calculated accordingly by multiplying the value of each factor (e1... e8) by its
weight and adding all the products to get the sum called the Efactor.
The formula below is applied:
EF = 1.4+(-0.03*EFactor)
The adjusted use case points (AUCP) are calculated as follows:
AUCP = UUCP*TCF*EF
Back to top
One of the more remarkable aspects of use cases is that they have achieved such wide currency
despite an almost complete lack of precise definition.(Constantine & Lockwood, 1999). No doubt it is remarkable
but it also creates uncertainity due to lack of standards.When it comes to documenting the interaction between the actors and the system Use cases is the way to go and these
are excellent tools. But these could not be taken as solution to all the system design and architectur problems .Use cases are a relatively informal description of system behaviour and usage, which is
designed to show how a system provides some value for the user when it is used (Overgaard & Palmkvist,2005).
Following are some of the short comings:
Back to top
As we saw in the above discussion,Use cases provide several and very useful advantages and no doubt are these are
powerful tools that every
architects, systems analysts, designers, and testers can harness at different stages of software life cycle.
It stands out due to its simplicity and easiness to convey the ideas.But in concurrent and modern development processes
which are highly bject-oriented focussed it could be a mistake to blindly use it as it is more functional oriented.
Also easy-to-read is not always easy to write and writting a complex use case could also take time.While use cases, in general, and their current detailed formulations, in particular, provide useful information to manual test design, no current
use case formulation is adequate for automated test design that includes result checking.(Gelperin,2004).
But like any other technological models the risks related to use case modeling can be lessened if right training and experience
is provided. Use cases should compliment other models.Use cases should be only one of several ways of capturing user requirements. Use cases are useful in dealing with
functional requirements, and as such they play a primary role in product definition.
(Malan & Bredemeyer, 2011). Saying that "use cases will be used on the project" is therefore an insufficient phrase, and any
recommendation or process definition that simply says, "use use cases" is incomplete. A use case
valid on one project is not a valid use case on another project. (Cockburn,1999). An architecturally relevant subset of the use cases for each of the
products to be based on the architecture also plays a valuable role in architecting. They direct the architects to
support the required functionality, and provide the starting points for collaboration diagrams (or sequence diagrams).
Following shortcomings should be kept in mind while being considered:
The business model of the redesigned company and the requirements model for the information system must be seamless. This is achieved by pairing object-oriented business engineering and object-
oriented software engineering - a use case driven approach (OOSE), which work in harmony.(Jacobson,1995)
. So it make sense to use other models like Object Oreinted Design along with Use case to make the best use of it.
Back to Top
Armour, F., and Miller, G.,"Advanced Use Case Modeling: Software Systems," Addison-Wesley Professional,Reading,MA May 2000.
Adolph, S., Bramble, P., Cockburn, A., and Pols, A.,"Patterns for effective use cases," Addison-Wesley Publishing, Boston, MA,August 2002.
Bittner, K. and Spence, I. "Use case modeling," Addison-Wesley Publishing,Boston, MA,August 2003.
Cockburn, A., "Use cases,ten years later,"STQE magazine,March/April 2002
Cockburn, A., "Writing Effective Use Cases",Addison-Wesley,Reading,Boston, MA, April 1999.
Coleman, D., "A Use Case Template: Draft for discussion", Fusion Newsletter, April 1998.
Constantine, L., and Lockwood, L., "Design for Use", Addison Wesley,Boston,MA,USA,1999.
Denney, R., "Succeeding with Use Cases: Working Smart to Deliver Quality", Addison-Wesley Professional,Reading, MA,2005.
Gelperin, D. "Precise Use Cases", www.livespecs.com,2004.
Hoffer, J., George,J., and Valacich,J.,"Modern Systems Analysis And Design ",Pearson Prentice Hall,Upper Saddle River,New Jersey,2008.
Jacobson, I., "The Object Advantage : Business Process Reengineering With Object Technology", Addison Wesley,Reading, MA,1995.
Kulak, D., and Guiney, E., " Use Cases: Requirements in Context", Addison Wesley,Reading, MA,2000.
Larman, C., "Applying UML and Patterns: An Introduction to object-oriented Analysis and Design and iterative development",Prentice Hall,Upper Saddle River,NJ,2001.
Malan, R., and Bredemeyer, D., "Functional Requirements and Use Cases",www.bredemeyer.com,Bredemeyer Consulting,Bloomington, Indiana,USA, 2011
Overgaard, G., and Palmkvist, K.,"Use cases: patterns and blueprints",Addison-Wesley,Reading, MA,2005.
Jacobson, I. and Ng, P., "Aspect-oriented software development with use cases",Addison-Wesley,Reading, MA,2005.
IRMA International Conference,"Emerging Information Technologies for Competitive Advantages and Economic Development",Idea Group Publishing,, 1992.
Schneider, G., and Winters,J.,"Applying Use Cases: A Practical Guide (Google eBook)",Que Publishing, 2001.
Meyer, B.,"Object Oriented Software Construction ",Prentice Hall,Englewood Cliffs, NJ,1997.
Koirala, S., "How to Prepare Quotation Using Use Case Points", www.codeproject.com, 13 Dec 2004
Kusumoto,S., "Estimating Effort by Use Case Points:Method,Tool and Case Study", 10th IEEE International Symposium, Sep11-Sep17 2004
Back to top
APPENDIX
Table1:Abbreviations and Terms
| S.N. |
Abbreviation/Terms |
Full Form |
| 1 |
UML |
Unified Modelling Language |
| 2 |
UCP |
Use Case Point |
| 3 |
ATM. |
Automated Teller Machine |
Table2:Classification of Actors for UCP(Source:www.codeproject.com)
| Classification |
Litmus test to recognize classifications |
Value/Factor |
| Simple actors |
Simple actors are those which communicate to system through API. |
1 |
| Average actors |
Average actors are recognized if they have the following properties:Actors who are interacting
with the system through some protocol (HTTP, FTP).
Actors which are data stores (Files, RDBMS).
|
2 |
| Complex |
Complex actor is interacting normally through GUI. |
3 |
Table3: Adusted Use Case Weight (Source:www.codeproject.com)
| Use Case Type |
Litmus test to decide the Classification |
Value/Factor |
| Simple |
Greater than or equal to 3 transactions |
5 |
| Average |
Between 4 to 7 transactions |
10 |
| Complex |
Greater than 7 transactions |
15 |
Table4: Environmental complexity fact (Source:www.codeproject.com)
| |
Technical factor |
Weight |
Description |
| t1 |
Distributed System |
2 |
Is the system having distributed architecture or centralized architecture? |
| t2 |
Response time |
1 |
Does the client need the system to fast? Is time response one of the important criteria? |
| t3 |
End user efficiency |
1 |
How's the end user's efficiency? |
| t4 |
Complex internal processing |
1 |
Is the business process very complex? Like complicated accounts closing, inventory tracking,
heavy tax calculation etc. |
| t5 |
Reusable code |
1 |
Do we intend to keep the reusability high? So will increase the design complexity. |
| t6 |
Installation ease |
0.5 |
Is client looking for installation ease? |
| t7 |
Easy use |
0.5 |
Is user friendliness a top priority? |
| t8 |
Portable |
2 |
Is the customer also looking for cross platform implementation? |
| t9 |
Easy to change |
1 |
Is the customer looking for high customization in the future? |
| t10 |
Concurrent |
1 |
Is the customer looking at large number of users working with locking support? This will
increase the architecture complexity and hence this value. |
| t11 |
Security objectives |
1 |
Is the customer looking at having heavy security like SSL? |
| t12 |
Direct access to third parties |
1 |
Does the project depend in using third party controls? |
| t13 |
User training facilities |
1 |
Will the software from user perspective be so complex that separate training has to be provided? So this factor will vary accordingly |
Table5:Environmental factors(Source:www.codeproject.com)
| |
Environmental Factor |
Weight |
Description |
| e1 |
Familiarity with project |
1.5 |
Are all the people working in the project familiar with domain and technical details of the
project? |
| e2 |
Application experience |
0.5 |
How much is the application experience? |
| e3 |
Object-oriented programming experience |
1 |
As use-case documents are inputs to object oriented design, it's important that people on the
project should have basic knowledge of OOP concepts |
| e4 |
Lead analyst capability |
0.5 |
How is the analyst who is leading the project? Does he have enough knowledge of the domain?. |
| e5 |
Motivation |
1 |
Are the programmers motivated for working on the project? Instability in the project will always lead to people leaving half way through their source code.This factorcan be put according to how software industry is going on? |
| e6 |
Stable requirements |
2 |
Is the client clear of what he wants?If the client is of highly changing nature,this value is
maximum. |
| e7 |
Part-time Staff |
-1 |
Are there part-time staff in projects, like consultants etc.? |
| e8 |
Difficult programming language |
-1 |
How much is the language complexity, Assembly, VB 6.0, C++, C etc. |
|