Thoughtfulness about specification phase

In the post series about definitions, I would like to focus today on the specification phase, and in particular on viewing this phase according to different perspectives we used to use. It is not revolutionary while we root them out "old methods" like SART or HOOD.
First of all I would like to consider the V life cycle, which is traditionnaly used as reference for every life cycles, under the concepts of Problem and Solutions domains.
We actually can break down the V life cycle into two main parts, i.e.

1. Problem domain : it is the modelization from an external point of view of the real system under development, and also the requirements wrt the system to be developped. We find in this area three main types of activities, ie establishing system needs document by the customer, describing by IT guys the software specification from this document, describing then running validation tests, and qualification tests
   
2. Solution domain : it is the internal view of the system under development which regroups the following formal phases : analysis, design, coding, verification testing(unit and integration testing)

In this post, we focus specifically on the specification phase which is part of the Problem domain area.
The goal of the sofware specification is to provide the development team with a set of elements needed to realize in the best conditions a system which is as close as possible from the customer needs.
There are many means to reach this goal. We can envisage :

• simulation
• modelisation
• mockups and prototypes
• free textual expression of the needs
• formal specifications with methods like the B Method
• ...

All these methods can be used simultaneously of course, everything being a matter of means and/or time.
It is important to notice that the specification model pursues three goals, ie :

• a cognitive aiming, ie understanding the environment of the system under development. We then speak about establishing the Knowledge model
• a prescriptive aiming, ie undertanding interactions between the environment and the real system under development. We then speak about Requirement model also known as Interaction model
  
• an operational aiming, ie designing an effective system in order to fulfill customer needs as close as possible; it is known as Operational model.
  

Knowledge and Requirement models are part of the Problem domain and the Operational model mainly constitutes the Solution domain.
Knowledge and Requirement models establishment is the goal of the specification phase.

We'll see in later blog messages a deeper definition of thoses models.