Archive for the ‘Software Development’ Category

Software Development Observations: #1 Requirements/Specifications

November 23, 2008

The first statement on observations within software development is around requirements/specifications.

While it may be possible to fully specify a piece of software upfront, it is generally undesirable to do because:

  1. As complexity goes up, it becomes less likely that everything can be captured correctly
  2. The interpretation of what the customer wants the system to do can be misaligned between customer and development group even after agreement.
  3. Sometimes the customer can’t express fully upfront what it is they want.

This sentiment has already been documented by:

In [1], Winston Royce, in 1970 said:

For some reason what a software design is going to do is subject to wide interpretation even after previous agreement.

In [2], Fred Brooks, in 1986 said:

Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem up the detail necessary for specification.

He also goes on to say:

I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.

Does anyone know of other sources?

Some Questions

  1. To what level of detail should we specify then?
  2. Should we try to prioritize our extraction of requirements from the client?
  3. How much time is appropriate to spend on requirements/specifications gathering in relation to the time it takes to turn that specification into working software?
  4. How many times had we to go back and communicate with a customer over gaining understanding on a specific requirement?
  5. How many times was this requirement modified after feedback from the client?

Bibliography

[1] [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf]
[2] [http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html]
[2] [http://www.scribd.com/doc/4025086/No-Silver-Bullet-Essence-and-Accidents-of-Software-Engineering]

Advertisements

Software hypothetical question 1: Response

November 23, 2008

In the following post https://heraclitusonsoftware.wordpress.com/2008/11/21/software-hypothetical-question-1-given-a-situation-of-perfect-specificationrequirements-how-should-one-go-about-creating-the-piece-of-software/, I asked a hypothetical question; here is my response (so far):

Customer Involvement

In [1], Winston Royce, in 1970, writes of the importance of customer involvement in the development of software.

For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.

Fred Brooks in 1986 goes further in [2] saying:

Therefore, the most important function that the software builder performs for the client is the iterative extraction and refinement of the product requirements. For the truth is, the client does not know what he wants. The client usually does not know what questions must be answered, and he has almost never thought of the problem up the detail necessary for specification. Even the simple answer–“Make the new software system work like our old manual information-processing system” –is in far too simple. One never wants exactly that. Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software-design activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.

I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.

Our hypothetical situation removes the core need for customer involvement as outlined by Royce and Brooks above. However we must still expect the customer to be involved in the project for the following reasons:

  1. The customer has invested money (and time) in the project and will most likely require visibility on the progress of the development
  2. Even though the specifications were perfect, there is always the possibility that they were implemented incorrectly and somehow this problem has passed through our testing procedures. It is the customer who must finally verify that the implemented behavior is exactly what they required.

It would be extremely risky to not involve the customer and at the start of any project, this should be made clear that customer involvement is so important and an agreement should be made between the customer and development group about what form this involvement will take.

Approach to Analysis/Design

As the specification is perfect, one could argue that it makes sense to perform all the analysis and design up front before considering any implementation. That way we get it all correct in the first go and would be more efficient when it came to the task of writing the code. However there are a few problems with this approach:

  1. This approach assumes we can create a design for the entire system without making mistakes. This is highly unlikely as the complexity and size of systems grow.
  2. Typically we are not producing any working software when we are designing.
  3. Eventually we must implement the design with the technologies that are available. By trying to design the entire system or large majority of it up front, we are not learning anything from creating software with the technologies at hand and feeding that back into our design process.

The truth is that software is complex. And as we progress, we are developing more and more complex systems. The key to being successful at software is to reduce complexity wherever possible. It would make sense then to grow or evolve the system by incrementally developing the system. Thus not all the specification, or analysis or design or implementation or testing needs to be completed, we just need enough specification to get started, enough analysis and design based on what we know, enough implementation to implement this small chunk of the specification and enough testing to verify what we have done so far is correct.

Bibliography

[1] [http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf]
[2] [http://www.virtualschool.edu/mon/SoftwareEngineering/BrooksNoSilverBullet.html]
[2] [http://www.scribd.com/doc/4025086/No-Silver-Bullet-Essence-and-Accidents-of-Software-Engineering]

Software hypothetical question 1: Given a situation of perfect specification/requirements, how should one go about creating the piece of software?

November 21, 2008

Consider the following hypothetical situation:

A set of perfect requirements/specifications exist for a piece of software. They completely describe what it is the customer wants/requires. They also communicate everything that the developers need to know about the software to be written and no matter how deep the developer delves into the problem at hand, there is also information on the specification to answer the developer/designers questions. The specification is complete and will never change!

The piece of software is sufficiently complex but certainly not impossible. The customer would like the finished product within a specified time frame (say 9-12 months). You have people available to work on the project and they have sufficient skills to complete the software.

So given the current situation, what should be the approach to building this software?

In particular I am wondering about the following given that the specification is perfectly complete and will never change:

  1. What is the involvement of the customer in the software project if any?
  2. What approach should be taken with respect to design of the software?
    1. Should a Big Design Up Front approach be taken?
    2. Should we take an evolutionary design approach and grow the software?
  3. Is there any impact on the way the software is implemented?
  4. Is there any impact on the way the software is tested?
  5. Is there any impact on the way the documentation is created?
  6. What now are the risks in the project?

I am of course going to write a response to my own question but would be interested in hearing/reading the thoughts of others.