Questions of use case

[Angiewen]

Hi:
recently, I've been studying UML. I have some confused about the use case. It is said use cases are the user requirements. They take requirements from the users, so the users are easier to find if anything missed when they look at the diagram. It is also said use cases are the functional requirements which includes each functional requirement should have a use case or a use case can satisfy one or more than one requirements. I am confused here. I think user requirement is what the users want to do in the system; whiles functional requirement is what the system will do in order to satisfy user's needs. These are two seperate specifications. Why use case is said in both of these two specifications? I mean if use case is functional requirement specifications, why can it also be used as user requirement specifications?

Thank in advance for your help.

regards,
angiewen

 

[DonQuichote]

In my opinion, use cases have no "hard" definition. The use case diagrams show which actions are possible for which entities. I say entities instead of users, because an entity may be a user, a server, a process or a subroutine. The actions are pieces of functionality of the system, described in short, everyday language.
It is up to you to refine the diagram to your own needs or leave it this general. You may draw diagrams to show the user rights or draw diagrams that show the program's responsiblity for handling a task properly.

Best regards ;-)

 

[jfrost10]

Hey angie,

Some places use two sets of use cases: a business set and a design set.

The business set is just that: business level processes described and documented, without any technology involved
(i.e. a workorder is submitted to a secretary, who types it up and sends it off to the site foreman)

The design set is used when technical terms start entering the picture, and the actual designers are going over the business logic and how to implement it with technology.
(i.e. secretary checks the work order que and finds a work order waiting. She selects it, and the application fills a form with the work order's data from the db. Secretary verifies the work order, and submits it to the supervisor que)

I hit the same wall when I was in school and we were trying to figure this all out. Hope this helped.

Jack

 

[GARooke]

I must warn about the last post, as i think it is misleading. I am also doubtful about the first one and also your question. Wow :-(

I have said it in the other forum, dont think about requirement and functional specs when talking UML.

You define a business process as a sequence of activities triggered by some event. Operators do some things, and then they use computers for others in some well defined order.

From the computer's perspective, operators keep logging in to do something, or to do a number of different things each done sequentially, and not necessarily imeddiately one after the other. These occur when 'ONE operator wants to do ONE thing at ONE time'. The ONE thing that they do is a use case. It achieves ONE small single business objective on behalf of ONE operator at the ONE visit to the computer.

The normal format is that it is written like a prototype. A few general bits at the start to explain it and then a sequence of 'Operator (actor) does', 'computer does', operator does' 'computer does'......

There can be complications due to reuse, multiple actors, actors that are other computers, conditional reqirements etc. but ignore those initially.

Firstly, the requirments of any sort consist of use cases and business rules, where the business rules can all be mapped into the constraints in a class diagram. So adding well thought out business rules to a set of use cases gives a good description of the requirements for a system. Possibly what you call 'user requirements'. Perhaps, if the business rules are expanded out into the class diagram, it is then that the use cases and class diagrams, with their sequence diagrams, becomes the 'functional specifications'.

The second responder introduces all kinds of new terminology, which I think confuses the UML. I prefer to stick to actors, use cases, steps, sequence diagrams, classes, methods, constraints etc. Also, dont think a use case is not well defined. It is. What is not well defined is how each specific use case is described.

Thirdly, dont think of 'Business use cases' and 'design use cases', because they can be confusing. Certainly, I dont like the distinction made in the previous response. The key feature is that a use case defines the interaction between the user and the computer in business terms. Do NOT define GUIs with use cases; they are part of the design. Do NOT describe how these interactions will be carried out in use cases. A use case is always the same thing, a simple actor-computer protocol.

In the design phase, you work out how this protocol will be imlemented, using sequence diagrams to add methods to your classes. At this stage, you may find out that there are use cases for entering Names, that rely on selecting a title; Mr, Mrs, Dr, Sir etc. Now what if the Queen is referred to? You may need to add another title, not originally envisaged. Often, the developers will spot lots of extra 'administrative' operations where the administrator needs to have an extra use case not originally specified. These are sometimes called 'System Use Cases' to distinguish them from the 'Business Use Cases' written by the business. Really, they are no different although patterns do emerge. For example you need a lot of these to change the near static data like 'lists of titles'. These things tend to have a related set of use cases, sometimes called the CRUD functions: Create, Read(or display), Update and Delete which get 'used' by business use cases.

I hope this helps.

Gil

 

[jfrost10]

Hi Gil,

Thanks for your response.

I disagree with you on the business and design level use cases. You mentioned:

The key feature is that a use case defines the interaction between the user and the computer in business terms.

I agree: the DESIGN use cases define the interaction between the user and the computer. However the actual business processes should be diagramed and understood BEFORE any technical jargon is added in. Business level use cases do that: map the processes of the business as it is now, without technology. The design level use cases are the transition from pure business to technical, after the business analysts review the requirements with the IT team.

Also, the use cases do not just describe a simple actor-computer protocol. In his book 'Use Case Drivin Object Modeling With UML', Doug Rosenberg defines a use case as A sequence of actions that an actor performs within a system to achieve a particular goal.(pg 38)

Note that a "system" does not necessarily mean a computer system. A use case called "Fill Order" could detail how an ordering personnel fills a paper reciept and submits it as a 'to be filled' order. That would be a BUSINESS level use case. An ordering personnel who accesses the ordering system, enters the information, sets the status to be 'to be filled' and clicks save would be a DESIGN level use case.

Isn't it interesting that on pages 54-55 of 'UML For Database Design' by Naiburg and Maksimchuk, they discuss how many dig right into the design level use cases, but disregard the business model.

I also disagree with your last statement that
In the design phase, you work out how this protocol will be imlemented, using sequence diagrams to add methods to your classes.

The idea that you would add methods to classes FROM sequence diagrams is backward thinking. You mine your methods and attributes FROM your use cases! You then apply them TO your classes, utilizing robustness diagramming to determine where the logic should reside. Then you diagram them in sequence diagrams to show the proper flow.

So where does this leave us? No where. I've found that when it comes to OO and UML, there are as many views and methodologies as there are books on the subject, probably more.

However, I fear that this has also left Angie more confused than helped. I don't disagree with Don's post: he made some valid statements that actors are not necesarily users, that they could be an external system, a program, etc.

I also appreciate your post, and your take on how usecases should be used in design and development. However, I don't appreciate your attitude that Don or I know nothing about the issue, and that our posts are "misleading". Obviously experts in the field have written books that are contrary to your thoughts, and maybe it is your post that we should warn of being misleading.

My wish is not to start a flame war here, however these forums (especially one like this where there are rarely one correct answer) must be kept open and free for discussion. Disagree if you like, but don't be presumptuous while doing it.

Regards,

Jack

 

[GARooke]

Differences of Opinion
----------------------
Lets try to cool the flame first. Within the framwork I have experience of, your concept IS misleading. However, I carefully used the word 'I think' because I appreciated that there are other views. I never said or even implied that you 'knew nothing'. There was no intention to belittle, but purely to warn that your comments, as you both yourselves say, are not gospel and to give the other side of the coin.

Now lets look at the disagreement, which is quite simple. We are jointly talking about two types of use cases.
1 Use cases to describe business processes - your <Business UC>s
2 Use Cases to describe actor interaction with computer systems - my [Business UC]s and your <Design UC>s.
I mentioned [System Use Cases] but they are NOT fundamentally different from [Business UC]s above except for who defines them.

There is one major area of agreement. I think we both believe that
'The business process should be understood before we DELIVER the system'. You try to do it before DESIGN, I'm less sure of that.

Business
--------

Firstly, I applaud the idea of using UML to help understand the business. The usual techniques are reminiscent of software design in the 70s/80s.

The application of use cases depends largely on the definition of the word 'System'. Use cases are ideal for 'systems that respond' and flow charts for those that are static. As such, your example of an order form is not a good one, but interfacing with the 'Purchasing Department' would be. It is the interactive banter that makes a use case useful and my use of the word 'protocol' suitable.

However, if the 'interactive system' is the computer instead of the Purchasing Department, then the <Business use case>s are identical to the <Design Use Cases> which is confusing. Hence, I worry about going that far.

Another issue, is your assumption (assumptions are always worse than presumptions because they are so insideous), that use cases contain jargon. If I find jargon in a use case, I reject it. Even business jargon, such as 'ROI' is unacceptable, because the developers also have to be able to read it.

Again there is an assumption that you can't understand the business until it is 'diagrammed'. That is totally misleading as the iterative developers are showing. In my experience, it is the most common cause of both cost and time overflow. There are lots of other ways of understanding the business. Anyway, can you ever understand every aspect of the business? No business man ever does. You only go as deep as you need to and in some methodologies, that need not be very deep.

Use case development.
---------------------
Your idea of 'backward thinking' is another assumption; you make no concession to it being not true. In that sense I strongly disagree. You only describe the Iconix methodology, which is far from being universally accepted. I like it, but not all of it, 'Robustness Analysis' being my least favoured bit, particulary Rosenberg's dictate that this must be done before sequence diagrams. I would NOT advise any of my teams to do that. I think the concept of 'Robustness' is mathematically significantly weaker than 'Sequence'. I'll start a new thread on this.

Advice to Angie
---------------
My advice is, initially be very clear in the distinction of when you are understanding 'the business' and when you are understanding how it interfaces with 'the computer system'.

To start with keep all of UML and the concept of 'System' to the computer system and its requirements. That was how UML was conceived and is predominantly thought about. It is a relatively 'complete' solution. Roughly speaking, this merges what I think you meant by 'Functional Specifications' and Design.

At the business level, make sure the that all developement is based on a clear understanding of the business. The business objective is to deliver what the business NEEDS when the system is delivered. It is not what YOU/THEY thought they WANTED, and was signed off, a year before.
However, it may have been agreed to produce what was signed off. If that is so, so be it. That's what you have to do.

These thoughts encompass the concepts of 'Business Requirements', but as you see, they are not a god given part of the process. Such requirements can be specified by formally written 'Business Requirements', as 'flow charts (business process or thread diagrams)' or as we see above a fudge on UML so that they are recorded as <Business Use Cases>. All are valid competing techniques and different people will have different preferences. Some of us will be wrong.

One thing is certain. A project needs a defined methodology, which may be quite flexible. It should resolve these issues. Then, no matter how sick it makes one feel, we should all work to it. Not doing so is a major cause of disater.

I have not really defined the full process I would use, but that must appear on another day.

Sorry to all who feel this is too long. but it is an important set of concepts.

Gil

 

[jfrost10]

Differences of Opinion
----------------------

You are correct: I do believe that the business process should be understood before design.

Business
---------

I have issues with this statement you made:
However, if the 'interactive system' is the computer instead of the Purchasing Department, then the <Business use case>s are identical to the <Design Use Cases> which is confusing. Hence, I worry about going that far.

The computer, PDA, phone, whatever, is never EVER the &quot;system&quot;. It is merely the &quot;boundary object&quot; used to interface with the system. Let's take the scenario of the purchasing department:

Business Level:
The ordering manager for a branch office types up an order for office supplies. He gets the branch manager to sign it, and drops it in the office outgoing mail. When the mail is delivered to the purchasing department, the administrator reviews the purchase request and contacts their supplier. The administrator gives the supplier the order and the branch address, and fulfills the order.

There's alot of business processes there, which need to be modelled. Once the process is understood, then its time to convert it into a DESIGN level use case, with an overview of the process:

The ordering manager enters an order for office supplies into a vb form. He saves it in a qeue for his branch manager to validate. Once validated, its moved to a Purchasing Department qeue. A purchasing administrator reviews the order, and submits it to their supplier via the supplier's online ordering system.

As you can see, the business and design use cases are not identical at all. One is pure business process, the other involves tech &quot;jargon&quot;

(NOTE: the comment I made about Jargon was that the design level use cases would have more technical merits than the business level, and could be confusing to someone not technically inclined. Where you percieved that to mean business jargon, I'm not sure. Further, certain business terms should be documented in a repository anyway, for further understanding by the team)

I stand firm in this: You cannot build a system without understanding the business processes driving it.

Iconix and Understanding the business
-------------------------------------
Unfortunately, I see my assumptions as correct.

I would hope that your company doesn't tread off into the world of building construction. How would it look if you didn't understand exactly how the skyscraper should be built, from blue prints, to plumbing diagrams, to floor plans...and just start building with a half-done set of designs, only to change them mid way? This is how we see software development: Figure out what you're building, then build it. Does that mean that changes won't occur? Of course not. But having a detailed model makes changes much easier to incorporate into the design.

My last company performed the way you describe. They were a little extreme mind you (minimal modeling, if any at all) but basically felt that modeling all the business processes was a waste of time. Their staff continue to work excessive hours with high stress because of the lack of design artifacts. It just so happens that their software is very buggy, and field many complaints. The cost and time overflow required to dig them selves out of that is much less than what would have been required if proper diagramming would have been done.

Mining your classes and methods from your sequence diagram, in my opinion, IS backwards thinking. Iconix does teach that yes: sequence is the last thing you do. But guess what: so did my ENTIRE schooling (which was not based on Iconix and was taught by a project manager with many years experience). How can I describe a sequence if I don't know what components are part of it? How can I effectively map out my tiers if I don't even know what code I'm going to be needing?! From my experience, that is what robustness has been able to give me: A clear picture of the code I need, and where it lives.

Also, keep in mind that I don't think (and neither does Iconix teach) that Robustness is a replacement for Sequence (not sure if you think that, but your comment I would NOT advise any of my teams to do that. I think the concept of 'Robustness' is mathematically significantly weaker than 'Sequence'. I'll start a new thread on this. lends itself to that conclusion). Rather, its a bridge TO sequence.

Advice to Angie
---------------

Instead of commenting on Gil's advice, i'll just give you my own:

A system is not a computer. A system is a set of processes that together or by itself accomplishes a task. As IT professionals, we're given the task of taking processes and making them efficient utilizing technology.

The systems we build are based on business processes. So it only seems logical that to build a correct system, we need to understand what the processes are. If a person wants to build a house, the architect draws out the blueprint, reviews teh design with the customer, and once everything is in place builds the house. This too should be our attitude in software design. Unfortunately, its not one that is widely adopted. Isn't it interesting to note that 80% of all software projects fail...maybe they started building without a blueprint?

IT is not about building what a business needs, its about building what the CUSTOMER WANTS! We are a CUSTOMER SERVICE industry. Gone are the days when we knew best, when everyone else were doing things wrong and we were the gallant knights to save them. You may like extra pickles on your burger. The McDonald's employee serving you might think thats disgusting. Doesn't matter though, they give you the burger. Same with systems development: model their processes, have the customer agree with the design, and then build it. Doesn't matter how much you disagree, THEY'RE PAYING THE CHEQUE.

But most importantly Angie, research as many methodologies as you can! There are a great deal of them out there, and as Gil has said: All are valid competing techniques and different people will have different preferences. The main thing is to find one that you believe in, that you feel suits what you need best, and roll with it. Personally, i find the Iconix methodology a great starting point. It has a limited set of diagrams (4), an easy to follow flow, and doesn't bother with some older, more archaic diagrams that can simply cause confusion. It might be a good place to start, and there are some great books on it.

Jack

 

[Guest_imported]

To answer the question in the beginning of this post, it goes in the following order:

- Stakeholder requests
- Features
- Use-cases
- Analysis & Design
- Implementation
- Testing

So, User requirements start from capturing the 'stakeholder requests', detailing these requests as 'features'(high level) and then mapping these features into 'functionalities' (use-cases).

 

[Guest_imported]

Stakeholder Request:
--------------------
* Make existing system 'Internet Ready'

Features:
---------
* The system shall be available 24/7
* The system shall be accessible using most widely used web browsers.
* The system shall allow the users to update their personal information, subscribe for services, check the status of the account.
* The system shall allow the users to receive monthly statements, newsletters via email.
* The system shall allow the users to view monthly statements in different document types, for e.g., word document, pdf document.
* The system allow the users to opt for notification of optional reports.
* The system shall display information only pertinent to the user as per the company's security policies.
* The system shall store the users' mailing addresses in a normalized form.
etc., etc.,

Use-cases:
----------

One single user-requirement(or feature) could lead to multiple use-cases:
For e.g., the security specific requirement(or feature) would lead to use-cases:
* Login to the system
* Maintain User

Multiple user-requirements(or features) could be combined and specified in a single use-case:
For e.g., Generate Report

Hope this clears as how a use-case can satisfy one or more users requirements(or features)