[SystemSafety] Software Requirements and Specifications

[paul_e.bennett at topmail.co.uk]

On 15/04/2017 at 7:06 AM, "Peter Bernard Ladkin" <ladkin at causalis.com> wrote:
>
>On a holiday, one is typically supposed to do fun things, or to 
>worship, if it is a religious
>holiday. I did both by reading Michael Jackson's 1995 book 
>Software Requirements and Specifications
>cover to cover. It's written in the form of a lexicon.

[%X]

>I was struck by a short statement on p188 in the entry on 
>Software. "Organising, structuring and
>making descriptions is the central activity of software 
>development. So software development is....
>the engineering of complex structures of descriptions." Michael 
>points out in various entries that a
>computer program is a description of a machine that will 
>accomplish a given task or solve a problem.

I would hope that even the most complex statements of requirements 
of need can be unravelled into simpler statements of specification. So,
as these descriptions are organised, you end up with simpler and 
clearer requirements specifications of the required components
(Something George Polya espoused).

>I think it resonated, not only because of its clear statement of a 
>core truth about SW development,
>but because I have been discussing with other engineers recently 
>about SW and have been impressed by
>the size and persistence of the gap in understanding of what is 
>needed to engineer reliable SW.

As the mechanics can do for humble nuts and bolts destined for
the highly dependable constructions, I expect component specifications
to clearly state the limitations beyond which all bets are off. We also do
that in electrical an electronics engineering. Look at any datasheet for a
physical component and you will see tolerances and limits beyond which
failure is more likely. Why should software be different?

The answer of course, is it shouldn't. When I write specification for my low
level software components I am able to state the limits beyond which it will
not operate as specified (in terms of machine word width, number radix, 
repetition rates, sign of input values etc.). I have a variety of software
components in my personal library that I used back in the early eighties
that would still compile and run today on the latest hardware with the latest
compiler and I would be able to depend on the result (I would still make the
appropriate sanity checks though).

Engineers create not only the artefacts but the tools to make it easier to
construct those artefacts. If we make, or select, poor tools the results will
be poor.

[%X]

>I share Michael's view that reliable SW development is largely 
>about the careful engineering of
>descriptions. It is obviously true that some knowledge of the 
>application domain is essential for
>reliable-SW engineering.

[%X]

Like for any tall building, attention to details in setting the foundations will
have a profound impact on whether it stands or not. The Parnas view of
anyone wishing to be considered an engineer doing a properly structured
engineering course builds on that notion. In Software, the basis from which
you build the systems is going to be in knowing how your compiler is going
to translate your hieroglyphics into something the machine will understand.

Software Engineers should probably also start by asking to see cast iron 
certification for the translations their compilers will perform. However, with
the number of directive switches in many compilers, I think that would be a
rather tall order for most.

Regards

Paul E. Bennett IEng MIET
Systems Engineer

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1392-426688
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************