Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm working on the use case model of a web design application something like Dreamwaver, I'm little confusing about to which level should I write the use case model. ex: when the user insert a text should I provide a use cases of:

  1. select font
  2. select size
  3. color
  4. Italic
  5. bold
    ..
    ..
    ..

or it's enough just providing a use case called "modify text properties"?

share|improve this question
    
Check this, the case is somewhat similar to your case: programmers.stackexchange.com/questions/123560/… –  Emmad Kareem Dec 11 '11 at 13:18

3 Answers 3

up vote 1 down vote accepted

Lot of documents about UML and how to write use cases, focuses only the how part. Here is one document that seems to be best answer your question. Read this : Writing Effective Use Cases. (Write to me if you want a copy) The same author have the book which is an extended form. See the book here.

In essence, as the books puts up, you first need to define the scope of the overall system at different levels. For example, it starts with An Organization X serving its client organization. The use case is defined of the organization at that scale. Further down, now individual functions are then done at (one or more Products) say a client application (that the client application as well as administrators use) will talk to server and so on.

The level of details increases as you go down, but the scope becomes narrow. Understand that the purpose is not to repeat things but to organize things in the form of different levels hierarchy.

This way, you keep refining the scope and go deeper. So when do you stop? Probably the simple answer is: when it is trivial not to write the question. Essentially, (as per the book) you write use cases of each entity separately. - The organization, various systems (or products) being consumed, At some point writing use cases of an entire UI application could be enough; But if you do have a major component which does seems of far more important than use case at that level of is more important; at that level you probably have to write use case at the level of forms/inputs at that level.

EDIT:
Now coming to your question - as i said, it depends on the scope. From the UI (also when you are treating word processor or rich text editor within a very larger system), you expect that UI provides many messages back to core (each formatting command as a simple message). However, from the point of view of the actual model object which implements this - each command is a unique item. Hence, for the back-end object, each command is unique functionality and hence they are unique different use cases.

share|improve this answer
    
about my question about text formatting what should I do? –  Amged Dec 11 '11 at 15:20
    
@Amged : edited the answer for your formatting example. –  Dipan Mehta Dec 11 '11 at 16:42

If it is okay by your customer to provide a use-case called "modify text properties" and list in it all the text properties that should be modifiable, then it should be okay.

The question sparks in the end the question on what the appropriate level of granularity is. But it all depends on what level that you want your use-cases to be in (as a developer or designer) or what level of control that your client has or wants. It is a balance act and there are some things to consider between fine and course use-cases:

Fine (small and plenty)

  • Easier to time estimate (because they're small in scope)
  • Related use-cases are harder to keep track of if they're put in different project scopes. Design that you did in previous project/sprint will mandate a redesign when a conflicting change is needed
  • Pushes the control over implementational design over to BA or who ever writes the use-case

Course (large and few)

  • Simpler to write
  • Easier to keep in your head and design
  • Difficult to time estimate, though the developer can always break it down for himself and time estimate each piece of functionality needed for the use-case to be implemented
  • The developer can be more flexible with design and implementational details

I found the best is a balanced mix of them, and also let the customer specify (or specify it for them) the features they wants and form use-cases from them. It is okay for use-cases to be course, the customer shouldn't care about in the finer details of how the software works. The only thing they care about is if the feature is working or not.

Now time estimation is important, both for you and your customer/client/project manager, and if the use-case is too large for you to time estimate then you have an option as a developer to break it down for yourself so you can plan, make a top-down design and be able to estimate it better. Think about it; it is easier to estimate several 1 hour changes than one big 8 hour change.

share|improve this answer

It is best to define use case at user goal level (some thing user would achieve after having done the use case), since use cases are meant to capture functional requirements and detailed steps can be elaborate in use case descriptions or use case realizations. For your case "modify text properties" would enough and different usage scenarios can describes as different use case instances and paths.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.