# Managing Requirements: For an Integrated Approach from System Engineering to Project Management

Michel Malbert, Daniel Estève, Claude Baron, Philippe Esteban, Rui Xue

► To cite this version:

Michel Malbert, Daniel Estève, Claude Baron, Philippe Esteban, Rui Xue. Managing Requirements: For an Integrated Approach from System Engineering to Project Management. IFIP International Conference on Advances in Production Management Systems (APMS), Sep 2014, Ajaccio, France. pp.142-149, 10.1007/978-3-662-44739-0_18 . hal-01284568

HAL Id: hal-01284568

https://hal.science/hal-01284568

Submitted on 7 Mar 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Managing requirements: for an integrated approach from system engineering to project management

Michel Malbert¹, Daniel Estève², Claude Baron²,³, Philippe Esteban²,⁴, and Rui Xue²,³

¹Consultant, 24 rue Cartailhac, 31000 Toulouse, France
michel.malbert@outlook.fr

²CNRS, LAAS, 7 av. du colonel Roche, F-31400 Toulouse, France
{daniel.esteve, claud.e.baron, philippe.esteban,
rui.xue}@laas.fr

³Univ de Toulouse, INSA, LAAS, F-31400 Toulouse, France

⁴Univ de Toulouse, UPS, LAAS, F-31400 Toulouse, France

**Abstract.** This paper puts forward several evolutions in methodological approaches to « project management». Firstly, it aims to bring closer the founding models of different engineering approaches including systems engineering and project management recommendations to allow for a greater continuity and enhanced management coherence, from beginning to end of the project. It focuses on operating a generic process, called DECWAYS, based on handling management requirements: (1) analyze the requirements to arrive at a complete inventory of the final product ; (2) associate with each one of these requirements, an « indicator » setting a target objective for completion, supplemented by a risk function detailing the risk at hand based on the deviation relative to this target objective; (3) share and allocate the responsibility for requirements follow-up between the project team leaders; (4) organize and coordinate the follow-up of these indicators throughout the product development as proof of a good work management and, (5) finally, validate the total completion of the target objectivesthrough the final prediction/completion conformity of these indicators. Based on this, several operational recommendations are explained and the practicality of DECWAYS embodying these principles is demonstrated using an experimental example for the design/planning of an electronic key.

**Keywords:** System Engineering, Project Management, Collaborative Engineering

**Introduction:** In terms of « system », innovation defines an issue which is very difficult to address and still open to methodological progress in the management of multidisciplinary and complexity, prerequisite for success at all levels of the innovation process: from project definition and design stages to the finished product's send of life cycle. This issue is therefore grounded in all scientific and technical approaches built around this system innovation: « system engineering» which purports to formalize
and comprehend the design of complex systems; «project management» which aims to
organize step by step the smooth operation of project development (or program devel-
opment when several projects have to be coordinated); «collaborative engineering»
which intends to facilitate, optimize communication between all actors and therefore
contribute to meeting coordination needs... Naturally, to master the difficulties inhe-
rent in multidisciplinary, it is first assumed that these various inputs get progressively
aligned through a single "integrated" approach. These alignments are being carried
out and have already given rise to meetings and joint documents [1, 2, 3]: they define a
path of progress through terminological adjustments and a standardization of processes
which will necessarily have to cut across various fields. This path is slow and arduous
if only for the reason that it must be constructed on the operational ground, that of the
company... Here, a more conceptual path is being proposed to move forward: we
intend to rely on an innovation process, a unique federating process built on manag-
ing «systems requirements» only: this overall system development-innovation process
can be defined as the set of basic processes enabling us to organize and handle the full
completion of specifications and requirements, from the product definition phase to
the product's end of life cycle... The prerequisite for success is that system require-
ments are complete in the sense that they have to address the whole innovation-
development process one intends to manage: for simplicity's sake it is assumed that
these requirements can be presented in the form of a List (R1, R2...). Based on these
considerations, DECWAYS propose a complete innovative generic process build on
the idea of sharing the requirements follow up between three specialized leaders (ex-
ecuting, controlling and planning), for structuring a permanent coordination. The
presentation develop successively: the question of requirements to arrive at a com-
plete inventory of the final product ; the association with each one of these require-
ments, an « indicator » setting a target objective for completion, supplemented by a
risk function detailing the risk at hand based on the deviation relative to this target
objective; the information system which organize and coordinate the follow-up of
these indicators throughout the product development as proof of a good work man-
agement. Finally, we illustrate a first step of DECWAYS development on an experi-
mental example for the design/planning of an electronic key.

1 Requirements, the foundation for a «product» development follow-up process

Requirements analysis is a ‘critical’ input at the start of an innovating project: based
on the results of this analysis are all the prospective assessments that will play such an
important part in the decision to launch the project... And it is worth underlining here
how important these results are in the drawing up of a management methodology
which on the basis of a complete inventory of these requirements, supports the defini-
tion of a consistent approach for product development construction and manage-
ment. This approach consists of the following steps: (1) Analyze requirements to ar-
rive at a complete inventory of the product life; (2) Associate with each one of these
requirements an ‘indicator’ setting a completion target objective, supplemented by a
risk function detailing the risk at hand as a function of the deviation relative to that
target objective; (3) Assign responsibility for requirements follow-up among the
project team leaders; (4) Organize the follow-up of these indicators throughout product development as proof of a soundwork management; (5) Finally, validate the full completion of the target objectives through the final prediction/completion conformity of these indicators.

<figure><img src="image_2.png" /><figcaption>Fig. 1. Requirements-based project management</figcaption></figure>

It appears that a requirements-based management lays the groundwork for a generic and complete project management process: generic because it does not imply that the nature of the project be specified as it may be a product or service; complete in the sense that it arises from an expression of ideas and objectives, through requirements and these target indicators, and finishes with an ending «selected» by the degree of conformity of the work result with these target objectives. Our ambition is to propose a «supervision system» associated with an «information system» related to this generic process whose assignment is to provide information and monitor automatically the evolution of “indicators” values throughout the work: thus emphasis is placed on the choice and quality of these indicators which more than ever must be fully defined, measurable, traceable and documented...

## 2 Indicators

In the approach put forward, **indicators** are directly associated with the requirement of which they are proof throughout the development work. Under this assumption, their evolution from the initial situation to the target objectivemust be programmed using milestone target valuesin relation to the overall progress of the development work. Let us call Δthe deviation, at a given step t,between target value and current value, our proposal being to associate with this deviation a «**risk function**»for the project. In most cases, this function will pertain specifically to the corporate policy and will therefore be perfectly known to all actors. Our recommendation is that, at the very least, this function, which will be involved in the decisionchoices, be concerted at the start of the project and then have its full part in the decision phases. In practice it may take the simple form of a conventional risk scale, typically Δ be-
tween1 and 7, to calibrate the response between a low level of risk and a serious dan-
ger of failure. Indicators are simple and straightforward if they reflect requirements
such as timelines, expenditures and certain performances, but they may also result
from an aggregation of data selected following discussions to narrow down the num-
ber of parameters to be followedin the progress of the work or to express more clearly
the corporate policy. These indicators will be computed online by the information
system. In practice, the approach we recommend consists in collecting and recording
during a step assessment (milestone) all indicator data on a «management dash-
board» comparing the current reality with the «strategic dashboard» drawn up in-
itiallyby the project management team. Any deviations found may then lead to man-
agement correctiveactions partly guided by the risk functions analysis. This point is
key for a sound management of the project and actors must necessarily be coordinated
to ensure pertinence, coherence and efficiency in their corrective choices. In these
choices, the corporate policy plays a decisional role which should already be known
to all, given the calibrations of risk functions selected for each requirement. One may
question the genericity of the proposal as a function of specificities in the choice of
certain preferred industrial management options: for example, can this approach be
applied indifferently, for a «conventional top-down»management andan «agile» ma-
nagementof project: in the latter case, the alignment of milestone deadlines and the
need to factor in an added value foreach one does not call for a change in the ap-
proach: at each new step in the project breakdown, a limited number of selected re-
quirements will guide in the management of the new step, once the results of the pre-
vious step have been achieved.

3 **Information system**

<figure><img src="image_3.png" /><figcaption>Fig. 2. Information system</figcaption></figure>

During project development, a requirements-based management will basically consist
infollowing up the indicators throughout the project life: thus any deviations in terms
of completion between the current progress and the target objective initially defined
by the requirements will be detected. Thus, looking at all the indicators (dashboards)
one can accurately monitorthе evolution of the project and detect at the earliest any
possible drift relative to the target objectives and possible errors in operational management: this can be achieved by programming milestones or alternatively, it may spontaneously follow a project management decision to intervene. For complex projects necessitating a task breakdown, task managers will receive their roadmaps on the basis of a project requirements assignment and will be able to organize their task developments in accordance with our recommendations. Together they will have to complete during the milestones their progress file stating to senior management any progress that has been recorded under their guidance. An information system is essential for the collection and storage of all useful data: organizational choices, target data, current data, management decisions and exchanges between the different actors.

## 4 Supervision (DECWAYS)

Improving the methods and tools in project management is an industrial imperative-early identified in the reviews dealing with assessment study: successes and failures of a large sample of projects. Here our ambition is to improve the dysfunction detection approach in project management and the ability of all project actors to coordinate their involvement. The idea is to propose a structured path for the actions to be carried out by apportioning the requirements follow-up tasks between a defined number of managers and thus oblige the latter to structurally make concerted decisions. This principle is supplemented by the choice, for project management, of a supervision system approach based on an automated detection of deviations or malfunctions during programmed management, by risk analysis in the choice or corrective decisions and by a systematic storage of all decisions made. This choice should facilitate implementation in practice since monitoring does not call for a modification of the tools already in use in companies but «only» to make them communicate towards the proposed procedures. These proposals lead in turn to the proposal of a new tool: DECWAYS. DECWAYS intends to provide the company with a method and a tool for supervision, coordination and decision support during the management of development projects: **Supervision**: this function is designed to detect and characterize systematically and automatically any erroneous trends and possible errors in design and management throughout project development. **Coordination**: this function is designed, following detection of the malfunction or deviation, to «oblige» the collegial body made up of a limited number of managers to consult each other on their structurally complementary points of view, and to propose a corrective consensus in accordance with the common objective of achieving success with the project. **Decision support**: this function which aims to support the diagnosis of the cause for the difficulty encountered and to formulate a corrective approach which anticipates the compared «risks» of the different solutions proposed by the limited number of partners in charge. DECWAYS is built around a conventional supervision system architecture[4]: measurements are regularly obtained from the system and compared with reference values. Any deviations found can then be used to check the proper functioning and detect possible «failures». But that can only be done if the reference values, that is the correct functioning model, are «fair». In practice, there exist two options: one is an empirical based on value learning during periods of correct operation, the other relying on a theoretical model. In terms of project management, the model is neces-
sarily theoretical: it results from an initial modeling which is predictive of the project
progress.

<figure><img src="image_4.png" /><figcaption>Fig. 3 Project supervision project: « DECWAYS »</figcaption></figure>

5 Example of DECWAYS implementation and application to the
design of an electronic key

Basic rules [5] condition the development of specialized tools furnishing supervision, coordination and decision support in project management. However, it turns out that these expert rules are in part the result of work conducted within the framework of the contract ANR/ATLAS [6] in which the three salient features of DECWAYS were being explored :supervision, coordination and decision supportthrough the concept of risk functions associated with the deviations between current data and target objec- tives. A first result of this experiment: it is imperative that design and planning man- agers share the same Work Breakdown Structure (hereafter ‘WBS’) for the project. This structural framework formalizes and organizes exchange, coordination and deci- sionneeds shared at each level(milestones). A supervision software mockup [7] has been developed with an industrial support which validated the practicality of the ap- proach. It is being investigated in depth in order to create a newDECWAYS toolin- cluding the previous proposals and puts forward a generalization of the notion of indi- cators inorder to take into account the strategic objective of standardization between system engineering andproject management processes.The toolATLAS has been in- vestigated within the framework of an «electronic key» projectfollow-up for the au- tomotive industry. Look at Fig. 4 below: it depicts at the instant considered,the logic- breakdown tree for theproject’s system design with a review of possible solutionsin the case of a key-detector couple. The project management tree remains the same. This homomorphy results from the step-by-step construct logic reliant upon the gener- ic process and illustrated in Fig. 5.
<figure><img src="image_5.png" /><figcaption>Fig. 4.– The electronic key project « Sésame»</figcaption></figure>

The generic process relies on the general idea that it is possible, on the basis of the initial set of specifications and its embodiment in requirements and therefore in indicators under constraints, to draw up derivative specifications and requirements for a group of subcontractors in charge of part of the project. Of course all this applies to the design as well as to management and should not lead to any loss of information. Coupling design and management processes is achieved by pooling together a number of indicators (allowing thus for the detection of any inconsistencies between the two parties) and sharing decisions (eg, the decision to define a subcontractor workpackage calls for the approval by both partners as to the technical objectives and the means provided to reach them). Example of a situation handled by ATLAS: consider a joint design and management indicator, Nhthe total number of work hours to reach the objective assigned to a subcontracted workpackage. This value is set by the prime contractor and assigned as objective to be reached by the subcontractor's management. The subcontractor's design will assess this value and submit the result to his management colleague: in the event of a dispute they will either look for a solution acceptable to them or contact the prime contractor to negotiate a settlement. Indicator values are known at each tree node (nodes being depicted as small squares in Fig. 4). Therefore it is possible to know the state of the system at each tree node via the associated dashboard: this information along with the formalized collaboration between these two major functions “design” and “management” are both a diagnostic support and beyond, a decision support. Note that the dashboard associated with a node yields for an indicator the local value and the aggregate value fed from the tree branch concerned This feature allows management to choose between several solutions the one which yields for example the best result for a key indicator. An operational prototype ATLAS has been drawn up and allows us to check 1/ the feasibility of the design – management coupling, 2/ the support in choosing the right solutions for the electronic key problem, 3/ the relevance of the choice of thin client-Web technology as an implementation environment.
<figure><img src="image_6.png" /><figcaption>Fig. 5.-Tree construction principle</figcaption></figure>

**Conclusions:** Improving the methods and tools for project management is an industrial imperative that has been clearly identified in the analyses dealing with assessment reviews, successes and failures of a large sample of projects. The aim of the proposals made in this paper is to improve coordination and cooperation between all project leaders. The idea relies on putting forward a generic process built on the thorough management of the system requirements which is then used to build up information and supervision system referred to asDECWAYS. Thanks to a generalized follow-up of « indicators », this system supports automated detection of any deviations or malfunctions in the programmed management, risk analysis in the choice of corrective actions and systematic storage of these decisions... These proposals lead in turn to the proposed use of an existing tool DECWAYS which does not call for any modification of the tools already in use by companies but «simply» to have them communicate (information system) towards the proposed procedures. A simple example of a first development shows the feasibility and confirms the interest of the approach.

## References

1. A. Sharon, O. L. de Weck, et D. Dori, « Project management vs. systems engineering management: A practitioners' view on integrating the project and product domains », *Syst. Eng.*, vol. 14, n° 4, p. 427-440, 2011.

2. E. Conforto, M. Rossi, E. Rebentisch, J. Oehmen, et M. Pacenza, « Survey Report: Improving Integration of Program Management and Systems Engineering », MIT Consortium for Engineering Program Excellence, 2013.

3. « Systems Engineering – Project Management (SE – PM) Working Group — INCOSE Chesapeake Chapter of INCOSE ». [Online]. Available on: http://www incose-cc org/2012/04/systems-engineering-project-management-se-pm-working-group/ [last consult: 27-feb-2014].

4. S.BONHOMME, E.CAMPO, D.ESTEVE, J.GUENNEC, « Methodology and tools for the design and verification of complex systems », IS'08, Varna, Sept 2008, pp.24-2-24-7

5. M. Malbert, D. Estève, C. Baron, R. Xue, P. Esteban « DECWAYS, une nouvelle étape dans les approches de la conduite de projet », LAAS-CNRS, 2014 (in press)

6. ATLAS « Aides et assisTances pour la conception, la conduite et leur coupLage par les-connAissanceS », Contrat ANR programme « Technologies Logicielles » 07-TLOG-002-05, 2007-2011.
<figure><img src="image_7.png" /></figure>