Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Documenting requirements for automated processes
Previous Previous
 
Next Next
New Post 12/8/2009 1:08 AM
User is offline Peter Herring
13 posts
10th Level Poster


Documenting requirements for automated processes 

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.:-

  • We receive an XML from an external source wihich is imported into the system and validated.
  • From here the system will run a number of business rules
  • If validated a new policy is setup automatically

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

 

 
New Post 12/8/2009 9:33 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Documenting requirements for automated processes 

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

 
New Post 12/9/2009 6:48 AM
User is offline Peter Herring
13 posts
10th Level Poster


Re: Documenting requirements for automated processes 

 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.

 

Regards

 

Pete

 
New Post 12/14/2009 1:42 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Documenting requirements for automated processes 

 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 

 
New Post 12/16/2009 12:27 AM
User is offline Peter Herring
13 posts
10th Level Poster


Re: Documenting requirements for automated processes 

Hi, Thanks for your reply.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Documenting requirements for automated processes

Community Blog - Latest Posts

Salesforce has established itself as one of the most reputable CRM platforms, providing important customer data to assist businesses in effectively managing their operations. Salesforce is the world's best CRM platform that helps businesses to keep up the data in an arranged or structured manner. Salesforce is the world's most popular...
There are big differences between data exploration versus data presentation. And you need to be aware of these differences as you're creating data stories and data presentations. Let’s start by defining our terms: Data exploration means the deep-dive analysis of data in search of new insights. Data presentation means...
Is Agile a reason to avoid documentation? I bet this question shows up again and again while working with product requirements. On one side, we have got long specifications, complicated diagrams, mystical technical design, too many prototypes and pretty obvious for engineers user guides (do we really need so much?). On the other side, can we actual...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC