home
Home » Requirements Management

Are business rules part of requirements

Submitted by larrygoldberg on Tue, 2007-06-12 08:16.

I was speaking to Barbara von Halle after she returned from an address to requirements people in Connecticut recently, and she told me how surprised she was that the folks at her talk did not see business rules as part of their activities. I wonder whether participants in RQNG believe that business rules are an integral part of requirements gathering...

» login or register to post comments | previous forum topic | next forum topic | printer friendly version | 3880 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Yes

Submitted by Kevin Brennan on Tue, 2007-06-12 11:15. *

Like Barbara, I have a hard time understanding the idea that they aren't.

---------------------------------------
Kevin Brennan, CBAP, PMP
Vice-President, Body of Knowledge, IIBA

» login or register to post comments

Relationship Between Business Rules and Requirements

Submitted by rcauvin on Tue, 2007-06-12 14:56. *

Understanding existing and future business rules is indeed an integral part of requirements gathering and definition. However, business rules do not always drive requirements. Sometimes, it's the other way around. More here.

» login or register to post comments

I wonder...

Submitted by Rojo22 on Tue, 2007-06-12 15:40. *

I would be rather perplexed by the overall sentiment that the business rules are not considered "part of their activities".

I wonder then, what do they use to define the level of detail at which the requirements can be used by the design team to satisfy many of the contextual questions?

Business rules are critical to offering the level of detail the requirements need to support the entire user need, and not just satisfy an open request for functionality in an open context. Solving the business needs will require at best a minimal elicitation of the business as it is applied, thus the rules.

I would be open to hearing how the detail is captured by those who do not feel the business rules are part of the process, but business rules are easy to elicit, and offer a very traceable method across the requirements landscape.

» login or register to post comments

Yes and No

Submitted by jamet123 on Tue, 2007-06-12 16:14. *

YES in the sense that clearly capturing rules should be part of the process that also captures requirements and that many of the techniques used to capture requirements also work for capturing rules and that keeping rules explicit but linked with the requirements process can be very effective.
NO in the sense that rules are not requirements and so should be managed, described and ultimately implemented differently.

JT
My blogs: www.edmblog.com & www.ebizq.net/blogs/decision_management

» login or register to post comments

What is your definition of a requirement?

Submitted by kupe on Tue, 2007-06-12 16:41. *

Why is a business rule not a requirement? I too am as surprised as Barbara.

» login or register to post comments

Rule vs Requirement

Submitted by cpwalker on Tue, 2007-06-12 16:53. *

Over-simplifying...

A requirement is something that must be done (by a person, within a process, by a system).

A rule states, from a business perspective, HOW the requirement must be met. I.e.: it's a condition that determines which path you take through a business process.

Think of the process of obtaining a passport. If the applicant is under 16 use the green form. If the applicant is 16 or over use the blue form. Same process, different rules (conditions).

» login or register to post comments

Requiremments are...

Submitted by dwright on Wed, 2007-06-13 10:11. *

The problem is, do we have a good definition for a Requirement in the first place? I finally found the following:

"A requirement is a property that is essential for an IT system to perform its functions. Requirements vary in intent and in the kinds of properties they represent. They can be functions, constraints, or other properties that must be provided, met, or satisfied so the needs are filled for the system’s intended users. …Roger Abbott (1986)"

Given this, I would say that automation of Rules can be a requirement, but the Rules themselves exist independently.

Now, if you are going to automate some Rules, you do have to know what they are, and capturing them is much like capturing Requirements, which is why we might think they are indeed Requirements.

To me, Rules are business information which can be captured and automated, just like business data is kept in a database. In the latter, knowing that the system must capture Customer Name is a requirement, but the name "Fred Smith" is not a Requirement.

So, automating Rules can be a Requirement, and categorizing Rules as Constraints, Calculations, Inferences, etc., might be part of that Requirement. "Customer must be 19 or older to buy alcohol in Ontario" is not a Requirement.

What this implies (for me, anyway) is that like adding or changing a Customer Name does not require a programmer to change code, adding or changing a business rule should not need a code change either.

David Wright
Member, IIBA
"I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How and Where and Who." …Rudyard Kipling

» login or register to post comments

rules are not requirements

Submitted by barbaravonhalle on Thu, 2007-06-21 13:07. *

Very well said. In fact, we have had discussions as to whether rules that are to be automated ought to be treated as "code" (because they represent executable logic) or "data" (because they are actually instances of a pattern of logic).

The reason that distinction is interesting is that we manage code differently than we manage data. I think your comment brings this to the surface.

For example, there is a whole change management process around changing code in a program and yet a different process around changing rows in a relational table. It is easier and faster to change rows in a relational table than to change code in a program.

I like your comment, which indicates that the individual rules are not requirements, they are more like business information. That probably means that rules themselves are instances of something bigger (a rule pattern, perhaps).

» login or register to post comments

Perhaps we should improve the processes surrounding data?

Submitted by ScottWAmbler on Mon, 2008-01-28 16:01. *

If data is a critical component to the definition of a business rule, should there not be some sort of CM process in place to protect it?

Seems to me that the IT industry has some very significant challenges when it comes to data quality, and part of the issue is we keep tolerating undisciplined data management approaches. We can CM data as well as code.

- Scott
Scott W. Ambler
Practice Leader Agile Development, IBM Rational

» login or register to post comments

Yes, but turn the statement around.

Submitted by jsammy on Mon, 2008-01-28 20:24. *

I agree that CM should be applied to requirements - not just information requirements. In fact, I'd take your first sentence and turn it around:

If business rules are a critical component to the definition of data, should there not be some sort of CM process in place to protect them?

Julian Sammy
Chief Architect, IIBA

» login or register to post comments

  Sponsored Announcements & Special Offers


FREE Web-based Requirements Management (not just a trial, no time limit)
Lighthouse is a web-based IT project workspace for managing requirements, change requests, project scope, and much more. Lighthouse also automates traceability through the entire life cycle so you will always know the impact of change requests and whether requirements have been built, tested and fulfilled. Free for 5-users, sign-up today.

Download a free trial of ActiveVOS for BPM application development for a chance to win an ultra-portable Lenovo IdeaPad S10 netbook
With the ActiveVOS Business Process Management system (BPMS), the creation of compelling business process applications is compatible, scalable and affordable for everyone from the developer to the business analyst. Download a free, 30-day supported trial of ActiveVOS for the chance to win a Lenovo IdeaPad S10 netbook. No purchase necessary. Download ActiveVOS today at www.wheel-of-function.com.

Writing Use Cases with Word and Excel? Suffered enough?
Create use cases, requirements, diagrams, test cases, and screen prototypes - in one easy-to-use tool. Generate Word and Excel specifications automatically. Consistent, traceable requirements in less time. Try CaseComplete FREE for 30-days.


© 2007 Requirements Networking Group All rights reserved. contact | advertise | privacy
Requirements Networking Group