Re: Where are the limits of Business Requirements Documents / Software Requirements Specifications?

[Keith Hood <bus -dot- write -at- gmail -dot- com>]

I was taught that business requirements should explain what functions a
product should provide in order to allow the user to accomplish some goal.
Those include front-end functions that say what a user should be able to
see and do, and back-end functions that say what the product has to do in
order to effect communications between the user and the core. As far as how
those functions are implemented, things like whether the user is given a
pulldown list instead of a clump of option buttons, what kind of data
format is used to pass information to the back end, those are enumerated in
a functional requirements document, which is focused more narrowly. The BRD
is what the user should expect, the FRD is how the user is given what he
should expect. Despite the name, business requirements do not necessarily
have to do with dollars and cents, and they can be developed by anyone who
has a clue what the product is meant to do. Business analysts definitely
can play a key role in that, but any tech writer who has more than a couple
of years of experience in a development environment should be able to come
up with useful BRDs. There is often a great deal of overlap between those
two jobs.

On Sun, Jan 25, 2015 at 2:51 PM, Uwe Ziegenhagen <ziegenhagen -at- gmail -dot- com>
wrote:

> âHello,
>
> a few days ago I was part of a discussion of what BRDs are to provide. A
> few colleagues argued that BRDs not only define the business' requirements
> but also what the solution (which the BRD describes) will provide.
>
> For me a BRD describes the requirements (even the name says so), not the
> actual deliverables.
>
> To define what the actual deliverables for ths BRD are, other documents
> such as design specifications (from the software vendor) must be prepared
> and discussed with the business.
>
> The following statement from IEEE 830 describes it well in my opinion:
> "Establish the basis for agreement between the customers and the suppliers
> on what the software product is to do." (not: will do)
>
>
>
> What is your opinion on this?
>
> Thanks,
>
>
> Uwe
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Doc-To-Help: The Quickest Way to Author and Publish Online Help, Policy &
> Procedure Guides, eBooks, and more using Microsoft Word |
> http://bit.ly/doctohelp2015
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as bus -dot- write -at- gmail -dot- com -dot- 
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
> http://www.techwhirl.com/email-discussion-groups/ for more resources and
> info.
>
> Looking for articles on Technical Communications?  Head over to our online
> magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions?  Search our public
> email archives @ http://techwr-l.com/archives
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Doc-To-Help: The Quickest Way to Author and Publish Online Help, Policy & Procedure Guides, eBooks, and more using Microsoft Word | http://bit.ly/doctohelp2015

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications?  Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions?  Search our public email archives @ http://techwr-l.com/archives