Requirements management using SysML
(→Introduction) |
(→Introduction) |
||
| Line 2: | Line 2: | ||
Every project involves ... highly interdependent requirements describing the relationships and constraints 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, 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 is traceability, ie. a way to trace down individual elements impact on other elements, from mikro to makro level. This ability is particularly important for projects mangaers, who cannot comprehend every little detail 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 it affects the project manager particular in regards to harnessing complexity, reducing risk, and communicating effectively. | Every project involves ... highly interdependent requirements describing the relationships and constraints 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, 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 is traceability, ie. a way to trace down individual elements impact on other elements, from mikro to makro level. This ability is particularly important for projects mangaers, who cannot comprehend every little detail 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 it affects the project manager particular in regards to harnessing complexity, reducing risk, and communicating effectively. | ||
| − | == Introduction == | + | == Introduction to requirements management== |
PMBOK describes a project as “ “.Any engineering project involves delivering --- within a agreed time frame, at a certain cost and to an agreed quality. | PMBOK describes a project as “ “.Any engineering project involves delivering --- within a agreed time frame, at a certain cost and to an agreed quality. | ||
| Line 8: | Line 8: | ||
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. | 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. | ||
| − | 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 approach to organize this structures in an intelligent way that deem them useful through the life cycle of the project. | + | 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. |
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.... | 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.... | ||
| Line 14: | Line 14: | ||
. kilde: 5.2.3 CoLLeCT reQuIreMenTS: ouTPuTS | . kilde: 5.2.3 CoLLeCT reQuIreMenTS: ouTPuTS | ||
| − | It can be argued that the RTM approach has some limitations | + | It can be argued that the RTM approach has some limitations in that .......... |
| − | + | 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. | |
| − | + | ||
| − | + | ||
Her skal der stå noget pmbok elller Prince om requriment g Irak. Hvornår og hvad gør de | Her skal der stå noget pmbok elller Prince om requriment g Irak. Hvornår og hvad gør de | ||
Revision as of 00:35, 1 March 2019
Contents |
Abstract
Every project involves ... highly interdependent requirements describing the relationships and constraints 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, 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 is traceability, ie. a way to trace down individual elements impact on other elements, from mikro to makro level. This ability is particularly important for projects mangaers, who cannot comprehend every little detail 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 it affects the project manager particular in regards to harnessing complexity, reducing risk, and communicating effectively.
Introduction to requirements management
PMBOK describes a project as “ “.Any engineering project involves delivering --- within a agreed time frame, at a certain cost and to an agreed quality.
To even discuss the quaility of a delivery, a clear non ambiguity specification must be made and requirements fulfilling this. This requirements in that sense specifies what exactly should be delivered and how it will perform, but will also function as a baseline (during development, and at closing) to evaluate whether the delivery is, as the client ordered - in other words if the project comply with the defined quality. 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.
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.
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 ..........
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.
Her skal der stå noget pmbok elller Prince om requriment g Irak. Hvornår og hvad gør de Find gradins objectives
Document-based or model-based
In many organisations the approach for managing requirements is a variant of the so called document based approach; here requirements are categorised and documented as text files and archived, often with limited reference to each other. Part from being a rigorous proces that can be difficult to maintain in large projects, this approach has a fundamental problem. The problem arises as it can not 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...
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.
Quick overview/introduction of 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.
SysML defines nine views/blocks to make a model, these are These are the different views that help us understand the complexity. When learning about SysML for the first time, it can be .. to start with the SysML Lite version, so we will do that here.
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
