Developing secure software. Was: Re: [Dshield] DCOM morning after

Jon R. Kibler Jon.Kibler at aset.com
Fri Aug 15 14:13:52 GMT 2003


Kenneth Porter wrote:
> 
> --On Thursday, August 14, 2003 2:02 PM -0400 "Jon R. Kibler"
> <Jon.Kibler at aset.com> wrote:
> 
> > Usually, by the beginning of the third day, the software types would start
> > complaining "Why do we need all these written requirements, design models,
> > test plans, and other documentation? We have some idea what the customer
> > wants, why can't we just start writing code?". Answer: Because without all
> > this paper work, you really cannot say exactly what it is the customer
> > wants, and exactly how it works. Plus, you have no way to prove what you
> > produce is exactly what the customer said they needed.
> 
> "Some idea"? :D In my experience, the *customer* doesn't know what he wants,
> so how could the programmers? It usually takes a few iterations of prototypes
> before the customer gets it together and settles on a set of requirements.
> Then the issue arises whether any of the work done on the prototypes can be
> recycled into the real product.

The problem of "the customer doesn't know what he wants" does not exist in a development effort done properly.

First, the definition of the problem -- getting the customer to decide what they want -- is ALWAYS a separate activity that precedes the initiation of the development effort. This activity usually starts with the development of an Operational Concept document that describes what it is the customer believes is the problem to be solved and how they believe the problem is best solved. 

Various formal methods are used to further define WHAT the system is to do. The result of this activity is a set of Functional Requirements that define WHAT it is the system is supposed to do (NOT HOW the system is supposed to do it). 

Note the clear distinction between WHAT and HOW. Too many seat-of-the-pants development efforts bog down because they too early into the project worry about "HOW" without every clearly defining "WHAT."

When models and prototypes are developed during the definition phase, they are deliberately developed in a non-scaleable, non-recycleable, and incomplete manner -- often using "smoke and mirrors" to illustrate concepts -- to force the focus on defining WHAT is the system's purpose and not on "what is the fastest way we can get something out the door."

If you study postmortems of failed projects, you will find that every significant failure was due to a single cause: Lack of adequate functional requirements.

One final point. Once the requirements for a development effort are in place, the projected cost of the project is based upon those requirements -- period. ALL changes to the requirements automatically require a renegotiation of project cost. This servers two purposes:
   1) It forces the customer to take seriously the problem definition effort, and helps insure that the requirements developed are complete and correct.
   2) It imposes change control the design, implementation, and testing efforts; this ensures that all "old" functionality is correctly removed from the system, and all "new" functionality is properly integrated into the system and adequately tested.

Moral: Good requirements improve product quality (for our purposes, more secure systems) and reduce the likelihood of project failure.

OK, I'm off my soap box.

Jon R. Kibler
A.S.E.T., Inc.
Charleston, SC  USA




More information about the list mailing list