Ivar Jacobson (the inventor of use-case and co-inventor of UML), in Use Case 2.0 Taken together the set of all the use cases gives you all of the useful ways to use the system, and illustrates the value that it will provide. Use cases represent " sets of offered behaviors" (UML definition of a use case) that correspond to user goals:Ī use case is all the ways of using a system to achieve a particular goal for a particular user. Otherwise, you'd end up with very complex diagrams that add little value to a textual list of requirements, and functional decomposition. But it's not equivalent to a functional requirement. Use cases mean different things to different people. This is what will help you design, build, and test the system to ensure it meets the use cases as they are understood. If you're using use cases, invest more time in things like identifying the actors, pre- and post- conditions, and scenarios and extensions. So when you do use cases put your energy into the text.ĭon't put too much energy into use case diagrams. Use cases appear in the UML in the form of use case diagrams, but these diagrams are of little value - the key value of use cases lies in the text which is not standardized in UML. I'll also leave one more parting thought, from Martin Fowler: Since textual descriptions also contain references to the actors involved, information about the actors or personas can be used to determine what languages the system needs to support and to design test cases that different actors are able to see the system in the correct language. The precondition to carrying out the steps could be something like "the user sets the user interface language to their language" or "the system displays user interface elements in the user's language". If you are using use cases to capture the behaviors of the system, I would consider including it as a precondition. Because of this, I don't think that the use case of "choose language" should be on the use case diagram, or even modeled as a textual user interface. Likewise, I find it unlikely that an actor will use your system to change the language of the user interface. An actor's goal is usually not to authenticate with the system. The notion of "log in" is a good example. Not all functional requirements are captured as a use case.
A use case is a description of a behavior of the system under specified conditions that allows an actor to accomplish a goal. It's important to understand what a use case is, though. Since the system changing its language is a functional requirement and is about the behavior of the system, it is something that could conceivably appear on a use case diagram. It defines a specific behavior that the system performs with respect to the language that appears on user interface elements. If the system supports changing its language, through user action, automatic detection, or some other means, that is a functional requirement. Although usability, accessibility, internationalization and localization, and documentation requirements tend toward non-functional requirements, there may be functional requirements that support these goals.
0 kommentar(er)
