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 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 SysML and requirements management 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 project team.

Introduction to requirements management

“A project consists of 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 mulitple constraints.” Accroding to The ISO 21500 project management.

To discuss whether a delivery comply with quaility, a project has to have a clear unambiguous specification that the relevant stakeholders or clients has agreed to. The requirements in that sense help specify what should be delivered and how it will perform, but will also function as a baseline for evaluation during the developme life cycle and at closing. If the outcome of the project does not live up to quality it may not harvest the business benefits it was initiated for, or it may even negatively affect the organization, for example if certain safety requirements are not met or not specified. The project organization must make requirement management plan.

“5.1.3.2 reQuIreMenTS ManaGeMenT PLan “The requirements management plan is a component of the project management plan that describes how project and product requirements will be analyzed, documented, and managed..... Components of the requirements management plan can include but are not limited to:

uuHow requirements activities will be planned, tracked, and reported; uuConfiguration management activities such as: how changes will be initiated; how impacts will be analyzed; how they will be traced, tracked, and reported; as well as the authorization levels required to approve these changes; uuRequirements prioritization process; uuMetrics that will be used and the rationale for using them; and uuTraceability structure that reflects the requirement attributes captured on the traceability matrix”

Maintaining and making this specefication 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, but it can even be to busienss objectives, use cases or even transitistiong requiremetns (Fx. A new software has to be applicable with former software version files). 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. (Kilde også til PmBok).

One way to order them, proposed by the PMBOK, is through a requireents tracebility 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

(It can be argued that the RTM approach has some limitations in that ......... .Her skal der stå noget pmbok elller Prince om requriment g Irak. Hvornår og hvad gør de Find gradins objectives. står noget i pmbok om requirements management.)

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 a variant of a document based approach; here requirements are categorised and archived as text files with no synchronization or inherint relations from one document to another, apart from llimited text reference. This means if an element is change, a system engineer has to manually make sure all other descriptions of that element is updated. Part from being a rigorous proces that can be difficult to maintain in large projects, this approach also has fundamental issues. Three main issues in this approach stands in the way for the project manager to take effective use of the requirements documentation.

First is the sychronization issue, that can , the other is, producing larger amounts of data than neccesary, as certain elements a depicted many times.

This all lead back to the fact that t

on is that it can be difficult to depict the complex reality of the relations between components, 

Instead the relations are depicted in a framing decided by the system engineer responsible for designing and maintaining the system. 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 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

Instead the Project management office should shift the requirements management approach to a model-based approach. In a model-based-approach, ....... OOSEM object-oriented systems engeneering method. The products of the model-based approach depicts the messy structures ... with fewer.. as requiremetns can be inherited and derived from eachother.

A good mental model for understanding the dynamics of the model-based system is picturing a mountain. The mountain itself is the model "object" with all its different trees, animals, snow. The different view that can be extracted from the model to understand to system is then photographs of the moutain from different lokations. Two photos may show partly similar elements, but they will depict different truths about the moutain itself.

Introduction to SysML

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. SysML is as the name reveals a langauge and not sert of specific processes. What this langauge enables, is a means for organizing large complex structure that make for an abstraction of the real egneering system, dvs. woth all its muulti dimeniosnal and crossing relations.

In brief SysML defines nine main digrams to make up an entire systems engineering model. For an easy introcuciton it can be wise to start with SysML LIte for the first time, it can b, so we will do that here.

One can build basic or complex strucutres using block diagrams. These are the artefacts that will be modeled, and relations between these will be described in the other 5 elements. A block digram can be a physical instance, say a component or a hierachi of componen, or I can be a.......

With the block digram defined, we can begin to model relationships. The Activity digram describes behavior or sequence in the system, this could be a use case scenario or it could be a flow of air though a pump. Parametrics are tupycally equations that describe for example natural laws around a system. An air pump could have some gas laws with ceratin parameters decribed in an equations. 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.

The handy thing is, that the project manager can start by roughly sketching the top level elemstes of the system with stakeholders, and as the project phases go on, more and more detailed is added as te pro ject team understands the system better.

billede a model

Affecting project and program management

The SysML approach contribute in variety of ways to simplify and give powerfull insights.

It makes it the trade-off analysis more clear, thereby making it easier to take the right decesions

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,

References

150211142014_2_Friedentahl_-_A_Practical_Guide_to_SysML_2nd

PMBOK 5.2.3.1 reQuIreMenTS doCuMenTaTIon