Requirements management using SysML

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 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 a integrated model that specifies the entire system design and in a subset of this endeavour is 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 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." 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 prepare a requirement management plan, that answers to how requirements activities will be planned, tracked, reported, and how one can analyse change and achieve traceabilty.

Maintaining and organizing the requirements is a non-trivial endeavor, as requirement is a broad term that can involve everything from functional (steering)/non function(reliability) 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 in large scale projects as in automotive or medical industries, and it is hard to imagine how to order thousands of requirement in practice. It is essential that the project organization chose an effective requirements management approach ie. a way to organize the structures of requirements 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, how it will perform and how the performance are verified, and will therefore function as a baseline for evaluation 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 different between the document-based and models-based approaches.

Document-based or model-based

Document-bases

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 etc.), 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 these documents through the project, this approach has fundamental limitation. (kig lige på denne) 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.

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". 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.

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. 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). SysML models reality 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 blacks say an engine, but is not limited hereto. (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 natural laws operating around a 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 port (input and output) of that black. (See picture).

The way in which the different diagrams defines a holistic represetation 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 evovles 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 phases go on, and more and more information is known, the model is detail further and further, as it is posibble to create a digram wihtout specying it.

Requirements diagram and Requirements Management

The requirements diagram draw requirement relationships to other diagrams. SysML provides seven different relationtypes; 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 as the figure depicts a verify relation can show how a requirement supposedly satisfied is going to be verified. In practice a combination of the requirement diagram and the other diagrams could be "...an engine component ... part of the automobile system [block diagram], connected to the transmission [internal block diagram], satisfies a power requirement [satisfy relation in 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." side 19 practical. 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. side 319 practical

How does effective and effecient requiremetns managment using SysML affect project 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 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.

Harnesing complexity

Requirements cannot be neglected as they have high influence on quality, and unfortunately they seems 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 literally 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, ie "What caused a problem to occur? How can we fix it?" ref=side117 managing medical devices with regulatory framework. In many organisations the act of tracing issues in the design is a unnecessary comprehensive effort, as relationships are not captured in such a integrated manner, instead a more "manual" search for errors would be initiated, which could introduce lag to the project (delay other activities of the project) and use unnecessary ressources.

Another way in which SysML harness complexity is through a more effient way of specifying requirements reducing duplikation 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 (resused), and elementes can inherit and copy properties. This is very powerfull 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 relationsship from a higher generalised object describing the requirements related to that object type. This reduce cost/time of creating and maintaining requirements manaagment and reduce complexity as you introduce a 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.

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. 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.

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 possible regardless of domain specific knowledge(kilde). The ability to integrate multiple and varous types diagrams, enables comprehensive relations to be easier communicated and understood. The project manager is responsible for controlling that the project comply with quality, but figuring out which requirements to incorporate is something that often needs domain specefic knowledge. With SysML the project manager can communicate a design of the over all system requirements traced from market analysis and client contracts, and business objectives to the project team and stakholders, and in a ongoing dialog this model can be refined with the help from project team and relevant stakeholders.

it is langauge

Maintaingning

Made for comunicatigng systems ideas, higher quality (kan skrive om cuomincation model) 1. having a shared lanuage,ref= distillid

---

Comparison with alternatives skal nok fjerens, svært at finde kilder

There are many approaches to requirements management, one way poposed 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 a typical spreadsheet manner. kilde: 5.2.3 CoLLeCT reQuIreMenTS: ouTPuTS The has been a lot of critique of this approach as it does depict a rich abstraction of the system, which can result in undocumented requirements or unforeseen issues, but still this method is used in many industires. What is generaly considered good practice is to use model-based tools. Alot of the benefits of the SysML comes down to that it is model based and integrated. However there exist other languages that have these properties too, one them being UML. UML is also developed by Object Management Group and came out before SysML, SysML was created as a "dialect" on UML to also being able to describe physical systems constrained to physical relations. They main difference is the addition of the requirements diagram and....

Limitations

Introducing SysML in the project organization yields many benefits, however there are also limitions 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 organisation also has to change processes related to design and specification and just requirements. Preferably all stakeholder in the project should be familiar with SysML, this requires large upfront investments in training, processes, tools and change in common practices which can be frustrated for the project team. kilde side21 prac. In many organisation project management maturity level can be an issue, as it is difficult to implement such a rigid tool if the environment in the project organisation 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-practise assessment should be carried out beforehand. The interdependencies in the SysML model, means the effectiveness of requirement management approach is sensitive to how well the organisation utilises SysML for the specification of the design. Considerations should also evolve around the complexity pf the project, in small projects the SysML can be unnecessary and slowing down progress.

References

Three books have been particularly helpfull in the creation of this article. Practical guide provided a..

PMBOK 5.2.3.1 reQuIreMenTS doCuMenTaTIon