Hello all!
The information provided is extremely beneficial and enlightening.
Another question please. With regard to the scope document, there are 2 schools of thought here. The first is that the scope document provides a HIGH LEVEL overview of what is going to be achieved. And that the detailed requirements are gathered, reviewed, and documented after the scope is established; thus providing a road map of sorts of what's in and what's out of scope. The second school of thought is that the requirements should be written first and then included in the scope document.
To me this is the proverbial "chicken of the egg" question.
Any thoughts on this? This may help me "explain" to others the solutions you all provided to me about the requirements.
Thanks!
I'm sorry. I may have been confusing in my last message.
The first school of thought is that the scope is done first, which provides a roadmap to gathering the requirements.
Sorry about that. :-)
Hi:
Great questions! In the ideal, you would first create a context diagram. A context diagram is a special type of data flow diagram in which the system is displayed as a single function/process - and also displayed is all the inputs to and outputs to/from the system. As it displays the whole system as a single function/process, it is the highest level view of the system possible. A context diagram is also an excellent scope statement, as it rigorously displays the extent of the system.
Notice that I bolded the words in the ideal. One of the things you would be very wise to learn is that in the BA world, what is ideal is often not pratical. In this case, especially for larger scale efforts, it is not possible to proceed in a pure top down manner as nobody - not even senior management - is knowledgeable enough to do such. This is one of those dirty little truths that no one wants to discuss in books.
So do the next best thing: proceed in as top-down a fashion as possible. What I do is first create and verify some lower level data flow diagrams and then summarize them upwards into the top-level context diagram. Key point: Create lower level diagrams - but also create diagrams that may be very far from the lowest level diagrams - otherwise you very well risk drowning in an ocean of detail and never being able to identify scope.
Tony
Scope the project first. The context diagram will then allow you to see the scope of the work to be done, and you can document requirements within scope.
If you try documenting the requirements first you're likely to end up with a much bigger scope. With the scope defined you may still see scope creep, but this will have a better chance of being managed.
brought to you by enabling practitioners & organizations to achieve their goals using: