SCJP, SCJD, SCWCD, SCBCD
Originally posted by Darya Akbari:
I think not only in Germany but everywhere that the term Requirements Specification is overloaded. Hence there is time to time a struggle what is meant by it really. [...] For example, what do you think means System Requirements Specifiation and Software Requirements Specification and who is responsible for producing these specs?
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
I could try and generalize what people seem to use this term for as being "the product definition", i.e. a description of what I, the one paying you to build the product, consider important properties, attributes, and constraints the product should have or conform to.
SCJP, SCJD, SCWCD, SCBCD
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Darya Akbari:
how would you translate the german terms Lastenheft and Pflichtenheft?
Originally posted by Darya Akbari:
In the next phase we take this WHAT document and provide our HOW document, the Software Requirements Specification
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Darya Akbari:
Let me try it this way. The Requirements Analysis Phase is something which is done on the customer side before there is any chance that one of us can get on board.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Peer Reynders:
DIN 69905/PMBOK
Lastenheft - Statement of Work (as issued by the Customer)
Plichtenheft - Proposal (as issued by the Vendor)
Originally posted by Peer Reynders:
I would go with the "IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE)".
...
So as far as I am concerned the SRS is the WHAT document and the functional and non-functional specifications are the HOW documents.
Originally posted by Ulf Dittmer:
to some projects these terms apply, to some they don't, but the important thing is not the documents, it's the outcome for the stakeholders (to tie this to another thread of yours ), especially the customer. Sometimes the customer won't even produce a requirements document, sometimes the customer will even do the technical specification. Well, the customer's paying, so what's to stop him?
Originally posted by Stan James:
Everybody's WHAT is somebody else's HOW.
...
So what's an SRS to you may be somethign totally different to me. Bummer.
...
Then a requirement is replaced by a new one. Heh, wasn't really REQUIRED was it?
...
Long and mayabe useless answer, but this is such a fuzzy business. All the teams I know struggle with it, and the company's direction is to add more layers of people and docs and handoffs, which seems ... can't think of a nicer word right now ... wrong.
Originally posted by Ilja Preuss:
... As a consquence, analysis needs to be an ongoing activity throughout the whole project - declaring it "done" before you start coding will ignore so much valuable feedback from actually implementing and using the system that it significantly reduces the project's chance of success.
SCJP, SCJD, SCWCD, SCBCD
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Darya Akbari:
I only want to make a clear distinction between the WHAT document and the HOW document and their commonly used names.
Another question in this respect . How valuable do you think are such standardization bodies like PMI, IEEE, DIN etc.?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Darya Akbari:
So this can be one origin why we have those naming conflicts. Despite of that, I don't think SRS is what you mean . The central word here is Software. To me Software is the HOW and System is the WHAT.
But what if the customer know those standard processes (IEEE, DIN, etc.). What will you do then?
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Darya Akbari:
What do you think of IEEE's SWEBOK effort. Is it rubbish?
Originally posted by Peer Reynders:
I think you are getting a bit bogged down by trying to differentiate terms that are sometimes used interchangeably (I've often found that English word/term use is much less precise than what you might be used to in German). If I had to choose a (document heavy) definition for the requirements I would go with the "IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE)".
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Ilja Preuss:
But why would you want to do that?
There are a quantrillion of things that need to be communicated in a software development project. I don't think that categorizing them in "what" and "how" helps in actually communicating them. (Setting aside that I don't think *documents* are the perfect way to communicate them.)
SCJP, SCJD, SCWCD, SCBCD
Originally posted by Darya Akbari:
Why I want separate between a WHAT document and a HOW document ? Don't you normally start a project after you signed a contract?
One maybe the most important input to the contract between you and your customer is your HOW document. At least a condensed form of your HOW document should be included. Otherwise what are you talking about in such contract?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Darya Akbari:
To my opinion standardization bodies like IEEE, DIN, PMI, etc. are not to be underestimated.
...
So it was easy for you to lay back and relax, being sure that everything else important is written down there. I see it the same way
Why is IEEE 830-1998 Recommended Practice for Software Requirements Specifications (ANSI/IEEE) OK for you and IEEE's SWEBOK again NOT OK?
Originally posted by Peer Reynders:
That's the problem with these large standardization bodies - they are too slow to keep up with one of the fastest developing fields of commercial endeavor (faster than any traditional engineering profession)
SCJP, SCJD, SCWCD, SCBCD
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |