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

Heta Raval
Heta Raval
In a current scenario, when you are eliciting software service-based requirements then, you may be able to derive requirements in certain varieties. In the beginning, they can be just functional or non-functional requirements. But when you come across many other requirements as time goes, you can conclude requirements into several categories and wi...
0 Responses
Heta Raval
Heta Raval
It is essential to write an impressive approach which helps you to make a client convinced about your understanding of his requirement. The satisfactory approach would help you to be on the same page with the client. So, your chances to get the contract/project would raise. In order to provide a technical solution, a business analyst needs to recog...
2 Responses
Arash
Arash
Machine Learning (ML) models are intended to positively impact business efficiency. By understanding how these models are created, how they function, and how they are put into production, one can fully utilize their potential to make a difference in every day scenarios.   What is a Machine Learning Model? By creating cases within a narrow d...
0 Responses




Latest Articles

Six Estimation Safety Tips
Oct 13, 2019
0 Comments
Estimation is a chronically thorny issue for software practitioners. Most people need to prepare estimates for the work they do, but in our industry w...
Copyright 2006-2019 by Modern Analyst Media LLC