Both organisations are actors (primary actors that is) of the process.
The subject boundary would be invoice transmision
Use cases could be:
package unload invoice (actor org 1)
use case send invoice (actor org 1 and 2 this for handshaking making sure it all arrives and goes)
use case receive invoice (actor org1 and 2 see above)
package load invoice (actor org2)
I introduce package because i assume there are some flags and other settings required to make the db aware that the invoice is send or unloaded. You do not want to send the same invoice twice i reckong.
Use class diagram to define the information contents of the invoice and required transmittion controls.
Hi, IT Farmer. Since actors are outside the system, it seems that you assumed the system is outside the two organizations, right? What you do differs a lot by different system boundary.
No not really, where the system is is independant from any organisation. Same applies for subject boundary (system boundary).
Each organisation has interaction with one or more use cases. Where the system (Solution) resides is not relevant to use cases. Even better the solution in general is not relevant, use cases are about requirements not the perse the solution for the requirements.
Think what and how, the issue here is what is required not how it is resolved.
No not really, where the system is is independant from any organisation. Same applies for subject boundary (system boundary).
Each organisation has interaction with one or more use cases. Where the system (Solution) resides is not relevant to use cases. Even better the solution in general is not relevant, use cases are about requirements not the perse the solution for the requirements.
Think what and how, the issue here is what is required not how it is resolved.
OK, IT Farmer, you aggreed with “the actor is outside the system boundary”. Do you agree with “System boundary is the boundary between the system being developed and the outside world” (http://www.apl.jhu.edu/Classes/Notes/Schappelle/704/RequirementsModeling.PDF)? And then, do you agree with “it seems that you assumed the system is outside the two organizations”?
LOL, I do not agree with the statement but lets put it this way, quite frankly it is plain wrong from a requirements gathering point of view. (based upon the name of the PDF). See requirements gathering is exactly that it should not denote a solution eg using things like system boundary. System hints towards a computerised solution, and it not necessary requires a system it can be just as simple as a process change.
Anyway the correct statement would be something like:
“Identify the boundaries of the system by deciding which behaviors are part of it and which are performed by external entities. This defines the subject.”
“Subject boundary is the boundary of the subject area that is represented in the diagram” Having said that a boundary it is too ring fence what you are going to model. Do not get hang up to much on the “outside world” thingy.
I do not event think there is such a thing of a system boundary, it should be called subject boundary.
See UML states that the “System is a collection of connected units organised to accomplish a prupose.” So the model describes the system.
Not sure why you are so persistent on me to agree that the system is outside two organisations. It is not relevant for any UML modeling. See UML modeling is not about dictating the solution or where what resides.
The solution or where and what resides (inside or outside organisations) is irrelivant to UML modeling at this level UML modelling does not care if the system is in organisation one or organisation two or both. As long the organisations can exchange invoices it does not matter if the “system” is on the moon. Where it is is and implementation issue not a modeling one.
Hi, Henk. I think whether the system resides on org1 or not makes a big difference. If you have an external interface, you have to identify it. Then, discuss about the interface with the outside system owner. If it’s not the case, you can define it within your system. That’s why I think system boundary helps. Use case model is to define how the system interact with actors. If you don’t give a precise definition on use case model, how can you develop your system or test case accordingly?
Let’s talk about three kinds of actors:outside system, human actor, and time. external interface to outside system is conceptually same with GUI to human actor. But in practice, we have different process for them:
1.if actor is outside system:Negotiate external interface with outside system owner. An interface spec is required. Design a subsystem for the mechnism of external interface.
2.if actor is human actor:Design GUI. Negotiate with the corresponding people.
3.if actor is time:Use the built-in timer utility in programming language or design timer utility by ourselves.
That’s our process for 3 different kinds of actors.
but it is IT Farmer