Methodology for writing requirements specification for embedded software

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Methodology for writing requirements specification for embedded software
Quoted text here. Click to load it

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


Re: Methodology for writing requirements specification for embedded software

Quoted text here. Click to load it

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.

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Methodology for writing requirements specification for embedded software
Quoted text here. Click to load it

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.

Re: Methodology for writing requirements specification for embedded software

<snip>

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

--
Prafulla Harpanhalli


Re: Methodology for writing requirements specification for embedded software
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.

Re: Methodology for writing requirements specification for embedded software


Quoted text here. Click to load it

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.


Re: Methodology for writing requirements specification for embedded software

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.
 
Quoted text here. Click to load it

Yes.
 
Quoted text here. Click to load it

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).
 
Quoted text here. Click to load it

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.
 
Quoted text here. Click to load it

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

--
********************************************************************
We've slightly trimmed the long signature. Click to see the full one.
Re: Methodology for writing requirements specification for embedded software

Quoted text here. Click to load it

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.

Re: Methodology for writing requirements specification for embedded software
Quoted text here. Click to load it

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



Re: Methodology for writing requirements specification for embedded software
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


Site Timeline