Bill O'Brien's WebLog

Non functional requirements and building architects.

Read a funny post recently, "If Building Architects had to work like Software Architects". You may have seen it before. It got me thinking again about the area of requirements. Having recently completed some house building work where I had commissioned a building Architect it started me thinking.

Many people comment after reading the above ditty, that software Archs have a long way to go to match the professionalism/process/skills of building architects. I have to agree that software architects do not yet have an industry standard qualification - consequently we lack the social/industry status this affords. The building architect I employed was able to use her 'seal' from the national regulatory body on her correspondence - and charge me a set fee based on their guidelines!

When working with my building architect we obviously started with a brief. This was a short document listing the high level requirements. If it were an IT project the closest thing I can compare it to would be a project goal statement e.g. Convert basement into two bedrooms with rear access and new windows. It was as high level as that. The next step was to draw plans, these were extremely detailed and the builder could essentially build off these plans. So building architects have refined their specification process to produce a set of highly refined diagrams. Crucially these diagrams can be read and understood by the clients (me) and the builder. What’s the best we've got in IT - UML?

My point (finally J), the builder architect does not labour under the detail of non-functional requirements. e.g. Security, reliability, maintainability, reusability, usability etc. At no stage did we have a discussion about say - security. Obviously the standard was to put windows and doors in that have locks! Also I assumed that insulation and damp proofing would be done in accordance with best practice - obviously I talked about this with the architect but we never got to the level of talking about U values etc - I trusted her and the builder to do the right thing. Of course trusting builders and architects has been the ruin of many before so the other thing on my side was the building regulations that specify minimum insulation levels (sound and heat), plumbing standards etc. etc.  So building has, over time, evolved a process whereby regulations and habit ensure buildings are built to a certain standard using a common set of materials and conventions. As IT Architects we are heading in this direction and in my opinion we need to quickly accelerate past the standard of workmanship and process in the building trade (which I believe to be inefficient with too many trades and skills fragmentation – more about this another time).

Finally - the big difference between house building and system building - in my house I could see everything! So I could see insulation in the ceiling joists damp courses in the floor etc. Our customers can’t see our security or reliability features nor can they understand our diagrams/schematics. Until these non-functional requirements become standard (or regulated) our requirements and design processes will be bogged down trying to specify them and our customers will be bamboozled trying to understand what we are selling them.

Published Wednesday, December 01, 2004 10:31 AM by bobrien

Comments

 

Hector Correa said:

I think another difference between building a house versus a software product is the level of standard components used (locks, windows, doors, pipes, bulbs.)

While on the other side, in software, it is not uncommon for developers to make everything from scratch -- "custom made bricks" if you will :)

That is something that I think we still need to learn from other industries.
December 1, 2004 11:27 AM
 

Adam Young said:

You say that in your house you can "see" everything - i.e. understand the components of your house, what they're for and how they work. Realistically, however, most people probably only have a superficial knowledge of a house's components - personally, I don't know enough about electronics or sewage systems to be able to understand what's involved in building or repairing these systems - I just flick a switch or pull a lever, and either a light comes on or the toilet flushes. Most people's knowledge of how a house works is based on being a "user" of a house - they're familiar with building terms, and the "services" that a house provides; but they're not really interested in how they work to a great extent - else you'd build it yourself, right?

I think we're definitely moving towards "standardisation" within IT, in terms of making UI widgets and app services & behaviour standard, so that systems tend to be designed and constructed in similar ways. So when we've got the IT bricks and mortar, the hallways, gazebos, conservatories and lofts straight, what then?

Many users don't currently have enough IT literacy to be able to feel themselves a proper, equal partner in the software building process - so they leave it all up to us, and don't get involved enough. Until this is rectified, and people become used to "living" with systems, then this is going to continue being a problem.

Certainly IT literacy is increasing - a lot of people these days use computers all day long to do their work; young people grow up with computers and use them in their spare time too. Most electronic devices these days have GUIs, including mobile phones which are used by everyone. Already, users are making very specific demands of systems, even if they don't fully understand what's going on behind the scenes. So if a mobile phone's GUI isn't intuitive enough, or offer certain features, the entire phone gets ditched - I see this translating over to business systems soon enough.

As for diagrams - UML is a whole host of things, and diagrams can be as complex or simple as you care to make them. Personally, I think there's a lot of hogwash being bandied about re. UML being "elitist" or difficult to understand - what could be simpler to understand than a Use Case? The more complex diagrams generated during development don't need to be seen by users (just as not all the blueprints generated during house construction need to be seen by the customer: http://www.thehousedesigners.com/Understanding_Blue_Prints.asp - there's a difference between floor plans and blueprints). For example, does the architect of a house show her customers diagrams of the electrical circuit within the house, or the outlet pipes that lead to the drains? Perhaps, but only in special circumstances - likewise, simple class diagrams modelled on business entities may be shown to users, and are as complex as it needs to go.
December 1, 2004 1:40 PM
 

Bill said:

All great points, UML is fantastic because it has given us a set of diagrams that are well understood and standardised, before UML we had 10 different ways of drawing inheritance etc.

In the case of my house - being a techie I pretty much do know how most things work. But your point is genuinely well taken, most people dont. They are excluded by tech jargon and a mercurial technology landscape that never allows them to keep up to date.

So users should be able to specify their requirements as simply as we can when building "e.g. I want a big room with lots of light that I can use as a bedroom or kids playroom". We as system builders can surface low level details only when required (e.g "Do you want really thick insulation $$$$$ or the minumum spec stuff $$") The rest of the time we follow the standard patterns and do the right thing - and hope it all works and that our builders (developers) can read our blueprints - but thats a whole other set of problems !
December 1, 2004 3:30 PM
 

Eduardo Shanahan said:

I am not so sure about standards and regulations, specially in an industry which is less than a century old.

Houses, bridges and roads are built since we go down the trees, and really, with all the new materials, I am not so sure that most new houses are made in the best possible way (more, I believe that they are made in a sound way, but far from the best).

It makes sense to agree in security levels for columns width and height for example, but after that, many regulations are used just to be within the law and excused to think about better solutions.

I worked with many people in Argentina who takes part in the creation of the new councils for computer professionals, and was sad to see that most of them believe that "everything was thought in IBM 30 years ago". To many of them, the world is a chaos since the aparition of the PC and it's impossible that anything good result from it. I disagree with this kind of ideas.

I prefeer the way in which PARC worked, just leaving the people experimenting and doing something with that later. Many products resulting from PARC where thought in IBM too, but nobody do anything about them in IBM because they where not part of the plans. And later most products from PARC grown outside because nobody in Xerox cared about them.

I doubt that this could be possible with experts and regulations telling what is right and what is not, for two reasons.

First because each expert knows a right way to do many things, and it's natural to think that to try something different is a loss of time and money. If this thinking is law, progress is stalled until the barbarians came from the other side of the walls.

Second, being inside a corporation of professionals gives you a sense of security, and this also could stall progress. You will be paid the same for your work doesn't matter if it's the best or if it's just good, or even bad but inside the regulations. And it's dificult to fight the current if other people are making more money with less job.

I think that it's OK for the computer industry to do cathedrals and bridges for a while, even if they fall apart sometimes. We are learning with each failing project, and with the successfull ones too.

People started thinking about how to calculate a beam just 300 years ago, after cities where built and burned for centuries, and this methods needed 200 years more until transform in laws for engineers. I think that we need some more time to play before start writing regulations.
December 1, 2004 3:33 PM
 

Bill O Brien s WebLog Non functional requirements and building architects | Shed Kits said:

May 27, 2009 1:22 AM
 

Bill O Brien s WebLog Non functional requirements and building architects | Paid Surveys said:

May 29, 2009 1:22 PM
 

Bill O Brien s WebLog Non functional requirements and building architects | Outdoor Ceiling Fans said:

May 31, 2009 6:16 AM
 

Bill O Brien s WebLog Non functional requirements and building architects | My Site said:

May 31, 2009 11:52 PM
 

Bill O Brien s WebLog Non functional requirements and building architects | Portable Greenhouse said:

June 1, 2009 7:35 AM
 

Bill O Brien s WebLog Non functional requirements and building architects | porch swing said:

June 14, 2009 4:20 AM
 

Bill O Brien s WebLog Non functional requirements and building architects | debt solutions said:

June 15, 2009 9:01 PM
 

Bill O Brien s WebLog Non functional requirements and building architects | work from home said:

June 16, 2009 8:38 AM
 

Bill O Brien s WebLog Non functional requirements and building architects | home lighting said:

June 19, 2009 1:55 AM
 

Bill O Brien s WebLog Non functional requirements and building architects | debt consolidator said:

June 19, 2009 10:54 AM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker