Methodology for writing requirements specification for embedded software

God, I wish our marketing people would take as much care about this task as you are doing.

In simple terms, the requirements specification should start out by identifying the goals for the system. These goals should be expressed in terms of the required functions and the constraints that will be imposed by external factors such as available size for the enclosure, how the system might be mounted, the sort of environment it will operate in etc. Noting that your aim is for software requirements only, one of the constraints will be the processor, on which the software is to run, and how much memeory and other resources will be available.

Clear, concise writing is most important in this respect. Separate numbered paragraphs for each system aspect is most helpful when the engineers come to convert your requirements specification into a technical specification for the hardware and software.

Include diagrams where they help the text. Remember that a picture can often be worth more than a thousand words.

The requirements document should have a reasonable structure that enables the engineers gain a clear view of what the customer wants out of the system. It should have an introduction (featureing scope, reference documents and glossary of terms) followed by the detailed description of, fist, the functional aspects, then, the physical aspects.

Do not forget to mention any standards or legislative requirements that the product must meet. It is not fair to leave such research up to the engineer to find out for himself.

I have found "Practical Software Requirements: A Manual of Content and Style" by Benjamin L. Kovitz

d.k.

Very true. Think like the acceptance tester - they want a clear set of simple cases they can test, which show that the product performs as expected. If a statement doesn't yield a testable scenario, it's part of the preamble, not part of the requirements.

Clifford Heath.

RTCA DO-178B has some good guidance on requirements, even if your project doesn't mandate the 178 process.

We use a template based on the Volere one. (May be a bit heavyweight if your target is an 8051 with 4K of code)

The Kovitz book someone else recommended is good too.

Software Requirements and Specifications ( ISBN: 0201877120) has some good ideas, but doesn't actually tell you how to do it.

Cheers TW

I don't think so. In a few SRSs i have come across, requirements were identified as Functional requirements and "Non-Functional" requirements. The latter were mostly of the type where one could'nt frame a testcase to test that requirement precisely. I can't recollect any example/scenario, but that was also an effective way of product architecting.

Maybe, requirements laid out in preamble are similar to the Non-Functional requirements i am talking about.

-- Prafulla Harpanhalli

I don't believe you have a fair complaint - I'm not talking solely about functional requirements. I've come across RS's where every second "requirement" was not testable, *even in theory*. Ultimately, if you can't tell whether a requirement has been met, it wasn't a requirement.

An NFR is a requirement such as an aesthetic one, or usability. You can still test those by finding out whether people like the product, and how many times they're baffled about what to do next. Most consumer goods are "tested" this way. You can *frame* the requirement this way, generally by identifying the minimum response to such a test.

Clifford.

Non functional requirements are very important for embedded devices, they include:

- product requirements: efficiency requirements reliability requirements portability requirements

- organisational requirements: delivery requirements implementation requirements standard requirements

- external requirements: interoperability requirements legislative requirements (safety)

Functional requirements can be relatively easily tested, given the proper simulators and test cases.

Reliability requirements can generally not be tested but are demonstrated.

Safety requirements must be proven.

Functional requirements come to mind first but are far from being the whole story.

Requirements specifications can, and should, be written such that each statement of requirement is, in some form, testable. The test may be by inspection or by technical operation. It does require that the specification adopts a style of writing that yields a high degree of testable statements (which does require a significant amount of thought).

However, I wouldn't berate a customer that provided a wooly requirements specification. I would, instead, begin to write my technical specifications and gain the customers confirmation on the points that were not adequately expressed in his document. The technical spec should be much more testable than the requirements.

You forgot physical requirements (as part of the NFR set). - mechanical mounting - enclosure size - enclosure weight - vibration and shock withstand - Temperature withstand (powered and un-powered) - Temperature generation limits - Connector placement and alignment - Moisture and Dust Ingress withstand - personnel access arrangements.

All these are testable attributes.

Yes.

Demonstration is usually by performing FMECA or Reliability Analysis calculations from data about the components. If the specification was written such that 99.xxx% reliability was demonstrable then the fact of the statement becomes testable (you see what I mean about the style of writing).

Absolutely. This should, however, be by some form of demonstration, that the requirements are met, to the client so that he is confident of the result.

True. It can be surprising how many clients can be upset if the box ends up being the wrong color. ;>