>
>
> 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/
********************************************************************
Reply by Lanarcam●June 15, 20052005-06-15
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.
Reply by Clifford Heath●June 15, 20052005-06-15
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.
Reply by Prafulla Harpanhalli●June 13, 20052005-06-13
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
Reply by Ted●June 13, 20052005-06-13
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
Reply by flowrate●June 13, 20052005-06-13
> 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.
Reply by Clifford Heath●June 12, 20052005-06-12
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.
Reply by ●June 12, 20052005-06-12
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.
Reply by Paul E. Bennett●June 12, 20052005-06-12
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/
********************************************************************
Reply by ●June 12, 20052005-06-12
> 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.