Who is your hero systems engineer?

These days, I‘m inquiring about engineering. I‘d like to know who your hero systems engineer was or is (or will be?). Please comment, or send me a twitter message. Thank you!

Thank you again for making it past the first paragraph. ;-) It all started when a couple of weeks ago I again was confronted with a colleague‘s opinion which said that I am a theorist. I refuse this opinion vehemently; quite the contrary, I believe my work, especially my work for the company, is a paragon of pragmatism. ;-)

So my argument against the opinion usually is ,no, I‘m not a theorist!', in a more or less agitated voice. Obviously, I need a better basis for making that point. Kurt Lewin said:

Nothing is a s practical as a good theory.

I used this sentence for a while as a footer for email that I suspected to raise the ,theorist‘ criticism again.

After all this sentence is only a claim as well, just like my stubborn phrase above. It may be stronger because it carries Lewin‘s weight. Unfortunately very few people instantly know who Kurt Lewin was, and that he most of all used experience - not theory - to advance humankind.

Then a friend of mine, a U. S. citizen who at some point in time chose to live in Norway (which is a very practical move in my eyes :-), pointed me to the work of Billy V. Koen, Professor for Mechanical Engineering at the University of Texas. You should watch this 1 hour movie if you are least interested in engineering, philosophy and art. Or in more mundane things like best practices, methods, techniques, recipes, and checklists, many of which concerning business analysis and project management can be found at Planet Project in case you don‘t know.

Here is Prof. Koen‘s definition of engineering from the movie:

The Engineering Method (Design) is the use of heuristics to cause the best change in an uncertain situation within the available resources.

Causing change in an uncertain situation within the available resources sounds a lot like project management to me. Like program or portfolio management, too. Maybe like management in general.

It is always when an improbable connection opens up between two different fields of my thinking when I find there is useful truth in it. Next, I want to learn about engineering and me, and one way to approach this is to find out who I admire for his or her engineering skills. I tried thinking of a couple of candidate names and found surprisingly few. I‘ve already identified Leonardo Da Vinci (who is not a Dan Brown invention like my nephew once suggested. :-) A quick request to the twitterverse offered nothing, no new name.

So this is my next take: I‘d like to know who your hero systems engineer was or is (or will be?), and why. Please comment, or send me a (twitter) message. Thank you!

Refurbished: Non-Functional Requirements and Levels of Specification

follow me on Twitter: @rolfgoetz

After an interesting and insightful discussion with Tom Gilb and Sven Biedermann about one of my latest PlanetProject articles I decided to work it over. It is a how-to for a good requirements hierarchy. A good requirements hierarchy is an important prerequisite to a more-conscious and logical design or architecture process. This is because real requirements drive design, not designs in requirements clothes. (Thanks Tom for yet another clarification!)

It seems, in trying to write as short as possible I was kind of swept away from good writing practice and got sloppy with wording. I also found out that there is a philosophical, hence essential difference in how the process of 'requirements decomposition' can be seen.

1. One school of thought describes requirements decomposition as a process to help us select and evaluate appropriate designs.
2. The other school describes requirements decomposition as being a form of the design process.
   

Personally, I subscribe to the second meaning, because of a belief of mine: mankind is very used to solution-thinking, but very new to problem-thinking (Darwin weights in). So most forms of thinking, including requirements decomposition, are outputs of a solution-finding or design process. Or, as Sven put it, requirements decompostion is a shortcut to designing, where 'designing' takes on the meaning suggested by number 1 above.

However, it can be very useful to assume there actually is an essential and clear destinction between requirements decomposition and design processes. The point here is: you need to define it that way, then all is well :-) I didn't define it properly, and thus gave rise to many arguments written and exchanged.

Anyway, I hope the article now sheds even more light on the the constant quarrel about so called 'nonfunctional requirements', i. e. what they are, what they are for, why they are so sparse in the common requirement specification documents.

Most requirement specification document I see these days have lots of required functions, and few (if any) requirements for other attributes of the system, like all the -illities. AND many analysts (including me from time to time) confuse non-functional with scalar. Read the article on PlanetProject to learn more.

Levels of Spec Principle, Non-Functional Requirements

Follow me on Twitter: @rolfgoetz

Just a quick remark: I added a grammar representation to the "levels of specification principle" on PlanetProject. For those of you who like precision. 

If my boss sees this, he again will call me a "theorist." :-)

12 Helpful Rules for Refactoring a System

Name: 12 Helpful Rules for Refactoring a System
Type: Rules
Status: final
Version: 2008-04-25

Gist: to provoke 2nd thoughts if you are to take some part in a refactoring. Refactorings seem to come about more frequently these days, maybe because even the stolid of the business people start to talk about 'agile'. Like all these now-buzzwords, there's a lot of potential misunderstanding hiding in the very word.

Refactoring DEFINED AS modifying something without changing its externally observable behaviour with the purpose of making maintenance easier. Note that you can refactor many things, ranging from systems to architectures to design to code. However, relevant literature suggests that Refactoring is meant to relate to Design and Implementation. See Martin Fowler's Website. Also see Code Refactoring.

R1) Whenever you hear the word refactoring, run! 'just joking...

R2) Precisely understand what the various stakeholders think a refactoring is. You'll be surprised. Correct the wording if needed.

R3) Precisely understand what purpose the refactoring has, from each of the stakeholder's point of view. Align expectations before you start.

R4) Assume a great deal of resistance from the people who pay. Refactoring for them is another word for "Give me $$$, I'll give you what you already have! " Find out who will pay for maintenance.

R5) By all means reduce the risk of having a system with new bugs after the refactoring. This can be done by rigorous test driven or even behaviour driven development for example. Any change in behaviour should be treated as a bug.

R6) Challenge the business case (if any ...) of the refactoring. At least, do proper cost-benefit analysis. For example, the system may not live long enough to amortize refactoring.

R7) Prepare for the situation that nobody can provide exact and dependable information on how future budgets will be affected by the refactoring

R8) Back off from refactoring if significant portions of the code will be both refactored and worked over due to new requirements. Do one thing at a time and bear in mind R5.

R9) Prepare for 3 different points of view if you ask 2 people for what specific refactorings should be done.

R10) Think of short-term and long-term effects.

R11) The improvement must be both quantified beforehand and measured afterwards, at least for non-local changes to the system.

R12) Be suspicious if someone suggests only one or two specific refactoring techniques will suffice to reach a project-level goal.

Analysis Mechanisms for Eliciting Architecturally Significant Requirements

Name: Analysis Mechanisms for Eliciting Architecturally Significant Requirements
Type: Rule
Status: final
Version: 2007-12-06
Source: Peter Eeles, Senior Architect, IBM, 2004, http://www.ibm.com/developerworks/rational/library/4706.html

Gist: to provide a checklist of analysis mechanisms that can be used in order to find out about requirements that will be significant to the achitect.
Analysis mechanism DEFINED AS implementation-independent solution to a problem

R1: Consider the following analysis mechanisms when gathering architectural requirements.

Analysis-Mechanism - Description
Auditing - Provides audit trails of system execution.
Communication - Allows distributed processes to communicate.
Debugging - Provides elements to support application debugging.
Error Management - Allows errors to be detected, propagated, and reported.
Event Management - Supports the use of asynchronous messages within a system.
File Management - Provides services for accessing a file system.
Graphics - Supports user interface services, such as 3D rendering.
Information Exchange - Supports data format conversion.
Licensing - Provides services for acquiring, installing, tracking, and monitoring license usage.
Localization - Provides facilities for supporting multiple human languages.
Mail Services that allow applications to send and receive mail.
Mega-data - Support for handling large amounts of data in a client-server environment.
Memory Management - Services for abstracting how memory is allocated and freed.
Meta-data - Supports the runtime introspection of components.
Online help - Provides online help capability.
Persistence - Services to manipulate persistent data.
Printing - Provides facilities for printing.
Process Management - Provides support for the management of processes and threads.
Reporting - Provides reporting facilities.
Resource Management - Provides support for the management of expensive resources, such as database connections. Provides support for the management of expensive resources, such as database connections.
Scheduling - Provides scheduling capability.
Security - Provides services to protect access to certain resources or information.
System Management - Services that facilitate management of applications in a distributed environment.
Time - Services to synchronize time on a network, and to translate times into different time zones.
Transaction Management - A mechanism for handling ACID 1 transactions. ' The acronym ACID refers to four characteristics of a transaction: Atomic, Consistent, Isolated and Durable.
Workflow - Support for the movement of documents and other items of work, typically through an organization.

3 Characteristics of Engineering

Name: 3 Characteristics of Engineering
Type: Principles
Status: final
Version: 2007-10-26
Source: Chris Britton, Microsoft, 2007 (http://msdn2.microsoft.com/en-us/library/bb508955.aspx)

The characteristics of engineering are:

1) The design is decomposed from top to bottom
Note: In contrast, software design is almost all low-level, and it is often hard to see how the entire system works.
2) All designs (high-level and detailed) are analyzed or tested to check for correctness.
Note: In contrast, software development relies almost entirely on testing the product only-in other words, the program code.
3) Implicit requirements, as well as explicit requirements.
Note: In engineering, there are some basic requirements-such as the fact that a bridge should not fall down-that do not need to be specified by the stakeholder.

And a nice quote of Chris': "Engineering is the art of scale."

10 Principles for UI Design

Title: 10 Principles for UI Design
Type: principles
Status: final
Version: 2007-09-03

Gist: to support good user interfaces. These principles can be used in an attempt to test UI very efficiently without doing usability studies.
Note: In one of my projects we designed a user interface for a handheld device running Windows Mobile. It seemed apparent that it is not useful to mimic a Windows-like UI with windows, tabs and long lists. After the fact I read a lot of 'our' ideas in Jakob Nielsen's article. Thank you!

Source: Jakob Nielsen, thanks to Scott Selhorst


P1 interacting: Does the system provide information about its status? [”Please wait while the system is updating”]
P2 familiar: Does the system use terms and language that are familiar to the user?
P3 oops-tolerant: Can mistakes easily be undone? [”Undo” and “How do I get back to where I was from here?”]
P4 consistency: Does the system use controls (buttons, links, words) to enable actions consistently [”Yes” vs. “OK” vs. “Apply”]
P5 error preventing: Does the system help prevent common user errors?
P6 obvious: Is it easy for users to see what they can do, versus being forced to remember what they can do?
P7 user differentiating: Are there ways for expert users to be more efficient than novice users?
P8 minimal information: Are users forced to filter out irrelevant information (minimalist design)?
P9 useful on errors: Do error messages help users to resolve the errors?
P10 documentation: Is the documentation searchable, task-centric, and precise with “how to” steps?

Kick-ass or at least suck-less Design

Title: Kick-ass or at least suck-less Design
Type: principles
Status: final
Version: 2007-09-03
Gist: to explain how to design kick-ass products (or at least suck-less products)
Source: Michael Shrivathsan, with some minor addition on my side. Thanks to Scott Selhorst for bringing me this stuff.


P1: Start With the User Interface - because this is the only thing your user will see.
P2: Work Closely With UI Designers - because of R1
P3: Pay Attention to Details - because it's part of the success of Apple Computers :-)
P4: Simpler is Better - because more features are worse
P5: Be Brave - because you need something that differentiates your product from the rest
P6: Be passionate about your own product - because if you're not, chances are nobody is.

Means and Ends again

Title: Means and Ends again
Type: citation
Source: Kathy Sierra

What good does it do to master a tool if we haven't understood (let alone mastered) the thing we're using the tool for?

Humane Interface Design

Title: Humane Interface Design
Type: Principles
Status: final
Version: 2007-08-22
Gist: guiding you in making decisions when designing a user interface.
Source: An article on Shmula on humane interface design. I stole it completely because I like them so much. Did not add anything.

P1) It's not your fault.
P2) Simple things should stay simple.
P3) Fewer choices mean fewer worries.
P4) Your data is sacred.
P5) Your train of thought is sacred.
P6) Good interfaces create good habits.
P7) Modes cause misery.

Principles of Clear Thinking

Type: Rules
Status: Draft
Version: 2007-12-20
Quelle: Principles of Clear Thinking. <- Blog on http://www.blogger.com/www.gilb.com 2007-03-27 (R1 to R10); rest: own thoughts
R1. You have to have a clear set of objectives and constraints, to evaluate proposed solutions or strategies against.
R2. You have to have a reasonable set of facts about the benefits and costs of any proposed idea, so that you can relate it to you current outstanding requirements.
R3. You have to have some notion of the risks associated with the idea, so that you can understand and take account of the worst possible case.
R4. You have to have some ideas about how to test the ideas gradually, early and on a small scale before committing to full scale implementation.
R5. If there are more than very few factors involved ( 2 to 4) then you are going to have to use a written model of the objectives, constraints, costs, benefits, and risks.
R6. If you want to check your thinking with anyone else, then you will need a written model to safely and completely share your understanding with anyone else.
R7. You will need to make a clear distinction between necessities (constraints) and desirables (targets).
R8. You will need to state all assumptions clearly, in writing, and to challenge them, or ask ‘what if they are not true?’
R9. You will want to have a backup plan, contingencies, for the worst case scenarios – failure to fund, failure for benefits to materialize, unexpected risk elements, political problems.
R10. Assume that information from other people is unreliable, slanted, incomplete, risky – and needs checking.
R11. Assume that you models are incomplete and wrong, so check the evidence to support, modify or destroy your models.