RE: [epf-dev] supporting requirements

[Russell Pannone <rpannone@xxxxxxxxxx>]

Business rules come in many shapes and sizes.

There is art and science in and of itself for identifying and articulating the rules that define the structure and control the operation of an enterprise.

Learn more about business rules from the attached or go to this link: http://www.businessrulesgroup.org/first_paper/br01c0.htm

Take care,
Russell Pannone
_________________________________
Method Architect and Software Engineer
RUP/RMC 7.x Certification, UML Certification, ITIL Foundation Certification
IBM Software Group, Rational
San Jose - CA 95141
Tel: +1 (408) 463-5286

"Things turn out best for the people who make the best out of the way things turn out."

(See attached file: BRG-whatisBR_3ed.pdf)

Jim Ruehlin/Irvine/IBM@IBMUS

Jim Ruehlin/Irvine/IBM@IBMUS
Sent by: epf-dev-bounces@xxxxxxxxxxx

06/19/2007 08:18 AM

Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>

To	epf-dev@xxxxxxxxxxx
cc
Subject	RE: [epf-dev] supporting requirements

Hi Ronaldo,
 
Business rules often state the requirements of the business that need to be realized in the software. Said another way, the business must conform to these requirements whether or not those requirements are implemented in the software. Sometimes business rules are considered a type of software requirement, while other organizations refine business rules further into requirements.
 
For instance, a mortgage company might have a business rule that states that a mortgage application must have certain information (name, social security number, annual income, etc) before it can be accepted. In other words, the “state” of the application is “accepted” only after certain data has been provided. This might be good enough as a software requirement for some organizations. Other organizations would refine it further into a requirement by saying something like “Mortgage application data must include the following: name, (etc), before the application can be submitted to the system”. 
 
Personally, I prefer refining it into a software requirement. It can often be the case where a business rule evolves into multiple software requirements. In the example above, a functional requirement has been identified. A usability requirement can also be defined that states “The Submit button is inactive until the following information has been entered: Name (etc)”.
 
Jim
 
____________________
Jim Ruehlin, IBM Rational
RUP Content Developer
Eclipse Process Framework (EPF) Committer www.eclipse.org/epf
email:   jruehlin@xxxxxxxxxx
phone:  760.505.3232
fax:      949.369.0720

---

From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of "Nate Oster" <noster@xxxxxxxxxxxxx>
Sent: Tuesday, June 19, 2007 7:43 AM
To: Eclipse Process Framework Project Developers List
Subject: RE: [epf-dev] supporting requirements
 
Ronaldo, 

I'm not sure where in OpenUP you're referencing, but I think the 
distinction is SCOPE. "System wide Functional Requirements" are 
*global* - they apply to the entire system. The entire system must 
behave a certain way. 

"Business Rules" might be associated with only part of the system. For 
example, there may be many business rules about a Register Member use 
case, but contradictory business rules for the Manage Member Profiles 
use case. There could be any number of reasons for this, such as 
different actors (perhaps one is an end user, the other a customer 
support engineer). 

Is there somewhere that this is too ambiguous in OpenUP? We can always 
submit a bug! :) 

Nate 

-----Original Message----- 
From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] 
On Behalf Of Ronaldo r 
Sent: Monday, June 18, 2007 3:30 PM 
To: Eclipse Process Framework Project Developers List 
Subject: [epf-dev] supporting requirements 

What's the difference of "System wide Functional Requirements" section 
and "Business Rules"? What kind of rule fit in each of these? 

_______________________________________________ 
epf-dev mailing list 
epf-dev@xxxxxxxxxxx 
https://dev.eclipse.org/mailman/listinfo/epf-dev _______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev

Attachment: BRG-whatisBR_3ed.pdf
Description: Adobe PDF document