Methodology for writing requirements specification for embedded software

Hello,

I have to write requirements specification for an embedded software (to 
be developed by someone else) and I would need advice about how to 
proceed. Is there utilities which could be helpful to carry out this 
work such as software, guidelines, books...

Thanks in advance.
-- 
Eric Meurville

> I have to write requirements specification for an embedded software (to
> be developed by someone else) and I would need advice about how to

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

Eric Meurville wrote:

> Hello,
> 
> I have to write requirements specification for an embedded software (to
> be developed by someone else) and I would need advice about how to
> proceed. Is there utilities which could be helpful to carry out this
> work such as software, guidelines, books...

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.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ....EBA. http://www.electric-boat-association.org.uk/
********************************************************************

Eric Meurville <eric.meurville@epfl.ch> writes:

> I have to write requirements specification for an embedded software
> (to be developed by someone else) and I would need advice about how to
> proceed. Is there utilities which could be helpful to carry out this
> work such as software, guidelines, books...

I have found "Practical Software Requirements: A Manual of Content and
Style" by Benjamin L. Kovitz (http://www.manning.com/kovitz) useful.

d.k.

-- 
Daniel Kelley - San Jose, CA
For email, replace the first dot in the domain with an at.

Paul E. Bennett wrote:
> ...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.

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.

> I have to write requirements specification for an embedded software (to
> be developed by someone else) and I would need advice about how to
> proceed. Is there utilities which could be helpful to carry out this
> work such as software, guidelines, books...
>
> Thanks in advance.

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)

http://www.volere.co.uk/template.htm

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

Clifford Heath wrote:
<snip>

> If a statement doesn't yield a testable scenario, it's part
> of the preamble, not part of the requirements.

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.

>
> Clifford Heath.

--
Prafulla Harpanhalli

Prafulla Harpanhalli wrote:
>>If a statement doesn't yield a testable scenario, it's part
>>of the preamble, not part of the requirements.
> I don't think so.

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.

> identified as Functional requirements and "Non-Functional"
> requirements.

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.

Clifford Heath wrote:
> Prafulla Harpanhalli wrote:
> >>If a statement doesn't yield a testable scenario, it's part
> >>of the preamble, not part of the requirements.
> > I don't think so.
>
> 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.
>
> > identified as Functional requirements and "Non-Functional"
> > requirements.
>
> 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.

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.