This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
We had a discussion on what should be there and what should not be. My colleague said we should include Java interfaces with all the methods in SRS. But I believe we should have only the system contract in laymans terms in SRS and leave the details to the design document.
I'm not really sure what you mean under Software Requirement Specification.
I think requirements must be independent from source code. I think it's the task of the customers (with help of the IT-Consultants) to write the requirements. But even if the IT-Spe******ts write the requirements, they have to write them in a language that customers can understand.
You can use the open source product FIT or Fitnesse (www.fitnesse.org) to write requirements and translate the requirements into java code.
If you mean with SRS a document that explains how to use or extend a framework it makes sense to use Java interfaces.
An SRS (IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications) is a Requirements Document. The problem is that some people seem to be under the impression that there is only "one" specification - categorizing something as the "specifications document" is pretty useless. In many waterfall based processes the Requirements Document (which can be an SRS) is used to drive the definition of the Functional Specifications which address the functional requirements and the definition of the Non-Functional Specifications to support the non-functional requirements. Additional detailed information is often captured in "Technical Specifications" to support the Functional and Non-Functional Specifications - it is usually at this level that you may find something like a Java interface. [ November 28, 2006: Message edited by: Peer Reynders ]
But your organization is really free to define any document any way you like it. You'll need to get a good concensus from all players or you can spend forever debating what goes in some document and what doesn't. We had this experience with a consultant who just couldn't come around to our team's definitions. We had to ask the consulting company to take him away before somebody strangled him.
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