My software provides two functional requirements, and I represent them as Do A and Do B in the figure 1 below. At the same time, my software has a non-functional requirement to provide the interface in multiple languages. To the best of my knowledge, non-functional requirements should not be modeled as use cases, however, I am not sure how to represent this, as at the same time, it seems natural to include the capability to change language as something user would do. Please help me understand.

enter image description here

  • It is beyond me why this question would get thumbs down??
    – User 19826
    Oct 30, 2021 at 6:17
  • Well, I don't know why someone else downvoted your question, the topic is ok for this site. However, it does not show much research effort of yours, which is expected by the community here. Using google, for example, I was able to spot this older SO Q&A Is there such a thing as a "Non-Functional Use Case"? within a few seconds, so what search key words did you try, what did you find and why doesn't it answer your question? I recommend to edit such kind of information into your question.
    – Doc Brown
    Oct 30, 2021 at 6:45
  • Given that any device has an option to set/change the default language, is that not adequate? Why do you need a separate mechanism?
    – Andrew
    Oct 30, 2021 at 7:13
  • 1
    Change language is a behavior of the system, so it’s a functional requirement.
    – Rik D
    Oct 30, 2021 at 8:29

3 Answers 3


Although usability, accessibility, internationalization and localization, and documentation requirements tend toward non-functional requirements, there may be functional requirements that support these goals. If the system supports changing its language, through user action, automatic detection, or some other means, that is a functional requirement. It defines a specific behavior that the system performs with respect to the language that appears on user interface elements.

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's important to understand what a use case is, though. A use case is a description of a behavior of the system under specified conditions that allows an actor to accomplish a goal.

Not all functional requirements are captured as a use case. The notion of "log in" is a good example. An actor's goal is usually not to authenticate with the system. Likewise, I find it unlikely that an actor will use your system to change the language of the user interface. 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.

If you are using use cases to capture the behaviors of the system, I would consider including it as a precondition. 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". 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.

I'll also leave one more parting thought, from Martin Fowler:

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. So when you do use cases put your energy into the text.

Don't put too much energy into use case diagrams. If you're using use cases, invest more time in things like identifying the actors, pre- and post- conditions, and scenarios and extensions. This is what will help you design, build, and test the system to ensure it meets the use cases as they are understood.

  • Thanks. I agree that I need to focus on textual description. At this stage, I am trying to understand UC diagrams. Hence NFR do not appear on UCD. FR that implements NFR, does not typically appear on UCD, as it is not main goal of actor. Q1: is it possible to use "USES" to show FR that implements NFR on UCD (plz see updated figure 2 above). Q2: Are there any cases where FR that implement NFR need to appear on UC diagrams?
    – User 19826
    Oct 31, 2021 at 3:42
  • 1
    @Fabiana More recent revisions of the UML specification have replaces <<uses>> with <<includes>>, but I do believe they mean the same thing. Aside from not using the latest terminology, the second diagram appears to be correct per the specification. However, choosing to show this level of detail or not is at the discretion of the author of the diagram. Personally, it seems too detailed for my liking, and having this level of detail could add to clutter on the diagram as you add more use cases.
    – Thomas Owens
    Oct 31, 2021 at 9:53

UML use case diagrams have a very restricted semantics "by design". Hence, to make these diagrams useful, one has to provide a description for each use case (for example, in text form). How you structure this description is up to you, if required, it can also include parts which apply to all use cases of your system. There would be the natural place for a non-functional requirement like "ability to change the language".


Use cases mean different things to different people. But it's not equivalent to a functional requirement. Otherwise, you'd end up with very complex diagrams that add little value to a textual list of requirements, and functional decomposition.

Use cases represent "sets of offered behaviors" (UML definition of a use case) that correspond to user goals:

A use case is all the ways of using a system to achieve a particular goal for a particular user. 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.
- Ivar Jacobson (the inventor of use-case and co-inventor of UML), in Use Case 2.0

In principle, you therefore should not diagram all the functional requirements, but only the most important ones. In some case you'd even group some together: The diagram should show the big picture.

Behind each use-case in the diagram, you'd have a description. Popular formats are Cockburn's template, Lockwookd and Constantine's "essential use case", more traditional ones often inspired by Bittner & Spence, or even simple text narratives). In this description you would find the remaining functional requirements, as well as non-functional requirements that are specific to a use case. But you'll also certainly have somewhere a list of general non-functional requirements that are relevant for all the use-cases.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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