AIDM Project and CR Templates

The Airline Industry Data Model (AIDM) methodology defines an agile, model driven approach to building modern data exchange standards under the Passenger Standards Conference

Business and technical groups work together in order to build the necessary messages to support the standard.

A common Change Request template is used to introduce an issue and to develop a proposal, and this template is used throughout the lifecycle of a proposal from development to endorsement.

To initiate a new Request you may use the following template then submit it to your IATA Standards secretary for Triage into the respective group.

Note: this template is the minimum required information to raise a change into PSC Standards, modeling activities will be documented later using AIDM templates (see below) and soon will be captured in the IATA Jira workflow

Download the AIDM BRD and CR Templates documents from the .zip file below.

The AIDM BRD and CR templates to develop Data Standards Messages Exchanged by project stages:

The templates are being continuously refined based on user experiences.

Instructions

Use the BRD or CR templates, that have been developed for the data model as the starting point for all projects in need of new XML messages.

Change Request (Request for change existing standards)

This form should be selected when a change is required on a existing data message standards, the aim is to request an enhancement or correction with minimum information by reuse existing documentation and highlight the necessary changes.

Stage 1: Project Initiation

In this stage, the initiation needs to collect basic information about the project, its objectives, expected benefits, resources required to develop the standard and approximate timelines. The project team is established at the conclusion of this stage.

This step of ATSB (ex PADIS) methodology is new. It was introduced to provide more predictability in the entire message development process. Introduction of this step received strong support of the PSC Steering Group in June 2014.

Stage 2: Business Requirements and Modeling
Business Requirements should be written in a manner that is understandable to a 3^rd person, such as business or data analyst, who may not be an expert in the business area covered by this document.

Compared to the previous BRD template, this template was simplified and restructured into two parts.

Part 1 (sections 1 – 5) allows the business users, who are generally not used to follow a highly structured and formalized approach, to articulate business requirements without unnecessary formal constraints before starting any formal analysis or modeling activity starts. During this phase, the business users are also expected to collect and provide all reference information that will be required for further analysis and modelling. This information is collected in a word document (or similar).
Part 2 (sections 6-7) requires support by a trained Data modeler who is expected to develop all diagrams based on the input from the business users directly in the AIDM. The completion of the Business modeling diagram (developed using BPMN 2.0) with associated Business keys data and Business Use cases is a mandatory component of a BRD submission for all new XML schemas or JSON Messages before data modeling gap assessment within AIDM Data Models and API Development. Business users are required to validate all work produced by the Data modeler.

Stage 3: Modeling and detailed analysis of non-functional requirements

This stage represents all the detailed work needed to analyze the requirements and convert them into a “solution”. This stage involves data modelling on the logical layer, message modeling as well as structured analysis of non-functional requirements. Most of the work will be driven by individuals with expertise to document analyze and model business requirements. However, business users must provide necessary input in order to ensure that all data and their relationships are modelled and validate all the results.

Data modeling includes documenting the hierarchical structure of data, all relationships between data and the nature of the relationship; documenting the type of each data item, e.g. alphabetic, numeric, alphanumeric and length of characters and applicable codes for data whose type is defined in a code list or enumeration. This activity will take place directly in the model.

Message modelling includes documenting which data elements of the data model are to be included in each message, in what sequence, and the number of times a piece of data, or a grouping of data, may be required/repeated and documenting the status of the data as being either mandatory, conditional or optional. Mandatory means always required and conditional means required depending on the conditions. This activity will take place directly in the model.

Stage 4 & 5 are not included in the templates