Requirements management using SysML

Revision as of 23:30, 3 March 2019

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 projects 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 be responsive to change in requirements. These strong abilities arises from the nature of object oriented modeling. Instead of archiving requirements in large amounts of text-documents (document approach), a model is build 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, ie. a way to track down the impact of individual elements on the system, from micro to macro level. This ability is particularly meaningful 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. In this article, a brief introduction to requirements management and SysML will be introduced laying the basis for further discussion about how modeling requirements affects the project manager particular in regards to; harnessing complexity, reducing risk, and communicating effectively with stakeholders and the project team.

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 safety requirements. Therefore the project organization must have a requirement management plan, that answers to how requirements activities will be planned, tracked, reported, and how one can analyse change and achieve traceabilty. ^[2] Maintaining and organizing this specefication "document" is a non-trivial endeavor, as requirements is a broad term that can involve everything from functional/non function requirements related to a products physical capabilities, to busienss objectives, use cases or even transitistiong requiremetns (Fx. A new software release has to be applicable with prior file versions). The complexity can be overwhelming, and it is hard to imagine how to make sense of this in a practical setting. Therefore it is key, that the project organization chose an requirements management approach ie. a way to organize this structures in an intelligent way that deem them useful through the life cycle of the project. This requirements structure helps to communicate and specify what should be delivered and how it will perform, and will functions as a baseline for evaluation during the project and at closing, that the delivery is as the relevant stakeholder agreed to. Before digging deeper into SysML in requirements management on must understand the different between document based, models based approaches, and how object oriented paradigm may be beneficial for engineering systems, and not just software as original developed for.

Document-based or model-based

In many organisations the requirements mangement approach remains document based. This means requirements are archived in text-documents (hard copy or digital), and depicted in hierarchal specification trees (components are split into sub-components and so on), with no synchronisation of elements between documents. This means if an element is changed or updated, a system-responsible has to manually make sure all other descriptions of that element across the documents is updated accordingly - naturally a proces prone to error. Part from the rigor and the difficulties of maintaining in large projects, this approach has fundamental limitation. The first being, it creates unnecessary large amounts of data, as similar components cannot reuse/inherent properties from elements already documented. The second being it can be difficult to depict the complex reality of the relations between components, as the classic can tree structure only reveals so much. The first issues makes it difficult to analyse and trace requirements, because the system is incomplete and spread over several documents, with other relation than inherit text reference. The second problem tells us that this structure is not a wholesome abstraction of the true relationships in the project. ^[3]

Instead the Project management office should 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". ^[4] A model-based approach, as the SysML, is an object-oriented systems engineering method. (kilde). The product of the model-based approach is a 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 automaticcaly upadted in the entire system, as all digrams refers to this same instance of the object. This means there is exist only one of the given component in the system, but this component 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 "object" with all its different attributes say, plants, animals, and snow. The different view that can be extracted from the model to understand to system is then photographs of the mountain from different lokations. Two photos may show partly similar elements, but they will depict different truths about the mountain itself. ^[5]

Model-approaches has been used for many years in software industry, the most famous the language being the Unified Modeling Language made by Object Management Group. SysML is a visual modeling language developed by the Object Mangagement Group (OMG), as a profile/flavour/extension to the UML from software development. It is an object-oriented language specifically made to specify engineering systems. (Kilde)

System Modeling Langauge

SysML is a visual modeling language but not set of specific processes or a tool itself (kilde). 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. This implies that every project organisation has to build their own model that fits their particular project.

SysML defines nine diagrams to construct a systems engineering model. For a light introduction it can be wise to start with SysML Lite (A simplified version with six diagrams instead of nine). The way one build the model in SysML is 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 digram can for example be a physical instance, say a valve, or a hierarchy of components say an engine, but is not limited to that. (Kilde). With one or more block digram defined, one can begin modelling relationships to these blocks. The Activity digram 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 nature laws around a system. An air pump could have some gas laws with ceratin parameters decribed in an equations. The requirements digram depicts requirement relationships, for example the engine satisfies .... The internal block diagram is analgous to opening op a certain block and describing the port (input and output) of that black. (See picture). What then happens is, that these elements are paried together, for example a flow generator (block) might be part og a flow diagram (activity) where flow can be parametrized (Parametrics). Objects are created that has certain parameters og values, and these can be modeled in different digram, all synchronised. At any given time the user can decide to query a certain view/diagram to reveal that aspect of the model. In the modelbased enviroment, the modeler build the model and refines it more and more though the life cycle. In practice this means, that the project manager can start by roughly sketching the top level of the system with stakeholders, and as the project phases go on, and more and more information is known, the model is detail further and further.

Requirement managment

Affecting project management

Why not a different model-based approach to requirements management? 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 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 made 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, and see how they practically are beneficial.

Traceability It allows full traceability, maening if an error happens at any given point, it is possible to litteraly "draw" the entire network of relations out as diagram, to see all things that influence the particular instance. In practice this could be "...an engine component ... part of the automobile system, connected to the transmission, satisfies a power requirement, performs a function to convert fuel to mechanical energy, and has a weight property that contributes to the vehicle’s weight." side 19 practical. In many organizations the procedure of tracing issues in the design is a complex analysis, as these relationships are not captured in such a intergrated way, instead a search for errors would be initaied. The drives a range of issues related to managements decision making, as certain perspectives of the system are not visble: making for traceability issues I.e. when tracing a customer requirements all the way down to the rationale behind decisions of low system level components.

Effective impact analsys and trade-off analaysis As all relations are captured in the same model, it becomes much easier to perform trade-off analysis and impact analysis of the system, as one can easily follow how change affects the system.^[3] For the project manager this means, that when sudden changes occur, say unexpected opportunities or thread occurs the project manager will have a strong .. to take decisions. Say a validation of a component in the crtical path revealed some errors that will delay the whole project, then the project manger can use the model to quickly understand how changes in proceses will affect different parameters as risk. (kilde) This makes for a very effective understanding and exploration of the trade-off space, without the project manager needing to have particular domain specific knowledge as for example technical knowledge around building engines.

Communication: On the premise that stakeholders are familiar with looking at SysML diagrams, the communication between stakeholders becomes more effective as stakeholder will have a shared understanding of the system, critical problems in tecnical systems can be understood without deep technical knowledge (kilde).,

Effiency Reuse of mdeols: Another benefits that relates to the object orieneted nature of the SysML, evolves around reuse of existing documentation from simliar instances in the same system, or from prior projects or programs.

This in turn makes it difficult to asses change impact in projects, and delivering with the right quality, .. leading to reduced quality and higher uncertainty.... The complexity and probability of damage drastically increases with the size of projects and width of program, as more complicated networks of relation arises between technology, stakeholders...

In practice it becomes difficult to understand the full picture, fx. if a failure in a subsystem of say a engine for a car fails, it becomes a puzzle to trace back what affects the the given system

One way to order them, proposed by the PMBOK, is through a requirements traceability matrix (RTM). This matrix relates entities on one axis with multiple requirements on the other axis. In this way a multiple to.... kilde: 5.2.3 CoLLeCT reQuIreMenTS: ouTPuTS Skriv her noget kritik og husk at få kilder på.

Skriv om risk, og de tre ting nævnt i abstract.

GENERLT læS side 19 og 20 i practical for dette afsnit "provide additional rigor in the specification and design process when implemented using appropriate method"

Implementing SysML

Before deciding to implement SysML in a project or program, the project mangement office has to asses whether the right ressources in terms of time/knpwledge are present for .. as well as understanding..... læs øverst i bog efter forklaring

Limitations

Increased complexity, for small projects. Requireme that all people are in and understand,

Da det ikke er sen reg metode i sigelv, men en specifiering skal mange ting ændres

Se også Transitioning to MBSE på side 20 i practical.

References

1. ↑ ISO 21500 Project Management. Page 3
2. ↑ PMBOK. 5.1.3.2 Requirements Management Plan, Page 137
3. ↑ ^{3.0 3.1} A Practical Guide to SysML 2nd. Page 15
4. ↑ International Council on Systems Engineering (INCOSE), Systems Engineering Vision 2020.
5. ↑ SysML Distilled_ A Brief Guide - Lenny Delligatti. Page 19

PMBOK 5.2.3.1 reQuIreMenTS doCuMenTaTIon