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