Typically we follow an Agile development process that tends not to put an emphasis on writing requirements and technical documents that nobody will read. We tend to focus our limited manpower to development and testing activities with collaborative design and whiteboarding as a key focus.
There is a mostly standalone web component that will take quite a few weeks to develop, but this work can be mostly parallel with other project work going on. To try and catch up time I was given a budget for hiring a developer on oDesk to complete this work.
While my team isn't accustomed to working off of a firm SRS document, I realize that with outsourced development that it is a good idea to be as firm and specific as possible so I realize that I need to provide a detailed Requirements and Technical Specification document for this work to be done correctly.
When I do write a Requirements document I typically utilize the standard IEEE SRS document template but I think this is too verbose and probably overkill for what I need to communicate to a developer. Is there another requirements document that is more lightweight and also accepted by a major standards organization like the IEEE?
Further, as what will be developed as a software module that will interact with other software modules, my requirements really need to delve into technical specifications for things to work correctly. In this scenario does it make sense to merge technical and requirements specifications into a single document, and if not, what is a viable alternative?
Best Answer
The best option is probably to take an existing template or two (for purchase - also found in the appendices of Software Requirements) or three and tailor them. Remove sections that are irrelevant to your needs or add new sections that you like from one template into the rest of another template. Merge sections together if that makes sense. When combined, these would probably cover every possible type of question that might be asked, it's just a matter of filling in the details where they are needed.
Tailoring would make it not match templates by major standards organizations, but tailoring is a key component of process improvement and deployment programs. I don't think that anyone would have a problem with a tailored template, in most cases. To me, the explicit removal of sections makes for a nicer and more reader-friendly document than text that says "does not apply".
As far as providing specifications, I'd be hesitant on what is provided. If you will be providing inputs in a specified format, provide that format. If another system will be consuming outputs, provide the expected output format. These could be railroad diagrams, XML schemas, byte layout maps, and any sample inputs/outputs (sanitized, if necessary). If you're specifying something that needs to be a drop-in replacement for another system, specifying the public interface may be necessary as well. However, I'd recommend leaving as much leeway to the developer as possible to design and build a system around your requirements.
In my experiences, there's often a separation of the requirements of the system and a detailed description of the interfaces between components. I don't think this is always necessary, though. Conformance to a specified interface is, technically, a communication or environment requirement ("the system shall provide output in XML that conforms to the schema defined in schema file"). Separating the two is probably more appropriate when describing a system of related components rather than a single component, where I'd argue that having a single, comprehensive resource for what I'm expected to produce is better.
I'd recommend approaching this as defining only what you need from this system, leaving as much as possible up to the developer. If you spend too much time doing the specification such that there's only one or two solutions, then you've done most of the time intensive work (in my experience). As a developer yourself, you probably know what questions you might ask if you were presented with the general scope of the system you want - answer those as clearly and specifically as possible and hope the developer will ask any other questions you might not have thought of.