Recently I learned that sequence diagrams can be used at both requirements specification and design level.

My search so far shows the boxes on top of the sequence diagrams used for design consist of objects, while the boxes used on top of sequence diagrams for requirement specification contain classes, and other concepts such as data stores. I see actors used in both.

Could you please help clarify the differences for me?

  • 1
    It seems like you've identified the difference. What more are you looking for?
    – Thomas Owens
    Oct 19, 2021 at 22:07
  • I Just guessed from some pictures. It does not mean that I am right. There must be systematic difference, and exactly which elements each contain. Stack exchange requires that we show effort. I just mentioned what was the result of my effort, which is by no means correct
    – Melanie A
    Oct 20, 2021 at 3:25

1 Answer 1


There's no difference in terms of the kinds of elements that you'd use (classes vs objects, kinds of arrows, etc.). It's the same kind of diagram. The difference is extraneous to UML and depends on the details of the development process people use; the difference is entirely in intent, and the level of detail needed.

UML is a communication tool & a thinking tool; diagrams can be used in formal documents (such as a specification), but you can also use them in informal settings, e.g., you and your teammates gathered around a whiteboard, trying to figure out how to approach the problem, what the "moving parts" are, what extra info you'll need to collect from your clients, etc. You don't have a specification, you're trying to come up with one. So, in this initial phase, people might be scribbling diagrams on the whiteboard to capture what's known, or to work through ideas etc. You might even have one of the business stakeholders in the room, and ask them to clarify things as you draw. (I'm not talking yet specifically about sequence diagrams, but diagrams in general.)

You are working with incomplete information at this stage, so your diagrams are not intended to be exactly what you are going to make in the end. They are high-level, conceptual diagrams, intended to give you a rough idea of what you're dealing with. E.g., the business people (your clients) might have mentioned that they need to have products placed into a small number of major categories, and then each is classified into a product type. So you draw a "Product" box, connect it with a "Category" box, and with a "ProductType" box.

The connections do not neccesarily mean that there's going to be a member field in a Product class that references an instance of the Category class. Maybe it will, but maybe the Category will be just a string, or an enum. Or maybe they'll be related by the database ID. You're just identifying general conceptual relationships between elements at this stage. Is Product represented by a single class, or is it a composite object made up of 3 classes? You don't know - you'll find out later, but at this stage, it's just a single box. What's the multiplicity on the Category end: 1, 1..*? Can a Product belong to more than one Category? You assumed not, but now that you think about it, the business people weren't clear about that. What should the system do if no category is specified? You'll need to find out all that too. But wait, to which box should the ProductType connect? Is ProductType really a subcategory, so that you can divide ProductTypes into these categories (so it should connect to Category), or is ProductType an entirely separate (orthogonal) property (so it should connect to Product)? If you had a business stakeholder in there, you could ask them which picture makes more sense.

So you see, these diagrams aren't detailed, they are rough sketches and are not set in stone. You might draw a bunch and then erase them, throwing them away. You might come up with something that you feel captures the big picture well enough, take a photo of that, and place it in an internal wiki or something. You're not going to expend a lot of effort writing formal documents containing these conceptual diagrams, because your conceptions will change as you learn more, and the exact details of the implementation might depend on the quirks of the libraries, languages and other tools you use to actually build the system.

You use sequence diagrams to work through, for your own understanding, (or depict, for others) a sequence of events in an interaction. But this is only really useful if there are some subtleties in the interaction that you want to emphasize. Something that may be confusing, or non-obvious (e.g., maybe there's a lot of nontrivial back and forth, or maybe the call goes off to some non-obvious object to make a decision, or maybe there's asynchrony involved). If the interaction is simple (like a straightforward sequence of calls), then just don't draw the diagram. You don't have to have every kind of diagram for everything.

My search so far shows the boxes on top of the sequence diagrams used for design consist of objects, while the boxes used on top of sequence diagrams for requirement specification contain classes

The boxes on top are always instances (objects) - classes are just static "blueprints" for how to create objects, and they don't really interact; it's object that talk to each other at runtime. (At least in the idealized OO world; you can tweak this to suit your needs; e.g. you might have static classes and/or free functions that you want to include.)

The boxes contain labels of the form objectName:ClassName, but often you don't care about the object name, so you use an anonymous object, and write :ClassName. So it's still an object, it just isn't named. Sometimes, people will not bother with these formalities, and will just write ClassName.

  • Thank you for the great response. In the book UML Distilled it is mentioned "Most of the time, you can think of the participants in an interaction diagram as objects, as indeed they were in UML 1. But in UML 2, their roles are much more complicated, and to explain it all fully is beyond this book. " that is why I assumed boxes could be anything, not necessarily objects.
    – Melanie A
    Oct 21, 2021 at 7:13
  • So in case I see Database written in a box, does that mean database is an object? I have seen some examples like that.
    – Melanie A
    Oct 21, 2021 at 7:14
  • @MelanieA Don't overthink it too much; technically, it's always an instance of something. A class (or a type, or in ordinary language, a kind, a group, a species, etc.) is really just a name for a group of things that share certain common characteristics. E.g. the name "pigeon" is a species of birds, denoting any pigeon there is; any individual pigeon is an instance - a specific example of, or a specific animal belonging to - that species. An instance of a class is called an object in OOP (in other context "object" is just a generic word denoting "a thing"). 1/3 Oct 21, 2021 at 12:46
  • @MelanieA Now, your software is going to be communicating to a specific instance of a database (e.g. a production database deployed at client A's company, as opposed to the same kind of database deployed at client B, or your test database). So, in a diagram, the "Database" is an instance ("a database actually running somewhere"), but this is often not too important to emphasize. But maybe you have two instances of the same "kind" of database that you need to sync or something. 2/3 Oct 21, 2021 at 12:47
  • @MelanieA Sometimes, the person who made the diagram will write "Database", but actually mean "an instance of a class that communicates with the database" or something along those lines; often it doesn't really make a difference, but the meaning might be clarified in the accompanying text (if any), or if it's an internal document of sorts, people working together might just know what's meant. 3/3 Oct 21, 2021 at 12:47

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.