Hi I am hoping to get some feedback around how you guys document these type of requirements. I am working on a project at the moment Where I have just completed a number of Use Case specifications. I am now trying to document one where the process is automated and should have no user interaction. To summarise it's for an insurnace policy systemand in this instance we are receiving business in from an external source.:-
IF the process fails an taks is created an a user will then need to take a look.
Any help will be greatly appreciated.
Regards
Hi:
Sounds like you believe that documenting a completely automated process is different than documenting other types of processes, including, for example, a manual process. Is this true? If yes, can you state why? (Helps with formulating advice.)
Tony Markos
Hi Tony,
No, it isn't that I feel they are different. In previous projects I've worked on they haven't necessarily used Use Cases to document these type of processes. Some people I've worked with believe that Use Cases should only be used where a human user is interacting with the system. Personally I dont see a great deal of difference other than how to produce a flow where the system is interacting with itself, rather than interacting with an external actor. as an example, from the point of receaiving new business electronically, the system goes through a process of validating the information against business rules, and then automatically setting up the policy. I hope this makes things a bit clearer.
Pete
Hi Pete,
An actor in UML speak can be a person or an external system. In your example, the initiating actor in your use case is the external system that sends the XML file to your system. Btw, "external" does not have to mean external to your company, its just another system from the one that you're defining. For example, I often find that most systems I model have automated functions where the triggering actor is something like a scheduler or even think of it as the system clock - whatever works for you.
And yet another thing to remember is the actors - people, systems - that your use case interacts with e.g. you may notify another user of something or update the general ledger. Even though we aren't in solution mode, putting in the effort here, helps you start to identify interfaces you'll need.
Kimbo
Hi, Thanks for your reply.
brought to you by enabling practitioners & organizations to achieve their goals using: