4.2Design
Naturally each airport or IT partner will have their own established way of addressing an airport’s requirements and developing those requirements into what will be a contracted solution. However, an airport requires a rigorous, legal, and fair way of evaluating different designs and proposals so that it can select the most effective design for its own purpose.
To get the best out of any vendor’s bidding team, the more creativity that can be encouraged, the better. This lends itself well to specifying a functional solution, rather than specifying a particular design with pre-identified components.
The more a vendor sees that a design is built around a specific component, the less the chance you have of getting a fair market price for the functionality.
4.2.1The End-to-End Process
In order to develop a good design, keep the end game in sight. This is the desired outcome that is ideally expressed in terms of metrics that signify success, e.g., 10,000 passengers an hour throughput, with each passenger boarded costing $5 for IT&S, 50,000 bags an hour, 1,000 vehicles an hour, etc. The more an IT project ties to a business outcome, the better the chance of successfully implementing it.
4.2.2Benchmarking
Another thing that is often overlooked in IT&S systems, is the ongoing running costs. This is often referred to as the Total Cost of Ownership (TCO). The goal is to identify an acceptable cost of operation. Airports should not be shy in benchmarking costs with similar industries or concerns and using this as a target when developing a scope of work. This will help plan for vendor costs and internal costs, as well.
This is also an important point for airport CFOs. If this type of objective is not set correctly, then an airport’s IT department could become a large entity in its own right—it is unlikely the CIO will suggest outsourcing it.
4.2.3Setting the Baseline, Including Glossary & Terminology
All good designs need a consistent frame of reference. This will allow different parties to communicate effectively with each other and prevent misunderstandings. A glossary of terms should be published with pre-identified units of measures (e.g., Kva, etc.) and the acceptable quality standards (e.g., UL, BSA, etc).
4.2.4System Requirements/Design Specification Guidelines
IT&S projects should start out meeting system requirements which reflect the business objectives for the system/solution. System requirement specifications ensure building needs are met and design guidelines and specifications are in line.
The following is an outline to assist IT&S in developing these specifications:
The typical contents of a system requirements specification include:
-
Front Matter:
-
Title Page:
-
Executive Overview
-
Information Page:
-
Revision History
-
Approval Signatures
-
Location of Signed Original
-
Distribution List
-
Table of Contents
-
Table of Figures
-
Introduction:
-
Document Definition
-
Document Objectives
-
Intended Audience
-
References
-
Document Overview
-
System Definition
-
Business Goals
-
Business Objectives
-
System Context
-
Summary of System Capabilities
-
External (Actor) Types:
-
Externals (e.g., Actors):
-
Requirements Data Model
(e.g., Business Object Model or Logical Data Model)
-
Required Data Type Descriptions
(e.g., data dictionary with textual definitions and associated data expressions, XML DTDs)
-
Developer-Oriented Quality Requirements:
-
Maintainability
-
Correct ability
-
Extensibility
-
Portability
-
Reusability
-
Scalability
-
Testability
-
User-Oriented Quality Requirements:
-
Audit Ability
-
Branding
-
Capacity
-
Configurability:
-
Internationalization
-
Personalization
-
Variant Capabilities
-
Correctness:
-
Latent Defect
-
Accuracy
-
Precision
-
Timeliness
-
Dependability:
-
Defensibility:
-
Safety
-
Security:
-
Access Control:
-
Identification
-
Authentication
-
Authorization
-
Immunity
-
Integrity
-
Intrusion Detection
-
Non-repudiation
-
Privacy
-
Security Auditing
-
Survivability
-
Physical Protection
-
System Maintenance Security
-
Operational Availability
-
Reliability
-
Robustness
-
Efficiency
-
Interoperability
-
Operational Environment Compatibility
-
Performance:
-
Jitter
-
Latency
-
Response Time
-
Schedulability
-
Throughput
-
Utility:
-
Accessibility
-
Installability
-
Operability
-
Transportability
-
Usability
-
Physical Constraints
-
Business Rules:
-
Calculations
-
Logical Constraints
-
Logical Inferences
-
Physical Facts
-
Triggering Events
-
System Component Specific Constraints:
-
Data and Content Constraints
-
Hardware Constraints
-
Software Constraints
-
Personnel Constraints
-
Industry Standards
-
Legal and Regulatory Constraints
-
Production Environment Constraints
-
Envisioned Future Enhancements
-
Tentative Requirements
-
Desirable Functional and Nonfunctional Capabilities (“should”)
-
Nice to Have Capabilities
-
Permitted Capabilities (“may”, if any)
-
Rejected “Requirements” (e.g., out of scope or inconsistent)
-
Major Issues
-
Major Items To Be Determined
-
Assumptions
The following is a generic outline that could be used for an IT&S Design Specification. It is not intended to be complete but provides the key areas which the specification needs to address:
-
Introduction
-
System Overview
-
Design Considerations
-
Assumptions and Dependencies
-
General Constraints
-
Goals and Guidelines
-
Development Methods
-
Strategy 1 name or description
-
Strategy 2 name or description
-
...
-
Component 1 name or description
-
Component 2 name or description
-
...
-
Design Policies and Tactics
-
Policy/Tactic 1 name or description
-
Policy/Tactic 2 name or description
-
...
-
Module 1 name or description
-
Module 2 name or description
4.2.5Objectives
The purpose of the design phase is to develop the most efficient and productive design solution for the airport IT&S project based on the baseline system requirements document. The design effort can be broken into phases reflecting the progress of the design effort, such as 30, 60, 90, and 100 percent design completion phases. Actual phasing definition is left up to the airport operator, based on specified requirements. The more complex the project, the better it may be to use a phased-design approach.
4.2.6Key Elements
The key elements of the design effort of an IT&S project focus on functional and performance systems requirements and decomposition of the system architecture. As a result, the typical IT&S project will include the following design elements:
-
System Design Phase (30 percent)
-
Preliminary Design Phase (60 percent)
-
Detailed Design Phase (90-100 percent)
Share with your friends: |
