Systems Engineering–Coping with Complexity

A readable introduction to Systems Engineering. 

 

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (Sometimes, I list only those that interest me).  When there is a newer edition of a book than the one originally referenced, the link is to the newer version.  Items marked with a , are works I can recommend.

Title	Author	Remarks
Winning at New Products	Robert G Cooper	Amazon
Metrics and Case Studies for Evaluating Engineering Designs	William L. Chapman, F. David Van Voorhees, A. Terry Bahill, Jay Alan Moody	Amazon
The Anatomy of Major Projects	Peter Morris	Amazon
Systems Thinking, Systems Practice	Peter Checkland	Amazon
Turn Signals are the Facial Expressions of Automobiles	Donald Norman	Amazon
21sr Century Jet – The Making of the Boeing 777	Karl Sabbagh	Amazon
The Sources of Innovation	Eric Von Hippel	Amazon
Object-Oriented Software Engineering: A Use Case Driven Approach	Ivar Jacobson	Amazon
Principles of Software Engineering Management	Tom Gilb	Amazon
UML Distilled: Applying the Standard Object Modeling Language	Martin Fowler, Kendall Scott	Amazon
Real Time Structured Methods	Keith Edwards	Amazon
Object-Oriented Modeling and Design	James Rumbaugh	Amazon
Notes on the Synthesis of Form	Christopher Alexander	Amazon
The Rise and Fall of Strategic Planning	Henry Mintzberg	Amazon
Normal Accidents: Living with High Risk Technologies	Charles Perrow	Amazon
MANPRINT – An Approach to System Integration	Booher	Amazon
Value Analysis and Value Engineering	Frederick Oughton	Amazon
Invention by Design: How Engineers Get From Thought to Thing	Henry Petroski	Amazon
The House of Quality	J. Hauser, D. Clausing	Amazon
To Engineer is Human	Henry Petroski	Amazon
Product Development Performance	Clark	Amazon
Design Methods	Christopher-Jones	Amazon
Software Inspection	Tom Gilb, Dorothy Graham	Amazon
The New Rational Manager	Kepner	Amazon
Against the Gods: The Remarkable Story of Risk	Peter Bernstein	Amazon
The Sciences of the Artificial	Herbert Simon	Amazon
Managerial Economics	Evan Douglas	Amazon
Mastering the Dynamics of Innovation	James Utterback	Amazon
The Product Manager’s Handbook	Linda Gorchels	Amazon
Intellectual Capital	Thomas Stewart	Amazon
New Products: The Key Factors in Success	Elko Kleinschmidt	Amazon
Systems Engineering Guidebook: A Process for Developing Systems and Products	James N. Martin	Amazon
A Quantitative Approach to Software Management	Kevin Pulford	Amazon
Skunk Works	Ben Rich	Amazon
The New Organizational Wealth	Svieby	Amazon
Peopleware: Productive Projects and Teams	Tom DeMarco, Tim Lister	Amazon
A Methodology for Systems Engineering	A. D. Hall	Amazon This is a classic.
The Fifth Discipline: The Art and Practice of the Learning Organization	Peter Senge	Amazon
Guns, Gems and Steel: The Fate of Human Society	Jared Diamond	Amazon
The Blind Watchmaker	Richard Dawkins	Amazon

Visualizing Project Management

The 2nd edition of this book was my introduction to the subject of systems engineering.  Because it is one of the very few that discusses the critical importance of systems engineering to project management, I still consider it one of the best project management texts around. 

Project management is about organising the work required to deliver a product or service.  Its competence is in organising the work and making it go forward to completion within the planned cost and schedule.  It has no competence in determining whether the end product is going to be effective or not.  Systems engineering provides this competency.

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (sometimes I list only those that interest me).  When there is a newer edition of a book than the one originally referenced, the link is to the newer version.  Items marked with a , are works I can recommend.

Title	Author	Remarks
Search for the Real and Other Essays	Hans Hoffman (ed.)	Amazon
Communicating Project Management	Hal Mooz, Kevin Forsberg, Howard Cotterman	Amazon
A Guide to the Project Management Body of Knowledge	Project Management Institute	Amazon
Ship of Gold in the Deep Blue Sea	Gary Kinder	Amazon
General and Industrial Management	Henri Fayol	Amazon
Star Teams, Key Players	Michele Jackman	Amazon
Superior Teams: What They Are and How to Develop Them	Dennis Kinlaw	Amazon
Lean Thinking: Banish Waste and Create Wealth in Your Corporation	James Womack	Amazon
Final Report of the Columbia Accident Investigation Board	NASA	Amazon
Theories of Human Communication	Stephen W. Littlejohn	Amazon
Phenomenology of Communication: Merleau Ponty’s Thematics in Communicology and Semiology	Richard L. Lanigan	Amazon
Communicate with Confidence! How to Say it Right the First Time and Every Time	Dianna Booher	Amazon
Powerful Conversations: How High-Impact Leaders Communicate	Philip J. Harkins	Amazon
How the Way We Talk Can Change the Way We Work: Seven Languages for Transformation	Robert Kegan, Lisa Laskow Lahey	Amazon
Jack Welch and the GE Way: Management Insights and Leadership Secrets of the Legendary CEO	Robert Slater	Amazon
The Power of Little Words	John L. Beckley	Amazon
The Professor and the Madman	Simon Winchester	Amazon
McGraw-Hill Dictionary of Mechanical and Design Engineering	Sybil Parker, ed	Amazon
Tutorial: System and Software Requirements Engineering	R. H. Thayer, M. Dorfman, eds	Amazon
The 7 Habits of Highly Effective People	Stephen R. Covey	Amazon
People and Performance: The Best  of  Peter Drucker on Management	Peter F. Drucker	Amazon
Dynamic Project Management	Deborah S. Kezsbom, Donald Schilling, Katherine A. Edward	Amazon (links to the new version of the book)
NASA GPG 7120.5 System Engineering	Systems Management Office, NASA GSFC	Amazon
NASA NPG 7120.5C Program and Project Management Processes and Requirements	AE/Office of Chief Engineer, NASA HQ	Amazon
DoDI 5000.2 Acquisition Management	DoD	Amazon
ISO 15288, “Systems Engineering: System Life Cycle Processes”	ISO	Amazon
Microsoft Secrets	Michael Cusumano,  Richard Selby	Amazon
Partnership Pays: Project Management the Øresund Way	Helena Russell	Amazon Website
The Path Between the Seas	David McCullough	Amazon
The Art of Systems Architecting	Eberhardt Rechtin, Mark W. Maier	Amazon (link to 3rd edition).  Some people prefer the older version authored by Rechtin
Systems Engineering: Coping with Complexity	Richard Stevens, Peter Brook, Ken Jackson, Stuart Arnold	Amazon
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, 3rd ed.	Craig Larman	Amazon
Apollo 13	Jim Lovell, Jeffrey Kluger	Amazon
Skunk Works	Ben R. Rich, Leo Janos	Amazon
Moving Mountains	William G. Pagonis	Amazon
The Bishop’s Boys: A Life of Wilbur and Orville Wright	Tom D. Crouch	Amazon
An Essay Concerning Human Understanding	John Locke	Amazon
The Innovator’s Dilemma	Clayton M. Christensen	Amazon
The QFD Book: The Team Approach to Solving Problems and Satisfying Customers through Quality Function Deployment	L. Guinta, N. Praizler	Amazon
Business @ the Speed of Thought	Bill Gates	Amazon
The New Rational Manager	Charles H. Kepner, Benjamin B. Tregoe	Amazon
Engineering Complex Systems with Models and Objects	David Oliver, Timothy P. Kelliher, James G. Keegan Jr.	Amazon
Tropic of Capricorn	Henry Miller	Amazon
Team-Based Project Management	James P. Lewis	Amazon
In Search of Excellence	Tom I. Peters, R. H. Waterman Jr	Amazon
Project Management	Harold Kerzner	Amazon
The Complete Idiot’s Guide to Project Management	Sunny Baker, Kim Baker	Amazon
Risk Management: Tricks of the Trade for Project Managers	Rita Mulcahy	Amazon
Identifying and Managing Project Risk: Essential Tools for Failure-Proofing Your Project	Tom Kendrick	Amazon
Making Hard Decisions	Robert T. Clemen	Amazon
Into Thin Air	Jon Krakauer	Amazon
Principles of Management	Leonard J. Kazmier	Amazon
The Wiley Guide to Managing Projects	Peter W. G. Morris, Jeffrey K. Pinto	Amazon
How to Make Meetings Work	Michael Doyle, David Straus	Amazon
Gnomologia, Adagies and Proverbs, Wise Sentences and Witty Sayings, Ancient and Modern, Foreign and British	Thomas Fuller	Amazon
The Visual Display of Quantitative Information	Edward R. Tufte	Amazon
Visual Explanations	Edward R. Tufte	Amazon
Blind Man’s Bluff: An Untold Story of American Submarine Espionage	Sherry Sontag, Chistopher Drew	Amazon
The Leadership Moment	Michael Useem	Amazon
The Human Side of Enterprise	Douglas McGregor	Amazon
Theory  Z:  How American Business Can Meet the Japanese Challenge	William G. Ouchi	Amazon
The Motivation to Work	Frederick Herzberg, Bernard Mausner, Barbara Snyderman	Amazon
Punished by Rewards	Alfie Kohn	Amazon
Management of Organizational Behavior: Utilizing Group Resources	P. Hersey, K. H. Blanchard	Amazon
Please Under-stand Me, Character & Temperament Types	David Keirsey , Marilyn Bates	Amazon
Have Blue and the 117A	David C. Aronstein, Albert C. Piccirillo	Amazon
Influence, the Psychology of Persuasion	Robert B. Cialdini	Amazon
Lewis Spacecraft Mission Failure Investigation Board Final Report	NASA Headquarters	Amazon
Death March	Edward Yourdon	Amazon

Software Project Management: A Unified Framework, Walker Royce

Software Project Management: A Unified Framework (paperback) (The Addison-Wesley Object Technology): Walker Royce: 9780321734020: Books

Books referenced or mentioned in this book:

Title	Author	Link
Software Engineering Economics	Barry W. Boehm	Amazon
Object Solutions: Managing the Object-Oriented Project	Grady Booch	Amazon
201 Principles of Software Development	Alan M. Davis	Amazon
Controlling Software Projects: Management, Measurement, and Estimates	Tom Demarco	Amazon
Managing the Software Process	Watts S. Humphrey	Amazon
A Discipline for Software Engineering	Watts S. Humphrey	Amazon
The Capability Maturity Model: Guidelines for Improving the Software Process	Carnegie Mellon Univ. Software Engineering Inst.	Amazon

Project Delivery System, 4th Ed

This book was highly recommended by a project manager I respected as someone very highly experienced.  The book presents the project delivery system used by the engineering firm CH2MHILL. It covers the topic at a very high level, and is very straightforward and practical.  It is by no means complete.  I doubt if CH2MHILL uses this and only this as their project delivery system.  For example, it does not tackle progress monitoring.

Project Delivery System: Fourth Edition: CH2M HILL Project Mangers: 9780965261616: Books ISBN: 0965261611 ISBN-13: 9780965261616

I found the chapters on planning the project, and the one on building customer relationships clear and enlightening.  They are the best parts of the book.

If you work in a project where there is no project management process, this book provides a framework (but no more than that).  It does not explain what they mean by ‘Project Delivery’ as opposed to ‘Project Management’. 

Listed below are some of the books referenced by the above work.  This list is not necessarily complete (sometimes, I list only those that interest me).  The Amazon links are to the latest editions of the book, not necessarily the edition cited in the above work. 

Items marked with a , are works I can recommend.

Title	Author	Remarks
Force For Change: How Leadership Differs from Management	John P. Kotter	Amazon
Principle-Centered Leadership	Stephen Covey	Amazon
The Leader-Manager: Guidelines for Action	William Hitt	Amazon
The Empowered Manager	Peter Block	Amazon
Crisis & Renewal: Meeting the Challenge of Organizational Change	David K Hurst	Amazon
Leadership, New and Revised: The Inner Side of Greatness, A Philosophy for Leaders	Peter Koestenbaum	Amazon
The Fifth Discipline: The Art & Practice of The Learning Organization	Peter Senge	Amazon
Engineering Management: People and Projects	Murray Shainis, Anton Dekom, and Charles McVinney	Amazon
Managing as a Performing Art: New Ideas for a World of Chaotic Change	Peter B. Vaill	Amazon)
Productive Workplaces: Dignity, Meaning, and Community in the 21st Century	Marvin R. Weisbord	Amazon
Stewardship: Choosing Service Over Self Interest	Peter Block	Amazon
Customer Bonding: Pathway to Lasting Customer Loyalty	Richard Cross and Janet Smith	Amazon
Service Breakthroughs	James L. Heskett	Amazon
The One to One Future - Building Relationships One Customer at a Time	Don Peppers and Martha Rogers	Amazon
Value Pricing for the Design Firm	Frank A. Stasiowski	Amazon
Managing Transitions: Making the Most of Change	William Bridges and Susan Bridges	Amazon
Getting to Yes: Negotiating Agreement Without Giving In	Roger Fisher, William L. Ury and Bruce Patton	Amazon

UML Review–Views

A brief review of UML.

UML is a modelling system.  Every model is a simplification of the real thing and is intended to highlight the focus of that model and to recede what is not important for that particular model.   Reality cannot be modelled fully.  We will always have to select the perspective, or ‘view’, that we want to focus on.

UML is designed around a set of views. Its notations allow you to create diagrams that model a particular view.

Static View. The static view models the structure of the application domain. You use the Class diagram to represent the static view.

Use Case View.  Shows the functions of the system in its interaction with entities outside of it.  These entities are the ‘actors’.  The functionality is grouped together into use cases, where a use case is a specific transaction (or usage) of the system.  The Use Case diagram is used to present the Use Case View.

Interaction View. UML being object-oriented oriented (sic), entities communicate with each other through messages.  The Interaction View shows the message-passing interaction between the entities (strictly speaking, ‘between the roles’). UML has two diagrams that capture these interactions, the Sequence diagram, and the Collaboration diagram.  The Sequence diagram shows the messages and their sent between the different roles as each role requests and responds to the messaged.  The collaboration diagram focuses on the links between objects during an interaction.  So while the Sequence Diagram highlights the messages and their sequences during a specific transaction, the Collaboration Diagram highlights which objects are involved in the same transaction.  There is clearly some overlap between the two diagrams, and in practice, the Collaboration Diagram tends to be given up in favour of the Sequence Diagram.

State Machine View. Unlike the previous views, the State Machine view focuses on only one object or class.  This view models all the possible states of an object, what states it can transition to from each of those states, and what would cause it to transition to each of those states. The statechart diagram is used to draw this view.

Activity View.  This view maps the activities performed by whatever entity we want to model.  We do not have to pick an entity, in fact, and just proceed to model activities related to a particular outcome.  This view is similar to a project network diagram in that it simply maps dependencies and sequences of activities to produce a result.  You use the activity diagram to create this view.

Physical View. The physical views leave the world of concepts to model the physical realities.  There are two physical views in UML.  The implementation view shows the various software components and the links between them.  This is captured using a Component Diagram.  The other view is the deployment view, which shows the software components in the physical computers and servers they will be deployed in.

THE TRIPLE CONSTRAINTS ANOMALY

You cannot possibly be a project manager and not have heard of the term 'Triple Constraints', and the surest sign that you are a novice project manager is your belief that the Triple Constraints is made up a 3 things.

That is one of the odd things about this term.  Originally, it was indeed about three constraints: Cost, Time, and Scope – project and programme managers have to deliver the goods (Scope), within the budget (Cost), within the schedule (Time).

Later, thinkers thought to add 'Quality' because well, sure, you can deliver the goods, but are the goods you deliver up-to-spec?. So the Triple Constraints began to consist of four items.  There are some heretics (or perhaps they are prophets of wisdom) who insist that Quality is just part of Scope, and ought not be considered separately from the other.  The argument is, if you delivered 600 green umbrellas rather than the required 600 red umbrellas, it is not a 'Quality' problem but a Scope problem – you simply didn't deliver what was asked for.

Project managers with more than a week experience, began to realise that despite their personal charm, the world doesn't revolve around them or their naive assumptions. 

Things go wrong.

"We need to add another constraint - Risk", came the chorus. And so the Triple Constraints became five (and have to be redrawn as a pentagon – we are not geometrical ignorami, after all)

Courageous project and programme managers soon began to point out their specialty: delivering goods within the constraints of time, cost, scope, quality, and risks. There is no need to be mean-spirited by reminding them that postmen and newspaper delivery kids and mothers and housewives, have been doing the same since the invention of anything.

But no matter how well we think we manage the five constraints, projects still tend to head south, and so we need another constraint to lay the blame on.

Resources.

"Surely Resources are a constraint!" came the battle-cry of the project and programme manager. "Even if I have a budget of $50 million if I cannot find Fortran programmers, my Fortran project cannot succeed." And of course, when they burn up my $50 million without delivering anything, they can point to the incompetent resources they had to work with. 

But let's take a step back (after first checking we are not on the edge of a cliff; risk management in action).

We can take the view that the constraints are about what a project manager has to deliver against. Or we can take the view that the constraints are 'natural' limitations that enterprises have to balance when deciding which projects to undertake.

We want to finish the project as soon as possible so we can reap the benefits and start other projects as well. But to finish faster means applying more resources. This is a natural constraint in our world.

We want to do it right the first time, but it will mean more time and more cost, so we may need to cut a little bit of scope here and there. Another natural constraint.

We want to deliver the project as cheaply as possible, but if we put a limited number of resources will take the project that much longer to finish. Another natural constraint.

I think the Triple Constraints are about having the enterprise (not the project manager) balance between the 3 (not six) constraints.  The project manager, for his part have to deliver the Triple Constraints while working through the constraints of Risks and Resources. (Quality is part of Scope).

Risk Velocity

Someone asked about ‘risk velocity’ in the Linkedin discussion groups.  She was asking about its use as a criteria in prioritising risks. But she was also interested about the term itself. Why ‘velocity’?  What did the (so far anonymous) coiners of the term have in mind?  The original poster notes that definitions of the term were very vague. 

Subsequent comments from the other posters bear this out – it seems everyone had their own thoughts about what risk velocity meant.  I myself had none, having not heard of this term before.

One poster suggested that risk velocity is about the ‘timeframe within which the risk event might occur’.  That is, ‘risk proximity’ (which begs the question – what’s the difference between the two?).

Another poster posited that risk velocity is not the proximity of the risk itself, but the time to impact of its consequences.  That is, how much time do we have before the consequences happen after the risk occurs?  This poster rather correctly points out that the common measure of risk, which is “probability x impact”, tells us nothing about when either the risk or its impact might occur.

A third poster comments that he sometimes uses ‘Velocity of Risk’ to describe the state of the financial market.  Presumably, during a volatile situation, the velocity is higher.  This is somewhat akin to wind velocity, blowing more violently in a hurricane, and much more calmly in normal weather.

A commenter named Val brings forward her own use of the term. If I understand her correctly, she uses risk velocity to describe how the risk grows the longer it takes to mitigate its occurrence.  Her example tells me she is talking about the impact growing the longer we wait to mitigate. 

Someone named Peter chimes in, properly noting that ‘velocity’ is a vector – a measure containing both magnitude and direction.  He posits that perhaps the term includes (or should include) the idea of something that is moving in a certain direction. Perhaps we are running directly into the risk (or the risk is bearing directly towards us), perhaps it might be a glancing blow, perhaps it may bypass us.

Yet another poster writes that her use of risk velocity is about assessing the likelihood of an event in a specific timeframe, that is, assessing that an event has a 50% chance of happening in the next 3 months, is much more useful than merely saying it has a 50% chance of happening.   While certainly sound, I just don’t see that this has any connection at all about velocity.

In a later post the original poster reveals her own understanding,  which is that risk velocity was about the rate of change of the likelihood, and not at all about the impact.

There were dozens of other further comments, too many to note here.  Some went beyond the original question, but providing interesting insights.

But what of it?  What about risk velocity?  Can it be used to rank risks?  I think the idea of getting a  good understanding of when a risk might occur (risk proximity) and how soon the impact will happen after the risk event occurs is sound, but very inadequate. 

First, which impact are we talking about?  The initial impact?  The follow-on impacts?  The maximum impact?  You need a good understanding of the impacts, when they will occur, how they will occur, in which order, and so on.  Some impacts will occur immediately, some will occur later.  How can a single risk velocity number capture these characteristics?

Risk velocity, as a singular number to be used for ranking risk events according to when their impact is to occur after the event, might appear to be simple and useful.  I think it has a use as a label to allow us to find those risks which may have a early impact, but as a prioritising value, I find it to be too ambiguous and potentially misdirecting.

Ten Lessons from ‘Intellectuals and Society’

Thomas Sowell’s ‘Intellectuals and Society’ describes what drives intellectuals, and what damages they have produced – and continue to produce – to society.  Typical of his other works, this one cites many references to back up its claims.  This is not a book written by solitary pondering.  Sowell could not have written this book without considerable time and effort exerted at compiling sources.

The ten lessons listed below are not the ten most important things this book says.  They are not even necessarily the most important things I learned (the items are not even listed in any order of importance).

I simply wanted to list down ten things I learned while read this book.

1. Special Knowledge – Many types of knowledge exist. Intellectuals possess a ‘special’ kind of knowledge that is not found in the general population. But this knowledge is taken (often wrongly) to be more important than ‘mundane’ knowledge.  Intellectuals often stray very far from their area of speciality, forgetting that knowledge does not necessarily travel with them as they cross other territories.  Chess grandmasters may be the pinnacle of intellectual skills in that game, but they themselves recognise that expertise in chess does not translate to expertise in politics or economics or indeed something closer, like poker.  Intellectuals seem to brush away this fact.  Even the very smartest intellectual possesses only a minuscule fraction of the knowledge of the general public.  Even taken collectively, the total knowledge of intellectuals is dwarfed by the knowledge of everyone else as a whole. 
   
2. Who Intellectuals Are – for the book’s intent, intellectuals are people whose work ‘begins and ends with ideas.’  Intellectuals do not build anything.  They just produce and propagate ideas.  There are many other professionals who engage in work requiring very high mental demands, but whose work does not end with ideas and therefore Sowell does not regard them as intellectuals (for the purpose of this book).  This latter kind include surgeons and doctors, engineers and architects, lawyers and business men, scientists and mathematicians (although Bertrand Russell when acting as a non-mathematician is included in the list of intellectuals).
   
3. Verbal Virtuosity – intellectuals very often frame reality with an inventive play of words to recast this reality into what it isn’t. They do not necessarily do this on purpose.  Very often it just happens as a result of an intellectual’s ignorance of the subject matter. Sowell gives the example of intellectuals calling for the abolition of ‘mandatory retirement.’ He says there has practically never been such a thing.  People who were let go by they employers due to age have always been free to work elsewhere.  They were not required by any law to not work anymore.
   
4. Intellectuals Have a Depp Need to be Recognised – because intellectuals do not do helpful work daily, they have a need to come up with new, exotic, exciting ideas. Whether there is proof that these ideas work is almost ignored.  They want to change the world.
   
5. Intellectuals can be Epic Fools – Sowell provides evidence that intellectuals have been supporters of Stalin, of Hitler, of unilateral disarmament in the face of Nazi Germany rearming, and many other examples.
   
6. The Media Does not Report on Reality – if you think about it, if the media reported only facts, people would not find them very interesting.  The media, like the intellectuals, have an interested in the new, exciting, and exotic.   Sowell unfortunately does not give guidance on where can find the facts, if the media cannot really be trusted.
   
7. Intellectuals Often Ignore Empirical Evidence – Intellectuals judge ideas, not by empirical evidence of its goodness, but by characteristics like ‘novelty’, ‘exciting', ‘complex’
   
8. Social Vision – Intellectuals have a ‘vision of the anointed’ , a vision of a world unable to improve without their (the intellectuals) wisdom and intelligence.  This vision Sowell contrasts with the ‘tragic vision’, where there is no solution – everything is a trade-off, civilisation people just lead their lives making their own choices in a world where civilised society is a veneer over barbarism forever threatening to spill out – and we can’t do much about that except strive to contain it.  This section is one of the harder parts for me to side with Sowell.  Much of society’s progress (material progress at least) is due to capitalists who have a vision of the world and who have staked their reputation and assets trying to put that vision (I would put the likes of Thomas Edison and Henry Ford, even though Sowell does not mention them).  Perhaps I have not understood it well yet.
   
9. Don’t Let the Intellectuals Run Your War – Sowell blames the intellectuals for the stunning weakness of France’s performance in World War II, despite it material military advantage.  He blames France’s military failure on the supine psychological attitude of the French, inculcated into its youth by the intellectuals running the education system.  Had it not been for pragmatic leaders like Winston Churchill,  intellectuals would have had Britain disarm completely in the naive hope that Hitler would do the same.  (Had that happened, I think Western Europe would be completely either under Nazi or Soviet rule)
   
10. Judges Shouldn’t be Making Laws but They are – Laws are supposed to be made by the Legislative branch of the government, and judges are to judges individual cases in light of those laws.  Judges sometimes rule in ways that make their rulings applicable ex post facto.

Eliciting Requirements

I was reading Mike Cohn’s book ‘User Stories Applied’.  He starts his chapter on gathering stories by pointing out that ‘Elicitation and Capture should be Illicit’.

Clearly, this is a play at words.  But the idea is that (to him) ‘elicitation’ rather improperly conveys the notion that ‘requirements are out there somewhere and all we need to do is have them explained to us and then we can lock them in a cage.’

He prefers ‘trawling’, a term he says was introduced by James Robertson  and Suzanne Robertson (‘Mastering the Requirements Process’).  The reason for his preference?  Trawling conveys the idea of a trawler (a boat that catches fish by dragging a large wide net behind it). 

Its a confusing argument.  If there is a word that conveys the capture of something that is ‘out there’ – exactly the image that Mike wants to get away from – it is trawling.

From Merriam-Webster’s Dictionary of Synonyms: “Elicit usually implies, pains, trouble, or skill in drawing something forth or out; it often implies resistance either in the person or thing that is the object of effort.’

‘Elicitation’ is far superior to ‘trawling’ when it comes to describing the process of gathering, extracting, and identifying requirements.

User Stories and Roles in Agile

The Agile approaches in system development rely very heavily on the concept of user stories.   A user story is a brief statement about how a specific user might use the system so that he achieves a specific outcome.  It is often stressed that this outcome must be expressed as something of value to the business.

An example user story might be: ‘As a system administrator, I can configure the access rights of users, so that I can restrict access to sensitive areas of the system.’

Identifying the users of the system to be developed is one of the first steps the development team should take (see for example Mike Cohn’s ‘User Stories Applied’).  To ‘identify’ users does not mean identify the actual persons, but rather to identify roles. 

A role is the capacity in which the user interacts with the system.  An example of a role might be the system administrator who is in charge of configuring and maintaining the system.  Another example is an assistant who is responsible for printing reports from the system. A third example is a data entry person who uses the system to input data. And so on.

In addition to the organisational position occupied by the user, it is also encouraged that the system designers further look at finer grains of the roles.   Rather than simply think of the system administrator as one role, think of possible types of system administrators because doing so can bring insights into what the role will need when using with the system. 

A highly experienced system administrator very familiar with the system will have different needs than an experienced system administrator new to the system, who will also have different needs from a system administrator by accident, and so on.

By further classifying the roles, we begin to realise that not all system administrators are the same.  They have different backgrounds.  They may have the same responsibilities, but they may have different capabilities and capacities.

Mike Cohn recommends the project team to hold a brainstorming session near the beginning of a system development project to identify the various roles that will be catered.  In this session, every team member writes down roles that they think about.  After everyone has written down the roles, the team collects the list and refines them, merging similar ones, and further splitting others.

A couple of observations can be made:

1.  The way some authors use the phrase ‘user’ they seem to be not very clear whether they refer only to those who will be actually using the system.  If that is the case, the definition excludes those stakeholders who do not use the system, and therefore some other exercies is needed to identify the larger set of stakeholders. 

For example, if the system is an immigration department front-end used by immigration officers (and never touched, or even viewed, by passengers), are passengers to be considered as users?  I would suggest they not be considered as users, but should be considered as some other kind of stakeholder (a very important class of stakeholder; not to be ignored), and a separate exercise to identify these kinds of stakeholders need to be performed. 

2.  I would also suggest that after identifying the users, and cleaning up the list, a second exercise be taken to note down the key interest of the user with regards to the system.  Why does this user have to interact with the system – what are their responsibilities to the organisation?