[SystemSafety] Software Requirements and Specifications

[Peter Bernard Ladkin]

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.

I had expected to be regaled by insights and it happened. (It's also a little embarrassing to be
reading for the first time things that Michael must have known for decades. I should have done this
twenty years ago when the book came out.) But I hadn't realised quite how much fun it would be, and
how easy and compelling to read, even though these are qualities for which Michael's work is renowned.

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

Dave Parnas has taken the view that, if SW engineers wish to be engineers, then they should train as
engineers, with the first two years in college being the usual preparatory engineering courses;
mechanics, electrics/onics, continuous math and so forth. I've thought about curricula a lot over
the decades, and I have not yet found how Parnas's view could be reconciled with the time/effort
requirements for the "lower division" of typical Bachelor's degrees and study of core computer
science and engineering (discrete math, logic, computational description techniques, scope and
limitations of digital computing, computer architecture, programming languages, programming skill).
The ACM's most recent view (AFAIK) is https://www.acm.org/education/se2014.pdf

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. It may be true that a SW engineer specialising in embedded and
cyberphysical systems needs an understanding of traditional engineering. But a future engineer of
financial software systems would surely benefit less from a course in Newtonian mechanics than from,
say, fundamental courses in economics, and would be no less an engineer for that.

The very best story in the book concerns Barry Boehm and an aerospace engineer, in the entry on
Software. However tempting, I'm not going to spoil things by repeating it. I encourage everyone to
buy the book and read it for yourselves (and the rest, too)!

Happy Easter everyone. We got a new bunny, but no eggs so far. Somebody said you need chickens for
those.

PBL

Prof. i.R. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20170415/7303e241/attachment.pgp>