Your challenge: win and deliver this contract without taking unnecessary risks
That’s it ! The long-awaited call for tenders is on your desk. You know this client, you have a good relationship.
But the project is complex compared to your experience. The client has told you both of his desire to work with you, but also of his reservations. Competitors as motivated as you have more experience at this scale of complexity.
However, winning and succeeding in this case will allow you to reach the next stage of your strategy.
So, how do you convince the client that you will master the complexity of the project? And to convince yourself?
Answer: Create a requirements traceability matrix that will follow you throughout the contract.
Give the client confidence from the first meeting
Trust is the fundamental pillar of any successful business relationship. In the industrial field, where the stakes are often high and expectations complex, gaining your client’s trust from the first meeting is crucial to winning the contract.
Your customer must have confidence that you fully understand their needs and are able to meet them reliably and efficiently. Without trust, it is difficult for a client to make the decision to hire a company for a critical project.
You have to convince yourself first
Trust is like everything else: we only give what we already have. How can we convince ourselves that we will succeed in the contract? Two essential points for this:
1. You need to make sure that the entire specification is understood, and that you have a plan to address each of its points.
2. You must also know the main points of attention, especially those which will need to be discussed as soon as possible with the client.
In other words, you must prepare for a debate with the client knowing that the latter has an advantage over you: he knows his specifications like the back of his hand since he wrote them.
You have little time to master the details as well as the big picture!
Requirements Traceability Matrix
Ideally, there should be a sticky note that connects everything the client wants with everything you propose to do. A reminder that allows you to easily navigate between the specifications and your offer.
This way, you will be ready to argue your proposal in session, without fearing questions that jump from one topic to another, without fearing having neglected this or that requirement.
This is exactly the role of the requirements traceability matrix. (It is also called a “conformity matrix”, or “requirements traceability matrix” in English.)
This tool allows you to easily navigate between the specifications and your offer. It indicates, for each customer requirement, the response you propose to provide. For example, if section 1.1 of the specifications states that ” The application must be compatible with the main browsers on the market “, then the matrix can point to the precise list of browsers to which you are committing.
External reference: IREB Handbook for Requirements Engineering
How to create a traceability matrix?
First of all, it is essential to carefully review the specifications to understand each requirement stated by the client. Then, for each requirement, identify the corresponding elements in your offering or proposed solution. This may include specific features, manufacturing processes, quality standards, etc.
Once you have identified these matches, organize them in a structured way in a matrix, where each row represents a customer requirement and each column represents a feature or functionality of your offering. This allows the client to clearly see how each requirement is addressed in your proposal, increasing their confidence in your ability to completely meet their needs.
Sample traceability matrix as a simple table
In its simplest form, it can be a table whose columns would be:
- unique customer requirement number
- reference to the paragraph of the specifications
- raw requirement
- comment, question, hypothesis
- unique number of the refined requirement, presented in the supplier offer
- reference to the paragraph of the supplier offer
- refined requirement, expressed in the supplier’s terms
| #client | §client | verbatim | commentaire | #fourn | §fourn | raffinée |
|---|---|---|---|---|---|---|
| EX01 | 1.1 | L’application doit être compatible avec les navigateurs principaux du marché | il faut définir les navigateurs souhaités avec le client | CP01 | 1.1 | L'application sera compatible avec Chrome, Edge, Firefox et Safari |
| EX02 | 1.1 | L’application doit être compatible sur smartphone | on ne prévoit pas de développer une application native sur smartphone | CP02 | 1.2 | L'application sera accessible avec les navigateurs compatibles, sur téléphone Android et iOS |
A simple table has advantages, but...
Such a table is useful for checking the offer before submitting it. Is the offer complete, are the requirements clear, are there inconsistencies in the specifications, will you be able to respond to them, etc.?
This table will also be useful during the first discussions with the client. Provide relevant answers to questions, argue your ability to achieve, point out elements that require clarification, etc.
But such a table is not applicable outside of very simple projects or standard products.
For what ? Because it is painful to build and very difficult to maintain over time.
Building a simple table is tedious
Building a traceability table by hand is particularly tedious. There are three essential reasons for this:
1. We must constantly copy information that exists elsewhere, with all the risks of error and inconsistency that this implies. We move from one file to another, from one application to another.
2. It is collective work, so all stakeholders must have access to the same information to avoid inconsistencies and duplication: numbering of requirements, comments and hypotheses, etc.
3. Rearranging the offer paragraphs changes the numbering. You must then update the references in the table.
A simple table is hard to maintain in the long run
As the project progresses, the effort to update the traceability matrix increases, until it becomes impossible without the use of a database.
What are the reasons ?
1. Requirements are becoming more refined. In the example above, we see the notion “refined requirement” appear. Because customer requirements are reflected in design, manufacturing, testing, etc. At each stage, they transform into requirements closer and closer to the realm of realization. We must keep track of this genealogy.
2. Requirements branch out. The same upstream requirement can give rise to several downstream requirements as the work progresses. Cross-references are increasing, because the same requirement can be referenced in several places in your offer or in several documents. In our example, in relation to the requirement relating to browsers, we would produce requirements relating to versions and test environments:
| #réf | verbatim | commentaire | #réf | raffinée |
|---|---|---|---|---|
| CP01 | L'application sera compatible avec Chrome, Edge, Firefox et Safari | identifier les versions, définir les tests | CD01 | Chrome version ≥ 115 |
| CD02 | Chrome version ≥ 119 | |||
| CD03 | Safari version ≥ 16.1 | |||
| CD04 | Edge version ≥ 123 | |||
| CD05 | Développer un environnement de test adapté aux exigences CD01, CD02, CD03 et CD04 |
3. Requirements change over time. This is the normal life of projects. Outside of short projects and standard products, there is a good chance that the customer, supplier or regulator will introduce changes. We must then be able to bring the matrix to life.
We can therefore see why a traceability matrix in table form is quickly impossible to keep up to date manually.
Solution build a real traceability matrix straight from customer requirements
Qinaps proposes to very quickly build a living traceability matrix that can be used throughout the life of the project.
It is produced in two steps:
- step 1 — identify the requirements in the specifications,
- step 2 — match the requirements to the elements of your offer.
Step 1 — Identify requirements within customer document
Once the specifications are imported into Qinaps, open them in the editor and go through them carefully. Highlight a portion of text, then click “track” to make it a requirement object. The object in question knows its source paragraph, has content and a unique number.
From this step, Qinaps is able to generate:
- the specifications with the link to the requirements directly in the text,
- the traceability matrix: it shows the requirements in relation to the table of contents of the specifications. Note that at this time the requirements are neither refined nor assigned.
As seen above, certain requirements need to be clarified. In our example, the requirement “The software is compatible with the main browsers on the market” must be specified: which browsers, which versions.
You then complete the first level of requirements refinement. You open the Qinaps editor on the head requirement, write the expression for the refinement(s), and click “refine” to create the desired refinements. The traceability matrix is updated to indicate how the original requirement was translated or understood.
Step 2 — Match requirements with parts of your proposal
Now you have the requirements of the specifications, possibly reformulated with more precision. It is time to link them to your proposal to complete building the traceability matrix.
You create the different sections of your response document. At this point, don’t worry about the order of the paragraphs in the final document, it’s completely independent. Think “reasoning logic” instead.
To link a requirement to a paragraph in your answer, you draw a link from the requirement to the paragraph. That’s all.
Your traceability matrix is complete, Qinaps memorizes the links in both directions: from the specifications to the offer, from the offer to the specifications.
Produce your proposal and convince your customer
Qinaps documents are constructed by assembling reusable blocks.
No more copy-pasting and cross-referencing to manage. For example, Qinaps is able to synchronize several occurrences of the same requirement in different documents.
You simplify your document management. You simplify the lives of your teams.
Create a document by cherry-picking blocks of text
To create a document, you place the blocks of your choice in a table of contents. The order and nature of the blocks is completely free.
From the table of contents, Qinaps produces a document with or without reference to the requirements.
The huge advantage is that links between blocks persist and are not affected, so the traceability matrix is not affected. It will always point to the right paragraph in the customer specifications as well as in your offer document.
Benefits
You are confident in presenting your offer to the client, because the specifications are now marked with all the links to your offer, and vice versa.
You will manage the project based on a traceability matrix which will be automatically enriched as production progresses.
Earn your customer’s trust and be confident of delivering what is desired.
And all this with an extremely simple tool.
Our approach with Qinaps: Simplicity
With Qinaps, we want to offer an effective alternative to post-its and spreadsheets to manage requirements. We decided to place everything “as a watermark” in the text editor, and to limit the concepts to know to two types of text blocks and four types of links. We are aimed at companies who wish to progress beyond the spreadsheet, but who do not wish to tackle a complete system engineering approach, who do not wish to have to train to use a new tool.
There are other tools on the market
There are other tools, we have looked at them carefully. They naturally have merits that we do not have.
The most common functions are:
- manage a unique numbering system,
- write and memorize requirements, tests, test results,
- manage several types of requirements or tests,
- define and memorize the links between objects,
- manage the different versions, user rights,
- produce reports and dashboards.
Many integrate systems engineering methodologies, for example to model different types of requirements according to their level, and impose relationship rules between the different types. This is a sort of “meta” level requirements management: we must first configure how to manage the project data before starting to do so. Some are able to connect to model-based system engineering (MBSE) chains.
Référence externe : Requirements in Model-Based Systems Engineering, Carnegie Mellon University
They are generally more feature-rich and more complex than Qinaps. By See for example IBM Doors , or Siemens Polarion .
But the biggest difference is that they are not closely linked to the documents produced by the teams. Because they are organized around a database to identify requirements and the deliverables are managed elsewhere. It is then up to users to document their progress or difficulties in the database. This needs to be thought of in the project management process.
You will therefore not escape a rigorous process of review and coordination between the content of the tool and the documents produced by your teams.
Fewer tools can link external documents to the database, provided the documents include formatted tags to identify the linked requirement and describe the contribution. The tags are detected and analyzed by the tool to which the documents are provided. There are, however, three major limitations:
- the analysis of requirements coverage is dependent on the document review and approval cycles,
- the formatting of the tag may be altered when writing the file,
- the database must be able to confidently access the right document, wherever it is located.
In summary
Requirements engineering is an interdisciplinary function that mediates between the acquirer and supplier domains to establish and maintain the requirements that the system, software or service in question must meet.
Requirements engineering is concerned with discovering, obtaining, developing, analyzing, determining verification methods, validating, communicating, documenting and managing requirements. The output of requirements engineering is a hierarchy of requirements that:
- enables common understanding between stakeholders (e.g. acquirers, users, customers, operators, suppliers)
- is validated against real-world needs and can be implemented
- provides a basis for verification of designs and acceptance of solutions.
There are many tools on the market, which you will choose according to your system engineering chain.
Qinaps is very well placed on the “complexity/benefit” diagram: an easy-to-use tool that will give you confidence that your documents take into account the client’s requirements.
On the other hand, you will not find workflow management, electronic signature, UML process modeling, state diagrams, SysML modeling , etc. in Qinaps.
Qinaps is and will remain a simple tool to boost your processes, without replacing them.
To know more :
Watch a demo of Qinaps here ,
Fill out the contact form below and we will be happy to arrange a private demo.
Look at our other articles on requirements management.