Writing a specification for an object-oriented implementation

Write a specification

On the forum, many people ask questions to know how to write specifications. This tutorial helps answer that question.

First, I suggest you do with the people responsible for your project what they really expect specifications. According to the organization, it can take very different forms. It is therefore important to know what format is expected: which parts perform in the specifications?

I would say that the key to a specification is successfully "accuracy and consistency".

In general, to create a specification, you must:

Think about the features that will be proposed

You can start by listing the features that the application will offer, such as: "Save a customer record". This list will enable you to realize a use case diagram.

If you do not know what a use case diagram, you can consult the following websites:



Prioritize features (optional but very interesting)

It may be interesting to prioritize the features to find out why it is essential to develop and those that will be based on the time remaining.

In general, projects are delayed, it is interesting to define as soon as what functions are essential them what functions can be optional (especially as part of a final project splices).

Describe scenarios

Once each feature was clearly identify, describe them with the greatest possible precision. This description is made from a functional point of view it helps answer the question: "How will the user to perform the function."

For this, we take all the use cases previously listed and described as accurately as possible unwinding of functionality. Do not forget the exceptional scenarios on error and consistency checks on the data.

For example, to "Save a customer record" :

Once the manager has connected to the application, it is on the home page and choose from the menu: "new customer". A new window opens, it allows him to enter all the necessary information for the establishment of a customer record. This information is as follows:

- Client Name (required)

- Client Name (required)

- address (optional)

- telephone number (optional)

Once the user has completed the form, you click OK.

The data are then checked:
  • If a required field is missing when a message is displayed to inform the manager
  • If the client already exists in the database then the manager is informed by an error message

Once the control is valid, the data is stored in the database.

Note: This description is quite light, I think we must be more specific in your descriptions of particularly exceptional scenarios and controls: should mention the presentation of these data, eg that in the number field phone, you can not enter letters, for example.

NB2: In this step, it is important to list everything and not to use etc. or ... that your description is very accurate.

NB3: This part can be illustrated with activity diagrams or sequence.

These diagrams are described here:



NB4: This part can be illustrated with models of screens.

NB5: Attention to consistency with the class diagram, all the information described here must be present in the class diagram (which is generally not presented in the specifications).


Write a specification may take you a really long time (ten hours if the application is not huge, like an EFP for example). By cons, it really saves time in modeling and implementation phase when the specifications are defined properly.

I would say that time spent on drafting specifications saves two hours in the design phase.
Writing a specification for an object-oriented implementationDownload this article (PDF) Posted by cs_Julien39. This document entitled " Write a specification for an object-oriented application »fromCodeS-SourceS (Codes-sources.commentcamarche.net)is made available under the Creative Commons license.You can copy, modify copies of this page, under the conditions stipulated by the license,as this note appears clearly.download this article (PDF