From: Andrew Gabb (agabb@tpgi.com.au)
Date: Thu Jul 29 2004 - 23:52:41 EST
Synchronicity is a wonderful thing. We have active threads on quite
different subjects, but there are some serious commonalities here
related to user requirements and requirements derived from the user
requirements. I've done quite a bit of chopping and chanelling below.
Monterey, Laura CTR wrote:
> Once again, from the other side of the world, he has accurately
> read the tea leaves about this organization where I work. It's
> amazing. Do his powers extend to reading the writing on the wall,
> too?
Thanks Laura, but in truth my specialty is stating the obvious. Developers the world over assume they know the requirements. This can lead to better systems faster and cheaper (if they really *do* know the requirements) or as we all know, incorrect assumptions can lead to terminal project disease. The writing on the wall suggests that this situation will continue in many shops, driven as it is by human nature. For us REs it can be very frustrating.
[BTW, if your users are in another country, another culture, you have yet another risk - and this is not just limited to language. I've seen US, UK, French and German systems proposed for Australians which would have been totally inappropriate. They normally lost the bid, I'm pleased to say! And not necessarily to Australian suppliers. It's good to see there are some folks out there doing their jobs.]
Where the developers should excel is in deriving requirements from a coherent, complete, etc., set of user requirements. But - see below.
Donald Firesmith wrote:
>> Can anyone think of ways to quantitatively specify security requirements >> that capture "how much" security (e.g., identification, authentication, >> authorization, confidentiality, integrity, availability, non-repudiation, >> etc.) is needed and required?
I don't see anything particularly special about security requirements, Donald. I've run into the same problems with safety, usability, availability, portability, etc. These are 'quality factors', as opposed to directly 'operational' requirements, although the separation is sometimes unclear. As I've said previously, I also have trouble with the qualitative vs. quantitative separation. I see them forming a continuum of requirements. That doesn't matter - I understand your needs.
As Keith points out, the user requirements for security (as for other requirements) should come from working through appropriate scenarios. One common difficulty with quality factors is finding meaningful quantitative requirements in the user domain, particularly those which are adequate for handing on to designers.
Generally the requirements that users provide are vague and possibly infeasible. Smart developers will not sign up to many of these requirements, often because they are close to impossible to meet (eg, 'prevent all attempts at intrusion'). Slimier developers will sign up, knowing that their lawyers can handle the problems later. Frustrating this problem is the reticence on the users' part to back off from a 'total' requirement, thinking that they might lose something in the wash.
In my own experience I've tried to resolve these problems, but with only partial success. The main obstacle was not the difficulty of the subject, but the pedantry medallists of the local specification police.
HERESY WARNING!!!!
Dogmatics stop reading now and move on to more comfortable fare!!!!
I'm now convinced that it is *impossible* to adequately define security requirements (and some other quality factors) as user requirements, such that they can be used as the contractual basis for the system. Robert might feel that he has provided suggestions (Hi Robert) but it's much more likely that he knows that his suggestions are 'derived requirements'. After all, users rarely have any knowledge of or interest in "covert channel bandwidth" (some do) or understand the significance or value of the "mean times". However, these may be useful derived requirements. Read on.
[Corollary: It is *sometimes* possible to adequately specify operational requirements fully using only user level requirements, but I'd be nervous in suggesting a non-trivial example.]
More worrying, the user requirements are normally so wobbly that including them in a contract might put the customer at risk, even when they are covered by appropriate derived requirements. Blame the slimes and their briefs for this one - it's a real risk, even where the precedence is carefully defined. Also worrying is that even when we appear to get agreement on detailed requirements, those requirements are inherently untestable (or unforgivably expensive in time or $$ to test).
So what I'm saying is that the contractual requirements should normally be 'technical' derived requirements (noting that most quality factors are associated with one or more specialty engineering fields). Under these circumstances, getting qualitative requirements is obviously much easier.
So do we get the developers to suggest the derived requirements, as Keith suggests? Yes, or we use a technical specialist working for the customer. I generally prefer the latter if the issues are serious, because many developers will minimise their contractual requirements. It is common to use a third party for safety assurance, for example. In fact, the treatment of safety in requirements and development is a good start in looking at security.
But the real question is: "What user requirements do these specialists derive their requirements from, and how do they then validate those derived requirements?".
This is where I came in. We MUST have a clear statement of the users' needs, expectations and concerns regarding security, so that we can maintain the contractual derived requirements. I feel that this would normally be a combination of 'requirements', scenarios and expressed concerns (including known and possible threats).
In addition, the specialists must clearly demonstrate to the user community that the derived requirements cover the users' needs, expectations and concerns. This is the hardest part.
Oh, and before I forget, at the start we must all know and agree on what 'security' means. Privacy? Integrity? Levels? Criticality?
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Mon Aug 02 2004 - 09:00:21 EST