Seamless requirements management during development process
Mohamed BOUALI, Hycham ABOUTALEB, Samuel BOUTIN Knowledge Inside (KI)
7C Rue Jean Mermoz, 78000 Versailles, France Tel. +33(0)1 39 02 70 29 – Fax. +33(0)1 39 51 90 66
Abstract
In a purpose of efficient requirement management, the company Knowledge Inside (KI), through its software arKItect® has implemented different requirement management methods. This paper aims at showing different items contributing to requirement management activities as proposed and implemented by KI in several industrial projects. Authors limit their contribution to practical issues in requirement statement, refinement, verification, validation, etc. and the close connection between requirements management processes and other processes in the system development cycle. Then, different representations (or modeling) of requirements: as objects, as flows and hybrid representations will be treated. The choice of one representation instead of another implies some consequences that will be shown.
Key words
Requirements Management, Refinement, Traceability, System Engineering
1 Introduction
In a very competitive context characterized by systems complexity increasing coupled with time/costs pressure on systems development, the use of structured methods to complex systems design becomes unavoidable. Incremental complexity of actual industrial systems and their integrated multidimensional modular design has led to the need of an optimization of the design process to get “the right product at the right time”. Consequently, one of the primary measures of success of a system is the degree to which it meets the purpose for which it was designed and produced.
The System Engineering (SE) methodologies seem to be the only way to reach efficiently nowadays systems design. When performing SE processes, the requirement engineering activity rises as a
central issue that deserves particular attention all over the development process. Requirements Engineering (RE) is the process that enables identifying this purpose, by identifying the stakeholders, their needs and their expectations, the environment and its constraints, and enables documenting this process in a way that is easy to use communicate and implement. Stakeholders’ needs, expectations, and environment constraints lead to a set of functional and non-functional requirements the system to design shall meet to be considered successful. However, the process has to be rigorous in order to ensure these system requirements completeness, non-ambiguity and consistency.
In the industrial context, many studies (like the Standish group report 2009) show that requirements engineering constitutes an Achilles’ heel of the system development process.[STAN 09]
Requirements engineering is concerned with the elicitation, specification, and evolution of the objectives, functionalities and constraints a system should meet within its environment. This task has a critical impact on system quality. Requirements related errors are widely and recurrently recognized to be the most frequent, expensive, and dangerous types of errors. The most serious error types include incomplete, inadequate, inconsistent, or ambiguous requirements.
Requirements-related errors are the major cause of project cost overruns, delivery delays, failure to meet expectations, or degradations in the environment interacting with the system to design.
Besides, since the product is more and more detailed during development process, requirements are accordingly refined: Requirements Engineering is a process that is iterative, and spans the whole development process or even the whole lifecycle: it is not a single phase that is completed at a certain point in the development process. This implies that a continuous information management is necessary to manage the evolution of the requirements during the whole process. This would support considerably the development process.
This paper, organized into three main sections, attempts to illustrate key features on requirements management as designed and implemented in Knowledge inside (KI) using the software arKItect®.
The first section is dedicated to show some key issues in requirements management. It illustrates nowadays industrial practices, several recommended practices and some implementation/deployment requests. The second sections makes a focus on arKItect® technology and the recommended requirement centric methodology to apply when designing a complex system.
The third section shows a practical implementation using a deployed meta-model which implements the presented methodology. The paper ends with some conclusions and perspectives.
1. Key issues in requirement management 1.1 Overview of current industrial practices
The application of efficient requirements management processes in industrial environments hits
are spreadsheet-like. They are almost hundreds, even thousands, lines long and all information relied to the requirements stored in such tools are described using text and natural language.
Consequently, they are very fastidious to edit and to maintain, and they induce some uncertainty due to different possible interpretations of the requirements description texts. Text-based tools are sequential and often suffer of either ambiguity (sentences being inaccurate) or being hard to process (too many sentences for one requirement/concept); while graphical tools are multidimensional (at least bidimensional) with diagrams containing implicit information that can be easily drawn by the user (mainly due to intuitive representation semantics).[LARK 87] On another side, Requirement management activities are almost disconnected from the other design and development activities.
This situation leads to impossibility to keep coherence between requirements themselves and between requirements and development steps like functional architecture, physical architecture, and simulation. In these conditions, the designed systems cannot fulfill the expected needs. [BROY 10]
1.2 Some recommended practices
To meet the purpose of efficient and seamless requirement management, some standards, like ISO 15288 [ISO 15288] and the INCOSE SE Handbook (for system engineering) [INCO 10] or ISO 26262 (for road vehicle safety) [ISO 26262] made recommendations which are summarized in the following items:
1. Requirements capture customer needs: a wrong statement, comprehension or formalization leads eventually to a product which couldn’t satisfy initial purposes of the system.
2. System architectures design driven by the requirements refinement: all functionalities and characteristics that the system has to fulfill are expressed via its requirements.
3. During the development cycle, requirements are stated very early and verified/validated late (via validation plans for example) so the process shall implement efficient traceability.
4. Requirements management needs to be coupled and integrated with SE to avoid discontinuity between processes.
5. Representation needs to be adapted to manage the complexity due to high number of requirements and to be intuitive to the engineer.
1.3 Deployment requests
When an organization decide to implement the Requirement Engineering task, the deployment appears as very difficult for the following reasons [LAM 08]:
1. Multiple stakeholders having different background, interests, and expectations need to cooperate. Their concerns are generally partial and often conflicting.
2. There are multiple transitions to handle. The system environment is informal whereas the system to design is formal. We need to move from partial, unstructured collections of sometimes inconsistent statements to a complete, structured set of consistent requirements.
Hidden, implicit needs and assumptions must be made explicit. Imprecise formulations must be converted into precise specifications.
3. The environment may be unfamiliar. While investigating it we need to consider two system versions: the environment as it exists before the system to design is added to it, and the environment as it should be when the system will operate in it.
4. A wide spectrum of concerns must be addressed, ranging from high-level, strategic objectives to detailed, technical requirements and assumptions. Different levels of concern are often intermixed.
5. For system robustness and requirements completeness, we need to anticipate the unexpected –including hazardous or malicious environment behaviors. The scope of such investigation may be hard to delimit.
2 Ergonomic requirements-driven design
To give an answer to the issues stated before, Knowledge Inside, through its tool -arKItect®- and experiments, proposes a solution for efficient and seamless requirement management. This solution is “system architecture centric” which means that all activities related to the system design are gathered in the same representation space. The two main items of this proposition are: 1) Keep close connections between all activities of the system design/development including requirements management, functional architecture, system architecture, ready-to-simulate models, etc. ; 2) Offer a more ergonomic and intuitive human interface. In this section, a brief presentation of Knowledge Inside and its tool (arKItect®) is given and then the focus is made of the presentation of the requirement centric methodology.
2.1 Brief presentation of KI
Knowledge Inside (KI) was created in January 2006. It is a CAD tool editor specialized in System Engineering (SE) with the objective of designing simple and ergonomic SE environment. The main edited product is arKItect® software. KI was founded by a Renault Engineers team cumulating more than 50 years experience in system design area. Its president and CTO is Mr. Samuel Boutin.
KI is about 20 collaborators able to support clients in arKItect® deployment projects for complex systems modeling. After 5 years implementation, the teams get an experience feedback allowing it to propose organizing for the implementation of system designer activity.
Beyond the system experience of different actors, Knowledge Inside developed for its own need, through participation to collaborative projects, referential systems models for different systems which are especially used for its courses. This includes simulation models (based on Matlab/Simulink blocs) allowing the implementation of “Model In the Loop” approaches from a functional architecture.
2.2 Brief Presentation of arKItect®
ArKItect is a software tool for the representation and design of systems, designed to assist users in the implementation of the key processes of Systems Engineering (SE). It offers a support to the activities of requirement management, functional analysis and system decomposition, analysis of the risks, management of the costs, project management. It is particularly adapted to the implementation of Systems Engineering steps corresponding to standards such as ISO15288 and ISO6150. Thanks to its flexible multi-scales modelling features, it makes it possible to define diagrams where coexist at the same time: 1) the representations of principal or derived requirements; and 2) architectures and the solutions or the alternatives of solutions.
2.2.1 arKItect® features
arKItect® is a software tool for representation and design of systems. arKItect® was developed to assist in implementing the key processes of system engineering.
It is a graphical multi-scale tool (It is commonly said that a picture stands for thousand words) for defining Diagram Domains Specific Languages (DSL) and using them in different applicative domains.
[LARK 87] arKItect® Diagram Domain Specific Language is made up of three layers: D2, D1 and D0 layer.[LANG 05]
At the D2 level, the Type Diagram describes the properties of the objects types that are used in the model. It also describes the relationship between these objects types (hierarchy)
At the D1 level, a Tree View Diagram describes the model elements to be displayed with their layout properties. This description respects the relationships defined by the Type Diagram.
At the D0 level, we have diagrams expected by end-users in their modeler.
Given the application domain and the size of the project, the environment needed for development and the way people work can vary a lot.
Therefore, arKItect® is a framework to develop system development tools and the three levels, D2, D1 and D0 are supported by the framework together with a user administration tool allowing granting a variety of access rights to the different users. arKItect© is funded on an evolution of the object model supporting a different approach to flows representation and handling. We call it a relational object model because flows between objects are first class citizens. The theoretical added value of this object model is that all the DSL are built upon very few features, in comparison to UML or other derived languages. Of course, the more diagrams are added, the more difficult it is to master a DSL. [COLE 10]
Our experience is that given the application domain and the size of the project, the environment needed for development and the way people work can vary a lot.
Last but not least, the tool is open, a python script is available and can be executed on each object or a diagram. This feature is used to import/export Microsoft Office documents and is typically used for documents generation.
To summarize, arKIitect® is a meta language definition system, a diagram definition system and a modeling tool. The language is formed of a very compact syntax allowing to specify diagrams and many others as needed for DSL design.
2.3 Requirement centric system engineering
The system engineering based on requirements management, as proposed by KI, is divided into the following four steps:
1. Requirements Statement
2. Functional and system architecture (rational associations) 3. Solutions prospecting (existent representation)
4. Interface with the simulation environment for solutions evaluation
The items 1) and 2) are “top-down” steps. It means that the starting point is a concept (which can be totally generic) that can be refined in an iterative process. The steps 3) an 4) are bottom-up. It means that these steps reuse existing basic blocs to be performed.
The first step of the process gathers all the requirements expressed by stakeholders in a concept system (we talk here about a system as concept and not as product). [NUSE 00] This step is very important because it is the basis of all what follows and conditions highly the remaining process.
Consequently the input requirements have to be as complete as possible. This step is illustrated in Figure 1.
Concept System
Req Req Req
Req
Req
Stakeholder 1
Stakeholder n Req
Req
Figure 1: Requirements Statement
The second step, functional and system architecture, is performed using the result of the previous step. The concept system (including requirements) is split using defined criteria, called “Rational”, into subsystems. Each subsystem corresponds to a function that the system has to perform. This operation is done iteratively, means that each subsystem can be split hierarchically into lower level subsystems. This decomposition induces appearance of complementary requirements, called
Interface requirement, that link different subsystems that have to be linked. Figure 2 illustrates this step.
Concept System
System_sub1
Req Req Req
System_sub2
Req
System_sub3
Req
Req Req System_
sub3.1
Figure 2: System splitting and refinement
In the third step, Solutions prospecting, the link to the real word has to be established through listing different existing options that can be given to implement the concept system resulting from the previous described works. Ones an existing option listed, it has to be represented (using right meta- model structures) in that way to be integrated into the model. The identified options can be associated (allocated) to different system levels and/or they can impact different subsystems perimeters. So, a major task to perform at this stage is to elaborate the association and selection criteria. Theses last ones influence the system in many ways, especially by appearance of new requirements (induced requirements) which can be the completion or the link between the initial abstract requirements and the realistic selected options. The last step, Interface with the simulation environment for solutions evaluation, characterizes the “accosting” task, means that simulation blocs are injected in the system through input/output interfaces. The system has the role of integration tool that can take heterogeneous simulation blocs which run together following a previously defined strategy. So, the system can allow a simulation scheduling taking in account system architecture and its requirements (functional, dysfunctional, interface and performance).
3 Case study
The practical example discussed in this paper is inspired from projects performed in collaboration with French vehicle manufacturers. Due to the confidentiality, the example is simplified to protect restricted data. An electrical vehicle development is taken as an example for the integrated requirement engineering/system engineering approach with arKItect®.
First of all, RE requires a data model that enables structuring the data that is shared by all the actors.
The defined Meta Model integrates all the elements necessary for a complete system development process that includes the following steps:
• Customer Needs Capture
• System Life Cycle Definition
• Top Requirements Statement
• Top Functions Identification
• Functions Definition
• Requirements & Functions Refinement
• System architecture definition
• Functions allocation upon system/subsystems/components
• Physical interface definition and flow allocation
• Requirements allocation upon systems
After documentation, discussions, prototypes, beta versions and upgraded versions, we obtained a Meta Model, which the process is illustrated in Figure 3, based on the INCOSE SE handbook. Figure 3 shows different views and seamless transition from one to the other (filtering) and their link with the steps of the process. In this Meta Model, decision made to represent “requirements as flows” (of information) from upper level to lower levels. The other way that could be used to represent requirements is “requirements as objects”. The implications of this last requirement representation will be discussed later.
Figure 3: Process view of INCOSE handbook-based meta model
3.1 Requirement statement
The first step is to identify the environment, the stakeholders and the boundaries of the system to design. This enables to capture the needs and state the top functional requirements and constraints.
The difference between these two categories is that functional requirements specify the need (“what we expect”) from the system. The “constraints” express dimensioning criteria that the system has to fulfill. In Figure 4, each conceptual element is represented by a visual form that allow an easy identification. The choice of the visual codes was developed with users to match their convenience.
• Thick blue bordered rectangle is the system. The instance on the figure is called “Electrical Generator in use”
• Yellow rectangles (client, regulation) are stakeholders
• Directed arrows are flows and represent requirements. They are produced in the stakeholders and consumed in the system
o Blue arrow is functional requirement o Orange arrow is constraint
Figure 4 Inform us that the system name “Electrical generator in use” has to fulfill two requirements:
a functional requirement named “client wants to have access to electricity” transmitted from the stakeholder “client”; and a constraint named “Electrical generator shall respect electrical standards”
transmitted from the stakeholder “regulation”.
Figure 4: High level requirements capture
3.2 High level functions
The second step consists in defining the service functions of the system to design and the constraint functions that apply, and to allocate the corresponding requirements upon them. Two new visual elements appear in Figure 5:
• Blue filled rectangle which is a service function. It describes, at the top level, how one (or more) functional requirement can be satisfied by the system.
• Orange filled ellipse which is a constraint function. It describes, at the top level, how one (or more) constraint can be satisfied by the system.
Figure 5: High level functions statement
3.3 Refinement
The objective of the requirements refinement is to translate the stakeholders’ requirements into measurable system requirements and functions. The requirements for the functions of the systems to be designed determine what the system must be able to do and must be functionally specified. At the same time the limitations, such as environmental factors and regulations, are also addressed.
When a requirement is refined, it is necessary to keep the rationale that explains why and how this requirement is refined. This information is relevant especially when new actors participate to the design.[ALEX 09] Visually, in Figure 6, the “rationale” is represented by the elements named “How to”. So in this figure, the service requirement “Client wants to have access to electricity” is refined into two technical requirements (represented with brown arrows): “Plug in the client’s electrical device” and “Concert heat energy to electrical energy”. This last requirement is itself refined into three technical requirements. The process is iterated as many times as necessary. [ZAVE 97]
3.4 Technical Requirements allocation
The obtained requirements are allocated on the corresponding functions. When a requirement (represented by an arrow) points to a white rectangles, it means that the requirement is allocated.
So each function is designed and refined to respond to one or a set of requirements. When a requirement is not allocated (the case of “Avoid burning client”), a visual warning (a blue question mark) informs the user.
Figure 7: requirement driven functional refinement
3.5 Documentation
RE is not only a process of discovering and specifying requirements, it is also a process of facilitating effective communication of these requirements among different stakeholders. The way in which requirements are documented plays an important role in ensuring that they can be read, analyzed, (re-)written, and validated. Therefore an interface with text editing tools like MS Word. Generating documents is hence a feature of the tool to get deliverables that could be used by other teams.
3.6 Traceability
Requirements traceability is another major factor that determines how easy it is to read, navigate and change requirements in model and in documentation. [GEBH 00] It lies at the heart of requirements management practice in that it can provide a rationale for requirements and is the basis for tools that analyze the consequences and impact of change.
Since arKItect® is a graphical tool, it is easier to follow the impact of a requirement modification:
objects related to this requirement are the elements of the system to design that have been impacted by the evolving requirement. A script allows analyzing the impact of any modification in the model, highlighting impacted elements. The elements are the ones that should be focused on if the requirement modification is considered.
3.7 Discussion: requirement as flow vs requirement as object
In the above showed environment, decisions have to be made about concepts representation especially requirements: requirements as objects or requirements as flows. The developed case study implements requirements as flows. This representation has the advantage to express, in the same graphical concept (an arrow or a line), the source of the requirement (the entity that produce the requirement) and its destination (the entity that have to fulfill it). But the requirement refinement and the hierarchical relation between requirements have to be expressed at the same level using intermediary objects like shown in Figure 6. The second possibility is to represent a requirement as an object. In this case the hierarchical relations are naturally expressed using multilevel encapsulations. This representation has its own drawbacks like the difficulty to identify easily a requirement with multiple parents. The final decision about the representation is always a motivated by a tradeoff between advantages and drawbacks of the two possible representations
4 Conclusion
The development and deployment of easy and efficient methods to keep coherence between all projects design became a necessity to respond to nowadays challenges like enhance product qualities and decrease the development time. The requirement management is a central issue taken in account in this purpose due to its important to state correctly the initial needs and to develop the right system to fulfill the needs. The proposed solution is to centralize all project date in the same space and to make projections by business. This way insures the continuity and between the needs and the solution consolidated by a seamless requirement management including statement, refinement, validation, and all other related activities.
References
[NUSE 00] B. Nuseibeh & S. Easterbrook, Requirements Engineering: A Roadmap, ICSE '00 Proceedings of the Conference on The Future of Software Engineering (2000)
[LAM 08] A. van Lamsweerde, Requirements Engineering: From Craft to Discipline, SIGSOFT '08/FSE- 16 Proceedings of the 16th ACM SIGSOFT International Symposium on Foundations of software engineering (2008)
[ZAVE 97] P. Zave & M. Jackson, Four Dark Corners of Requirements Engineering, ACM Transactions on Software Engineering and Methodology (TOSEM), Volume 6 Issue 1, Jan. 1997
[GEBH 00] B. Gebhard & M. Rappl, Requirements Management for Automotive Systems Development, The Engineering Society for Advancing mobility (SAE) world congress, 2000
[BROY 10] M. Broy and M. Feilkas and M. Herrmannsdoerfer and S. Merenda and D. Ratiu, Seamless Model-based Development: from Isolated Tools to Integrated Model Engineering Environments, Journal: Proceedings of The IEEE - PIEEE , vol. 98, no. 4, pp. 526-545, 2010
[ALEX 09] I. Alexander and L. Beus-Dukic, Discovering Requirements - How to Specify Products and Services, ISBN-13: 978-0470712405, Wiley editions 2009
[STAN 09] Standish Group (2009), Chaos summary 2009: The ten laws of chaos.
[COLE 10] F. Colet, S. Chabroux, J. Matta, An Advanced Engineering Framework experimented on a R&AE Electric Vehicle case, Embedded Real Time Software and Systems Congress, 2010.
[LANG 05] B. Langlois, D. Exertier and G. Devda, Toward Families of QVT DSL and Tools, DSM forum, 2005
[LARK 87] J.H. Larkin, H.A.Simon, Why a Diagram is (Sometimes) Worth Ten Thousand Word, Journal of Cognitive Science, vol. 11, pp. 65-99, 1987.
[ISO 15288] Systems Engineering – System Life-Cycle Processes, International Standard Organization, 2008
[ISO 26262] Road vehicles-Functional safety, International Standard Organization, 2011 [INCO 10] System Engineering Handbook, International Council on System Engineering, 2010
