Role of Use Cases in System Analysis and Development:
How effective it is today ?

Presented to Dr. Vicki Sauter, Professor, Information Systems, CoBA - UMSL.

Dhiraj Kumar
IS 6840, Fall 2011
University of Missouri - St. Louis

Introduction

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

Effectiveness of use-case in concurrent development processes

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

Structuring use case

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

Degree of detail

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

Use case diagram

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.

Basic use case diagram for
checkout
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

Use case template

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

The use case points method

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

Use Case Limitations

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:

  • Use cases are good for descrete and functional requirements but it can not be used to capture the flows of non-functional requirements or any requirements that do not rely upon an interaction between the actors and the system . These are better specified declaratively elsewhere.
  • Clarity is often considered the power of use cases but we need to remember that the ability to clearly depict through Use case Diagram will also depend upon the ability and experience of the use case designer. So assumption the assumption that use case itself has the power of clarity is a bit of risk and deceiving.
  • Like any other models time should be devoted in the projectTplan as there is a learning curve for the users and analysts to interpret what use cases is depicting.
  • The oreganizations/teams using the use cases would need to develop standards/rules because lack of formal rules for creating use cases leads to different analysts evolving their own methods of documenting use cases.
  • Use cases is not of much use when it comes to defining user interface.
  • It often requires too much documentation so if left on coders it may not get the due attention it requires because they may not consider as their job.
  • Use cases can be over-emphasized.(Meyer,1997)," Object Oriented Software Construction",1997 discusses issues such as driving the system design too literally from use cases and using use cases to the exclusion of other potentially valuable requirements analysis techniques.
  • In some organizations Use cases have been used to design test cases. But use case pre- and post conditions should be applied to all scenarios of a use case which limits the oppurtunity for designing the test cases. For example, the outputs and final state of a failed attempt to withdraw cash from an ATM are not the same as a successful withdrawal: if the post conditions reflect this, they too will differ; if the post conditions donot reflect this, then they canot be used to specify the expected behavior of tests.
  • Some systems like data-mining and Business Intelligence systems are better suited and described in a data driven approach than in a the functionality-driven approach of use cases.
  • Back to top

    Conclusion

    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:

  • Use cases do not offer a means to reflect variability across products in a product line.
  • Many teams are not able to decide on the appropriate level of generalization to follow use cases, and experience an uncontrolled and time-consuming growth in their use cases.
  • Use case does not document well the non-functional requirements of the system.
  • Inexperienced teams may revert to functional decomposition by driving component identification too closely off the use cases (Meyer, 1997). The danger is that the system will not be very extensible.
  • 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

    References

      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.



    Back to top

    Copyright © 2011, Dhiraj Kumar
    University of Missouri, St. Louis