Scribd
Upload
26 views3 pages

IDM template-ExchangeRequirements

This document provides a template for creating exchange requirements with guidance. Elements in angle brackets (<...>) should be replaced with specific text. Italicized and boxed elements are for guidance and should be removed. The template includes sections for general information, preconditions, parts and concepts with required information, and an example table of information requirements. The purpose is to enable the standardized exchange of information between systems.

Uploaded by

ALUÍZIO FERREIRA DOS SANTOS FILHO
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
26 views3 pages

IDM template-ExchangeRequirements

This document provides a template for creating exchange requirements with guidance. Elements in angle brackets (<...>) should be replaced with specific text. Italicized and boxed elements are for guidance and should be removed. The template includes sections for general information, preconditions, parts and concepts with required information, and an example table of information requirements. The purpose is to enable the standardized exchange of information between systems.

Uploaded by

ALUÍZIO FERREIRA DOS SANTOS FILHO
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

In this exchange requirement template, headings that should be retained are not surrounded by < ..

>, not in italic text


and are not contained in a comment box(such as this box).
Elements that are within <…> should be replaced by user defined or developed text
Elements in italic and marked, coloured comment boxes are for guidance and should be removed from the final version.
Delete this box from the final version.

Exchange Requirement

Name <replace with name of exchange requirement without er_ prefix>

Identifier <give the exchange requirement a unique identifier>

Change Log
<yyyy-mm-dd> <action> <author email address>

Project Stage 0 Portfolio requirements 


<omit  for 1 Conception of need 
not relevant 2 Outline feasibility 
stages and 3 Substantive feasibility 
omit this text> 4 Outline conceptual design 
5 Full conceptual design 
6 Coordinated design and procurement 
7 Production information 
8 Construction 
9 Operation and maintenance 
10 Disposal 

Overview
Provide a textual overview of the exchange requirement under the headings Scope, Description and Information
Description. This should be non technical, written at a ‘business’ level and targeted to the ‘executive user’

Scope
<Define the scope of the exchange requirement>
e.g. ‘The scope of this exchange requirement is to enable the exchange of information about the Estimated Service Life
of a type or occurrence of an element or product.’

General Description
<Provide a simple to understand description of how the exchange requirement will meet the scope>
This should give a scenario of the need for the exchange requirement and provide useful information of the approaches,
codes, standards and other references it will apply e.g. ‘Estimated Service Life (ESL) is the service life that a product or
parts of a product would be expected to have in a set of specific in use conditions calculated by adjusting the reference
in use conditions in terms of materials, design, environment, use and maintenance….. (etc.)

Information Description
<Provide a simple listing of the information that will be handled through the exchange requirement>
This should be an annotated bullet list e.g.
Information required concerning the external library reference includes:
 Name of the library
 Publisher or authority responsible for making it available
 Version number or reference
In this exchange requirement template, headings that should be retained are not surrounded by < ..>, not in italic text
and are not contained in a comment box(such as this box).
Elements that are within <…> should be replaced by user defined or developed text
Elements in italic and marked, coloured comment boxes are for guidance and should be removed from the final version.
Delete this box from the final version.

Information Requirements

Preconditions
<What information needs to exist or what actions need to have been achieved before this exchange requirement can take
place. >
Typically, what is (are) the immediately preceding exchange requirement(s) from which required information should be
available

<Part Name>
<Name each part>
A part is a set of information that achieves a specific purpose or function within this exchange requirement and should
be named to indicate what it does e.g. Select Object, Assign To Group, Associate Library Reference. An exchange
requirement is expected to consist of many parts.

<Describe the purpose of the part>.


Each part should have a simple description of its purpose e.g. for the part Select Object, this could be ‘Physical objects
are the actual elements and products that are to have a service life assigned’

<[Concept Name]>
<Name each concept within a part. >
A part may contain a set of named sub parts or concepts e.g. for Associate Library Reference, the concepts Library
Reference, Library Information and Library Association may apply.

<Describe the purpose of the concept.>


Each concept should have a simple description of its purpose e.g. for the concept [LibraryReference], this could be
‘Reference to an external data source from which service life information is obtained’

<Provide a table with the set of information requirements for each concept.>
Below is an example of how a table might look. It contains the ‘ideas’ or ‘the information to be exchanged’ together
with a non technical description for each idea. This is a minimal set of information needed. More can be given and the
table can be extended
Idea Explanation
Select Select the objects that are to have the service life assigned.
Objects
For Estimated Service Life, the object(s) selected will be occurrences of products of a particular type.
Occurrences will be collected into groups for easier referencing.
Since the physical objects exist (by design), they already have globally unique identity and owner history.
Physical objects may have a name whose provision is required by other exchange requirements. It is not a
specific need for service life planning and therefore, the name attribute of physical objects should not be
In this exchange requirement template, headings that should be retained are not surrounded by < ..>, not in italic text
and are not contained in a comment box(such as this box).
Elements that are within <…> should be replaced by user defined or developed text
Elements in italic and marked, coloured comment boxes are for guidance and should be removed from the final version.
Delete this box from the final version.

changed through this exchange requirement.


Physical objects may have a description whose provision is required by other exchange requirements. It
is not a specific need for service life planning and therefore, the description attribute of physical objects
should not be changed through this exchange requirement.

… end of table example.

You might also like