Hi,
I have been tasked to facilitate a whiteboarding session to gather requirements. We have a web application & we need to develop a maintenance function for the user. I am new to business analysis & wanted to find out what sort of documents should be produced from the session. Also if there are examples I can build upon. Any and all help is greatly appreciated.
Hi:
Use the white board to quickly create just barely good enough models. System behavior analysis drives system data analysis, so the first order of business is to create and walk through behavioral models.
If your system is simple, then you can jump right into sequence based behavioral modeling techniques (BPM and Activity Diagrams). If your system is complex, then you need to model at various levels of abstraction using decomposition to handle the complexity. This is where data flow diagrams come into play. With DFD's after you decompose a system far enough down, then you switch over to sequence based modeling to handle modeling the "system in the small".
After you have scoped out the essential behavior of the system, then use the white board to create just barely good enough data models, like ERDs.
Your deliverables should be defined by the needs of the people who will consume them. Identify those people and ask them what documents they need. Typically, the consumers are developers, testers, release managers, operations, security, product owners, change managers, etc. etc. etc. Having said that, there's several ways that could go depending on the development methodology in place (or lack thereof).
Is this a contractual arrangement with an external client? If so, check the contract and/or the statement of work. Your deliverables hopefully are stated there. Keep in mind, however, that what you are contractually obligated to deliver may not actually be what the consumers of the deliverables need. Which brings me back to... identify those people and ask them what they need.
If your team is doing waterfall development, you're likely to be document heavy, and you probably need requirements specs and such. If your team is agile, you're likely to be document light and may only need user stories and such.
didelancey said: "If your team is doing waterfall development, you're likely to be document heavy, and you probably need requirements specs and such. If your team is agile, you're likely to be document light and may only need user stories and such."
Unfortunately, this confuses bad waterfall with waterfall. Good waterfall has always been "just barely good enough" documentation. I know that bad waterfall is much more common, but, just like good Agile is not "hackers gone wild" , good waterfall is not "heavy documentation"
Tony
You will note my use of the word likely. Unfortunately, bad waterfall is more likely than good. But that is entirely beside the point of the original poster's question.
brought to you by enabling practitioners & organizations to achieve their goals using: