Business Requirements Document

[Thomas Mercer-Hursh]

I have a customer who has a need for a business requirements document (BRD) to cover the workflow in one of their lines of business.  I have done a lot of this sort of thing in the past, but never using UML .. which now seems like the obvious thing to do.  Does anyone have an sources they can point me to for an example BRD that I can show the client as what to expect?  Any other particular resources that might be useful?

[marcelloh]

I won't draw anything that is not meant to be drawn ;-)
A BRD holds no graphical representation as far as I use them.
And what would this look like on a big projects with more than 250 BR's?

[Geert Bellekens]

Marcel,

It's not because you use UML that you have to draw diagrams.
I can perfectly imagine a model with lots of elements (business requirements) that are not used on any diagram.

Geert

[marcelloh]

Silly me  :-)

I thought UML is:
UML includes a set of [highlight]graphical notation techniques[/highlight] to create visual models of software-intensive systems.

The Unified Modeling Language (UML) is used to specify, [highlight]visualize[/highlight], modify, construct and document the artifacts of an object-oriented software intensive system under development.[1] UML offers a standard way to visualize a system's architectural blueprints.

I agree... the visual part is a part of UML, but not nessecary if the audience can live without it.  

[Paolo F Cantoni]

Silly me  :-)

I thought UML is:
UML includes a set of [highlight]graphical notation techniques[/highlight] to create visual models of software-intensive systems.

Includes doesn't mean IS...  It's the difference between composition and inheritance...  

The Unified Modeling Language (UML) is used to specify, [highlight]visualize[/highlight], modify, construct and document the artifacts of an object-oriented software intensive system under development.[1] UML offers a standard way to visualize a system's architectural blueprints.

There are many ways to visualize things WITHOUT a graphical interface...

I agree... the visual part is a part of UML, but not necessary if the audience can live without it.  

The real problem if UML is that although it includes the graphical notation techniques, the diagrams themselves (except for the special case of activity diagrams) are not part of the language itself - that is, not first class citizens.

HTH,
Paolo

[Geert Bellekens]

Silly me  :-)

I thought UML is:
UML includes a set of [highlight]graphical notation techniques[/highlight] to create visual models of software-intensive systems.

The Unified Modeling Language (UML) is used to specify, [highlight]visualize[/highlight], modify, construct and document the artifacts of an object-oriented software intensive system under development.[1] UML offers a standard way to visualize a system's architectural blueprints.

I agree... the visual part is a part of UML, but not nessecary if the audience can live without it.  

Marcel,

Are you saying that ALL UML elements in a model should be used on a diagram to be a valid UML model :-?

Do you show every comment, constraint, tagged value,... on a diagram?

... didn't think so...

In fact I'll go even further. If I delete all diagrams in my model I haven't lost any information about my model.

The only thing I've lost is an effective way to work on the model and communicate it to humans. (and yes there are other audiences for UML model then humans, think code generators etc..)

Geert

[son-of-sargasso]

[size=8](ahem, just getting back to Thomas here)[/size]

a need for a business requirements document (BRD) to cover the workflow in one of their lines of business.

If it was me,
1) model their workflow using whatever UML workflow modelling method and or diagrams you will and arrive at a point where both you and they agree that it adequately defines the current situation.
2) identify the changes that are expected and the benefits that will be realised.
3) remodel the "to be workflow", including all new/changed actors to level that [size=8](watch this bit carefully, my hands will never leave their arms)[/size] will allow you to specify a BRD in whatever format is convenient to both you and the client.
4) write BRD
5) receive acclaim and reward, go on to design the solution, build it, implement it and retire well-off, fullfilled and etc etc

UML is a technique, the artifact of the assignment (AFAICS) may or may not need to have a single "stick man" or "football" in it.

cheers
bruce

p.s. But if you do frame the functional requirements in terms of use case, every poor sodding tester involved in the ultimate project will be forever in your debt.  

[marcelloh]

@Geert:
No, I didn't mean to say that  
Just that as a "best of breed" the UML has a graphical representation,
so the visual strong people can read our thoughts too
Of course you can leave it out.
(That's why I said, it depends on the audience. )

@son-of-sargasso:
And of course we could develop a new way of visualising our thoughts,
but it's better to go with the flow.

@Everybody:
I know we understand exactly what we write ourselves, but the trick
is, we don't actually write for ourselves. And the saying goes like this:
A picture is worth more than a thousand words.

So, did I mention the silly me part gheghe.

Perhaps it would be better in this case to ask the client a template (or download one), just to see at what part EA can come in handy.

[Paolo F Cantoni]

My take on it is that "A picture is worth a thousand words" - until there's more than 6 boxes or 12 lines on it!  In that case, all bets are off...

 

Paolo

[marcelloh]

You weren't referring to my last family picture, did you  

[Thomas Mercer-Hursh]

I'm not sure why all the excitement about diagrams.  A BRD that was all diagrams probably wouldn't accomplish much, but a BRD without diagrams would probably be less clear than it could be.  I got a couple reasonable samples of RTF output which are in the right direction, if a bit sparse and possibly not my idea of the perfect formatting, but they certainly get the idea across.

I was just hoping that someone could point me to a richer example, something about a more enterprise-class focus than the samples provided with EA.

[paddler]

Dear All

 Having just gone through this I can speak  with some limited confidence on the matter.

 If you need to captiure their BUSINESS in some way and then identify gaps and BUSINESS REQUIREMENTS to help them meet BUSINES needs ( as opposed to functional/software ones) I would suggest using

- Business Use Cases ( you can create this brand of Use Case in EA - there is even a stereotype for it!!). The BUC would show what steps are taken by whom in an organization to respond to a client request of any kind.

- As you are writing this out..identify all of your actors (internal to the business and external to the business...the former are called Business Workers). You can create an actor model if you wish

- Lay out the BUC in an activity diagram. The activity diagram's swimlanes would be "named" after those Business Workers who took part in the Business Use Case.

Now you have a textual and graphical representation of the business processes. A nice extra step, is to draw out a rough domain model of business objects as you are documenting the Business Use Cases..

 Dor more, see "Practical SW Engineering - Analysis and Design for the .Net Platform _ enricos Manassis"

I wish our snow would go