Methodology for writing requirements specification for embedded software

Lanarcam wrote:

> 
> 
> 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.

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.

>> > 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)

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.
 
> Functional requirements can be relatively easily tested, given
> the proper simulators and test cases.

Yes.
 
> Reliability requirements can generally not be tested but
> are demonstrated.

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).
 
> Safety requirements must be proven.

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.
 
> Functional requirements come to mind first but are far
> from being the whole story.

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

-- 
********************************************************************
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/
********************************************************************