Requirements

Craig has posted a taxonomy of requirements on his blog (the taxonomy is Don Firesmith’s not Craig’s). 

I haven’t seen the discussion mentioned in the post, so I don’t know  whether it had any influence on the illustration or is independent of it.  But the nomenclature shown in the illustration, having the format of ‘X requirements’ where X can be anything from ‘Functiona'l’ requirements, ‘Documentation’ requirements, etc. got me thinking. 

A ‘requirement’ is something that someone needs from someone else.  A bit more formally, some entity needs (‘requires’) something from another entity.  When you say ‘maintenance requirements’, ou have to be clear, who is needing these requirements?

Without a clear understanding of who or what that requiree is, you can be assured that the ‘requirement’ will be muddled. 

The diagram shows ‘Documentation Requirement’ in a box.  There is an arrow from that box pointing to a box labeled ‘Product Requirements’.  What does that arrow mean?  Does it mean that documentation requirements are a subset of product requirements? And that as part of delivering the product, documentation should be delivered as well? 

If that is how to interpret the arrow, what does the arrow from ‘Business Requirements’ to ‘Product Requirements’ mean? 

Concatenation of Risk

Currently reading J. Davidson Frame’s “Managing Risk in Organizations”.  Great example of a seemingly insignificant event cascading into a major headache.  A printing press experiences a fire and will not be able to deliver brochures expected to be that were supposed to come today.  These brochures are needed for a client’s conference in two weeks time. All the arranged plans to sort, label, and send them out have to be replanned.

The Problem Statement

Man-made systems are created to exploit opportunities or to reduce threats.  They are designed to fulfill a mission, or objective, aimed a exploiting the opportunity, or reducing a threat.

A problem space is a relativistic concept. Two people in the same organisation may view problems differently.

Problems and solutions could be two sides of the same coin. One man’s problem is another man’s opportunity -- a client has a problem, the solution provider has an opportunity.

Sometimes what we think as problem solving is actually only symptom solving.

Problem spaces are not static. They evolve.

Problems can be symptoms.  Finding the root cause helps in finding an effective solution.

In systems, often the root cause of problem spaces can be many.

Sometimes the best way to understand the solution space is to strart with a conceptual solution.

The problem space is partitioned into solution spaces. This is to reduce the complexity.  It can be impossible to provide a single homogeneous solution that addresses the whole solution space. Each partitioned solution space is analysed deeper and even partitioned.

You cannot really expect to solve a problem if you don’t know what the problem is.  One of the first steps in solving a problem is to understand the problem. 

Often, a problem cannot be solved away, it can only be managed.

Implementation of a solution changes the surrounding system and may introduce new problems and opportunities. Systems are systems.

 

References:

• System Analysis, Design, and Development: Concepts, Principles, and Practices (Wiley Series in Systems Engineering and Management)