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 4: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 7: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 1: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 2: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

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC