Enterprise Standards:Requirement Modelling Reference Content - Revision history

Admin at 09:20, 9 January 2017

2017-01-09T09:20:40Z

Admin at 09:14, 9 January 2017

2017-01-09T09:14:58Z

Admin at 09:12, 9 January 2017

2017-01-09T09:12:12Z

90.185.212.37 at 11:46, 1 September 2015

2015-09-01T11:46:05Z

90.185.212.37 at 11:45, 1 September 2015

2015-09-01T11:45:39Z

Dobromir.orpheus at 13:50, 17 August 2015

2015-08-17T13:50:31Z

Dobromir.orpheus at 13:49, 17 August 2015

2015-08-17T13:49:52Z

Dobromir.orpheus at 14:29, 10 August 2015

2015-08-10T14:29:22Z

Dobromir.orpheus at 14:27, 10 August 2015

2015-08-10T14:27:32Z

87.121.100.91: Created page with "Category:Enterprise Modelling Standards"

2015-07-13T09:11:40Z

Created page with "Category:Enterprise Modelling Standards"

New page

[[Category:Enterprise Modelling Standards]]

@@ Line 9: / Line 9: @@
 The Requirement Reference Content also provides an overview of the key requirement aspects of the organisation and how they relate to the various business aspects, e.g. organizational construct, competencies, roles, resources, objects, rules, compliance, channel, media as well as reporting. The Requirement Reference Content therefore provides a way of analysing, appraising, approximating, assessing and capturing requirement related objects to enable innovation and transformation.
-'''Documentat''': [[Media:LEADing Practice Requirement Modelling REFERENCE CONTENT-LEAD-ES20012BC.pdf.pdf|Download the Requirement Modelling Reference Content document]]
+'''Documentat''': [[Media:LEADing Practice Requirement Modelling REFERENCE CONTENT-LEAD-ES20012BC.pdf|Download the Requirement Modelling Reference Content document]]
 [[Category:Enterprise Standards]]

← Older revision		Revision as of 09:14, 9 January 2017
Line 8:		Line 8:

	The Requirement Reference Content also provides an overview of the key requirement aspects of the organisation and how they relate to the various business aspects, e.g. organizational construct, competencies, roles, resources, objects, rules, compliance, channel, media as well as reporting. The Requirement Reference Content therefore provides a way of analysing, appraising, approximating, assessing and capturing requirement related objects to enable innovation and transformation.		The Requirement Reference Content also provides an overview of the key requirement aspects of the organisation and how they relate to the various business aspects, e.g. organizational construct, competencies, roles, resources, objects, rules, compliance, channel, media as well as reporting. The Requirement Reference Content therefore provides a way of analysing, appraising, approximating, assessing and capturing requirement related objects to enable innovation and transformation.
		+
		+	'''Documentat''': [[Media:LEADing Practice Requirement Modelling REFERENCE CONTENT-LEAD-ES20012BC.pdf.pdf\|Download the Requirement Modelling Reference Content document]]
		+
		+	[[Category:Enterprise Standards]]

@@ Line 1: / Line 1: @@
 {{DISPLAYTITLE:Requirement Modelling Reference Content}}
-<blockquote>
+== Introduction ==
-''A requirement is an agreed upon need and want to which a business or project outcome (solution/product or service) should conform.''
-</blockquote>
-Requirement Modelling is the addressing of requirements through a lifecycle of requirement analysis, requirement formulation/design, the implementation and thereby the governance of the requirements as well as continuous improvement of requirements, all triggered by an insight, event, or condition with respect to the business.
+The LEADing Practice Requirement Reference Content provides requirement ontology with its requirement description, specific requirement semantic relations and correlations. It is based on a collection of best and leading practice around how to work with requirements within enterprise modelling, enterprise engineering and enterprise architecture disciplines.
-In the LEADing Practice Requirement Modelling Reference Content, requirements are classified at two different levels:
+The Requirement Reference Content is therefore and essential part for any practitioner working with and around requirement aspects. It provides a structural way of thinking, working, modelling, implementation and governance around requirement definitions, and how requirements are applied within business functions, services, processes as well as applications.
-# High-level requirements, which are primarily business specific; and
-# Detailed requirements, which are mostly function-specific and generally relate to product requirements.
-Typically, the different LEAD eXperts and architects working within their specific modelling principles would use the LEADing Practice Requirement Reference Content to map the high-level and detailed requirements to the different LEAD layers (e.g. business, application and technology). This is done to determine the implications of above requirement classification areas in the different layers of the LEAD architecture. The purpose of allocating the identified requirements into the layers is to ensure an organization documents, verifies and meets the needs and expectations of both the stakeholders and the organization's goals, competencies, services, processes, applications, data, platforms, and technology.
+The Requirement Reference Content also provides an overview of the key requirement aspects of the organisation and how they relate to the various business aspects, e.g. organizational construct, competencies, roles, resources, objects, rules, compliance, channel, media as well as reporting. The Requirement Reference Content therefore provides a way of analysing, appraising, approximating, assessing and capturing requirement related objects to enable innovation and transformation.
-−
-=== Decomposition & Composition of Requirements ===
-[[File:LEAD-Requirements-Reference-Method-Decomposition-Composition-of-Requirements.png|900px]]
-−
-The LEADing Practice Requirements Decomposition & Composition provides a comprehensive framework for requirement connections and relations and helps embed the following three approaches:
-−
-# [[Enterprise Requirement Management|Enterprise Requirement Management]] in Blueprinting;
-# [[Enterprise Requirement Management in Build/Implementation|Enterprise Requirement Management in Build/Implementation]]; and
-# [[Enterprise Requirement Management in Governance/Continuous Improvement|Enterprise Requirement Management in Governance/Continuous Improvement]].
-−
-Requirements related within the LEADing Practice Blueprinting Approach, LEADing Practice Build Approach and LEADing Practice Continuous Improvement Approach can be analyzed for alignment with business goals as well as IT goals and support impact analysis so you can see what effect a change will have before you make it. Therefore in the LEADing Practice Way of Modelling with requirements, the above classification and LEADing Practice Requirement Decomposition into the layers is mostly done in the LEADing Practice Blueprinting, Build and Continuous Improvement Approach as the high-level requirements are decomposed in the areas of business, application, data, platform and infrastructure and then used as inputs into the different decomposition areas .
-−
-The detailed requirements that need to be identified in the business, application, data, platform, and infrastructure area are being applied to the specific composition areas.

@@ Line 14: / Line 14: @@
 === Decomposition & Composition of Requirements ===
-[[File:LEAD-Requirements-Reference-Method-Decomposition-Composition-of-Requirements.png|400px]]
+[[File:LEAD-Requirements-Reference-Method-Decomposition-Composition-of-Requirements.png|900px]]
 The LEADing Practice Requirements Decomposition & Composition provides a comprehensive framework for requirement connections and relations and helps embed the following three approaches:

@@ Line 1: / Line 1: @@
 {{DISPLAYTITLE:Requirement Modelling Reference Content}}
 <blockquote>
 ''A requirement is an agreed upon need and want to which a business or project outcome (solution/product or service) should conform.''
 </blockquote>
 Requirement Modelling is the addressing of requirements through a lifecycle of requirement analysis, requirement formulation/design, the implementation and thereby the governance of the requirements as well as continuous improvement of requirements, all triggered by an insight, event, or condition with respect to the business.
-<br/><br/>
 In the LEADing Practice Requirement Modelling Reference Content, requirements are classified at two different levels:
 # High-level requirements, which are primarily business specific; and
 # Detailed requirements, which are mostly function-specific and generally relate to product requirements.
-<br/>
 Typically, the different LEAD eXperts and architects working within their specific modelling principles would use the LEADing Practice Requirement Reference Content to map the high-level and detailed requirements to the different LEAD layers (e.g. business, application and technology). This is done to determine the implications of above requirement classification areas in the different layers of the LEAD architecture. The purpose of allocating the identified requirements into the layers is to ensure an organization documents, verifies and meets the needs and expectations of both the stakeholders and the organization's goals, competencies, services, processes, applications, data, platforms, and technology.
-<br/>
 === Decomposition & Composition of Requirements ===
 [[File:LEAD-Requirements-Reference-Method-Decomposition-Composition-of-Requirements.png|400px]]
-<br/><br/>
 The LEADing Practice Requirements Decomposition & Composition provides a comprehensive framework for requirement connections and relations and helps embed the following three approaches:
-<br/>
 # [[Enterprise Requirement Management|Enterprise Requirement Management]] in Blueprinting;
 # [[Enterprise Requirement Management in Build/Implementation|Enterprise Requirement Management in Build/Implementation]]; and
 # [[Enterprise Requirement Management in Governance/Continuous Improvement|Enterprise Requirement Management in Governance/Continuous Improvement]].
-<br/>
 Requirements related within the LEADing Practice Blueprinting Approach, LEADing Practice Build Approach and LEADing Practice Continuous Improvement Approach can be analyzed for alignment with business goals as well as IT goals and support impact analysis so you can see what effect a change will have before you make it. Therefore in the LEADing Practice Way of Modelling with requirements, the above classification and LEADing Practice Requirement Decomposition into the layers is mostly done in the LEADing Practice Blueprinting, Build and Continuous Improvement Approach as the high-level requirements are decomposed in the areas of business, application, data, platform and infrastructure and then used as inputs into the different decomposition areas .
-<br/><br/>
 The detailed requirements that need to be identified in the business, application, data, platform, and infrastructure area are being applied to the specific composition areas.

← Older revision		Revision as of 14:27, 10 August 2015
Line 1:		Line 1:
	[[Category:Enterprise Modelling Standards]]		[[Category:Enterprise Modelling Standards]]
		+	{{DISPLAYTITLE:Requirement Modelling Reference Content}}
		+	<blockquote>
		+	A requirement is an agreed upon need and want to which a business or project outcome (solution/product or service) should conform.
		+	</blockquote>
		+	Requirement Modelling is the addressing of requirements through a lifecycle of requirement analysis, requirement formulation/design, the implementation and thereby the governance of the requirements as well as continuous improvement of requirements, all triggered by an insight, event, or condition with respect to the business.
		+	<br/>
		+	In the LEADing Practice Requirement Modelling Reference Content, requirements are classified at two different levels:
		+	<br/>
		+	# High-level requirements, which are primarily business specific; and
		+	# Detailed requirements, which are mostly function-specific and generally relate to product requirements.
		+	<br/>
		+	Typically, the different LEAD eXperts and architects working within their specific modelling principles would use the LEADing Practice Requirement Reference Content to map the high-level and detailed requirements to the different LEAD layers (e.g. business, application and technology). This is done to determine the implications of above requirement classification areas in the different layers of the LEAD architecture. The purpose of allocating the identified requirements into the layers is to ensure an organization documents, verifies and meets the needs and expectations of both the stakeholders and the organization's goals, competencies, services, processes, applications, data, platforms, and technology.
		+	<br/>
		+	=== Decomposition & Composition of Requirements ===
		+	[[File:LEAD-Requirements-Reference-Method-Decomposition-Composition-of-Requirements.png]]
		+	The LEADing Practice Requirements Decomposition & Composition provides a comprehensive framework for requirement connections and relations and helps embed the following three approaches:
		+	<br/>
		+	# [[#\|Enterprise Requirement Management]] in Blueprinting;
		+	# [[#\|Enterprise Requirement Management in Build/Implementation]]; and
		+	# [[#\|Enterprise Requirement Management in Governance/Continuous Improvement]].
		+	<br/>
		+	Requirements related within the LEADing Practice Blueprinting Approach, LEADing Practice Build Approach and LEADing Practice Continuous Improvement Approach can be analyzed for alignment with business goals as well as IT goals and support impact analysis so you can see what effect a change will have before you make it. Therefore in the LEADing Practice Way of Modelling with requirements, the above classification and LEADing Practice Requirement Decomposition into the layers is mostly done in the LEADing Practice Blueprinting, Build and Continuous Improvement Approach as the high-level requirements are decomposed in the areas of business, application, data, platform and infrastructure and then used as inputs into the different decomposition areas .
		+	<br/>
		+	The detailed requirements that need to be identified in the business, application, data, platform, and infrastructure area are being applied to the specific composition areas.