Chapter 5

Who Can Solve the Problem? ¹

“He who excels in solving problems solves them before they appear. He who excels in vanquishing his enemies triumphs before their threats take form.”

SUN TZU

The Art of War

Things are taking shape! Due to time constraints, Anne has been unable to consult all stakeholders, but the main stakeholders (those with the most mature and relevant information needed for comprehension of the problem) have been consulted. Thus, the identification of the requirements and expectations of all stakeholders is not “complete” in formal terms, and some contradictions or incoherencies remain.

Time is pressing on, however, and Anne is under pressure from Yves to produce concrete results. The results obtained so far are tangible: using reasoning techniques, Anne has been able to obtain a list of requirements for the life support facility covering multiple aspects and points of view, including operational use, the particular lifecycle of the system, etc.

For the moment, no supplier has been found to fulfill all needs and drafting of a solution has not begun. It is time for Yves to begin seeking the “pearl of great value” with the ability to rapidly produce an operational solution, delivered on time, with the appropriate characteristics.

A rapid summary of the status quo shows us that:

– the identification of requirements remains incomplete but has reached an acceptable level. Progress can be measured objectively using the established framework for direction (see section 4.4);

– the main risks, while they have not yet been mitigated or taken into consideration, have nevertheless been identified.

The work carried out by Anne has thus allowed the creation of a specification for the Antarctica Life Support Facility that is judged to be acceptable: it can serve as a basis for the following step, which is decided upon and launched.

5.1. Consultation and selection

In this section, we shall consider matters from the acquirer’s perspective. We shall therefore discuss the situation as experienced by Anne.

5.1.1. Establishment of an acquisition plan

Anne must find a supplier to take charge of the development of the system. Of course, she wants to find the “best” industrialist to respond to her needs. She wants someone able to define, develop and launch a system suited to her technical expectations, while staying within the budget and respecting the time constraints of the mission. The problem with this kind of research-oriented project is that it does not correspond to a sufficiently generic, traditional need that would enable the rapid and easy creation of a list of industrialists with past references corresponding to Anne’s needs.

Moreover, it is highly unlikely that a single industrial group will be able to create the system “all alone”, with exclusive use of its own resources and technical abilities. As Anne does not want to divide her project into several lots given to different sub-contractors, the company will itself need to deal with other subcontractors (“level 2” sub-contractors) for certain aspects that do not correspond to their core business. This means that the industrialist must have strong organizational competences and a strong track record in systems engineering. Often, the term “integrator”¹ is used, as this industrialist must “integrate” several different contributions to constitute a single response to Anne’s requirement.

Anne thus begins to create a list of companies that may be able to respond to her need. To do this, she seeks information within the scientific community, obtaining details of contacts established in the course of other projects. She then consults the purchasing department of her organization to obtain a list of industrial players previously involved in contracts for other projects.

During this phase, Anne rapidly becomes aware that it is not financially viable to immediately launch a call to tender to each identified company, as the work involved in going through responses would increase significantly with each new response. This approach may also be considered as economically unviable by supply companies, who do not wish to invest in the creation of a response without further details concerning Anne’s exact approach and their effective chances of winning the contract. Moreover, certain companies on the list will not wish to respond, and it would be pointless to consult them; others may wish to respond at all costs without presenting a minimum level of technical credibility or financial guarantees. Finally, although Anne is satisfied with her preliminary requirement analysis (see Chapter 4), this analysis has not yet been faced with industrial realities and may lack important points that will be essential in dimensioning costs, details or risks.

Anne finally decides to establish a multi-step selection strategy, as follows:

1) establish an initial list of potential candidates (see section 5.1.2);

2) organize and launch an information request to this first list based on a simplified specification (see section 5.1.3);

3) analyze the response to this information request and select a shortlist of industrials for the call to tender (see section 5.1.4);

4) prepare and launch a call to tender to shortlisted companies (see section 5.1.5);

5) select a partner company (see section 5.1.6).

These steps are not purely sequential as some may begin before the others are completed. The completion of each step will, however, follow the sequence set out in the above list.

For this type of project, we should highlight the need to establish a strong relationship of trust between those issuing orders (the acquirers) and the suppliers. It would be foolish to assume that all this can be resolved on the simple basis of contracts. Unexpected circumstances may arise on both sides, and these circumstances will be easier to account for if a reciprocal relationship of trust is established between both parties. The company chosen to create the life support facility must be considered, and feel as if they are considered to be a full “partner” in the mission. Remember that a “partner” may rapidly become a simple “subcontractor” in case of problems, and a good relationship should not mean that contractual and intellectual rigor are considered to be optional. While it takes time to gain someone’s trust, this trust can be reduced to zero much more rapidly. A project of this kind represents a human adventure that should be marked out as such from the earliest phases of the project.

This consultation process should also be the occasion to begin gradual construction of this relationship of trust, leading to a true partnership, a necessary (but not sufficient) condition for the success of the mission.

5.1.2. Creating an initial list of companies

Once an initial list of companies has been established, Anne contacts candidates one by one by telephone to find out whether they might be interested in this project. To do this, she gives a very brief description of her project, over two pages, which may be sent by email once contact has been established and covers the most important, dimensioning aspects of the project. This document also explains the planned chronology of the project (stages, schedule, expected involvement of tenderers, etc.) and selecting a company to be responsible for developing the system.

These first telephone contacts will allow Anne to rapidly eliminate certain companies from her list, confirm other possibilities and possibly even to obtain further options (if companies direct her towards other contacts). Certain contacts also come to meet Anne in order to present their company and abilities and to gain further details of the project.

This activity, which is relatively time-consuming², leads to the consolidation of a first list of companies who are a priori interested in the project and will be consulted during the information request phase. Anne also obtains a point of contact for each company. Certain exchanges also allow Anne to identify gaps in her specification, for example the identification of elements to be provided by the OTL laboratory itself, known as CFI (customer furnished items) that the suppliers will not need to develop or acquire.

Anne finally decides, mainly for reasons of workload, to only consult six companies. Selection at this level is not particularly complicated. The most complicated aspect is to explain and provide diplomatic justification to certain individuals of the fact that their company has not been selected to continue the process, despite their expressed desire to participate.

5.1.3. Organizing and launching a request for information

During the previous steps, Anne began to carefully construct the contents of her request for information.

This request for information is made up of a set of documents covering the following points:

– A technical specification resulting from the stakeholder requirements and engineering activities presented in Chapter 4. Given the informal nature of this first consultation, Anne only extracts the description of the context of the mission, main demands, the lifecycle, the main milestones in the project and a first outline of the management of sub-contracting.

– An administrative and financial specification providing an outline of the intentions of Anne’s organization concerning these aspects. This part describes how the contract should be managed in administrative terms (monitoring, constitution of teams, etc.) and how the management of financial flows is envisaged (orders, payment schedules and methods, etc.).

– Consultation rules indicating how to respond. This part describes the precise way in which a response should be presented. It also includes a series of questions to which each company must respond. These questions have been carefully prepared and cover the firm technical and organizational points identified by Anne during a first analysis of risks and opportunities, carried out beforehand. An administrative and financial questionnaire, prepared by the purchasing department, is also included. This questionnaire aims to establish whether the financial situation of the company is compatible with the demands of Anne’s projects. Finally, these rules also include a request for meaningful references from the company relating to similar subjects to that presented by Anne.

The questionnaire section of the consultation rules is the most important section, and care must be exercised in its constitution for the following main reasons:

– it allows us, in principle, to obtain precise responses suited to Anne’s expectations. Candidate companies may avoid certain questions or respond in an evasive manner, but this must be done knowingly and this kind of behavior will not escape Anne’s notice;

– it facilitates the comparison of responses from different companies during analysis;

– it allows comparison to be carried out on the most equitable basis possible (comparison on a factual basis, predefined selection criteria, etc.);

– it makes the task of responding easier for the companies involved.

One important point in this information request is the provision of a first estimation of the cost of the service. It is crucial to obtain a first cost estimation at this stage, even though this is based on a number of hypotheses and requires caution. Once again, if Anne wishes to obtain useable results and be able to compare the proposals of different companies, she must prepare a precise questionnaire identifying the main cost centers, following, for example, certain stages of the system lifecycle and the engineering process.

At this stage, the best we can hope for is an estimation of costs at +/-50% [PMI 09].

This information request is also studied carefully by Anne’s legal team, who specify certain contractual points linked to this information request. For example:

– no financial compensation may be requested by companies responding to this information request;

– this information request does not guarantee any further involvement;

– the response does not engage the requester to follow up on this information request;

– submitters cannot claim any indeminzation, whatever the outcome of the request.

Once the information request documents are ready and companies have been selected, the dossier is sent to each named contact. The response phase then follows the pattern set out in the consultation rules.

5.1.4. Selecting companies for the call to tender

Finally, all of the pre-identified companies respond to the information request prepared by Anne.

Initially, Anne intended to shortlist three companies. However, when analyzing the responses to the information request, it becomes clear that four companies may be in a position to respond to her needs. After in-depth discussions with her team and a detailed review of the plans for the tendering phase, based on the effort already devoted to the selection process, Anne realizes that it will not be possible to study a fourth offer due to clear cost and time limitations.

Anne must therefore select three companies to participate in tendering. As in step 1, the companies must each be informed of Anne’s decision regarding the remainder of the process.

5.1.5. Preparing and launching the call to tender

In parallel to the steps described above, Anne has prepared her call to tender.

The documents produced take an equivalent form to those prepared for the information request, but are much more precise.

In the technical specification, all of the results of the work described in Chapter 4 are published. This specification has, moreover, undergone modifications in response to certain remarks, opinions and advice expressed by companies during the information request phase.

In the consultation rules, Anne is careful to specify the organization of exchanges between the OTL laboratory and submitters. This is intended to guarantee a fair consideration of each proposal and maintain credible levels of competition between candidates.

5.1.6. Selecting a partner company

We shall not go into detail on this classic stage of analysis, negotiation and final selection, which may take various different forms but produces the same result: the identification of a winning company to supply the system.

We wish to highlight the importance of this phase from a relationship perspective, and it is essential that a relationship of mutual trust should be established between the acquirer and the industrial partner by adopting a win-win approach. The first step in the creation of trust is to “state what we will do and do what we say”. The selection process must also be clearly explained and objective (unambiguous, reproducible and respectful of legal constraints, etc.).

We shall work on the hypothesis that, at the end of this tendering process, a single company is retained. Note that for certain “heavy” projects, with extremely considerable financial and strategic stakes, several companies may be selected at once in order to launch a competitive definition phase.

Competitive definitions, while on principle more costly as the client finances two definition phases of which only one will finally be retained, may in fact be very effective and finally less costly. This is because they enable competition to be maintained until the presentation of a concrete solution that constitutes the best response to the needs of the client.

5.2. Responding (and winning)

We shall now return to the beginning of the consultation phase but take a different viewpoint, that of a potential supplier for the Antarctica Life Support Facility. This is the story as experienced by two new protagonists, Marc and Roger.

5.2.1. Approaching the problem

Roger is a head of projects at KYN Systems, one of the companies consulted. He has been particularly enthusiastic about this project since Anne first contacted him to explain her search for an industrial supplier for her life support facility project. The subject is interesting from a technical point of view and corresponds to the position of his company: the creation of made-to-measure complex systems. The company slogan is “integrators of complex systems”, illustrating their aims. Moreover, the company already has solid references for systems of a comparable nature and level of complexity, although this would be the first time they would install a system in Antarctica.

Roger has seen Anne speak of the project on a number of occasions and has expressed his motivation, and the company is (naturally) shortlisted for the information request. On receiving this request, Roger discovers the specification prepared by Anne alongside the list of questions. Certain questions are highly specific and require Roger to have an initial idea of the solution. He therefore requires an immediate idea of the solution, both in terms of tasks to be carried out and products to be developed or acquired, integrated, launched and operated. This will allow Roger to gain an idea of the feasibility of the project and gives a precious indication of whether or not it is reasonable for the company to launch into this venture.

Roger would also like to provide the most precise response possible to the information request, even though this is merely the first stage, as he wishes to be shortlisted for the call to tender and feels that this approach may potentially orient the final specification by offering propositions concerning Anne’s requests. Anne has explained to Roger that the specification has not yet been finalized and that it will evolve, particularly taking account of the responses to her information request. Roger therefore approaches Marc, one of the company’s best systems architects, to obtain his opinion.

After reading the information request, Marc returns to speak to Roger. Marc finds the project very interesting, but feels that the specification is not particularly precise. He feels that it will be difficult to develop a viable first solution in so little time and that it will be necessary to use a number of hypotheses that may later prove to be wrong. Furthermore, Marc’s budget for these consultation phases is very limited. As far as providing an idea of cost goes, Marc feels that this is meaningless. He reminds Roger that this is simply a request for information, and that a first, rough approach will suffice. At this stage, reasoning in terms of costs and delays should be based on analogy – using dimensioning elements in relation to similar, past cases – rather than the application of “building” methods involving the determination of costs and delays for the project based on elementary information.

5.2.2. Advancing into the unknown

The word “hypotheses” has now been mentioned, and there is a strong chance that it will feature a good deal in conversations within Roger’s team. First, though, what exactly is a hypothesis?

“For planning³ purposes, hypotheses are factors considered to be true, real or certain without proof or demonstration” [PMI 09].

This definition is very explicit, and for a project manager a hypothesis is de facto a risk factor in that if it proves to be false, it may have consequences in terms of performance, costs and time delays involved in a project.

At this stage of definition, we may oppose the notion of hypotheses with the notion of “facts”, which are true, real and certain factors of which we have proof.

As hypotheses are risk factors, we must aim to transform them as rapidly as possible into “facts” by reference to tangible proofs, for example using requirements (specification, etc.), correctly approved notes, requests for clarification, trustworthy scientific references, etc. In practice, we often see that a large number of hypotheses are simply facts that have not been identified as such due to a lack of time, simple intellectual laziness or a lack of method (the systematic application of the question “is this a fact or a hypothesis?” to assertions).

Certain hypotheses may refer to the project environment, for example the hypothesis that the project team will be correctly managed or that the authorities will provide the necessary authorizations for the launch of the life support facility in plenty of time. In this case, we are in the presence of a classic project riskmanagement approach and the notion of hypotheses is not particularly useful, apart from its use in the qualification and quantification of associated risks. We shall not, therefore, accord particular attention to these cases. Other hypotheses, however, directly concern engineering and are associated with notions linked either to the domain of need or to the domain of the solution.

In the first case, that of hypotheses linked to need, the client is directly concerned. The client must clarify these hypotheses to enable their transformation into facts, most often in the form of requirements or constraints. In practice, this generally occurs as follows: Roger’s team will need to create hypotheses concerning need in order to create a reasonable and engaging proposition in terms of cost and time performance. Roger will make every effort to validate these hypotheses (or, in other terms, transform them into “facts”) so that his offer can be based on solid foundations. To do this, he will ask Anne questions following the processes described in the consultation rules included in the information request and the call to tender.

Note that, very often, in order to ensure equality between candidates, acquirers respond openly, i.e. to all candidates, regarding questions asked by one or other of the candidates. Anne has, moreover, stipulated in the consultation rules that this approach will be taken. However, Roger is experienced and knows that certain questions might give precious hints to competitors who would not have thought of these details, due to a lack of experience; understandably, he does not wish to assist the other candidates in this way. He therefore decides that certain questions should be left as hypotheses, accepting the risks involved. Roger prefers to tackle these points as late as possible in negotiations, or if possible after signing the contract with Anne.

Anne must deal with each question and determine what level of response is required. She may wish to avoid giving too precise a response to certain questions in order to maintain margins for maneuver, as her requirements are not yet completely consolidated and she is awaiting feedback from companies. She may respond to certain questions in an evasive manner. This will not be satisfactory for Roger, who will be unable to consider his hypothesis as a fact.

For hypotheses concerning the domain of solutions, excepting external interfaces that will be dealt with elsewhere⁴, resolution does not depend on the client and must be considered by the supplier. In this case, why create hypotheses? Hypotheses are needed in order to make progress, and time delays must be respected; we will not be able to obtain the responses to all of these problems within the necessary time frame and without excessive financial investment at this stage. The solution will therefore be based on hypotheses that must be transformed into facts when this becomes possible. Effectively, in “real life”, theory is not always easy to put into practice, both because of time constraints and for strategic and political reasons. We are therefore forced to live with hypotheses even if these hypotheses are a clear source of risk. This means that we must identify and manage hypotheses in the same way as other engineering data (requirements, etc.). The problem is not so much in the creation of hypotheses as in their formal identification and correct monitoring throughout the whole development cycle, i.e. the use of a rigorous approach to “uncertainty management”.

Another potential source of confusion lies in the differentiation of hypotheses and incertitudes. Certain information, for example concerning equipment availability, may be the subject of hypotheses if we do not have access to manufacturer data; once these data have been obtained, incertitude will remain as to the exactitude of these values. Only use will allow us to check whether this information is correct, or if it requires review following observations from the logistics system. These data, provided by manufacturers who are not necessarily reliable, should not be considered “hypotheses” but as facts with a degree of incertitude.

5.2.3. Where should we start?

Taking on his role in directing activities, Roger wishes to immediately begin an activity that, for him, will provide the basis for his entire study: the identification of the object and perimeter of the project and the work breakdown structure (WBS). This involves the identification of the main elements that will generate activities, and thus costs and delays, allowing the construction of an offer, initially in rough outline. This structure will be refined as understanding of the problem improves and the structure is defined. Roger’s motivations in starting from this basis are understandable:

– the product breakdown structure (PBS, or BoM⁵) is a structural description of the solution, and thus allows different actors to work around a shared basis of definition of the solution. This allows us, among other things, to obtain an idea of the cost of the solution;

– the WBS sets out what teams and partners will do once the contract has been won. Once again, for Roger, this is an essential tool for:

This is made easier for Roger as, in common practice, the WBS is deduced from the product tree. He must therefore begin by creating the product tree and sharing it with all actors.

This startles Marc, who does not agree in the slightest with this vision of things and with this approach. He presents the following objections to Roger:

– First, the product tree is not an engineering vision, but a vision for the acquisition or assembly of a system and a vision for deployment: that which is delivered and deployed is, indeed, a set of products.

– Second, this product tree does not appear from nowhere. It is a causal consequence of systems architecture, and thus of the system breakdown structure (or SBS). A systemic approach, and thus system design, is carried out using a basis of system artifacts (functions and operational architecture, components and physical architecture) that take concrete form as tangible elements, products or resources, and not vice versa. It is not, therefore, possible to begin work using a hypothetical product tree produced from thin air, and produced from the embodiment of an as-yet unknown system architecture.

– Starting from a product tree promotes or even forces a bottom-up approach to system integration, as opposed to a top-down systems engineering vision. The first option may be applied when reproducing known and mastered solutions that provide almost complete coverage of a known and mastered need (problem) and thus require very little modification or development⁶. When the domain of the problem or that of the solution are not, or are poorly, mastered, or when deep-seated developments or modifications are required, this approach is no longer valid and an engineering approach becomes necessary.

– The creation of a work breakdown structure by deduction from the product tree is not an aberration – far from it – but is a partial and reductive vision⁷. It hides the system vision and systems engineering activities. It also tends to leave aside activities linked to consideration of the system lifecycle, particularly analysis, specification, design activities, etc. The systems vision of the problem thus includes activities that should be taken into account in the creation of the WBS.

Figure 5.1 is a graphical representation of Marc’s comments, showing, from his perspective, the causal relationships between different points of view.

Thus, for Marc the product tree and the WBS do not represent a coherent and relevant starting point for creating the “right” solution to the Antarctica Life Support Facility problem. The “systems integration” (bottom-up) approach cannot be applied in this case, because the domain of the problem is not well known and because the solution, while not necessarily innovative, will not be commonplace. While Marc’s company has worked on similar projects in the past, they have never established a life support facility in Antarctica. A rapid survey shows that, while feedback exists from similar projects (such as the Concordia facility – [GOD 00a], [FPI 00] – to cite but one of the main examples), knowledge is not abundant in this domain.

For Marc, the solution must be “engineered”, i.e. designed following a process based on reason, the application of knowledge and the application of rules (or heuristics) to arrive at a (the) mastered and optimal solution. Once this vision of the system has been developed, it will then be possible to create a product tree and the WBS to which Roger seems to be (understandably) particularly attached.

Marc’s argument seems to be strong, but Roger is not completely convinced, and responds:

“That’s all very well, but we don’t have the time!”

While the causal progression of points of view and items of information to be produced as explained by Marc seems entirely logical, Roger is reluctant to accord too much time to this preliminary stage of engineering. Waiting too long for the results of an activity that must precede all other activities at a critical point in the path seems, to Roger, to present too great a risk.

This illustrates one of the major difficulties involved in the use of systems engineering in our companies and institutions. The vision developed by systems engineering (technical requirements, functional – or service – architecture, physical architecture) should be the cornerstone from which all other visions of the project are built: the managerial (usually dominant) vision, the contractual vision, the logistical vision (project support and backing), the quality vision, etc. We note particularly that during the stage of response to calls to tender, the creation of a solution is often left to engineers who “feel out” the solution. Their intuition may prove fruitful, and we should not neglect the talent and experience of these engineers in imagining the “right” solutions. Nevertheless, we should be careful not to reduce systems engineering at this stage to:

– an attempt to justify, or even market, the imagined solution, especially if this solution has been obtained by the integration of components and not by the transformation of needs/demands into an optimal solution;

– an attempt to demonstrate conformity to input needs or demands, which is, moreover, often limited to the construction of a traceability matrix, which itself does not constitute a formal proof of conformity.

– a catalog of hypotheses upon which the offer is based.

5.2.4. Doing it all simultaneously

A compromise is reached between Marc and Roger, giving due consideration to each point of view.

A first one-day seminar is organized under Roger and Marc’s direction, including all actors involved in the response. The day’s activities consist of creating and sharing a vision of the expectations of the client by analyzing the specification, the expression of need of the stakeholders. Each participant must therefore already have a thorough knowledge of this specification. In addition to the creation of this shared vision, a collective brainstorming session will be held to establish a first general vision of the WBS and the product tree. The WBS and product tree will have been prepared in advance by Marc and Roger in order to direct reflection, avoiding excessive digression during the brainstorming session.

The results of this first iteration will identify classes of products or tasks, without necessarily giving precise and quantified characteristics (What is the volume of tasks? What about product performances?).

This first vision will allow Roger and his associates to begin to: – create a strategy and a vision of the course of the project (breakdown into phases, milestones, schedule, etc.);

– identify and create the team needed for successful completion of the project (internal teams and sub-contractors);

– seek and identify potential suppliers of products needed for the Antarctica Life Support Facility;

– evaluate the financial envelope and cost structure; and

– enter into negotiations with different project actors.

Marc was able to keep the definition of the product tree and WBS at a sufficiently general level to allow flexibility, avoiding imposing limits on the systems engineering approach to be implemented by his team of architects. However, regular points of synchronization are required in the development of these different visions, and thus essentially between the works carried out by Roger and Marc and their respective teams. Given the time constraints, these points of synchronization will take place on a daily basis in the form of a stand-up meeting.

This response phase therefore involves the execution of simultaneous engineering to allow parallel development of the different visions required of the object of the project. The success of this approach depends on:

– permanent sharing of a common and coherent vision of the solution. The coherence of the solution should not be reconstructed a posteriori by the juxtaposition and confrontation of electronic documents or the reconciliation of different models, but be a quality inherent to the approach;

– effective cooperation between different actors.

This type of cooperative work, based on strong and direct interaction between actors, recalls so-called “agile” approaches. The construction and permanent communication of a coherent vision involves the use of more visual and synthetic information supports and collective and direct techniques for manipulating this information. The overly-systematic use of computerized tools and applications currently seen in practice, in addition to the fact that it tends to de-humanize the relationships between actors, imposes excessive limits on interactivity and effectiveness and restricts the powers of expression and creativity needed during these phases.

Different types of design

The design process is a problem-solving approach. It consists of passing from a situation of dissatisfaction – identified here using the specification, expressing the expectations of different stakeholders – towards an objective solution resolving this dissatisfaction – here, initially, through a complete, coherent, figured and justified definition of the system to be produced. In the context of system design, this consists mostly of identifying a set of appropriate components. The identification of these components is the result of both analytical and design activities, evaluation, optimization, verification and validation of the solution. The integration of these components, and thus of the interactions between them, should allow us to cover all behaviors expected of the system in an optimal manner while avoiding or reducing undesired behaviors.

Systems design is generally a collective and coordinated activity, bringing together several actors from different professions (multi-disciplinary approach). Design practices differ depending on companies, the people involved (the talent of designers) and the nature of the problem under consideration.

Factors that have a major influence on the design approach include [CIR 98]:

– the availability (or otherwise) of a knowledge base;

– the availability (or otherwise) of a methodology for resolution.

To this, we may add:

– the necessity (or otherwise) of acquiring new knowledge in addition to the knowledge base already present to allow resolution of the problem.

It may also be interesting to place this into perspective in relation to classes of human behavior, and thus that of the designer(s), following the importance accorded to mental activity (following the SRK (Skill, Rule, Knowledge) taxonomy of human behaviors [RAS 83]):

– skill-based behavior: reproduction of mastered behaviors not requiring conscious mental activity;

– rule-based behavior: consciously executing coordinated tasks following rules or procedures;

– knowledge-based behavior: conscious and complex mental activity in order to plan and solve problems when no rule exists to do this, i.e. find the solution oneself.

This all leads us [SCA 04] to distinguish between the following approach typologies:

– routine design, which provides a solution to a new problem based entirely on existing solutions, usually cataloged solutions;

– re-design, which responds to new demands based on a pre-existing solution with the aim of improving performance or applying corrections;

– adaptive design, which allows us to keep initial functionalities by adapting the architecture following the appearance of new demands;

– variant design, which involves the creation of a product range based on an existing product;

– innovative design, allowing us to combine existing elements or knowledge in order to develop a new product;

– strategic design, allowing the development of new knowledge: results or applications produced by fundamental research;

– creative design, where the object to be designed is defined in an abstract manner and where knowledge and methodologies for resolution have not previously existed in the design field.

This allows us to represent design activities in the following manner (following [MOU 10]):

5.3. Committing to a “right” definition of the system to be created

Roger’s company has been selected to respond to the call to tender and Roger has received the consultation documents prepared by Anne. The decision to respond to the call to tender following the request for information and the pre-selection process has therefore been taken. The response team is led by Roger, as project manager, and Marc, as systems engineer.

Marc is well aware that this phase of response to the call to tender does not give him the opportunity to correctly and completely implement a system design phase that would produce a more rigorous and complete system definition – even with a fuller and less ambiguous specification than that provided during the information request phase. He therefore focuses his efforts on establishing a list of technical requirements while carrying out preliminary design activities.

The constitution of a list of technical requirements responds to a triple need. From a technical point of view, these technical requirements are the starting point for:

– system design. The designer will strive to find the optimal solution. This optimum is not absolute, as certain designers seem to suggest by offering “the best that can be done”, but is the option that provides maximal satisfaction of input requirements, mostly non-functional requirements, which are often discriminatory requirements;

– system verification (see Chapter 8).

From a contractual point of view, technical requirements ensure a clear understanding of the expectations of different participants and define what the supplier is committing to. Preliminary design activities will be carried out in order to:

– attempt to remove or reduce the maximum number of identified technological risks;

– increase confidence in the feasibility of the system through objective elements.

5.3.1. From stakeholder requirements to technical requirements

There is a tendency to restrict the transformation of the needs and expectations of stakeholders (expressed in a specification) into a list of technical requirements of an activity based on:

– analysis and understanding of the specification;

– reformulation of input requirements into technical requirements.

While the first of these activities is a necessary first step, the second is too often limited to a literary exercise consisting of expressing requirements following lexical, syntactic and grammatical canons, neglecting the semantic aspect.

The real challenge of technical requirements engineering is:

– to obtain a complete and coherent definition of the problem;

– to remain realistic, i.e. ensure feasibility faced with identified constraints and risks;

– finally, to express adequate requirements for the design and verification of the system in the correct terms and with a technical vision of the system.

This expression, while necessarily in accordance with the specification, may be formulated and structured in a completely different manner. The aim is not simply to rewrite the specification while eliminating any ambiguities inherent to the fact that it is expressed in the vocabulary of the stakeholders. We want to create a consistent and useful reference point for the design community, resolutely adopting their perspective.

Marc’s actions in terms of engineering activities are very similar to Anne’s initial requirements regarding engineering activities. However, his point of view and approach to the subject is different. He will, in fact, extend the field of vision by:

– Taking the whole of the system lifecycle into account. Anne deliberately chose to look at the “adult life” of the system after production. Here, Marc must look at the system from birth (definition and design) to death (retirement, dismantling or recycling).

– Giving consideration not only to the stakeholder expectations that Anne expressed in the specification, but to those of other participants involved in situations in the system lifecycle yet to be covered (design, development, construction, integration, etc.). Marc’s own company, with its habits, culture, knowledge and procedures (formalized by a quality standard) will act as a major stakeholder. In the same way, the sub-contractors and suppliers identified by Roger for the development and creation of the Life Support Facility are also stakeholders.

– Considering that the system will be inserted into one or more contexts (depending on its situation or phase in the lifecycle), with attention given to the “suprasystem” – the larger system of which the Life Support System is a component. The system will no longer be considered a black box, but a “dark gray” box. Without precisely or fully defining the System, Marc will still be obliged to carry out system studies or analyses in order to give a verdict on the global feasibility of the System, and thus to have an idea of the solution.

5.3.2. Covering the whole of the System’s lifecycle

Marc must extend the System’s lifecycle to cover its whole lifespan, considering the stages of definition, design, development and creation and those of integration, verification and validation⁸. The lifecycle stages already identified by Anne will be covered in greater depth here; for example, the system launch stage requires more detailed consideration. Marc rapidly becomes aware that in order to be operational at the final site, the system must be transported, and that this transportation process itself includes a certain number of distinct phases. This will have an impact in two main areas:

– On the course of the project. Each step will have a duration and constraints in terms of date and time of departure and journey length. This will undoubtedly constitute a critical path in the global schedule.

– In the technical domain. Up until now, the life support facility was envisaged by Anne in its operational context; consideration of the facility in other contexts will have an impact on design. The necessary adaptation to different contexts and changes of state or the integrity of the system must be clearly identified.

The analysis of the launch phase leads Marc to identify the following steps:

– prior to transportation, the system will be assembled and integrated at the final integration site. It is, however, reasonable to think that certain components, for example perishable goods or resources (fuel, gas) may be added later and that they will not be part of the concrete state of the system at this stage. Nevertheless, a nonnegligible part of the system will take concrete form as tangible elements (products). We must then dismount the system;

– the system is then stored at the final integration site, ready for sending;

– transportation to the final site is carried out as a series of stages, with corresponding milestones and journeys:

– once the journey to the site has been carried out, we must install the life support facility, including mounting it.

Based on this more detailed system chronology, Marc will be able to adopt an approach and organize engineering activities that bear a strong resemblance to those carried out by Anne:

– each of these stages will lead to the identification of new stakeholders in possession of information, expectations or limitations that apply to the system. The stakeholders encountered by Anne were mainly users or people profiting from the scientific mission, or sources of information. Here, Marc will deal mostly with service providers (transportation groups, logistics) or external constraints (Customs etc.);

– these different situations may be broken down into a certain number of operational scenarios. For example, the passage from one mode of transportation to another will necessitate transshipment activities. Thus, a step identified as “transportation from one point to another” will be broken down into the following generic series of operations:

– in these different situations, the system will be immersed in different contexts. The interactions (and constraints) linked to these contexts are potentially different or different in nature to the interactions and constraints to which the system is subject in its operational context. This should therefore lead to the production of an equivalent number of contextual models.

5.3.3. Accounting for stakeholder expectations and constraints

Certain information has been gleaned from bibliography or from Internet searches. However, a large portion of the information used by Marc was collected directly from the individuals concerned, either by asking Anne and the OTL laboratory personnel or by consulting other actors in the domain. Marc has therefore been in contact with different stakeholders.

Like Anne, Marc worked following a structured framework: {stakeholders} X {external entities} X {lifecycle phases and situations}. The extension of the field of the lifecycle considered had the effect of enlarging the range of stakeholders involved.

Marc, in cooperation with Roger, will therefore create his own list of stakeholders (see Table 5.1). Moreover, the very fact that Marc is part of an organization (his company) operating in an economic, social, financial and legal context, and working following set patterns with given means and infrastructures, imposes consideration of other expectations, and particularly constraints linked to his own environment.

Once again, these constraints are not necessarily negative. They may even be seen as positive in that they give concrete form to the knowledge and feedback of the company, considering its ways of designing, developing, producing, integrating, managing, ensuring quality, etc. At this stage, they merely present ulterior restrictions to the possible solution space, but guarantee the suitability of this solution both for client expectations and to industrial constraints on development, production, integration, deployment, etc.

5.3.4. Remaining realistic

The set of technical demands being established will act as a contractual commitment to the client concerning results. Without defining the solution, these demands will define the system to be delivered in terms of its behavior, performances, the constraints it will respect, the threats that it must resist, etc.

Without producing a full and detailed system design, Marc is now obliged to reveal part of the plan: just that which is needed to allow him to place reasonable confidence in the exhibited technical requirements and obtain objective elements relating to their feasibility. Typically, he will need to launch and direct a certain number of system analyses, choice studies or trade-off analyses. He will therefore have a first rough, but realistic, idea of the dimensioning performances of the system and of major and definitive choices that must be made.

For example, Marc must choose a means of transportation from the Dumont d’Urville station to the final choice. This choice will have a strong impact on the global cost and on the deployment schedule.

The choice of a means of transportation between Dumont d’Urville and the final site involves two alternatives:

– use of the DHC-6 Twin Otter, a reliable aircraft but with reduced capacity that can only fly in specific weather conditions;

– terrestrial convoys. These convoys are made up of leveling engines and tractors pulling loads on sleds [FPI 00], [GOD 00b].

The first solution is preferred for personnel movements, while the second solution is the only valid option for transporting significant loads. Without having carried out a precise estimation of weight, Marc has a good idea of the order of magnitude of the weight of the component products for the Antarctica Life Support Facility, which necessitates use of land convoys and exclusion of the Twin Otter option. The Twin Otter, which can transport eight passengers and their luggage, does however seem to be a very reasonable and relevant solution for transferring the OTL scientific team from Dumont d’Urville to the Antarctica Life Support Facility once it has been deployed and is operational. This choice implies a deeper analysis of the situation. The Dumont d’Urville station is located on an island a few kilometers from the continent itself. Convoys depart from the logistics base at Cape Prud’homme, on the coast a few kilometers from Dumont d’Urville. The crossing from Dumont d’Urville to Cape Prud’homme is carried out by sled during the winter months when the ice sheet is frozen or by boat during the summer. This point does not pose any problems as to the feasibility of the project and is judged to have a negligible effect on the schedule at this stage. The point therefore remains open for discussion for the moment and Marc does not go any further in his investigations at this time, judging that the level of knowledge of the system is sufficient at this stage.

5.3.5. Removing major risks

Prior to the decision to respond to this call to tender, Roger and Marc identified a certain number of risks that they consider to be major. One of their goals during this preliminary phase of engineering is to eliminate a certain number of risks as far as possible, or at least attempt to mitigate them. (For this, they have two strategies: the first is to reduce the possibility of occurrence, and thus “suffocate” risk factors; and the second is to reduce the potential impact of these occurrences on the project.)

When examining means of transportation to use for access to the final site, Marc recalls one of the identified risks: “inadequacy of the site chosen by the OTL laboratory for the implantation of a life support facility”. The precise location of the site was chosen following scientific criteria. Based on images and data produced by scientific satellites and on observation of the Earth, the OTL laboratory picked a site that they considered optimal in relation to their scientific mission, without looking at the capacity of the site to support life and facilities.

In the standard course of a project where products are to be installed at specific sites, Marc would request a preliminary site survey to check that the location corresponds to expectations. The commitment to a certain number of performances or operational characteristics depends on the effective configuration of the site; these performances were evaluated and estimated by analytical models, without necessarily considering the real parameters of the location. For example, the radioelectric environment (disturbances, presence of cables or antennae, etc.) or the presence of obstacles (mountains, buildings, etc.) might necessitate reconsideration of a link budget established and calculated using a certain number of hypotheses. This could thus invalidate the expected performance of the system in terms of the data exchange rate.

The possibility of flights between Dumont d’Urville and the planned site using the Twin Otter – which can operate over such distances and carry up to eight passengers – gives Marc an idea. Would it be possible to carry out a site survey after all? A small team with suitable measurement and observation materials could visit and qualify the site.

This possibility requires investigation. Such a course of action would generate costs, and due to the particular seasonal nature of the Antarctic climate would need to be carried out at a specific moment in time. It would, however, remove a major risk.

5.3.6. Facing identified threats

Marc discovers KAOS methodology through discussions with Anne. He is impressed by the rigor of the approach and the relevance of the results obtained. He therefore wishes to make use of this methodology to reinforce and improve his engineering approach.

KAOS methodology: obstacles and anti-models

The goal models constructed so far create a “positive” vision of the system. They describe the objectives expected of the system. Their refinement shows how the satisfaction of these goals may be objectively attained. They prescribe intentional behaviors of the system and result in prescriptive scenarios expressing the behavioral dynamics expected of the system.

The realization of these scenarios may be prevented or obstructed by obstacles. An obstacle to a goal is a condition that may prevent a goal from being fulfilled. An obstacle O is an obstruction to a goal B in relation to a domain characterized by a set of domain properties Dom if and only if:

The analysis of and search for obstacles is carried out using a resolutely “negative” or pessimistic view of the system goals, looking systematically for obstructions to the attainment of these goals.

If obstacles pose a threat to the satisfaction of a goal, then it is possible and desirable to reduce their effects or prevent these obstacles from acting on the system. This resolution is carried out via one or more goals that prevent, limit or correct the effects of an obstacle. These are known as protection goals.

The analysis of threats to a system may lead us to build anti-models of the system. A threat is a malicious use of the system, often by an agent that is hostile to the system. A threat is an obstacle situated and originating outside the system. It constitutes an anti-goal to a goal relating to the integrity, confidentiality, availability, reliability, etc. of the system. A method for the construction of antimodels is given in [LAM 04a].

The engineer will aim to counteract these anti-goals and vulnerabilities expressed in the anti-models, guarding against their effects by identifying means of protection or avoidance. At this stage, these do not constitute a solution but a prescription of the expected behavior, or “resistance”, of the system when faced with certain threats or vulnerabilities.

Marc knows that the deployment of a life support facility in a hostile environment such as the Antarctic is not without risks. The particular nature of the mission prevents:

– all changes to the schedule (constraints are linked to the southern summer);

– all modifications once the system is in place: only planned running repairs may be carried out. Design errors or the neglect of certain aspects could therefore prove fatal.

Marc must therefore do everything in his power to produce the most robust definition possible of the Antarctica Life Support Facility. He decides to apply the KAOS anti-model methodology. Here are some examples produced by his work.

From these last models, Marc is able to extract the following additional requirement for the life support facility: the facility must be able to provide the scientific team working outside the base with localization and navigation capabilities.

We clearly see here that this is not a solution (no details are given as to whether this localization and navigational assistance will depend on a GPS sensor, or on another technique), but a requirement. It may, moreover, be added to by operational and performance requirements relating to this: precision of localization, availability, autonomy, etc⁹.

5.3.7. Use of precise terminology

Marc has thus carried out or directed work involving the collection of information, analysis and reflection which he must now synthesize in order to create a reference list of technical requirements.

In the course of his investigations, Marc has become aware that his contacts use relatively precise terms and concepts, also found in the documents that he consulted.

As the purpose of technical requirements is to provide a relevant and understandable basis for the design community, Marc decides that he should synthesize and formalize these concepts to provide a terminology for use in the expression of technical requirements.

Once again, like Anne, Marc analyzes the domain and will produce a domain model.

For example, the following textual synthesis will allow him to establish an entity-relation model used to define terms linked to the domain of Antarctic transports.

“Heavy transport needs to cross in order to take containers of merchandise from the Dumont d’Urville station to the Antarctica site. A crossing is organized as a convoy and follows an itinerary. An itinerary is made up of a series of points of passage which may offer a storage area or an emergency assistance point. A convoy is made up of a team and a set of vehicles, either on caterpillar tracks or on skis: levelers, tractors and sleds”.

All of these concepts are formalized in the model shown in Figure 5.3.

This model acts as a terminological reference point for situations linked to the deployment of the base at its final site and the transportation (in both directions) of personnel.

5.4. Creating the list of technical requirements

5.4.1. Creating the necessary model

First, we should remember that the creation of a list of technical requirements does not consist solely of the reformulation of needs and expectations, but that it is the result of engineering work. This engineering work results in the construction of a “black box” (or very dark gray box) model of the system immersed in different contexts, from which we extract a coherent and complete set of technical requirements. This list constitutes the basis used by the design community and architects to seek and create an optimal solution.

A relevant model of the system at this stage must be constructed by adding, factorizing and synthesizing three main sources:

– Stakeholder needs in the “acquisition” sphere: the analysis and understanding of the needs, expectations and constraints of stakeholders, expressed through the specification. These generally cover the operational part of the system’s lifecycle and only include those stakeholders concerned in this operational phase.

– Stakeholder needs in the “supply” sphere: it is imperative that we integrate the expectations, constraints, habits and competences of the organizational environment. This includes not only the supply company at different levels (project, department/division, transverse cells – quality, buying, etc.) but also the surroundings: suppliers, partners etc.

– Initial knowledge of the capability of the final system to attain (or otherwise) certain key characteristics. A product of systems analysis work, often fairly rough, this is a first estimation or evaluation of certain performances or the efficiency of the system that allows us to place increased confidence in the feasibility of the system. To do this, we must begin to look at the solution. For this reason, in practice, models created at this stage cannot be completely and strictly “black box” in nature.

Figure 5.4 shows these three main sources for the creation of a relevant model for technical requirements engineering. All this must be carried out with an enlargement of the field of vision of the system and with consideration of the system throughout its lifecycle, including the design, development, production, launch and retirement phases, if these had previously been neglected.

Marc now has all the elements he needs in order to finalize his relevant system model for the creation of a list of technical requirements. This model covers the whole lifecycle of the Antarctica Life Support Facility. Like the models created by Anne in her requirements engineering activities, it includes:

– context models, from different perspectives: expected services and constraints, whether functional, physical, etc. These contexts are extended to cover the whole lifecycle of the system and situations that have not yet been identified. These will be aggregated using a model of the temporal breakdown of the system;

– goal models. Here, Marc has reinforced these models by an analysis of threats to and vulnerabilities of his system;

– domain models for the definition of concepts, artifacts and flows.

These “classic” systems engineering models will be supplemented by initial performance models allowing a rough evaluation or estimations to be made. For example, Marc will ask his teams to carry out their first performance reviews to obtain an order of magnitude on the mass and volume of the station, its consumption, the price, etc. He will also request external expert opinions to indicate the quantities needed for sustenance and hygiene by a human being in order to integrate this data into different reviews.

Marc is well aware that at this stage his model and knowledge of the system are not perfect:

– the performance models (analyses, simulations, etc.) used for the evaluation of the first performance reviews are full of incertitude and imprecision. They include a margin of error (and thus of unreliability);

– the results obtained are subject to hypotheses (see section 5.2.2).

5.4.2. Expressing the “right” technical requirements

As in the requirements engineering activities carried out by Anne, the creation of this model is indispensable. For Marc, it acts as a framework for reflection in order to create a relevant view of the system, for which he may verify certain “good properties” in a more or less formal manner: completeness, coherence, robustness, etc.

In the same way, textual expression – in this case of technical requirements – is carried out by quasi-direct extraction from the models, or at least by a reasoned reading of these models.

This expression of technical requirements must:

– be based on vocabulary and concepts formalized in the domain model;

– obey certain scriptural hygiene rules, such as preferring simple grammatical

constructions (subject + predicate), avoiding negations and passive forms, and using great precision when making statements in order to avoid the possibility of ambiguous interpretations.

The quality and relevance of the list of technical requirements lies essentially in:

– the succinctness of the set of requirements;

– the formalization of technical requirements;

– the structure of technical requirements.

5.4.2.1. Succinctness

All too often, we notice that the number of technical requirements at a given level (so for a given system, whether a sub-system of a suprasystem, or itself a system that will be broken down into sub-systems) tends to be too great, on occasion including over 1,000 requirements. This tendency is dangerous for a number of reasons.

First, it shows that the system team was unable to abstract and synthesize their system at the given level in an appropriate manner. It therefore considers the system as an assemblage of characteristics without necessarily identifying the main lines or essential characteristics: too much information and the information loses its value! This excessive accumulation of requirements tends to distance engineers from the tasks that make up the core of their work (reflection, calculation, analysis, synthesis, etc.) and forces them into management tasks. The central place occupied by requirement management, often to the detriment of requirement engineering, is lamentable. Strictly speaking, as shown above, engineering involves the constitution of a model of the system at the correct level of abstraction based on multiple information sources and activities.

Moreover, the increase in the number of requirements naturally results in an increase in the work involved in verification, with each requirement demanding individual verification¹⁰. This does not necessarily lead to increased profitability as the work involved in testing/inspecting/analyzing a system comes at a cost.

A reasonable reference point which any systems engineering team should aim to achieve is somewhere between 200 and 300 requirements, whatever the system under consideration and whatever the level of breakdown (or integration).

5.4.2.2. Formalization

The creation of a list of technical requirements is not a simple literary exercise. It demands the establishment of prescriptive (and not descriptive) propositions for the system with solid semantics. This may be obtained using:

– “controlled” or semi-formal language: based on strict grammatical and lexical rules and on formal elements such as pseudo-code, mathematical notation, etc.;

– requirement patterns: the capitalization of good practices (see especially [REG 09]) sometimes allows us to reuse solid and durable requirement constructions, with suitable adaptations;

– on occasion, formal languages based on mathematical logic: while their use is not yet sufficiently widespread, these formal languages are powerful when used on critical systems (guaranteeing certain vital properties) or on systems that still need to prove their conformity to regulations, for example in the context of certification [GAR 02].

This necessary quality of formalization must be carried out with one central goal: to make technical requirements objectively verifiable.

5.4.2.3. Structure

Given a reasonable but relatively high number of technical requirements, it is useful to structure these demands, i.e. organize them hierarchically.

It is also useful to categorize requirements using a typology: functional or nonfunctional (performance, operational, constraints, etc.). This cannot constitute the basis for structuring the list of technical requirements, however, as occasionally happens (producing specification documents structured by type, rendering global understanding by the reader almost impossible). Demands should be organized along central lines, following the vision seen to be the most relevant for the system concerned: missions, lifecycle, etc. We should be careful, for example, to group functional requirements and their non-functional characteristics (performances, constraints, etc.) together. We should avoid “scattering” requirements according to a typology that hides the links of coherence and dependence between these requirements. In other terms, we prefer to structure demands around a number of services (ideally around 7 +/-2 [MIL 56]) characterized by their expected QoS, or around stages of the lifecycle, or in another way depending on the particular nature of the system.

5.4.3. Compliance with the specification

Marc now has a complete set of technical requirements, ready for use as input for system design. This list of technical requirements is of an engaging and contractual nature and must be approved by the acquirers. For this, Roger asks Marc to produce a traceability matrix in order to demonstrate the compliance of the list to the specification.

While this exercise is standard practice, it poses certain problems for Marc. His list of technical requirements was established based on a model of the constructed system. This model itself was created not just from an understanding of the requirements and expectations expressed by the acquirers, but also from integration of the needs and constraints of the industrial development environment and the first results of system analysis.

This means that traceability between the technical requirements and the requirements and expectations contained in the specification is not direct, but indirect. It may be obtained by transitivity: a technical requirement comes from an element of the model, which itself may come from the analysis of one or more needs, but also from other sources. In other words, for a given technical requirement, this may come:

– entirely from consideration of the needs and expectations of the acquirers;

– from consideration of the needs and expectations of the acquirers and needs and constraints imposed by the industrial development environment, or from the results of systems analysis;

– entirely from consideration of the needs and constraints imposed by the industrial development environment, or from the results of systems analysis.

For Marc, the production of a traceability matrix, between the specification and the list of technical requirements, is a trivial exercise (a simple deduction by transitivity) and is achieved almost immediately. However, this matrix shows up “orphan” requirements (not extracted from the specification) and “composite” requirements (with their origins in both the specification and other sources); in addition, certain needs may be transformed through the constitution of the system model and its translation into multiple requirements. For Marc’s “inner mathematician”, this does not constitute a demonstration of compliance, even at an informal level. At best, it allows us to verify that each requirement has a potential translation in the list of technical requirements and, reciprocally, that each requirement comes from somewhere.

We thus see that the constitution and maintenance of this traceability information may be useful in supporting verification activities (detection of orphans, for example) and in information management (suspicion of impacts in the case of modification or development of an element). This cannot be considered a relevant means of validation (in this case, of technical requirements in relation to client requirements and expectations).

Being unable to provide formal proof and a mathematical demonstration¹¹, Marc chooses to use the following, rhetorical, demonstration technique: for each requirement or expectation expressed in the specification, he adds a textual explanation showing how this requirement is transformed into modeling elements; what system analyses were carried out to ensure its feasibility; and how these analyses and model elements were transformed into technical requirements. Marc may also take the opportunity to “color” the information, for example adding an estimated degree of compliance to the initial expression (total, partial, minimal or not compliant), or to its trustworthiness, risk level, maturity, etc., in relation to the objective attainment of the relevant requirement.

He may also proceed to carry out verification and validation activities¹² on the system model produced (this should be an obligation in the engineering process): the right system is modeled at the right level in relation to the right lifecycle. By verifying and validating the system model, Marc may claim to have obtained a relevant, complete, coherent and realistic set of technical requirements and can claim to have correctly accounted for the needs and expectations of the client at a global level.

5.5. Things to remember: technical requirements engineering

In their attempts to obtain and create a contract with the OTL laboratory, Roger and Marc have carried out requirements engineering activities, among other things, to define a list of technical demands upon which their solution will be built (Requirement Analysis in ISO 15288).

As with all technical engineering activities, this is an activity of (i) transformation (ii) based on reasoning (iii) producing added value:

(i) transformation: from the expressed (or hidden) needs and constraints of all stakeholders (including the expectations of clients and users, expressed through the specification and consideration of the constraints imposed by the real environment in which the system is developed) to a reference list of technical requirements that act as a basis for system design, contracting between the acquirer and suppliers and the verification/acceptation of the system;

(ii) based on reasoning:

(iii) producing added value:

5.6. Bibliography

[ATS 59] ATS, Antarctic Treaty System, www.ats.aq/e/ats_treaty.htm, December 1959.

[CIR 98] CIRRUS S., Discovery of design methodologies for the integration of multidisciplinary design problems, PhD Thesis, Worcester Polytechnic Institute, Worcester, 1998.

[FPI 00] FPI (French Polar Institute), Concordia: A New Permanent, International Research Support Facility High on the Antarctic Ice Cap – Technical Overview, Brest, 2000.

[GAR 02] GARION C., Apports de la logique mathématique en ingénierie des exigences, Doctoral thesis, École Nationale Supérieure de l’Aéronautique et de l’Espace, 2002.

[GOD 00a] GODON P., CUCINOTTA N., “Concordia: a new permanent, international research support facility high on the Antarctic ice cap”, Proceedings of the 6^th International Symposium on Cold Region Development, pp. 72-75, Hobart, Tasmania, January 31- February 4, 2000.

[GOD 00b] GODON P., Concordia Project – Information on the Surface Transport System set up for Servicing the Dome C Site, French Polar Institute, Brest, France, 2000.

[ISO 08a] ISO, Systems Engineering, System Life Cycle processes, ISO/IEC 15288:2008, ISO, 2008.

[LAM 04a] VAN LAMSWEERDE A., “Elaborating security requirements by construction of intentional ant-models”, Proceedings ICSE’04, 26^th International Conference on Software Engineering, Edinburgh, ACM-IEEE, May 2004.

[MIL 56] MILLER G.A., “The magical number seven, plus or minus two: some limits on our capacity for processing information”, Psychological Review, no. 63, pp. 81-97. Harvard University, 1956.

[MOU 10] MOUELHI O., Contribution à l’optimisation multiobjective en conception multidisciplinaire, Thesis, Institut National des Sciences Appliquées de Lyon, France, 2010.

[PMI 09] PMI (Project Management Institute), A Guide to the Project Management Body of Knowledge (PMBOK® Guide), PMI, 2009.

[RAS 83] RASMUSSEN J., “Skills, rules, knowledge; signals, signs, and symbols, and other distinctions in human performance models”, IEEE Transactions on Systems, Man and Cybernetics, no. 13, pp. 257-266, 1983.

[REG 09] REGAL, Requirements Engineering Guide for All, www.incose.org/REGAL, 2009.

[SCA 04] SCARAVETTI D., Formalisation préalable d’un problème de conception, pour l’aide à la décision en conception préliminaire, Thesis, École Nationale Supérieure des Arts et Métiers, Paris, France, 2004.

1 Chapter written by Olivier KLOTZ and Jean-Luc WIPPLER.

1 Not to be confused with system integration, a process or stage in the system lifecycle (see Chapter 8). On the other hand, “integrator” should not be understood as “no engineering, just sticking components together”!

2 A non-negligible part of project management consists of communication.

3 Planning in the broad sense of the organization of activities to be carried out, not in the restrictive sense of a schedule.

4 We consider that external interfaces are dependent on needs (problem domain) and that they will be dealt with separately.

5 PBS: Note that this denomination is dangerous and can lead to confusion for a number of reasons. In certain contexts, PBS stands for Project Breakdown Structure instead, and certain standards define a system structurally as a set of products [EIA 98] mixing and confusing a system vision and a product or service vision. We prefer to use the term BoM (Bill of Materials), as used in [PMI 09].

6 This may, notably, allow the creation of bottom-up estimates when attempting to estimate project costs in the early phases.

7 Note that certain methodologies extend the notion of product tree to all project deliverables and not just to the breakdown of the final system (or product). The tree defined in this way is thus easier to use when constructing a WBS, but remains ambiguous for the inexperienced (and sometimes even experienced) user, who naturally limits the product tree to the breakdown of the final product, leaving aside other activities that are just as important and costly in terms of time and money. The goal here is to construct the WBS for the project in the sense of the PMBoK (Project Management Body of Knowledge) [PMI 09] (hierarchical breakdown, focused on deliverables, of the work which the project team must carry out to attain project objectives and produce the desired deliverables). From the point of view of the project, the passage via a product tree is not a methodological necessity as the WBS is already a breakdown focused on deliverables – the “products of the project”.

8 These integration, verification and validation (IVV) “phases” will be covered and clarified in Chapter 8.

9 Note: often, when this exercise is given to students or interns, the obstacle “polar bear attacks” appears as an obstruction to “movement outside the base”. This threat seems relevant, and is indeed a genuine threat… in the Arctic.
Remember that there are no bears at the South Pole. Polar bears live in the region around the North Pole, on the edges of the Arctic Ocean. Incidentally, the name “Arctic” comes from the ancient Greek άμЙρκτος (árktos), meaning “bear”, in reference to the polar bear. The names of the constellations Ursa Major and Ursa Minor, situated near the celestial North Pole, also refer to this fact. The word Antarctic, however, comes from the Greek άνταρκτικός (antarktikós), which literally signifies “opposed to the bear”.
Polar bears are therefore found in “Bear Land” (the Arctic) and not in Antarctica. The Antarctic is populated mainly by birds, including penguins, and seals, concentrated around the sea board (there are very few animals inland).

10 Using verification techniques, such as testing, analysis, demonstration or inspection.

11 This is clearly illusory here, as we would require a formal expression – i.e. expressed in a formal system, such as mathematical logic – of needs, expectations and technical demands, then we would need to demonstrate, in the mathematical sense of the term, the equivalence of the two representations, i.e. prove that the technical requirements are truly a refinement of the requirements and expectations. This is possible using formal specification methods (Z, B, etc.), but their use is not widespread and limited mainly to hyper-critical systems.

12 See section 8.1 for a precise definition of these terms.