Requirements management using SysML

Latest revision as of 01:01, 5 March 2019

[edit] Abstract

Every project involves producing deliveries constrained to highly interdependent requirements describing the relationships of the elements that make up the project. Managing the complexity of these requirements is crucial for project success. Object-oriented modeling languages such as SysML provides a generic framework to construct so called models of engineering projects. These models make for a tool to comprehend specification complexity, thereby supporting the project manager to comply with quality, reduce risk, and to be responsive to change in requirements. These strong abilities arise from the nature of object-oriented modeling. Instead of archiving requirements in large amounts of text-documents (document approach), a model is built in a computer program that captures the multi-dimensional relationships between requirements across components, use cases, system level functioning, and performance. This enables full traceability, i.e. a way to track down the impact of individual elements on the system, from micro to macro level. This ability is particularly supportive for projects managers, as they naturally cannot comprehend all details in a project, instead they must understand the overall system dynamics, that focuses on the relationships of the elements. One property of SysML that drives strong representations of requirements, is the fact that it is an integrated model. This means it specifies the entire system design, and in a subset of this endeavor relating multiple requirements to system components. In this article, a brief introduction to requirements management and SysML will be introduced laying the basis for further discussion about how modeling requirements with SysML affect the project manager particularly in regard to; harnessing complexity, reducing risk, and communicating effectively with stakeholders and the project team.

[edit] Introduction to requirements management

The ISO 21500 project management standard defines a project as: “...a unique set of processes consisting of coordinated and controlled activities with start and end dates, performed to achieve project objectives. Achievement of the project objectives requires the provision of deliverables conforming to specific requirements. A project may be subject to multiple constraints." ^[1] The degree to which a project conforms to these specific requirements and constraints, is what determines the quality of the delivered project. If the outcome of the project does not comply with quality, the project may not meet the business objectives and harvest the benefits it was initiated for, or it may even negatively affect the entire organization, fx. if an accident occurs due to unmet or unverified safety requirements. Therefore, the project organization must prepare a requirement management plan, that answers to how requirements activities will be planned, tracked, reported, and how one can analyze change and achieve traceability. ^[2]

Maintaining and organizing requirements is a non-trivial endeavor, as the term "requirement" covers a wide variety of properties of a project involving everything functional/non-functional requirements related to a physical capability of systems, but also to business objectives, use-case scenarios or even transitioning requirements, just to mention a few. The complexity can be overwhelming, especially in large scale projects found in automotive, defense or medical industry, and it is hard to imagine how to order thousands of requirements of various type in practice. It is essential that the project organization chose an effective requirements management approach i.e. a way to organize the structures of requirements in an intelligent way that deem them useful throughout the life cycle of the project. ^[3] The requirements management appraoch helps to communicate and specify what should be delivered, how it will perform and how this performance is verified to all stakeholders involved. It will function as a baseline for evaluation and specification during all stages of the project, and at closing to verify that the delivery is as the relevant stakeholder requested and agreed to. Before digging deeper into SysML in requirements management, one must understand the difference between the document-based and models-based approaches.

[edit] Document-based or model-based

Figure 2, Model-based and Document-based approach.

[edit] Document-based

In many organizations the requirements management approach remains document-based. In this approach requirements are archived in text-documents (hard copy or digital) and organized hierarchically (components are split into sub-components etc.), with no synchronization of elements between documents. This means if an element is changed or updated in one document, a system-responsible person has to manually make sure all other documents with a description of that element gets updated accordingly - naturally a process prone to error. Part from the rigor of maintaining these documents through the project, this approach has some fundamental limitation. ^[4] The first being it can be difficult to depict the multiple to multiple relation structures using the classic hierarchically tree structure, as it shows a certain framing of the system, and when information is spread across documents, it can be difficult to understand a particular aspect of the system.^[5]The second being the creation of unnecessarily large amounts of data, as similar components cannot reuse/inherent properties from elements already documented, which means duplicate work is being undertaken.

[edit] Model-based

Project management office should instead look towards a model-based approach: "Model-based systems engineering (MBSE) is the formallized application of modeling to support system requirements, design, analysis, verification, and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases". ^[6] The product of the model-based approach is one coherent computer model, that handles objects instead of multiple text-documents. These objects can have properties and functions, and may be modelled in a variety of ways. So if the object is changed in on setting, say a physical component is updated, then the object is automaticaly updated likewise in the entire system, as relations refer to instances of objects. This means there is exist only one of the given object in the system, but this object can be viewed in different diagrams/views across the model, instead of one place in a tree structure. A mental way of understanding the model-based system is picturing a mountain. The mountain itself is the model with all its different attributes say, plants, animals, and snow. Various views extracted from the model to understand to system is then photographs of the mountain from different locations. Naturally two photos may show similar elements, but they will depict different information about these elements to make you understand the entire properties of the mountain. ^[7]

[edit] System Modeling Langauge

System Modeling Language (SysML) is a visual modeling language developed by the Object Mangagement Group (OMG), as a "dialect" of the famous language UML for specification of software. SysML is a visual modeling language and not a set of specific processes or a tool itself, which implies that every project organisation has to build their own model that fits their particular project. It is also important to note that SysML is not a dedicated requirements mangagement system, it is a language for organising large complex structure specifically designed for making abstractions of engineering systems, and while doing so, tracking of requirements is a natural part of the specification of the system. ^[8]

Figure 3, The nine diagrams in SysML.

SysML defines nine diagrams to construct a systems engineering model. A diagram pictures a particular kind of view into the model. For an accesable first introduction it is recommended to start with SysML Lite (A simplified version with six diagrams instead of nine)^[9]. SysML represents systems by constructing basic building block called "block diagrams". One can say, these are the artefacts that will be modelled, and relations between these will be described using the rest of the diagrams. A block diagram can for example be a physical instance, say a valve, or a hierarchy of blocks say an engine. With one or more block diagram defined, one can begin modelling relationships to these blocks. The Activity diagram describes behavior or sequences in the system, this could be a use case-scenario or the flow of air though a valve. Parametrics are typically equations that describe natural laws operating around an aspect of the system. An air pump could have gas laws governing the flow with certain parameters described in an equation. The internal block diagram is analogous to opening op a certain block and describing the ports (inputs and outputs) of that block.^[10]

Figure 4, The intergrated model that allows a multiple configurations.

The way in which the different diagrams defines a holistic representation is by combining them: a flow generator (block) might be part og a flow diagram (activity) where flow is parametrized by an equation (Parametrics). At any given time the viewer can decide to query a certain view/diagram to reveal that aspect of the model. The life cycle of the model evolves around building a simple general model in the begning, and refining it through the life cycle. In practice this means, that the project manager start by roughly sketching the top level of the system with stakeholders, and as the project stages proceed, more and more information is known and the model is detail further.

[edit] Requirements diagram and Requirements Management

The requirements diagram draw requirement relationships to other diagrams in the model. SysML provides seven different relation types for requirements; composite, derive, define, satisfy, verify, copy, and trace. The relation type "satisfy" can be used to depict that a certain diagram satisfy a requirement, fx. an ABS breaking systems satisfy a requirement related to breaking distance. A trace relation can relate the rationale behind a requirement to a given diagram or artefact say a market analysis, and a verify relation can show how a supposedly satisfied requirement is going to be verified. ^[11] The big idea is combining the model diagram with requirement diagrams, and an example could be "...an engine component ... part of the automobile system [block diagram], connected to the transmission [internal block diagram], satisfies a power requirement [requirements diagram], performs a function to convert fuel to mechanical energy [parametrics and activity diagrams], and has a weight property that contributes to the vehicle’s weight[parametrics]." ^[12]. The important point to emphasise in relation to requirements management, is how requirements become part of the specification of the entire design, which makes for a much more rich description of the requirements. ^[13]

Figure 5, A verify relationship to a test case.

[edit] Comparison

There exist many other approaches to requirements management, one very used method also presented in the PMBOK is through a Requirements Traceability Matrix (RTM). This matrix relates elements on one axis with multiple requirements on the other axis in a typical spreadsheet manner. ^[14]The general critique of this approach is that it is not model-based, which limits its ability to depict a rich abstraction of the system, and it is not a intergrated approach, still this method remains the standard for requirements mangament in many industries. However RTM is much easier to learn and implement in an organisation, which is parameters to also consider when choosing requirement management approach, which will addressed further under the limitation section.

[edit] How does requirements management using SysML affect project management? (The Big Idea)

What makes SysML a powerfull model-based approach for requirements management comes down to that it is an Integrated model and not just a stand-alone requirements management tool. The way the project manager benefit from having design specification, analysis, verification and system requirements integrated into one cohesive model, instead having these functions spread across multiple documents with different approaches, can be distilled to: reducing risk, harnessing complexity and increasing effectiveness in communication with stakeholders. Let us dive deeper into these point.

[edit] Harnesing complexity

Traceability The importance of requirements cannot be emphasised enough as they have high influence on quality, but unfortunately, they seem to always appear in complex structures. For the project manager to manage and control requirements, he/she must be able to harness this complexity. SysML helps this by introducing full traceability by means of an integrated approach, meaning if an error occurs related to any given aspect of the system, it is possible to pick up the entire network of relations. Picture pulling out a long thread of diagrams depicting exactly what that particular instance is influence by, and what caused the problem at hand. This is making for extremely efficient Root Cause Analysis RCA, i.e "What caused a problem to occur? How can we fix it?" ^[15]. In many organisations the act of tracing issues in the design is a unnecessarily comprehensive effort, as relationships are not captured in such a integrated manner, instead a more "manual" search for errors must be initiated, which could introduce lag to the project (delay other activities of the project) and use unnecessary ressources.

Reuse Another way in which SysML harness complexity is through a more efficient way of specifying requirements reducing duplication of work. The oriented nature of SysML, enables reuse of existing documentation from similar instances in the same system, or from programs or prior projects. This has to implications: only one representation per elements exist, and this representation can be called from all diagrams (reused), and elements can inherit and copy properties. This is very powerful feature for the project manager, especially for managing programs of related projects. One could imagine a a program of car models with respective requirements structure, witch components more or less related to each other, where these component inherent structural relationship from a higher generalized object describing the requirements related to that object type. This reduce cost/time of creating and maintaining requirements management and reduce complexity as you introduce an architecture like thinking for the program. If the entire organization choose to streamline into SysML, lessons learned registered in prior project models can affect how requirements in new projects are constructed. The notion of reuse across projects will in turn reduce time to market of the entire program.

[edit] Reducing Risk

SysML influence risk assessment for the project manager in that it promotes rigor and unambiguous design of the system which in turn drives unambiguous requirements. Having a deep holistic model combined with precice ordered data, simply makes for better trade-off analysis and impact analysis of the system, as one can easily follow cause and effect.^[16] For the project manager this means, that when unexpected opportunities or threads changes the course of the project, say changes in the critical path require a packages being expedited, an impact analysis could reveal how this influence requirements and how to respond with a minimum risk. At best it can help the project manager shift from a reactive approach to a more preventive approach by having a better understanding and exploration of the trade-off space, without the project manager needing to have particular domain specific knowledge.

[edit] Effective Communication

On the premise that stakeholders are familiar with the common language of SysML diagrams, the communication between stakeholders becomes more effective as stakeholder will have a shared understanding of the system regardless of where in the organization or outside they operate. The focus on relations makes it possible to communicate quality of requirements and design regardless of domain specific knowledge. The ability to integrate multiple and various types of diagrams, enables comprehensive relations to be easier communicated and understood. The project manager is responsible for controlling that the project complies with quality but figuring out which requirements to incorporate is something that often needs domain specific knowledge. With SysML the project manager can communicate a design of the top-level system requirements traced from market analysis and client contracts, and business objectives to the project team and stakeholders, and in an ongoing dialog this model can be refined with the help from project team and relevant stakeholders. SysML is as mentioned a visual modeling language, this means it has certain semantics and these are designed to be effective in communicating system related topics. Without a lingua franca or common language for talking about systems, communicating these ideas would be impossible or very prone to be unambiguous. ^[17]

[edit] Limitations

Introducing SysML in the project organization yields many benefits, however there are also limitations that has to be considered before incorporating it as part of a requirement management plan. These limitations are often related to implementation. As requirements management is a subset of SysML, the organization also has to change processes related to design, specification and analysis and not just requirements. Preferably all stakeholders in the project should be familiar with SysML diagrams to gain benefits from communication. However, these two points requires substantial upfront investments in training, processes, tools and change in common practices for the project team and stakeholders. ^[18]. In many organization project management maturity level can be an issue, as it is difficult to implement such a rigid tool, if the environment in the project organization is not ready. Mostly these kinds of models are seen in pharmaceutical and automotive industry with higher project management maturity level, therefore a state-of-practice assessment should be carried out beforehand. ^[19] The interdependencies in the SysML model, means the effectiveness of requirement management approach is sensitive to how well the organization utilizes SysML for the specification of the design. Considerations should also evolve around the complexity of the project, for less complex or small size projects the SysML can be unnecessary and just slowing progress.

[edit] References

Three books have been particularly helpfull in the creation of this article. The first being Practical Guide to SysML by S. Friedenthal which explained how to use the diagrams of SysML with practical examples. It also did very well in explaining the benefits of transitioning to Sysml in an organistaion, and to be aware of. The second book was SysML Distiled by Delligatti, which gave a more formal introduction to what SysML is and what it is not. Lastly the PMBOK from PMI has given insights into where requirements management is positioned in the organisation and how it yields benefit to plan, manage and control requirements.

1. ↑ ISO 21500 Project Management Page 3
2. ↑ PMBOK. 5.1.3.2 Requirements Management Plan, Page 137
3. ↑ PMBOK. 5.1.3.2 Requirements Management Plan, Page 137
4. ↑ A Practical Guide to SysML 2nd. Page 15
5. ↑ A Practical Guide to SysML 2nd. Page 15
6. ↑ International Council on Systems Engineering (INCOSE), Systems Engineering Vision 2020.
7. ↑ SysML Distilled_ A Brief Guide - Lenny Delligatti. Page 19
8. ↑ SysML Distilled A Brief Guide, Page 12
9. ↑ A Practical Guide to SysML 2nd. Page 31
10. ↑ A Practical Guide to SysML 2nd. Page 35
11. ↑ The 01/03 2019: https://re-magazine.ireb.org/articles/modeling-requirements-with-sysml.
12. ↑ A Practical Guide to SysML 2nd. Page 19
13. ↑ A Practical Guide to SysML 2nd. Page 319
14. ↑ PMBOK 2017 . Section 5.2.3 Collect requirements
15. ↑ Managing Medical Devices with Regulatory Framework, Ann Fiedler. Page 117
16. ↑ A Practical Guide to SysML 2nd. Page 20
17. ↑ SysML Distilled_ A Brief Guide - Lenny Delligatti. Page 12
18. ↑ A Practical Guide to SysML 2nd: Deploying SysML into an Organization. Page 558
19. ↑ A Practical Guide to SysML 2nd: Deploying SysML into an Organization. Page 21