private7
private7

Reputation: 375

Is System Sequence Diagram part of Analysis or Design?

I'm wondering if System Sequence Diagram (SSD) belongs to design part or analysis part?

Upvotes: 1

Views: 1315

Answers (2)

muszeo
muszeo

Reputation: 2352

Elaborating a little on Christophe's answer:

I would add that analysis and design are two highly intertwined activities, so you would probably see these SSDs in both contexts and it would be perfectly fine and acceptable. Use Cases, those that involve a system, are necessarily a design artefact (they are a design of what the system does in relation to external actors) although you can of course see that same thing as a pure analysis output (telling you what the system is required to do). These things are very hard to separate. The point may seem philosophical (it is somewhat), but it is useful to think in these terms.

When you see people creating "Login" Use Cases you can bet they already stepped into pure design, in other words: functional decomposition. In analytical terms the state of a User being logged in is a constraint on a Use Case, not a Use Case itself. Having a Use Case called Login therefore represents only a design choice (incidentally, if you see this in contexts where there is a division of responsibilities between the people performing analysis and design, then you'd do well to consider it an analysis fail: the analyst is essentially designing the system and that's not their role). Analysts sometimes use Use Cases to model layers of requirements that relate only to business processes, usually referred to as "Business Use Cases", that don't involve any system per se. But the origins of Use Cases from 20-odd years ago was in the system space.

Upvotes: 3

Christophe
Christophe

Reputation: 73376

A System Sequence Diagram (SSD) is be a special type of UML sequence diagram that intends to document for one specific use case the the sequence of exchanges between the system under consideration and the outside actors.

It is not a standard UML diagram, but build upon such diagrams. The book "System analysis and design in a changing world" seem to have popularized this approach, but I could find articles dating back to the early 2000' (like this or this).

The above mentioned book places the SSD in the analysis activities. The reason is that analysis is about understanding the requirements, which often start with use-case. The SSD is then a fine-tuning of this analysis.

However, one could argue that it's part of the design activities, since the use case are the requirements, but how these requirements are addressed through a sequence of exchanges is already the start of the design of a solution, exactly as when you start to sketch an UI: more than one SSD could satisfy the needs and you have the choice.

So the answer depends on the purpose for which you're using the model.

My own point of view is that you're already drafting a solution, so it should be design, unless you do some reverse engineering of an existing application, or your client has very detailed requirements

Upvotes: 3

Related Questions