Re: [re-online] Universe, Machine, Interface: was: constituents of a reqt

From: Paul TIPLADY (Paul.TIPLADY@TRW.COM)
Date: Fri Mar 11 2005 - 22:30:12 EST


Don,

First up, I'll repeat the disclaimer -- this isn't my model, just one I've found useful so far.

I'm not convinced you've put forward real exceptions. You just have to draw the lines in the right places and use the words in the right way (sounds a bit too close to magic, phrased that way!), and everything drops into one of the three categories. And here's why I'm not convinced:

  1. If the workflow of the humans is modified, it's part of the Interface between the Machine and the Universe. To disregard it as part of the Universe (something we can't change) would lead to missed requirements, as would hiding it as part of the Machine we're specifying. Similarly, while the *implementation* of other systems is largely a part of the Universe that we can't change, if we need to change their *interface*, that interface becomes a part of the Interface between our Machine and the rest of the Universe (i.e. we need to write down what we want to tell it and what we need to know from it -- these, I believe, are requirements).

This is bound to be confusing because I've just used the word interface in two subtly different contexts. With an initial lower case 'i' ('interface'), I'm referring to the interface that a system presents to/expects of a user or another system (GUI, web page, serial communications, analogue signals etc). This is the accepted use, and the one I believe you have used to interpret what I wrote. With an initial upper case 'I' ('Interface') I'm referring to one of the three parts of the model described below. In this context, the Interface is more than just what the system presents to/expects of users and other systems. It includes references to legislation, environmental conditions, customer practices and processes, etc -- these are each a part of the Universe that we can't change, but we need to know about them in order to describe what our Machine must do and not do. The important point about the model is that it gives one a way of working out the relative importance of the facts/opinions/data with which an RE is presented when attempting to specify the requirements for a system.

2) Pah! Semantics! ;-) You can't do a webpage design until you know the requirements for that design. Ditto architecting website navigation (does that actually mean something?).

And as I've said before (and will no doubt say again), I do 'proper' systems - hard real time, deeply embedded control systems. The interfaces are mostly mechanical or serial communications, which are much simpler to specify than GUIs, and far less likely to be abused! This tends to colour my interpretation of other peoples' ideas on requirements, so I am grateful (honestly!) for the opportunity to consider this particular idea from another angle.

Regards,
Paul


Paul Tiplady, MIEE
Principal Software Engineer, Technology Group Electronic Control Systems

TRW Automotive
Technical Centre, Stratford Road,
Solihull B90 4GW
England

Tel: +44 (0)121 627 3837
Fax: +44 (0)121 627 3773 

E-Mail: Paul.Tiplady@TRW.com
Internal web: http://www.cirenuk.trw.com/technology/
External web: http://www.trwauto.com/

---------------------------------------------------------------------------
This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.

>>> "Donald Firesmith" <donald_firesmith@hotmail.com> Thu, 10 Mar 2005
06:16:42 -0600 >>>

Paul wrote:
"The best description of requirements engineering from the system point of view that I've come across is to consider the universe in two parts: the machine (or system) we are building, and the rest of the universe, parts of which our machine will change. The only way we can change the universe is via our machine. In order for this change to happen, there has to be an interface between our machine and the rest of the universe, and it is this interface with which the requirements engineering task involves itself. We don't care what's inside the machine (that's part of the 'how'). We can't influence the universe in any way apart from via our machine, all we can do is describe what it's like now and what we want our machine to do with/to it. Drawn as a Venn diagram, we have two overlapping circles -- one labelled 'Universe' (or Domain) and one labelled 'Machine' (or Specification) -- where the overlap is labelled 'Requirements'."

While largely true, there are a couple of exceptions that need to be addressed:
1) If humans use the system as part of some business process, then hopefully the system will improve the business process. Therefore, the workflow of the humans will be modified, so there is an impact on the universe. Similarly, if the system interfaces with other systems, the interfaces to/of these other systems may be improved by being modified ( these interfaces are not always considered fixed and unchangeable). 2) The boundary between the system and its context includes architecting (e.g., website navigation) and design (e.g., webpage design) as well as requirements.

;-)

Don

Donald Firesmith
Chairperson, OPF Repository Organization http://www.donald-firesmith.com


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 Mar 21 2005 - 09:00:23 EST