Readers may know that for quite some time I have been working on topics in requirements engineering, in particular for safety requirements. They may recall previous posts here at https://abnormaldistribution.org/index.php/2010/11/09/formal-definition-of-the-notion-of-safety-requirement/ and https://abnormaldistribution.org/index.php/2010/11/09/the-parable-of-the-exploding-apples/ as well as the terminology engineering in OPRA at https://rvs-bi.de/publications/books/RVS-Bk-17-02/Ch03-OPRA.pdf and the derivation of demonstrably-relatively-complete safety requirements in Bernd Sieker’s doctoral thesis (in German) https://rvs-bi.de/publications/Theses/Dissertation_Bernd_Sieker.pdf

Unfortunately, requirements analysis and engineering of the sort exhibited in Michael Jackson’s Problem Frames (ACM Press/Pearson Education 2001) is still relatively rare. A  couple of years ago, we were advising a large engineering company on transition to a IEC 61508-compatible software development process, and the topic of requirements engineering of course came up. IEC 61508-3 subclause 7.2.2 is where it is. There is mention of the key objective properties of requirements (in this case, restricted to safety requirements) by way of an introductory Note to the subclause, Note 2, which says that

the following properties ……… of the software safety requirements specification should be considered:

• completeness with respect to the safety needs to be addressed by software;
• correctness with respect to the safety needs to be addressed by software;
• freedom from intrinsic specification faults, including freedom from ambiguity;
• understandability of safety requirements;
• freedom from adverse interference of non-safety functions with the safety needs to be addressed by software;
•  capability of providing a basis for verification and validation.

Well, that’s not bad. Except that “should” means “recommended”. You don’t have to check completeness and correctness (including presumably consistency). It is just recommended that you do so. (“You have to…” is indicated in IEC standards by “shall”.)

I asked the clients what they did about checking requirements. “We have that sorted.” How? “We use DOORS.”

Exercise for the reader: how many of the recommended states above can be assured by DOORS? Hint: if you answer “none of them”, you won’t be far wrong.

But what prompted me to write this now? A couple of days ago, I had another frustrating experience with defining passwords. I submitted a paper to a journal which uses the submission and management software ScholarOne. You have to register. Now, I thought I had a ScholarOne account because one was set up for me when I was reviewing papers for the IEEE. But ScholarOne apparently didn’t know me from that. So I set up a new “account”. (Exactly why you need an account on a third-party WWW site to submit a paper to a journal is not immediately clear, but I think there are two reasons. One is the usual: this WWW site wants to collect data from people who submit papers to research journals and sell that accumulated knowledge. The second is that if an editor had to go through this laborious procedure for every submitted paper, no editor would ever use the site. Whereas this way the irritation is distributed amongst authors.) When you set up an account, ScholarOne wants you to define a password. It should contain more than 8 characters and 2 or more digits, says the instruction. And it wants you to type it in twice, so that it can check you have typed in the same thing twice and presumably mean it, rather than have inadvertent characters slipping in.

So I typed in a password in my usual style, and typed it in again. Result “your two passwords do not match”. Duh. Try again. Same thing. Check I didn’t inadvertently hit “caps lock” in the middle, and type in again, slowly and deliberately, with a couple of seconds pause. Same thing. Refresh, back out of the page, start again. Type in carefully, twice. Same thing.

Wait a minute. Wake up. You’ve been here before, PBL. Some sites don’t like punctuation symbols, which people like me have been using in passwords — well, since the 1970’s, when it used to be a sign that you were a “real” computer person. Go alphanumeric. Now, ScholarOne likes my password.

Some designer designed that interface; somebody wrote that code which checked typed-in password attempts and only accepted alphanumerics. Somebody forgot to say so in the instructions. And somebody wrote the code which said “your two passwords do not match” in response to two matching attempts which include non-alphanumeric characters. Very basic requirements engineering was not followed.

What would we thereby be inclined to think about the rest of this extensive SW product?

Postscript 2018-11-15.

A colleague read this note and mailed me an example which ties the two themes of requirements consistency checking and password requirements specification together:

I went to register on a site recently and it said, with regard to choice of password:

• Must be at least 10 characters long.
• Must contain at least one upper-case and lower-case letter or be 20 characters long.
• Must contain at least one number or be 20 characters long.
• Must contain at least one punctuation mark/symbol or be 20 characters long.
• Must not contain sequential characters or be 20 characters long. e.g. 123 or abc.
• Must not contain site info such as site name…
• Must not contain user info such as your name.
• Password must match confirm password field.

It says that the password must not be 20 characters long, having previously given that as an alternative to meeting other conditions…