Respect-IT has acquired a large expertise in the following topics:

• eliciting requirements
• writing requirements documents
• writing master plans

Respect-IT is also sometimes led to support the contracting authority during the development project after having be involved in the requirements phase as follows:

• as a third party of confidence playing the role of an intermediary between the contracting authority and the project management
• for validating the eleborated system wrt the requirements document
• for verifying the elaborated system by defining test cases based on the requirements
• for training the users.

The References page allows one to grasp the kind of missions, Respect-IT has achieved.

Synoptis of a typical support mission

• Profile of our customer
  • mid-size and large companies or administration
  • facing the need for a requirements analysis
    • involving many stakeholders
    • impacting the organisation in a sensitive way
    • about a complex problem, the ins and outs of which are not clearly identified
    • and the solution of which is not known in advance
  • from a statistical point of view, 55% of initial requests comes from the project management side and 45% from the contracting authority. When the request is issued by the project management, it is often for a project internal to the company.

• Mission duration : from 3 to 6 months for a project involving about thirty stakeholders
• Workload : 1 to 2 consultants
• Results :
  • a requirements model valided and open to changes,
  • a requirements document about one hundred pages long
• Process. The mission is achieved by following a process defined in the KAOS method: Identification of the stakeholders and of the project boundaries
  • Information gathering mainly by means of interviews
  • Requirements modelling
  • Model validation
  • Requirements document writing
  • Validation of the requirements document
• Profile of our consultants
  • skilled (more than 10 years of practical experience)
  • mastering requirements engineering techniques and tools
  • with a multidisciplinary background in order to apprehend most of domains easily. Note that a domain expert playing the role of a requirements engineer is not necessarily an asset for requirements elicitation because of the risk of introducing some bias in the study unintentionally or because of the risk of omitting some information trivial for the expert but not for the development team.