Business requirements vs Functional Requirements

[Crush]

We are setting up a new project.

We have both business and functional requirements.

Ideal format for a printed document would be
 
2.1  Business Requirement A
2.1.1 Functional Requirement A1
2.1.2 Functional Requirement A2
2.1.3 Functional Requirement A3

2.2 Business Requirement B
2.2.1 Functional Requirement B1
2.2.2 Functional Requirement B2

Also, we want to be able to print a doc with
1. just business requirements,
2. just functional requirements, or
3. both business and functional.

The question has arisen as to how to structure the requirements tree in the project browser.

One guy on the team wants to have a separate Business Requirements tree that is an identical match to the Functional Requirements tree. (Seems kinda complex and redundant)

example:

Business Requirements
  User Interface
  Printing
  Exporting

Functional Requirements
  User Interface
  Printing
  Exporting

Another guy on the team wants them all in one tree and wants to use the type field to distinguish the diff between Business and Functional (he added a Business type).

example:

Requirements
User Interface
 Business Requirement A
  Functional Requirement A1
  Funtional Requirement A2

  Business Requirement B
   Functional Requirement B1
   Functional Requirement B2

Printing
 Business Requirement A
  Functional Requirement A1
  Funtional Requirement A2

  Business Requirement B
   Functional Requirement B1
   Functional Requirement B2

Exporting
 Business Requirement A
  Functional Requirement A1
  Funtional Requirement A2

  Business Requirement B
   Functional Requirement B1
   Functional Requirement B2


This method seems cleaner and simpler to me, but Im wondering what would be standard practice or possible gotchas down the road with either approach.

Any ideas?

Thanks in advance!

 8-)

[sargasso]

Standard Practice:

Use one tree to print out all business requirements. Get that signed off.
Use another tree to print out all functional requirements. Get that signed off.
Place both signed off copies in a secure environment, a very secure environment.
Create a usecase model.  Balance usecase model against budget i.e.  (Apply Occams Razor, aka a chainsaw, against usecase model and decide what really can be done on time and in budget)
Use another tree to provide evidence that usecase model is actually a project plan.

Implement... and while implementing retrieve both authorised requirements documents for amusing reading at best or as evidence to be raised in court (in case your chainsaw was rusty).


Seriously, it doesn't really matter.  The structure of a requirements model is only beauty in the eye of the beholder.  What does matter is how that model can be unambiguously be interpreted, by both the business (i.e. the budget provider) and the implementer (i.e. the scum sucking bottom feeder that is the natural prey of all us budget providers).  It's like this, if you will allow me a little geographic inconsistency,  a polar bear engages a penguin to supply him with the ingredients for a reasonable seafood diet.  The requirements (business) say "get lots of fish or I'll eat you".  The "functional" requirements say "provide user with immediate access to an unlimited amount of piscatorial protein on demand".

[DanG83616]

It is generally easier to generate documentation if you structure the elements in the project browser to match the document layout. It seems likely that the all business and all functional sets are the two sets you'd actually print. Query reports might be adequate for the mixed output. You can use the Satisfies relationship to link functional to business requirements.

It might turn out that the structure for one set is not so intuitive for the other. Separate trees gives you the freedom to structure the documents according to domain. The business requirements are probably the goals of your uses cases. The functional requirements will fall out of the use case scenarios so there is a good chance that trying to use a single structure will be a compromise for one or both sets. If your team is having any trouble understanding your definitions of business and functional requirement then separate structures will help with that, too.

HTH, Dan