qwerty:
You ask: "Quite often the business requirement is the same as the user requirement?!"
I suggest that you ask yourself (and really few do this, so if you do, you will propel yourself ahead of the masses): Is there a real need to partition behavioral related requirements seperately into business requirements, user requirements, and funcitonal requirements?
Data flow diagramming principles tell us that the answer is no. With DFD's we can, at the highest level of abstraction capture business behavioral-related goals. And we can also decompose the business goals downwards to the detail level requirements met by manual efforts or within a computer.
In other words with DFD's ALL behavioral requirements - whether the are manual or automated, high-level business or embedded within a computer - are called the exact same thing. This unified view of requirements is critical to larger scale integration efforts, where a false partitioning of requirements into different types adds another layer of complexity that can really retard initiative.
Tony
You could just as easily model some of it in a Use Case as well though?
I suppose it depends on the project or system but perhaps the User requirement can be used during UAT by the actual users to see what they have to check and what was supposed to be included.
The BR might be: design an online shop
The URs might be: buy, edit account, checkout, login, logout + use cases
The FRs might be: the exact data processing, field names, how often updates occur, etc.
But sometimes you get a BR for a system enhancement, which is just: we now need to include all email addresses as usernames. The user requirement is almost the same here, it would be UR: user can use an email address or a username to login.
Qwertyjjj,
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: