Re: [scrumdevelopment] Re:Requirements documents and Scrum
- We use documentation as a way to convey intent across distance and time.
So during the development, we generally use stories and test cases. But
when we are done, our product may live 20 years. So 10 years from now
when a new feature is added to this area, how do you figure out what is
Dig out the index cards? Not likely. Review the unit tests? Reading
code is too hard.
How about the customer acceptance tests? (turns out they are very
It happens that a 3 or 4 page "specification" of "tagged requirements"
organized by "function/feature" is an easy way to understand the
incremental or changed content of part of the program.
It's not "overly detailed" nor is it "general to the point of
uselessness". I'm sure the level of detail would vary based on
organization and circumstance. But it works for us.
In general we want an observer looking backwards on our development to
not be able to tell whether or not we developed the code first, or the
requirements. (mostly it is the requirements, but often it is not).
> Roy Morien wrote:
>> OK, so documentation and the need for it or not is again a vexing
>> So tell me, please, exactly what is supposed to be in a 'requirements
>> document'? At one end of the scale it might be a simple statement
>> such as 'we need a payroll system including an HR department
>> website'. Or it might be inches thick and gives details down to which
>> font to use and what the colour scheme is.
>> I have often written down my thinking in a document, just to clarify
>> things. And often these thoughts have been included in a system
>> manual later on. But the fact is, creating a fully detailed,
>> comprehensive, all inclusive document is at least a 50% waste of time.
>> So ... what goes in the perfect requirements document?
>> Also, I think the statement of standards in an organisation should
>> state many of the details that are often put into a requirements
>> document. Do you have a statement of standards?
>> Too often the creation of a large document is just a proxy for making
>> progress. It is a substantial piece of work, and can always be
>> flaunted as proof that we are really doing something ... Look how big
>> it is!!!
>> Any document must be carefully scrutinised for its true purpose, its
>> correct content, for its intended audience, for its subsequent
>> maintainability, for its success at communication correct and useful
>> information to its intended audience etc.