Requirements management using SysML - Revision history

S153408: /* Abstract */

2019-03-04T23:01:28Z

Abstract

← Older revision		Revision as of 23:01, 4 March 2019
Line 1:		Line 1:
	== Abstract ==		== 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 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.		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.

	== Introduction to requirements management==		== Introduction to requirements management==

S153408: /* Limitations */

2019-03-04T22:57:56Z

Limitations

← Older revision		Revision as of 22:57, 4 March 2019
Line 58:		Line 58:

	==Limitations==		==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. ~~kilde side21 prac~~. 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. <ref>A Practical Guide to SysML 2nd: Deploying SysML into an Organization''. Page ~~558~~</ref> 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.		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. <ref>A Practical Guide to SysML 2nd: Deploying SysML into an Organization''. Page 558</ref>. 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. <ref>A Practical Guide to SysML 2nd: Deploying SysML into an Organization''. Page 21</ref> 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.

	== References ==		== References ==

S153408: /* Effective Communication */

2019-03-04T22:57:20Z

Effective Communication

← Older revision		Revision as of 22:57, 4 March 2019
Line 55:		Line 55:

	===Effective Communication===		===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~~(kilde)~~. 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. <ref>SysML Distilled_ A Brief Guide - Lenny Delligatti''. Page 12</ref>		'''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. <ref>SysML Distilled_ A Brief Guide - Lenny Delligatti''. Page 12</ref>

	==Limitations==		==Limitations==

S153408: /* System Modeling Langauge */

2019-03-04T22:57:00Z

System Modeling Langauge

← Older revision		Revision as of 22:57, 4 March 2019
Line 23:		Line 23:

	[[Image:nine_blocks.png‎ \| right\|thumb\| 400px \| Figure 3, The nine diagrams in SysML.]]		[[Image:nine_blocks.png‎ \| right\|thumb\| 400px \| 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)<ref>A Practical Guide to SysML 2nd''. Page 31</ref>. 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 ~~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 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~~. (See picture)~~.<ref>A Practical Guide to SysML 2nd''. Page 35</ref>		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)<ref>A Practical Guide to SysML 2nd''. Page 31</ref>. 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.<ref>A Practical Guide to SysML 2nd''. Page 35</ref>

	[[Image:holist.png‎ \| right\|thumb\| 400px \| Figure 4, The intergrated model that allows a multiple configurations.]]		[[Image:holist.png‎ \| right\|thumb\| 400px \| Figure 4, The intergrated model that allows a multiple configurations.]]

S153408: /* Limitations */

2019-03-04T22:56:00Z

Limitations

← Older revision		Revision as of 22:56, 4 March 2019
Line 58:		Line 58:

	==Limitations==		==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.		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. kilde side21 prac. 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. <ref>A Practical Guide to SysML 2nd: Deploying SysML into an Organization''. Page 558</ref> 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.
	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, 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 ~~point~~ requires substantial upfront investments in training, processes, tools and change in common practices for the project team and stakeholders. 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. <ref>A Practical Guide to SysML 2nd: Deploying SysML into an Organization''. Page 558</ref>
	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 of the project, for less complex or small size projects the SysML can be unnecessary and just slowing progress.

	== References ==		== References ==

S153408: /* How does requirements management using SysML affect project management? (The Big Idea) */

2019-03-04T22:55:21Z

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

← Older revision		Revision as of 22:55, 4 March 2019
Line 46:		Line 46:
	===Harnesing complexity===		===Harnesing complexity===
	'''Traceability'''		'''Traceability'''
	The importance of requirements cannot be ~~emphased~~ enough as they have high influence on quality, but 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>Managing Medical Devices with Regulatory Framework, Ann Fiedler''. Page 117</ref>. 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.		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?"'' <ref>Managing Medical Devices with Regulatory Framework, Ann Fiedler''. Page 117</ref>. 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'''		'''Reuse'''
	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 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 ~~acoress~~ projects will in turn reduce time to market of the entire program.		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.

	===Reducing Risk===		===Reducing Risk===
Line 55:		Line 55:

	===Effective Communication===		===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(kilde). The ability to integrate multiple and ~~varous~~ types of 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 top-level system requirements traced from market analysis and client contracts, and business objectives to the project team and ~~stakholders~~, 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. <ref>SysML Distilled_ A Brief Guide - Lenny Delligatti''. Page 12</ref>		'''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(kilde). 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. <ref>SysML Distilled_ A Brief Guide - Lenny Delligatti''. Page 12</ref>

	==Limitations==		==Limitations==

S153408: /* Introduction to requirements management */

2019-03-04T22:53:22Z

Introduction to requirements management

← Older revision		Revision as of 22:53, 4 March 2019
Line 4:		Line 4:
	== Introduction to requirements management==		== 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.'''" <ref> ISO 21500 Project Management Page 3 </ref>		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.'''" <ref> ISO 21500 Project Management Page 3 </ref>
	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 ~~analyse~~ change and achieve ~~traceabilty~~. <ref >PMBOK''. 5.1.3.2 Requirements Management Plan, Page 137</ref>		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. <ref >PMBOK''. 5.1.3.2 Requirements Management Plan, Page 137</ref>

	Maintaining and organizing requirements is a non-trivial endeavor, as the term "requirement" covers a wide variety of properties of a project involving everything ~~funcitonal~~/non ~~function~~ requirements related to a physical ~~capabilities~~ of systems, but also to business objectives, use-case scenarios or even transitioning requirements, just to mention a few ~~(See figure X for examples hereto)~~. The complexity can be overwhelming, especially in large scale projects found in automotive, ~~defence~~ 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. <ref>PMBOK''. 5.1.3.2 Requirements Management Plan, Page 137</ref> 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 ~~specificatio~~ during all stages of the project, and at closing to verify that the delivery is as the relevant stakeholder requested and agreed to.		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. <ref>PMBOK''. 5.1.3.2 Requirements Management Plan, Page 137</ref> 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.
	Before digging deeper into SysML in requirements management, one must understand the difference between the document-based and models-based approaches.

	=== Document-based or model-based ===		=== Document-based or model-based ===
	[[Image:Document-based.png‎ \| right\|thumb\| 350px \| Figure 2, Model-based and Document-based approach.]]		[[Image:Document-based.png‎ \| right\|thumb\| 350px \| Figure 2, Model-based and Document-based approach.]]
	====Document-based====		====Document-based====
	In many ~~organisations~~ the requirements ~~mangement~~ 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 ~~synchronisation~~ 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 ~~proces~~ prone to error. Part from the rigor of maintaining these documents through the project, this approach has ~~som~~ fundamental limitation. <ref>A Practical Guide to SysML 2nd''. Page 15</ref> 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.<ref>A Practical Guide to SysML 2nd''. Page 15</ref>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.		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. <ref>A Practical Guide to SysML 2nd''. Page 15</ref> 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.<ref>A Practical Guide to SysML 2nd''. Page 15</ref>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.

	====Model-based====		====Model-based====

S153408: /* Abstract */

2019-03-04T22:45:19Z

Abstract

← Older revision		Revision as of 22:45, 4 March 2019
Line 1:		Line 1:
	== Abstract ==		== 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 to 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, 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 ~~endeavour~~ 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 ~~regards~~ to; harnessing complexity, reducing risk, and communicating effectively with stakeholders and the project team.		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 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.

	== Introduction to requirements management==		== Introduction to requirements management==

S153408 at 22:41, 4 March 2019

2019-03-04T22:41:03Z

Show changes

S153408: /* Introduction to requirements management */

2019-03-04T22:38:07Z

Introduction to requirements management

← Older revision		Revision as of 22:38, 4 March 2019
Line 3:		Line 3:

	== Introduction to requirements management==		== 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.'''" <ref ISO 21500 Project Management Page 3 </ref>		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.'''" <ref> ISO 21500 Project Management Page 3 </ref>
	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 analyse change and achieve traceabilty. <ref name="PMI PMBOK">PMBOK''. 5.1.3.2 Requirements Management Plan, Page 137</ref>		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 analyse change and achieve traceabilty. <ref name="PMI PMBOK">PMBOK''. 5.1.3.2 Requirements Management Plan, Page 137</ref>