I am new to the role of a BA. Currently looking for a new assignment. On one of the interviews I was asked the following question:
"Would you include user stories into the BRD?".
It is me asking now:
Should they be included? If "YES" - why?; if "NO" - why? -
Should the use cases be part of a BRD or a sepparate document?
I am looking for the best practice and what is appropriate. Any help is appreciated.
Thank you.
Hi:
Some of the "experts" say that in an Agile environment, the BA would ONLY create the user stories - no supporting text. The User Stories would be the higher level behavioral requirement, and the detailed requirements would be fleshed out in conversations between the developers. Nix the BRD.
The same would apply in using Use Cases in an Agile project. Junk any wrtten BRD.
The problem that I see with using User Stories and Use Cases is that:
* They offer no means of accomplishing significant decomposition. (Decomposition is needed in higher level projects.)
* The REAL need is not so much to ID standalone requirements, but the essential interrelationships between the requirements (i.e., the data flows).
So for a best practice in documenting behavioral related requirements, I suggest an Agile approach using higher level essential data flow diagrams. No written documentation needed.
Tony
Tony,
You may or may not recall that I am not sold on your focus on data flow diagrams. However, if you could offer us an example or pilot of udsng DFDs, I for one would like to see it.
My philosophy is :" I may not like what you are doing, but if it works for you, my opinion is not that important; show me how it works."
David Wright
David:
To see a good example of a DFD go to the below and look at the "Level 0" diagram. (I found it at random in a quick search, but it is pretty good).
http://www.umsl.edu/~sauterv/analysis/dfd/dfd.htm
FYI: DFD are for manual systems or automated systems (data stores are data at rest - not necessarily computer storage).
Sorry, I meant a recent real project that used DFDs as the main artifact for requirements discovery and definition (I got trained on Structured Analysis back about 1982, so I saw a lot of DFDs)
You see, data used to move around, like from tape to tape, or even cards to tape (I am old...), but data today is everywhere, any time you need it, so I don't see the value of an artifact that does not seem to recognize this. So, you can still assume that I don't like using DFDs anymore, abandoning them in the late 80's for actual Functional Decomposition and parallel ER data modelling, ....but I am always willing to be persuaded of the value of a method if I can see examples of its successful use to deliver solutions(automated or not).
I have been through more methodologies than I can remember anymore, and the point was they were all good when I used them, until they weren't anymore. Use Cases and User Stories are what is working now, but will they still be used 10 years from now? I don't know, we shall see..
brought to you by enabling practitioners & organizations to achieve their goals using: