Requirements Driven System Design

A lot of the effort devoted to the development of computer-aided systems engineering (CASE) tool development in the 1970s was based on the belief that if you could capture the requirements you could rather easily design the system.  This was not proven wrong because no one ever completely captured the requirements.

There is some concern among design engineers that if organizations actually achieve CMMI Level 5 in their Systems Engineering processes the organizations can replace their design engineers with computers.  It is possible that among the managers that think about such esoteric things there may be some who actually want this to happen. 

A Correspondence in the INCOSE Journal, Systems Engineering, appears to indicate that there will always be a need for design engineers for the really interesting problems.  William L. Chapman, Jerzy Rozenbilt, and A. Terry Bahill, in “System Design Is an NP-Complete Problem,” SE, Vol. 4, No. 3, 2001, map the Knapsack Problem to the System Design Problem.  The Knapsack Problem has been known to be “NP-Complete” for over 30 years.  The technical implication of this is that “designing optimal systems with deterministic, polynomial time procedures is not possible.”  The article states, “This is the primary reason why engineers do not try to produce optimal systems:  They merely produce designs that are good enough.”

 The article states in its summary that creating a computer design tool will be very difficult.  They add that the interesting aspect of NP-complete algorithms is that it is often quite easy to find near-optimal solutions.  Within the context of product design, optimality is seldom an objective, but rather satisfaction of a problem statement.  Therefore, a solution good enough to satisfy the customer may be within reach of a knowledge-based design tool.

I think this sort of says that you can have Requirements Driven Systems Design for a limited domain.  You can have requirements driven design for “special-purpose systems.”  However, for general-purpose systems, the best you can do is verification that the requirements are met.  The design is selected to meet the requirements and the design process is “aided” by the requirements but it is not driven by the requirements.

The closing paragraph of the INCOSE article touches all the bases, it states that philosophers have pondered the type of problems that are solvable: They System Design Problem seems to be solvable.  Theoreticians have worried about how long it might take to find solutions for certain classes of problems: Because the System Design Problem is NP-complete, finding an optimal solution could take an infinite amount of time.  Behaviorists have shown that humans seek satisficing rather than optimal solutions.  And, academicians have proven that “the job of a systems engineer is hard, in fact, NP-hard.”

The reader is encouraged to figure out how to explain to the customer that he (the customer) should not require optimal solutions and also how to explain to the customer that the main reason for not requiring an optimal solution is that the design problem is “NP-hard” rather than because our design processes are “immature. “