Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Business Proces...  how does one derive processes from requirements?
Previous Previous
 
Next Next
New Post 1/17/2010 3:56 PM
User is offline mohoq
2 posts
No Ranking


how does one derive processes from requirements? 

I am little puzzled about how one derives processes from requirements.

In order to do use case modeling one has to know the necessary processes.

Where does one derive the processes from, is it from high-level requirements or functional requirements?

Is it necessary to specify process name beside each requirement, e.g. pay bill, order materials?

Thanks in advance.

 
New Post 1/18/2010 6:01 AM
User is offline Guy Beauchamp
257 posts
www.smart-ba.com
5th Level Poster




Re: how does one derive processes from requirements? 

 mohoq wrote
 

I am little puzzled about how one derives processes from requirements.

In order to do use case modeling one has to know the necessary processes.

Where does one derive the processes from, is it from high-level requirements or functional requirements?

Is it necessary to specify process name beside each requirement, e.g. pay bill, order materials?

Thanks in advance.

Hi Mohoq,

The definition I use of high level requirements is that they are statements of what the solutiuon must be able to do without any implication of the physical solution. A functional requirement would be a statement of what the computerised solution must be able to do.

In either case, they are statements of something that can be done. Doing something is (in this context) a process.

If you wish to document all the processes of the entire solution (computerised or not) then use high level functional requirements as a starting point. If you only wish to document the computeised processes then use functional requirements.

There is a many to many relationship between high level requirements (or functional requirements) and processes. E.g. The high level requirement "be able to order materials" might as you suggest be satisfied using "order materials" process. But the high level requirement "be able to order the building of a house" might also use the process "order materials" as well as (say) "plan work schedule".  Given this, while you might want to record which requirements are satisfied by which processes (and vice versa) as this is a many to many a table of some sort might be a better solution that noting the processes against the requirements.

Hope this helps.

Guy

 
New Post 1/18/2010 12:12 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: how does one derive processes from requirements? 

Hi:

If, for example, a software system is to "Calculate Sales Tax", this is a logical functional requirement.  It can also be partitioned into a logical process.

Stated differently:  Process: Calculate Sales Tax.  Logical requirement:  The system shall calulate sales tax.

With use cases, there is no formal mechanism to prod the analyst in discovering what the processes are.  Processes are determined by just plain old thinking hard (translation: by an unknown mystery).   The fact that use cases have no mechanism to prod the analyst to discover processes  is a HUGHLY important concept that is just plain over-the-head of about 98% of all BA's.    You would do very well to understand such.

Tony Markos 

 
New Post 1/18/2010 1:43 PM
User is offline Nathan Caswell
6 posts
10th Level Poster


Re: how does one derive processes from requirements? 

It works much better the other way around.

Requirements are, when you boil them down, just statements that are objectively true of the final system. No intrinsic sequence unless you happen to build it in. (This shall happen after that).

A process is a directed graph of activities. Generally you can get the requirements by asking 'what do you do', what doesn't work well, and gathering requirements around the new process. A crucial aspect of processes is that you have inputs, outputs, and invariants. These may or may not have been captured in your requirement set.

Use cases, with the scenarios defined, are also sets of activities. To keep it textual all the paths through are flattened and listed separately. No reason not to represent it as an activity diagram though. The key difference is that it is one actor that walks through the activities (card in the slot, card out of slot, enter pin, select transaction, ...).

It's a little baffeling how you have requirements (unless they are just a list of complaints) without something rather like either a process or a use case.

There should absolutely be tracability from a requirement to it's origin in a process, use case scenario, or other business entitiy and to the classs, packages, or subsystems that satisfy it.

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  how does one derive processes from requirements?

Community Blog - Latest Posts

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...
The cloud-native application development has helped enterprises all around the globe reduce time-to-market, enhance performance, and develop agility and flexibility. Several enterprises are achieving these results by migrating their systems or traditional monolithic applications to the cloud. But to gain from the real benefits of cloud technology, ...
So you’ve found the perfect time and place to study and you’re ready to finally get some work done. You’ve pulled out your laptop, your textbook, and your notes, and four different highlighters. After five minutes of reading your textbook, you start zoning out and thinking about puppies. Then, you go on Tumblr and look at cut...

 






 

Copyright 2006-2021 by Modern Analyst Media LLC