Frequently Asked Question / Tutorials

Inspecto need is a requirements management application. It allows you to create your requirements, formalize them, analyze them and export them to your software development projects. To ensure good practice, we recommend that you first define the domain in the Domain definition section. This step, although optional, ensures that the elements you will use in your requirements are properly bounded. For example, you can define that the led color variable can only be green, orange, red or off.

Once this is done, you can start writing your requirements in the Requirements section. The easiest way to do this is to start with user needs, which you can express freely (following the recommendations of the ambiguity analyzer), then refine them into more formal requirements that can be used with Inspecto code to generate tests.

Finally, you can export your requirements, either to GitHub or GitLab, or to JSON or Word format using the Exporter. All project team members can also import them directly into Inspecto code.

A project can be created using the Projects menu to group together the associated customer requests. All you have to do is enter a name and a description.

Once the project is created, several sections are available:

• Requirements: these are the customer requirements, see the associated section here for more details.
• Domain definition: this is the global environment of the requirements, see the associated section here for more details.
• Export: Allows you to export the written requirements to a file. See the related section here for more details.
• Project settings: This section allows you to configure the connection of the project to other tools and to manage the team associated with the project. See the associated section here for more details.

The New requirement window can be decomposed in 7 parts, as described below:

1. Requirement

   In this field you can write your requirements, whether formally or not. The editor offers autocompletion with the command ctrl + space to guide you in writing formal requirements.
   This is the field that will be analyzed by the ambiguity analyzer (and by the formal analyzer if the requirement is declared as formal).
2. Identifier

   In Inspecto need, it is mandatory to have a unique identifier for each requirement. Most often they are of the form 1.2.3, but you can use any notation you like.
3. Context

   The context of the requirement corresponds to the system to which it refers. Thus, for a requirement When the power supply is on, then the status led must be on, it is the context that makes it possible to specify that we are talking about the power supply and the status led of a computer for example.
4. Assignee

   The user assigned to work on the requiremnt (writing or development).
5. Metadata

   Metadata are associated with requirements and can be used to add specific information. It will be possible to edit them in the next version.

6. Notes

   This field is for free notes that you wish to add to a requirement for the purpose of providing additional information or clarification about the requirement.

7. Relationships

   You can create relationships to other requirements. These relationships are the following:

   Addition:

   A requirement is an addition to another requirement if it specifies more properties.

   Example: “The drone shall retrieve destination of handled parcel from an existing web service and transport it to this destination” is an addition to “When a parcel is handled by the drone, the drone shall transport it to its destination”.

   Constraint:

   A requirement is a constraint of another requirement if it specifies the same properties but in a more restricted context.

   Example: “When delivery order is given and when the battery is low, the drone shall send a notification and stay in the charge pad” is a constrained version of “When the battery is under 10%, the drone shall stay in charge and a notification of battery status shall be available for the user”.

   Contradiction:

   A requirement contradict another requirement if you cannot satisfy both of them at the same time.

   Example: “At any time, the drone shall avoid obstacles, fly at the minimum safe height and be able to stop in less than 1 second” contradicts “When the battery is under 10% then the drone shall switch to recovery mode and land quickly”.

   Partition:

   A requirement is part of another requirement if the first requirement participate to the satisfaction of the second one.

   Example: “When the battery is under 10% then the drone shall switch to recovery mode” is part of “When the distance to warehouse is more than 500 meters and when the drone battery is under 10%, then the drone shall switch to recovery mode, send a location message and land quickly”.

   Refinement:

   A requirement is a refinement of an other one if it introduces a new property and/or if it weakens the constraints.

   Example: “When the drone handle a parcel, then it shall transport it carefully” can be refined in “At any time, the drone shall avoid obstacles, fly at the minimum safe height and be able to stop in less than 1 second.”.

   Repetition:

   A requirement repeats another requirement if it specifies the same properties with the same constraints.

   Example: “When activated, the drone shall take over a parcel (pick it in the warehouse and deliver it)” repeats “The drone shall pick up a parcel, go to the destination and drop it off when activated on the web application”.

   Note that although we want to avoid repetitions and contradictions, it is important, if you detect some, to identify them.

8. Formal checkbox

   If checked, the Add requirement button will be changed to Parse and add requirement and clicking it will perform a formal analysis before adding the requirement.

Formal requirements are requirements expressed using a grammar that allows Inspecto need to parse and analyze them.
The greater the proportion of formal requirements, the lower the risk of ambiguities and misunderstandings related to the requirements.
Of course, the idea is not to write all the requirements in a formal way, but to start from non-formal requirements, close to the user needs, then to refine them little by little until the final requirements, which are formal.

Formal requirements are composed by two parts:

• constraints (introduced by the when keyword);
• properties (introduced by the then keyword).

Thus, a formal requirement is a set of properties that must be satisfied given the constraints.

The grammatical form of a formal requirement is thus:

When <constraints> then <properties>

Constraints and properties are about the value of variables (i.e., elements) of your system or domain.
The main idea is to express what should be the value of variables when other variables have a certain value.

For example, when you write When the power supply is on, then the status led must be on, you define that the value of status led is on when the value of power supply is on.

The grammatical form to express a constraint is:

<variable> <comparison operator> <value>

Variables are defined using words in a classical way. You can also use noun phrases connected by prepositions to talk about sub-elements, for example the led of the dashboard will be understood as the element led contained in the element dashboard.

The comparison operators are the classical ones:

• equality (using the keyword is);
• difference (using the keyword is not);
• strict inequalities (using the keywords is less than or is greater than);
• non-strict inequalities (using the keywords is less or equal to or is greater or equal to).

Value can be of type:

• boolean;
• character or string;
• integer;
• real;
• enumeration;
• or even other variables.

If variables and values do not change for properties, the syntax is slightly different since you have to introduce a modal verb:

<variable> <modal verb> <comparison operator> <value>

Modal verbs modify the comparison operators that follow them (the verb be is in the infinitive, e.g. be less than instead of is less than) and are:

• must;
• shall;
• could;
• would.

At any moment, if you are writing a formal requirement, you can press the Parse and add requirement button to verify that your formal requirement is written correctly.

A requirement in natural language is a requirement expressed in natural language and is not analyzed. These requirements make it possible to express global and initial needs, without formalization.
They are therefore useful for grouping together a set of requirements, for keeping track of customer requests or for writing a requirement that cannot be formalized.
Inspecto code will generate the test structure associated with this requirement and will make the link between the code and the requirement, but will not be able to generate the various test cases, which remain the responsibility of the developer.

Each variables expressed in requirements is defined by a domain.

Inspecto need infers the type of variables using the context, but it is possible to define it strictly in order to:

• avoid using a variable outside its domain (e.g. use a variable as a real when it is an integer);
• restrict the domain of a variable (e.g. say that led color variable can only be green, orange, red or off).

There are different types of domain definitions, as described below:

1. Literal

   These are the simplest literal types: boolean, character, double, integer, string.
2. Enumeration

   An enumeration is a list of possible values assigned to an element.
3. Structure

   A structure contains elements defined with a type:

   

4. Reference

   This type reference a previously defined domain definition.

This is done using the Domain definition section of Inspecto need. You simply add a new definition, giving a type to a given variable. Inspecto need will then parse it into the project based on that type.

The purpose of a glossary rule is to replace one element of requirements with another.

This can be used to replace words or groups of words with others (e.g. acronyms with their definitions) or to abstract formal phrases (e.g. abstract numerical data). You can define different type of glossary definitions :

• definitions without variable elements: the text is replaced as is;
• definitions to abstract the requirement with variable elements(e.g. say that {x} is flying means altitude of {x} is greater than 0).
• definitions with variable elements: the text is replaced except for the variable elements which are captured (e.g. the rule {x} is flying with as replacement altitude of {x} is greater than 0 will replace all sentences of type the plane is flying by altitude of the plane is greater than 0).

This is done using the Glossary definition section of Inspecto need. You simply add a new definition, giving a corresponding text with or without a variable element. Inspecto need will then replace it in requirements that use the first part of the definition.

The ambiguity score of the requirements ranges from A to E, depending on the ambiguity template detection.

If a requirement's ambiguity score is different from A, by going to the detailed requirement page, you can get information about what is detected as ambiguous in the requirement by clicking the "details" accordion button.

You have two possibilities to improve the global score of your requirements:

• edit a requirement and take into account the advice given in the "Details" section of ambiguity score;
• refine an ambiguous requirement with another requirement, more precise.

Warning: Possible improvements can be make in definitions, a yellow warning with some suggestions will help you improve your ambiguity score.

Error: Some values on your requirement don't exist in the field of possible defined in domain defintion. A red popup will help you fix the problem and find a suitable solution to improve your ambiguity score.

Dans les paramètres d’un projet, vous pouvez retrouver la section Connection to other tools qui permet de connecter votre projet Inspecto need à un projet GitHub ou GitLab. Cette connexion vous permettra d’importer l’ensemble de vos tickets labellisés “Requirement” et de les synchroniser avec les exigences sur Inspecto need.

Options de tracking :
Ces options permettent deux types de synchronisation avec les éléments de votre dépôt GitLab ou GitHub.

• GitLab/GitHub tracking : si cette option est activée, la synchronisation avec les tickets de votre dépôt distant se fera automatiquement.
• Change tracking : si cette option est activée, chaque modification sur une exigence sera sauvegardée sur votre dépôt distant sous forme de modification du ticket associé.

Au travers du menu Exporter, il est possible d’exporter les exigences d’un projet :

• Au format Word : pour générer un fichier qui servira de base à un cahier des charges par exemple ;
• Au format JSON : pour sérialiser les exigences dans un fichier qui pourra facilement être utilisé par d’autres outils.

Pour chaque projet, une équipe est définie par le créateur du projet. Seul le créateur du projet peut y ajouter ou supprimer des membres. Une liste récapitulative de l’ensemble des membres de l’équipe d’un projet est visible dans la section Project Settings 〉Projet Team . Celle-ci contient les données de chaque membre, incluant les licences activées.

De même, l’ensemble des membres que vous gérez sont présents dans la section Profile 〉Team members

Inspecto code is an automatic test generation software, directly linked to the Inspecto need projects of which you are a member. You will be able to retrieve all the requirements previously written on Inspecto need.
Inspecto code allows you to generate your behavior and acceptance tests in the programming language of your choice.
After linking the generated tests to your code, you can run your tests from Inspecto code and observe which requirements are met or not by the application.

From Menu 〉File 〉New Project or directly with the icon

In the wizard that appears, enter the name of your project and the folder in which you want to place your project. Using the drop-down menu, you can indicate the Inspecto need project you are working on.

On the next page, indicate the specifics of your project's test generation, such as the language, the test framework used or the location of the test files.

A project can be imported or exported to remote repositories (Inspecto need, GitLab, GitHub, Jira).

Import from Inspecto need

Import your requirements from an Inspecto need project of which you are a member.

Import from GitLab/GitHub

Import tickets from a GitHub or GitLab project, specifying or not a particular label. Once your project is created, from Menu 〉File 〉 Import from Git or directly with the icon from the toolbar, with the following data:

• Project from : GitHub
• Path for saving file : 〈the folder where to save the import (by default it is the project requirements file) 〉
• Project URL : 〈the URL of your deposit 〉
• Token : 〈the token if your remote repository is private, leave empty if it is public 〉
• Label : 〈the label of the requirements you want to import, leave empty to import all 〉

Import from Jira

In the same way as for GitHub or GitLab, you can import a project from a remote Jira repository.

Export to Inspecto need, GitLab, GitHub or Jira

Once your import is done, your remote repository will be associated to your project and you can export your requirements directly with the of the toolbar.

There are several possible views of your requirements depending on your needs. The visualization in the form of a list of all your requirements, which allows you to see at a glance all your requirements and the status of each one.

The visualization in the form of a ticket, which allows you to have all the data related to a requirement (texts, metadata, assigned member).

The graphical view, which allows you to see the links between your requirements from the Graph view tab. Thus, you will be able to see in green the minimum set of requirements that must be met to run all your tests.

It is also possible to open the .req files in the text editor by right-clicking 〉Open in editor.

It is possible to generate the test files associated with the requirements using the Tests 〉Process project menu or directly with the Process button in the toolbar. Your files will be generated in the tests sub-folder.

The generated tests are organized into two types of files:

• files containing the body of the test methods (Oracle) which have the form 〈reqFile〉requirements.
  It is up to the user to complete the method bodies of the non-formal requirements ;
• the files containing the different test cases named 〈reqFile〉requirementstests.
  In these files there is a need to initialize the tested objects correctly.

It is now necessary to link these test files to the developed application in order to be able to execute them. Note that it is possible to regenerate a requirement from the detailed view using the Generate test button.

It is possible to easily navigate between a requirement and the associated test code. To do this, there is a button in the detailed view of a requirement Go to test code. Conversely, you can return to a requirement with the command ctrl + space from the identifiers present in the comment of the test methods.

You must integrate the generated tests into your developments. Compile these tests with your application and then link the executable produced to Inspecto code using the Tests 〉Browse executable menu or using the button in the toolbar.

Once the tests are linked to the application code, it is possible to preview the results from the Inspecto Code application. It is possible to link an executable file for C++ projects, a jar for Java projects or the generated main file for interpreted languages such as Python. Once the executable file is linked, you can then launch the tests via the Run button> . The results appear in the console.

Some parameters of the application such as the generation language or the font size can be modified in the Settings of Inspecto code, accessible via Menu 〉File 〉Settings.

There are several possible generation languages, available in the Settings of the Inspecto code application.

In order to keep track of customer requests and their origin, Inspecto Code allows you to link documents to a project, a file or a particular requirement.
To do this, simply right-click on the externalSources folder and select Add new external source. In the wizard that appears, you can then choose the type of link, then the file to link.

You just have to register on the site using the form on the Registration page. You will then have access to your personal space and we will contact you shortly to allow you to obtain one or more licenses that you will manage.

The manager account is the account of the person managing all the licenses of his team or company. He can choose to activate or deactivate the users' licenses.

A license malfunction can be caused by several factors. First, contact your manager to verify that your license is activated. Otherwise, depending on your case, please refer to the I can't connect to Inspecto need or I can't connect to Inspecto code section below.

There are several reasons why you may not be able to connect to Inspecto need:

• Error in email/password combination : You no longer know your password or you don't have an account yet, contact your manager to give you access to a license or contact us.
• No License Activated: Your license is deactivated. Contact your manager to have your license reactivated or contact us.
• A problem appeared on our side: It is possible that a problem suddenly appeared on our side. In this case, go to our website www.spilen.fr or our networks for more information.

There are several reasons why you may not be able to connect to Inspecto code:

• Error in email/password combination : You no longer know your password or you don't have an account yet, contact your manager to give you access to a license or contact us.
• No License Activated: Your license is deactivated. Contact your manager to have your license reactivated or contact us.
• Logged in from multiple locations: If you are logged in from another device at the same time, it means someone else is using your account. However, it is forbidden to share the same license between several people. In this case, if you force the connection you will be disconnected from the place of your previous connection.
• A problem appeared on our side: It is possible that a problem suddenly appeared on our side. In this case, go to our website www.spilen.fr or our networks for more information.

Contrary to a BDD approach used in Cucumber, we have a more abstract approach because we focus on requirements. We could call this RDD approach (Requirement Driven Development). To make the link with the Gherkin files, we can open them in our application but no analysis is done on them. By transforming them into a requirements file with Inspecto need, you can generate the associated tests.