What to include in requirements documentations
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
Is a good back-propagation algorithm. Considering that maintenance is a valid stage of the waterfall model then it would make sense that feed back be included. Perhaps it would be easier to rationalize in a post mortem document that is referenced by the requirements with a deadline as opposed to in the requirements from the start which would mean the requirements are not finished until after it is done :p
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
Mark Nischalke wrote:
add user feedback
Ignore the whining and you won't have to do anything with the requirements :)
Why is common sense not common? Never argue with an idiot. They will drag you down to their level where they are an expert. Sometimes it takes a lot of work to be lazy Individuality is fine, as long as we do it together - F. Burns
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
All requirement documents should include a stipulation that the PM always takes the blame when things go wrong.
-
All requirement documents should include a stipulation that the PM always takes the blame when things go wrong.
Agreed :) Our PM claims to have worked for big companies and says all of them do it this way. Doesn't match my experience.
only two letters away from being an asset
-
Feedback should influence the requirements. Generally it doesn't become the requirements. What people actually want, and what they ask for, are sometimes quite different.
Excellent, that's what I've said also, however, they believe it becomes the requirements simply by added it to the document as an appendix. "Isn't that what a requirements document is for? Where else would we put the user feedback?" Actual quote.
only two letters away from being an asset
-
Excellent, that's what I've said also, however, they believe it becomes the requirements simply by added it to the document as an appendix. "Isn't that what a requirements document is for? Where else would we put the user feedback?" Actual quote.
only two letters away from being an asset
Clear up what "requirements document" means: A software requirements specification (SRS) is a complete description of the behavior of the system to be developed wikipedia[^] (emphasis by me) It is NOT a collection of every requirement uttered, but it defines what you will actually DO - and that incldues what you will NOT do. Requirement analysis means 1. Collecting all the wishes and ideas 2. Weed out the crap 3. Sign what you will do Otherwise, this generic requirements list could be used: Requirements: Has pr0n background image. [Joe User] Makes one point five gazillion money. Or maybe two point three. [board of directors] People will love it so much, they'll force their friends to buy it, too. [Director of Marketing] Can be used by an untrained monkey. [Helpdesk Sue] Takes no more than two weeks to implement in Excel. [Human Resosurces]
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
Excellent, that's what I've said also, however, they believe it becomes the requirements simply by added it to the document as an appendix. "Isn't that what a requirements document is for? Where else would we put the user feedback?" Actual quote.
only two letters away from being an asset
Hyperlink the requirement to user the feedback.
Todd Smith
-
Is a good back-propagation algorithm. Considering that maintenance is a valid stage of the waterfall model then it would make sense that feed back be included. Perhaps it would be easier to rationalize in a post mortem document that is referenced by the requirements with a deadline as opposed to in the requirements from the start which would mean the requirements are not finished until after it is done :p
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingwayyou forgot "facilitating leverages". :D
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
you forgot "facilitating leverages". :D
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistBe nice! He's a consultant and make his cash by the word :)
¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF! VCF Blog
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
Mark Nischalke wrote:
actual feedback doesn't belong there
No, it doesn't belong in the requirements, but should rather be a separate document showing whether or not the requirements are being met.
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
you forgot "facilitating leverages". :D
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistpeterchen wrote:
"facilitating leverages"
For a moment there, I read "facilitating beverages" (whether it be Dr. Pepper or :beer: ) :laugh:
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
I agree with you 100%. Requirement documents are NOT design documents. (Of course, where I work now, even requirements memos would be welcome.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
You're entirely correct; user feedback is reference material, not requirement documentation. A requirements document is a specification, and can be a contract document, even internally if several departments or individuals are involved in the development. Treat it with respect, and don't allow any deviation without a formal process involving all the players. User feedback is source material from which formal requirements are developed; keep the source in a file somewhere, but don't stuff it in the official documentation. As a rule, if it can't be measured quantitatively, or ticked off on a checklist during test or check-in, it's not a requirement, it's a comment.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
-
I agree with you 100%. Requirement documents are NOT design documents. (Of course, where I work now, even requirements memos would be welcome.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
I'd love a requirements doc. We do get the odd change request (user feedback?) but a requirements doc - not a chance.
Never underestimate the power of human stupidity RAH
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
Mark Nischalke wrote:
My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
i agree, it should be put into the next cycle of development requirements or something otherwise you are asking for a rolling spec which is the never ending carrot infront of the donkey...
-
Feedback should influence the requirements. Generally it doesn't become the requirements. What people actually want, and what they ask for, are sometimes quite different.
Graham Bradshaw wrote:
What people actually want, and what they ask for, are sometimes quite different.
Only sometimes? :~
Nobody can give you wiser advice than yourself. - Cicero .·´¯`·->Rajesh<-·´¯`·. Microsoft MVP - Visual C++[^]
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
-
No not a programming question, just an opinion and common practice question. We have recently been having a lively discussion at work with our tech writer and PM about what to include in the requirements documents. They want to add user feedback from alpha and beta testing to the document. My opinion is that the actual feedback doesn't belong there. It should be stored elsewhere and incorporated into the requirements.
only two letters away from being an asset
Yer just beggin' for unmanageable scope creep by making user feedback a part of the requirements doc. Version 1 should provide what was agreed on in the initial signed requirements document (unless there's a REALLY big breakdown of functionality), then features based on feedback can be added as a version 1.1 after the appropriate financial negotiations. Been there, done that, still got the burn marks.
-
All requirement documents should include a stipulation that the PM always takes the blame when things go wrong.
No, the contractor/consultant always takes the blame. If one can't live with that, then they should never consider being a contractor/consultant. I always start out every project by saying something like "Well, since as the gringo consultant, I'm going to take the blame for this at the end, let's talk about what you're going to blame me for."
The PetroNerd
Walt Fair, Jr. Comport Computing Specializing in Technical Engineering Software
-
Clear up what "requirements document" means: A software requirements specification (SRS) is a complete description of the behavior of the system to be developed wikipedia[^] (emphasis by me) It is NOT a collection of every requirement uttered, but it defines what you will actually DO - and that incldues what you will NOT do. Requirement analysis means 1. Collecting all the wishes and ideas 2. Weed out the crap 3. Sign what you will do Otherwise, this generic requirements list could be used: Requirements: Has pr0n background image. [Joe User] Makes one point five gazillion money. Or maybe two point three. [board of directors] People will love it so much, they'll force their friends to buy it, too. [Director of Marketing] Can be used by an untrained monkey. [Helpdesk Sue] Takes no more than two weeks to implement in Excel. [Human Resosurces]
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistTraditional Requirement Documents are great, but I have found greater success in the SCRUM methodology. You could spend weeks to even months getting wrapped around requirement documents before any development actually happens. Sure there are some that may be skeptical with SCRUM for various reasons. Some people may like to deal with evolving requirement documents, but I personally don't. :) Any developer knows that the customer can always change their mind in the next release, and typically that is what happens. http://en.wikipedia.org/wiki/Scrum_(development)[^]