Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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:
or it's enough just providing a use case called "modify text properties"?
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.
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:
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.
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.
