The gap between Customer's explanation and his real needs

Have you ever heard about the gap between the Customer's requirements and the point of view of the project team's members?

All the people involved in a software project have heard about the gap between: 

• Customer explanation
• Project leader's understanding
• Analyst's design
• Developed code
• Business description

And the unfortunately very common poor software results:

 Project documentation

• Operation installation
• Support

In my opinion, one of the most astonishing and even striking differences is between Customer's explanation and his real needs.

My work as Functional Analyst has shown me that very often, the customer doesn't know what he wants or, more precisely, he does not know how to explain it. It gives the opportunity to any unscrupulous marketing agent to sell him any kind of solution.

One of the tasks that I really like is the work with the customer and final users in order to help them representing (or even better, modelling) their needs. All this, in the form of graphical models, requirement specifications, user stories, storyboards, use cases, mock-ups, sketches, etc. This is a a very valuable work since it allows the customer to finely adapt his budget to target:

• All of the "Must-have" requirements
• Some "nice-to-have" requirements

We have also heard about these stories where a marketing guy sells something that cannot be developed. Moreover, with a ridiculous delay and price. Then, the dev-team shall deal with all those restrictions and try to do it in the assigned time, quality and budget. A have written a post on Answering to Impossible Requirements.

The following video illustrates some of these problems:

• Customer doesn't know exactly what he wants
• Customer requirements are
• contradictory
• fuzzy
• impossible to implement
•  Marketing agent pushes the expert guy to accept any requirement

        At the end of the sketch, everybody agrees on a "seven perpendicular red lines drown with green ink" project!

I really laugh at the "perpendicularity" question:

        - ....
        - Seven lines, all strictly perpendicular
        - To..... what?
        - eeuuhhh...... to........ everything!
           ....... among ........ themselves !
           I assume you know what perpendicular lines are like !
        - Of course he does! He is an expert!
        -  ...
        - Why are they blue?
        - Indeed, over it was that myself
        - I have a blue pen with me
        - This was just a demonst.....
        - That's the problem, the lines are blue, draw them with red ink
        - That wont solve the problem
        - How do you know before you've tried?
           Lets draw them in red ink then lets see...

Is TDR suitable for a highly layered process?

I’m currently working on “Product assistance” for an aircraft constructor and my usual tasks are Requirements writing or update.

However, the specifications that I write are not used directly by the developers’ team. On the contrary, these high level specifications are translated into a technical requirement specification which is used by the developers’ team.

For any system, the process might be divided into multiple layers and each layer might write its own specification.

The business team writes a very high level specification. The Product team writes a high level specification with some details about the final system, but without any specificity about the implementation. While the Project team writes a detailed technical specification.

Of course, all these specifications are inter-related.

In a usual "Test Driven Requirement" (TDR) approach we should create the tests at the same time that we write the specification. Moreover, the tests are used to better understand and to better explain the requirements.

In this TDR approach we might use a tabular form in order to describe the tests. Then, it should be possible to write a fixture (code) that would execute the test on the System Under Test (SUT). This is the process described by Fitnesse or GreenPepper, for example.

The problem here is that a specification created by the Business team is very far from the SUT; then it is not possible to write any fixture.

The fixture is suitable for specifications that are going to be developed directly, without any other intermediary level.

If we consider TDR as only writing tests to clarify, improve and complete the requirement specification; then it is possible to use it at any level of abstraction. However, we loose all the advantages about test reusability, non-regression, continuous validation, completion measurement, etc. that a tool such as Fitnesse or GreePepper would provide.

Indeed, TDR shows all its power when working on a specification that is going to be used directly by the development team.

D. GARDUNO

Installing Richnesse on Fitnesse

RichNesse is a WYSIWYG text editor for Fitnesse. It is based on FCKEditor. The last version of Richnesse was released on 2008-06-03; while the current version of Fitnesse was released on 2010-01-03. Richnesse is no more compatible with Fitnesse since version 2009-03-21 (more or less).
Nevertheless, it is possible to make them Work together. The instructions are as follow:

1. Download and install the Fitnesse .JAR (I'm currently using the 20100103 version) file

• You should have a folder with the fitnesse.jar file and a FitNesseRoot folder
• The server should now be up at the end of the installation process. If so, then stop it by going to the following url: http://localhost/?responder=shutdown
  

2. Download the Richnesse Zip file (I'm currently using the 0.804 version from 2008-06-03) and unzip it into the same folder as Fitnesse

• You should obtain the following files beside the fitnesse.jar one:
• RichNesse.jar
• RichNesse.plugins.properties

3. The next step is to set the properties file

• Rename the RichNesse.plugins.properties file as plugins.properties

3. At this point I got a problem: It was impossible to configure the classpath in order to point to the RichNesse.jar file. Then, I had to relocate the Richnesse files inside the Fitnesse jar file.
   

• Open the RichNesse.jar file (try using winzip, for example)
• extract the RichNesse folder
• Open the fitnesse.jar file (try using winzip, for example)
• Add the RichNesse folder that you have just extracted into the fitnesse.jar file

4. Richnesse requires a 'responder' class which is not available any more in the recent versions of fitnesse (since 2009). It also requires an old version of a 'recorder' class. Lets get them:
   

• Download the fitnesse zip folder version 2009-03-21
• unzip this file into a temporal folder
• Open the old fitnesse.jar file (try using winzip, for example)
• Extract the SecureResponder.class file from fitnesse\responders\
• Extract the SaveRecorder.class file from fitnesse\components\

5. Lets integrate the old files into the new version of FitNesse

• Open the recent fitnesse.jar file (try using winzip, for example)
• Take the SecureResponder.class file you have extracted from the old fitnesse version and add it into fitnesse\responders\
  
• Take the SaveRecorder.class file you have extracted from the old fitnesse version and add it into fitnesse\components\
• Close the fitnesse.jar file

You can now launch the fitnesse server and access it in http://localhost/. The RichNesse button should now be available on the left panel.

The problem is that, when you install Richnesse this way, the standard 'Edit' button doesn't work any more. Moreover, if you click on this 'Edit' button, there will be a call to the server, the server will not respond to this call and the client will remain waiting for the answer. I think that the server is then altered and the following request will not longer succeed. The solution is then to shut-down and then up the Fitnesse server.

One more comment. I think that, when the Richnesse plugin is installed, then the reports created when there's a problem with the fixtures are less accurate.

Do you have another solution for installing a WYSIWYG editor for Fitnesse?

D. GARDUNO

Benefits of requirements traceability

“The hardest single part of building a software system is deciding precisely what to build.
No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all interfaces to people, to machines, and to other software systems.
No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Frederick P. Brooks Jr. in “No Silver Bullet: Essence and Accidents of Software Engineering.”

Bad foundations guarantee the instability of the entire building. Nevertheless The opposite is not always true. In order to have a stable building, the existence of good foundations is mandatory, but it’s not enough.

This premise is applicable to other domains than construction. In software engineering, the Software Requirement Specification (SRS) is the foundation of the entire system.

Writing a good SRS is mandatory in order to correctly start constructing stable software. However, the SRS is one of the more instable parts of software.

The number of modifications to the SRS grows very fast; we can say that 30% of requirements are modified in a midsize project.

“Changing requirements is as certain as death and taxes”

Daniel Amyot; Lecture in Software Engineering; Ottawa University

This presentation gives a brief description of the problem, then it remark the consequences and gives some advices in order to correctly write and trace requirements. Finally, it gives some examples of traceability by using the Reqtify tool.

This powerful traceability requires the specification document to be written by following strict naming rules so they can be correctly traced. In another post I give the code of a tool allowing you to add an "Automatic requirements numbering" to your Software Requirement Specifications.

Take a look to this presentation named Benefits of requirements traceability by David Garduno

D. GARDUNO

V Model Vs. Agile Methods: An historical explanation

The battle between traditional and well-established concepts against new and modern ideas is as old as the human being. The reticence to changes is also inherent to any society.

The following story gives a good example about this eternal contest . . .

Galileo Galilei was accused of witchcraft and heresy and he had to defend his ‘heretical’ theory about the heliocentric planet movement model (the model where the Earth turns around the Sun) face to the traditional geocentric model (the model where the Earth is in the center of the Universe). Galileo didn’t want to irritate the Church, and then he decided to develop his arguments as follows:

… “Your geocentric model explaining the Universe is not false; however it is quite more complicated than mine. Your model works, it allows to represent the planets’ trajectory; nevertheless I’m sure that the scientific community could take a huge advantage of my model since it is much more simple”.

Deferent and epicycle

The planets are assumed to move in a small circle, called an epicycle, which in turn moves along a larger circle called a deferent.

Copernican system

This is the heliocentric simplified system described by Copernicus in "De evolutionibus"

This simplified example shows us how traditional and dogmatic theories can slow the new ideas.

Most of the people working on software development can affirm that traditional models such as Waterfall and V model are not applied on real systems. However, this is still a standard on most industry processes.

It is true that many project have successfully applied these methods, but they could have reduced their duration and cost by using Agile methods.

David Garduno

A good explanation about Agile methods can be found in Wikipedia
A little explanation about the V model
However, I prefer the french explanation

Mots clés Technorati : Agile,Methods,V-modeling,Scrum,explanation,Modeling