Writing a Software Requirement Specification

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.

The purpose of specification refinement is twofold:

• Translate higher level requirements to something usable by developers: e.g., from I want a "Google Maps" with space imagery to The spacecraft shall follow a polar orbit to a bunch of equipements --sensors and actuators-- and a software implemented control loop involving quaternions and some real time OS.

• Provide a way to check that every customer need has been implemented, through traceability.

Therefore, you only have to make clear whether Req 3.1 is entirely implemented by Req 4.1, so that the developer either focuses on Req 4.1 (and I would put Req 3.1 in SSS) or has to implement both Req 3.1 and Req 4.1 (and I would put Req 3.1 in SRS).