The document discusses using operational and functional analysis techniques from systems engineering to effectively capture requirements prior to project bidding. It begins with an introduction on the importance of fully capturing requirements upfront. It then provides an overview of the requirements capture process using these techniques, which involves analyzing operational scenarios, stakeholders, and functional requirements. A case study on developing a mission computer for an aircraft is presented to illustrate applying these techniques. Key activities in operational analysis like identifying scenarios, stakeholders, and requirements flow are described.

1. 1 Page

2. Use of Operational and Functional
Analysis in Effective Requirements
Capture
Prabhakar A Mandakolluthur – Advisor, Tata Consultancy Services

3. Contents
1. Introduction ................................................................................................................................... 4
2. System engineering methodologies for requirements capture: ............................................ 4
3. Case Study – Mission Computer for a Transport Aircraft ...................................................... 6
4. Operational Analysis.................................................................................................................... 7
5. Training Scenario Analysis ....................................................................................................... 14
6. Regular Flight ............................................................................................................................. 15
7. Conclusion: ................................................................................................................................. 21
8. Author’s Profile: .......................................................................................................................... 24
3 Page

4. 1. Introduction
It is well known that the some of the major reasons for a project’s time and cost over runs are scope
increase and changes in requirements as it progresses. This happens due to the inability of both the
customer and the vendor to fully and exactly capture the requirements apriori. Such an exercise in
requirements capture is easier said than done. Not all product developments can be executed in a
spiral model or in an agile manner, which can take advantage of progressive elaboration of the
requirements that occur, as a project progresses. In such situations, it is essential that full and exact
requirements be captured to the extent possible, prior to the submission of the bid itself, let alone at
the beginning of the project. Fortunately, we can draw upon the techniques of ‘Operational and
Functional Analysis’ adopted by the ‘System Engineering’ profession. These two techniques allow
us to arrive at a near final set of requirements in a graded and iterative manner. This paper describes
the methods, objectives and the processes involved in ‘Operational and Functional Analysis’ in
effective Requirements Capture. A case study from aerospace sector is included in this paper to
illustrate the principles involved.
Compulsions of Getting the Requirements Right: Many factors contribute to the requirements not
being captured correctly which lead to, erroneous estimations and hidden costs, that are likely to
surface at a later stage. Traditionally, customer drafted formal RFP imposes a rigid set of conditions
on a project’s execution, such as rigorously defined tasks, schedules and milestones, coupled
generally with an attempt to exhaustively list the final specifications of the product. This problem gets
more acute in government contracts where open competitive bidding is involved. Consider the
situation in a country, such as India, wherein the bidders to the contract have to comply with strict
procedures during the bid process, but also have recourse to appeal to higher courts of justice, if they
fail to win a contract. Even genuine scope and cost escalation cannot be awarded after contract
signing without going through an elaborate process. This is out of an apprehension that someone can
raise an objection if bid amount is increased after contract award .It is indeed a tough balancing act,
to be declared the lowest bidder and also to ensure that Time and Cost are not under estimated. This
means that, more accurate one is in the requirement capture process the better will be the chances
that one is declared the lowest bidder. It also allows us to keep costs within estimates made, as early
as bid submission stage. Failure to do so will result in following familiar situations:
a. High level of stress created due to the anxiety in ensuring that the bid submitted is correctly
estimated.
b. Severe conflicts between customer and vendor in accommodating the scope increase or
change requirements within existing budget vis a vis cost and time increase.
c. Increase in Cost of Poor Quality due to rework that follows discovery of unavoidable new or
on foreseen requirements
d. Frantic efforts towards the end to complete the project as scheduled due to delays caused by
scope increase and rework
e. Some annoyed stakeholders who do not see their requirements considered in the first place
or inadequately addressed.
Value Addition: It is to be noted that requirements need not always be captured with a negative view
to keep costs within estimated limit. It can also be used to add value to the project / product outcome.
Elements and features that can be value added will come out as a result of applying System
Engineering principles.
2. System engineering methodologies for requirements
capture:
4 Page

5. The most important use of SE is to arrive at a robust System Architecture that best meets stated
requirements at the highest level of integrity of the product to be delivered. It is obvious that the first
instance of a System Architecture will be dependent on the High Level customer’s requirements. . But
the Final System Architecture is not arrived at solely based on these requirements. Additional inputs
are gathered by analysing all environments and context in which the intended product operates in.
Two essentials methods by which we gather further inputs are Operational and Functional Analysis.
These help in understanding the needs of the customer and help analyse the requirements better.
With this better understanding of requirements, it is possible to create a System Architecture that will
address the customer needs in much better manner. This exercise can be done in a recursive
manner, in as many iterations as desired, to arrive at a greater set of requirements than was originally
stated by the customer. Use of these techniques will be explained further with a case study, later in
this paper, but the Requirement Capturing Process is indicated in Fig 1 below. Please note that this
process tries to address all drawbacks of traditional methods. The next few paragraphs briefly
describe the activities in each block of the process diagram indicated in Fig 1.
Business Customer Regulatory
Requirements Requirements Requirements
Operational
Analysis
Functional
Analysis
Architectural Design Freeze
Analysis & Synthesis
Specifications
System Customer
Specifications Review
Fig 1: Requirement Capturing Process
Business Requirements: This addresses the enterprise level requirements of the product under
development. These will be mainly high level concerns such as commonality with rest of the fleet,
additional infrastructure requirements needed for maintenance, whether the product attract export
controls and technology denial regimes etc.
Customers Requirements: Customer’s requirements are generally stated in the formal document
issued by the customer such as the RFP and SoW. The extent of details contained in these will vary
very widely, from customer to customer. It should be ensured that all clauses in these documents are
5 Page

6. mapped to the final System Requirements document. What is not possible to include will also be
clearly brought out during Operational Analysis which can then be negotiated with the customer.
Regulatory Requirements: Almost all products, especially high technology products, are subject to
some form of governmental regulations or the other. Some examples are FAA, DGCA, IRS,
Emission Standards, RoHS, and WEEE etc. These constraints are taken into account in accordance
with relevant Regulatory Publications.
Operational Analysis: Operational Analysis is an important exercise for capturing unstated
requirements. Such analysis recognizes that a product operates in various regimes from the time it is
developed to the time it is retired. It also makes us examine various environments it operates in and
all the entities it has to interface with. All the stakeholders involved in its lifecycle can also be
identified. In short, Ops Analysis it leads us to true customer requirements.
Functional Analysis: helps us translate the requirements generated by Operational Analysis into a
functional model. This functional model does not concern itself with the solution to meet the
requirement. It only indicates the behaviour expected from the model irrespective of the nature of the
module such as hardware, software, firmware etc. Though Functional Analysis takes us closer to the
Final System Architecture and hence it is more of a System Design Tool. It nevertheless reveals the
complexities and the conflicts involved between stated requirements and practical realities. It is
therefore an important step, for rationalising amongst competing requirements. It also helps us
identify Requirements Coupling, which means that it identifies modules that serve a common purpose
during various operating regimes.
System Architecture Analysis & Synthesis: System Architecture lays the foundation for making the
right decisions for system partitioning and resource allocations for lower level activities such as
hardware, Software, Firmware etc. This is possible because System Architecture can be decomposed
(System Analysis) into sub systems and modules and requirements can then be allocated to them
individually. We can have bottoms up approach also; wherein lower level systems can be integrated
in a cumulative manner (System Synthesis) to understand the cumulative behaviour of inter
dependant subsystems. Not only that, it is possible to roll up the requirements allocated at the lower
system levels and consolidate a set of requirements for the highest level of integrity of the system to
be delivered. It is not necessary to assign lower level sub systems or modules to hardware or
software partitions at the first iteration of System Analysis. Such assignment can await many
iteration of System Analysis and Synthesis. It is not the aim of this paper to explain the System
Engineering Principles but only to adopt such techniques that are followed in its practice that can be
applied to overcome the drawbacks of traditional requirements capture.
3. Case Study – Mission Computer for a Transport Aircraft
Preamble: As indicated above the Operational Analysis and Functional Analysis processes will be
explained using a case study from the Aerospace and Defence Industry. It is obvious a full analysis
as in a real case cannot be done and presented in this paper. For the purpose of illustration , let us
assume that the product to be developed is a Mission Computer that will host , multiple software
applications, each of which, in turn control varied equipment and sensors on a transport aircraft .
(Integrated Modular Avionics Concept) It may be noted that the Operational and Functional
Analysis is better done in graphic form as text based documentation is not as effective to
communicate user and system requirements for complex systems. However, results of the analysis
will be captured in Text / Tabular form for ease of checking and enumeration. It is cautioned once
again, that a full fledged Ops & Functional analysis cannot be included in this paper. Hence only
6 Page

7. partial analysis by way of few examples of operating regimes of the Mission Computer will be
included for giving an idea of the principles involved.
Objectives of Operational Analysis: The main objectives of Operational Analysis are to capture and
clarify product requirements and stakeholders’ expectations, by examining the environment in which it
operates in all its life cycle phases. It overcomes the shortcomings of Requirements Capture
Process that is solely based on customer’s formally stated requirements. It specifically helps in the
following:-
a. Customer’s actual needs may not be the same as those stated in his formal requirements.
Generally it is greater. If this gap is left undiscovered, it is progressively stumbled upon in
parts, much after contract award leading to scope increase and change requests without time
& cost allowed to be increased.
b. Requirements of all the stakeholders in the customer’s organisation are captured.
Normally, the person designated as the ‘Buyer’ in a user’s organisation gets ‘listened to’ the
most. It is essential to keep in mind that the buyer may not be the sponsor, the user and the
fixer all rolled into one, even though we may treat him so, on a daily basis. One must be
aware of all the stake holders associated with a project.
c. System Decomposition: For the sake of cost and time estimates, stated requirements are
decomposed and sub estimates are made for these decomposed requirements. These are
then aggregated to arrive at a total figure. So if this exercise is based on a wrong set of
requirements to start with, the project estimates are flawed resulting in high probability of
slippages during execution. A ‘System Decomposition’ approach will yield better results than
such ‘Requirements Decomposition’. Operational Analysis leads us to a System Architecture
that fully supports the product requirements, in the given environment and context. It provides
the inputs to the next step which is Functional Analysis.
d. Requirements flow up and flow down the system hierarchy is often ignored. It is essential to
acknowledge that a system has a hierarchy of sub systems and sub sub systems, modules,
components etc. Any changes in the requirements at one level will affect some or all the
levels above and below it. Operational Analysis captures this flow efficiently and helps us
map requirements of all levels of a System as well Stakeholders hierarchy.
4. Operational Analysis
The activities involved in Operational Analysis are indicated below in Fig 2 below. We will now take
up each of the activity indicated in the boxes in this figure.
7 Page

8. Operational Analysis
Operational Analysis
Boundary Condition Operational Scenario
Analysis Analysis
Analysis
Information Interchange
Information Interchange Mission Scenario
Mission Scenario
Matrix
Matrix Analysis
Analysis
FIG 2: Activities of Operational Analysis
Operational Scenario Analysis: The first step is to examine in detail the entire environment in which
the Mission Computer is expected operate in all its life cycle phases. In doing this, the regimes in
which it operates and the level in the system hierarchy to which it belongs, are identified and the
requirements in each situation are mapped in a Requirement List. Following few paragraphs show
some of the scenarios for the mission computer and the requirements they generate
Capture all High Level Requirements: Consider the requirements that may be imposed by
organisations other than the customer’s immediate establishment. Fig 3 illustrates such linked
interests
Govt Customer Business
/Regulatory
Requirements Requirements
Requirements
Operational
Requirements
Analysis
FIG 3: Requirements Hierarchy
Regulatory Requirements: The Mission Computer will be required to be certified by either civilian
or military certification agencies such as DGCA or CEMILAC etc. Hence additional requirements
stipulated in documents such as RTCA DO 297 or its Indian equivalent will have to be included in our
Requirements Analysis.
Business Requirements: Similarly, Fleet Operators or Airline Operators who are likely to operate
aircraft that will have this Mission Computer fitted will have their own interests. These may be at a
fairly high level such as retrofit in existing fleet, compatibility with other equipment on order etc. At the
8 Page

9. enterprise level IAF and Navy may have a concern about components being used that attract ITAR or
export control laws.
Requirements Flow Up / Flow Down: It is essential to understand at what level does a product
being developed, belongs to, in a system. The definition of a system can include a wide range of
entities, from a simple power supply system to a system of systems such as an aircraft or even a
Fleet of aircraft. Higher the level the product belongs to in a system; more will be its impact on the
absolute whole in which it resides. In this case the Mission Computer belongs to at the vehicle
Integration level (See Fig 4 below) and it is likely to be responsible for many aircraft level functions
such as Flight Controls, Navigation, cabin pressure etc. This means that it has to meet the highest
level of safety criticality for certification purposes (Level A). It also means that it will have numerous
interfaces with other very important equipment in the aircraft. Hence higher the level more thorough
one has to be in Requirement analysis and interface details.
Operational
Regulating Authorities, Airlines, Air
Environment Force, Para Military
Vehicle Integration Level
Eg: IMA in Airbus 380. This could
(Mission Computer belongs here) be studied further as reference
Federated System Level
Older aircraft such as C130
(Combination of units to meet a
Function)
LRU Level
Gyro Compass, GPS, Vertical
(Line Replaceable Unit) Reference System
Component Level
ASIC's, FPGA's, SW Drivers
Fig 4: System Hierarchy
Address all Stakeholders needs: In order to arrive at a Comprehensive set of System requirements
it is imperative to recognize that different stakeholders in the customer’s organization have different
needs according to their roles. For example, such roles can be Buyer (Project Sponsor), Fixer
(Maintainer), User (Pilot) etc. We have already identified some stakeholders in the Regulatory and
9 Page

10. Business Enterprises owning and operating aircraft. But they would only address very high level
requirements. To identify all relevant stakeholders who would be affected at lower levels of
operations, we need to carry out an Operational Analysis as per processes indicated in Fig 2 above.
Operational Scenario Analysis: As mentioned before, the regimes and Environments that the
Mission Computer will operate in its life cycle needs to be identified and the requirements relevant to
that regime or environment need to be captured. Accordingly, a Flow Chart indicating all the
Development Phase
Lab Ground Aircraft Device Flight
Test On Test Test Manufacturing Factory
Ground Application
& Accept
H/W & S/W
Training Developmen
Log Test
t
System Install Post Ware Transit
House
Test Storage
Work shop & Check
Logistics
Commissionin
g Mid Life End Of
Upgrade Life
Flight Operations
Maintenance
Operational Phase
Fig 5: Operational Scenario Analysis – Product Life Cycle
Product Life Cycle Phases is indicated in Fig 5, assuming that the Mission Computer will have
following Life Cycle Phases. (Mid life upgrade and End of life are omitted from detailed analysis)
Product Life Cycle Phases of Mission Computer:
1. Design and Development
2. Flight Test & Certification
3. Manufacturing
10 Page

11. 4. Warehousing & Logistics
5. Initial Installation and Commissioning
6. Training
7. Operational Phase
8. Maintenance
Regimes of Operations of Mission Computer: Analyzing all the situations and environment the
Mission Computer will operate in or just plainly exist, we can identify that it will operate in three
regimes namely Operational Regime, Support Regime and Development Regime. The classification
tree for these regimes and their sub regimes are shown in following paragraphs.
a. Operational Regime: It is clear that when the aircraft is in flight that there is no question of
the Mission Computer not functioning or being switched off. Hence dual or triple redundancy
may be required, with all of them to Level A classification. This is one such requirement that
can be deduced. Another requirement is to figure out what happens to the Mission Computer
or what should it do if the plane is hijacked and the pilot presses the relevant button. We
need to examine in a similar fashion all the other regimes and accumulate requirements that
may be deduced from each situation. Such deductions are listed in cryptic form in the
Appendix A. Similar exercise for few other regimes have been conducted in the following
paragraphs
Operational
Regime
(In Air)
Modes
Normal Degraded Emergency Hijack
Fig 6: Operational Regime
b. Support Regime: It is to be expected that a product cannot be operational throughout its life
time. It will have to be maintained and otherwise supported at various stages. In addition it
will be handled by storekeepers and logistics personnel as well. Apart from this, both the
users and the engineers need to be trained on the Mission Computer.
c. In the case of Mission Computer it might have to be repaired whilst the aircraft is on ground
(AOG) or in a poorly equipped airport. Various sub regimes of the Mission Computer in the
support regime is indicated in Fig 7 below. It can be noted that the support regime has
following sub regimes
i. Manufacturing
ii. Logistics
11 Page

12. iii. Training
iv. Maintenance
These can be further divided as indicated in the Fig 7.
Support
Manufacturing Maintenance Training Logistics
Aircraft Workshop Poorly Storage Identity
Equipped /Aircraft
Airport Profiling
Airport
Ground Air User Maintenance
New Installn
Persons
Fig 7: Support Regimes
It is to be noted that the purpose of Regime breakdown is to identify the functionalities of the Mission
Computer that are to be provided in each lowest level regime that will enable it to operate in that
environment. In listing these functionalities a solution is not sought at this stage. For example in the
figure above, in logistic sub regime, an identity of the MC is to be provided along with a profile of the
aircraft in which it is to be fitted. These are to be electronically burnt in the Mission Computer’s non
volatile memory. We are not concerned at this stage as how this will be achieved such as in a ROM,
Flash memory, BIOS etc. We proceed to capture functions for each regime for the next step which is
functional analysis. Some more sub regimes are analyzed in subsequent operational scenarios, in a
similar manner.
12 Page

13. Logistics Regime
Mfg & Test Transit Storage Prior to Identity /Aircraft
Installation Profile Checks
Short Term
Long Term
Fig 8: Logistic Regime – Factory to Store house
a. Each computer type is uniquely designed for an aircraft. Tagging will help in Aircraft Profiling
details
b. Packing For Transit.
c. Packing For Long Time.
d. Enabling RFID tag or Bar code
e. Provide electronic identity in Non Volatile Memory.
f. How to check before issue for fitment on an aircraft?
New Installation Scenario Analysis
Power Up Ready for IMA
Installation Ground Test
& Test System
& Configuration
Integration
Installation
Inspection
Fig 9: New Installation Regime -Installing for First Time in Aircraft
a. Location of Mission Computer in Plane
b. Best protected environment for Mission Computer on plane and System Environment to be
considered.
c. Support System: Power supply to the System is essential and Failures are unacceptable.
d. Back up plans to supply power to be in place
e. Cooling Air: MISSION COMPUTER is an electronic system and Cooling is very much
necessary to it. Last device to go without controlled air. Bleed air possible?
f. Preventive measures: Fans and conduction cooling are also installed to support the system in
case of cooling air failure.
13 Page

14. g. Vibrations and Shocks: The system is shock mounted to withstand shocks and vibrations in
the aircraft. Special moment is landing.
h. Cable length limitations to be considered and the safe distance between the cables to be
maintained.
5. Training Scenario Analysis
Training based on the MC is given to both the pilot who uses the system and the maintenance team
which will service the system and repair it. See Fig 10.
a. Mission Computer in any case is designed to drive displays and host SW host applications.
Same capability can be used for a simulator that will train persons on the avionics system
which MC forms part of
b. Emulator to feed inputs or real life recordings can fed as inputs
c. Simulation software will be required to run on the MC
d. Can the ATE be used for Training Simulator function?
Display 1
Emulator
Display 2
Simulated
Software on Mission Display 3
Computer
Display 4
Simulation
S/W
Display 5
Mission Analysis: Having identified various regimes and ops scenarios that the MISSION
COMPUTER is expected to function in; the next step is to analyze these sub regimes which may be
termed as Mission Analysis. The most important Mission, of course, would be a Regular Flight
Operation and needs to be analyzed first. A typical Flight Envelope of a Transport Aircraft is indicated
below. Major functions that need to be met by the MISSION COMPUTER in this regime and the
safety issues are captured by careful analysis.
14 Page

15. 6. Regular Flight
Failure of the System is unacceptable.
Redundant Network- To be fail safe another System is kept as reserve.
No Switch to Turn On/Off the System.
Switching-Off the MISSION COMPUTER is not possible or made extremely difficult. Only Pilot has access to
this Switch
Safety Interlock - Switching-Off the MISSION COMPUTER possible only after
CRUISE FLIGHT
Emergency
3Hrs to 4Hrs Condition / Hijack
30,000 ft TO 40,000 ft
TAKE-OFF (-45°C TO -55°C) LANDING
AOG AOG
-10° TO 50°C
A LANDING ROLL B
TAXIING
10 Mins to 3Hrs 15 Mins
Fig 11: Mission Analysis
Emergencies in the System:
The Aircraft goes into emergency state under following conditions:
Mission Computer failure.
Power failure.
Disabled Controls.
Controlled Air failure Lab Trials:
Cooling to the System must be supplied through a duct as it would be done in the aircraft. 28 V DC Power
supply will be required
Ground Trials (AOG):
Applications which are not required to be removed from the system.
For extended checks on Mission Computer consider giving ground based power supply and controlled air.
Aircraft systems cannot be kept running
System Boundary Diagram: As part of Operational Analysis we must also examine in what all
manner and places does the product interfaces with rest of the system it resides in. For this a System
Boundary diagram will be a good tool for analyzing all the interface requirements to be provided
whether they be Mechanical, Electrical or Electronic in nature. This diagram is shown Fig 12 below.
As an example, the Aircraft ECS (Environmental Control System) and Aircraft power interface provide
vital information for the design of the box and power supply circuits of the Mission Computer. It has
15 Page

16. also come out that a portable device such as a laptop would be required for configuring the Mission
Computer in situ when aircraft is on ground. All other boundary interfaces will generate similar
requirements that need to be met.
Displays
+
Controls Communication
IVHMS
Equipment
+
Data Logging
Aircraft Aircraft
ECS Power
Flight Navigation Sys
Mission
INS
Control Computer G P S, Radar
Systems
Structural & Signal
Interfaces
Networking Mechanical
+ Data Loading
Network Interface Test & Configuring
Management Aircraft Systems
Device (Laptop)
Fuel, Flaps,
Engines &
Landing Gear
Fig 12: System Boundary Diagram:
I/ O Matrix: Analysis of the Boundary Conditions will yield details of which information or inputs enters
or is needed by the Mission Computer and where it is coming from. It will also yield the information
about the outputs the Mission Computer will have to give to its neighbouring units in the system. This
can be any information that can be exchanged such as voltage, current, clock speed, dimensions, air
flow etc. All such information is captured in a matrix form shown below.
Table 1: Sample Information Matrix
Regime Information / Input/ Output Interface with
1. Operational  ON/OFF Indication to the Pilot Console. Pilot Console
State  State Information on Pilot's Console.
 Power to the System
2. New 1. FTU/ Display/ LED's. FTU (Field Test Unit
Installation 2. FTU Connect/ Disconnect Indication.
16 Page

17. 3. Security/ Password Protected Access. –Laptop device)
4. Support  Power Supply. Aircraft Systems
Systems  Cool Air.
(Maintenance -  Maintenance mode Trigger from FTU. FTU
AOG)
5. Support Systems 1. Maintenance Mode – Trigger. Internet / VPN
Poorly Equipped 2. Remote Connection through internet
Airport 3. FTU Wired or Wireless Connection – Virtual FTU
Private Network (VPN).
4. Wireless Maintenance Trigger.
Functional Analysis: All the findings and outputs of the Operational Analysis are used as inputs for
Functional Analysis of the Mission Computer in all the regimes and modes. The main objectives of
this analysis are to assign functional behaviour model to the Mission Computer against requirement
deduced during Ops analysis without stipulating a solution. For example the Fig gives us the various
operating modes during an operational mission. The state flow diagram below examines how such
state change may occur in practice. Accordingly it captures all the triggers that can bring about such
state changes. It may be the ECS failing which is sensed and the Mission Computer goes into a
degraded mode. If this is done for all regimes and modes then all triggers can be captured and
functions required to be carried out can be listed. This is what is achieved by the initial steps of Fault
Analysis.
Hijack
Redundancy Pre Flight
Management Check
Off On Ready Full Degrad
State State Operati ed
on
Fault
Display
On/Off ? On What?
Manageme
Pilot Failure
nt
Indicatio
Emerge
n
Emerge
ncy
ncy
Data
Logging
Fig 13: State Change Diagram
17 Page

18. Additional hardware for development
REGIME MODE STATE
Additional Software for development
Aircraft on Ground Maintenance
Host Minimum Applications
Post Storage/Repair check
Host Limited Applications
Power on Self TestPOST
Post deep repair check
Lab Acceptance Check
Host all Applications
Parent Identification
Fats /Product check
Application Loading
Pre Flight Check
Master Interrupt
Drive Simulator
Data Loading
Lab Power
Normal y
y x
Degraded
AIR
Operationa
l y x
Emergency
x
AOG Switch-Off
In Workshop y y
x y
On Aircraft
Maintenance
Initial y
Installation
Storage
Support
Logistics
Manufacturin
g
Operators/Pil
ots
Training
Service
Engineer
Lab
Aircraft on Ground
Developme
nt
Aircraft in Air
From the state and mode change diagrams a regime, mode; state table can be built as indicated in
figure below. The purpose is to assign a function to each element of this matrix wherever applicable.
18 Page

19. Table 2: Mode, State and Function Table for MC
The collection of all functions forms the functionality List which can be analysed. The functions for
the Mission Computer after Operational Analysis and Functional Analysis have been done, may take
the form of a spread sheet, a portion of which is shown in Appendix A as a sample. This function list
leads us directly to a list of requirements that the MC should meet to satisfy the operational scenario
that has been assumed. Such a list of requirements is bound to be greater than the list provided by
the customer and by traditional Requirement Decomposition method. Further analysis will enable
additional understanding of the architecture required.
a. Requirements Coupling: Any coupling between two sub sets of requirements is not likely to be
noticed in the ‘Requirement Decomposition’ approach. This means that there may be absolute or
partial similarity between two sub system solutions which can be associated for execution or
development. Functional Analysis helps in this effort by enabling relationship amongst various
emerging requirements from Ops Analysis. This is illustrated in the fig 14 below.
These functions can be
combined in one Field Test
Post Post Unit
Fault
Installation Management
Data Loading
Checking
Initialise Redundancy
(AOG)
+
Management
Application
Pre Flight On Site Control &
(AOG)
Checks Servicing Manage
Host Main Services
Applications Operations
Fig 14: Functions / Requirements Coupling
Functional hierarchy: Solutions are indeterminate at the time of project estimation and bid
submission. So also is the importance to be assigned to different elements of the System
Architecture. Hence assumptions are made for likely solutions and costed accordingly. There is a very
high probability of missing the final cost figure by a large margin by such estimation. Functional
Analysis can minimise this error by providing a Basis for a sound System Architecture and its
analysis. For instance it can prioritize the requirements based on the functions required to be fulfilled
by various modules and entities of the product. For instance it can be seen from Fig 15 that Hosting
Applications is the primary function and the failure management module is more important than say
providing electronic identity to the box. This has come from analysing the Flight Regime Vs Support
Regime.
19 Page

20. Mission Computer
POST PRE-FLIGHT HOST FAILURE
& CHECKS APPLICATIONS MANAGEMENT
INITIALISATION FOR AIRCRAFT
FUNCTIONS
IVHMS BOOT LOAD TEST/CONFIG PROVIDE
+ MODE IDENTITY
DATA LOAD
DATA LOGGING
Fig 15: Functional Hierarchy Diagram
Human Machine Interface: Functional Analysis is also able to foresee the Human Machine Interface
required for effective exploitation of the combined system in which Mission Computer forms a part.
This emanates directly from the Information Matrix created and actively seeking control and
monitoring requirements.
Operational and Functional Analysis Results: These analyses result in a Function list that takes
into account all possible situations that a product would face in its life cycle, answer all expectations
of all the stakeholders and meet all interface requirements in its system boundary. The results of
these analyses are indicated in Appendix A which is only representative of a full fledged investigation.
These findings form an excellent basis for defining the physical model that would eventually lay the
foundation for good System Architecture that best satisfies the customer’s needs and adds value.
Each of the function or set of functions can be translated into real world system modules and
elements that together establish a robust System Architecture.
Applicability of Ops and Functional Analysis to other models: This method is eminently suitable
for other models also such as Spiral and Agile Programming as all these are also, recursive in nature.
In fact in agile programming, we have the added advantage of actually developing the end product
incrementally with each pass.
20 Page

21. 7. Conclusion:
In conclusion it can be said that following Operational and Functional Analysis for requirements
capture is a superior method that results in arriving at a comprehensive set of requirements that can
form the basis of an Excellent System Architecture that will ensure much greater probability of
success of a product development project.
Operational Operational Requirement Functional Requirement
Scenario /
Regime
Design for graceful degradation in Design the Mission Computer to
case of failures. have following states whilst in
OS – 01 Plan for Normal, Degraded and operation
Maintain hosted Emergency states. Off – Fully in operation –
services at all cost Mission Computer (MC) should Degraded mode – Emergency
with very high not fail whilst in flight. mode.
reliability. Prioritize services to be provided
in Normal, Degraded and Remember any transition away
Emergency states. from Normal state whilst in flight
(Fault Record) for the
investigation & resolution before
Legend: next mission.
Trigger for the ops state to
ASD – Aircraft System Designer degraded state and from
degraded state to emergency
FTU – Field Test Unit (Laptop state can be from within Mission
based) Computer
or from sources external to
MC - Mission Computer MC.(Mission Computer)
Identify triggers internal to MC.
Provide high degree of redundancy Prepare for receiving external
and manage it effectively. triggers.
Identify and define interface to
Provide excellent fault ASD (Aircraft System Designer)
management. Prioritize services to be provided
Do not provide facility on MC for in Normal/ Degraded/ Emergency
switching OFF. To be switched ON modes.
only in remote mode from pilot's Enable/ Initiate special data
console. logging/ transmission during
Aim for high MTBF. Industry emergency mode.
Standard? Build a good redundancy
management tool to select most
reliable combination/channel
whilst initializing.
All redundant channels to be
active at all times, ready to take
over full responsibility
Indicate readiness to start hosted
services only after stabilizing
21 Page

22. selected channel/lane.
Trigger for starting
redundancy/initialization is
successful completion of POST.
Allow a 'Pre-Flight checks’ routine
to be carried out by a 'hosted
application ‘before declaring
'Normal State'. Provide a trigger to
start the 'pre flight checks’
Make provision to receive a
completion signal.
Define internal conditions
which will make MC to go to a
degraded state and produce
triggers for a state transition
from Normal to Degraded.
Send alerts to the pilot. Provide
interfaces to send such alerts.
(HMI) Human Machine Interface
Memorize in Non-Volatile
Memory any state transition for
preventing next mission
without fault investigation.
Intervene during POST and
indicate faults that occurred in
previous mission and query 'if
resolved'.
Provide post mission recording
trigger.
Do not provide
switches/fuses/breakers for
switching on/off power supplies to
the MC.
.Do not provides ‘Reset’ button for
MC. Decide what limited action it
should perform in consultation
with ASD.
Allow remote switching on/off by
pilot from control console.
Intimate requirement of preventing
inadvertent switching off to ASD.
Allow for remote indication that
the MC is 'ON'.
Have robust safety assessments
done. Have a robust safety assessment
OS – 02 Provide high design margins. done and provide evidence for
Provide high De rate components FTA, FMEA &FHA.(Fault Tree
degree of safety Resource &Redundancy Analysis, Failure Mode Effects
and Security Management. Have good post Analysis, Functional Hazard
&pre flight check capability. Analysis)
Have a good initializing Show and prove margins required
22 Page

23. procedure. during Critical Design Review
Enable tightly controlled (CDR).
configuration management De rate Components as per
especially partitioning &interrupts customer/ industry practice.
(no conflict in resource sharing). Have good initialization procedure
Memorize faults that cause to select healthiest track /lane for
transition to Degraded / operation.
Emergency state until next Keep all channels alive at all
mission. times. Make selection of Channels
Enable parent / child identification unambiguous.
(no wrong box in wrong place) to Enable tightly controlled config
be embedded in the electronics management especially
and not only on the cabinet labels. partitioning & interrupt.
Provide integrity checks (no POST .( Power On Self Test)
wrong data to be shown as Initializing procedure. ASD to
validate). For Time, position, fuel provide externals inputs involved.
indications etc., Fault Management.
Maintain accurate timing &clock Integrity checks on the
frequency. Provide for performance parameters.
synchronizing with a standard or Memorize 'state transition in NVM
give out a standard in case of for checks before next mission.
becoming Master Clock. Prevent inadvertent trigger of
Special Regimes: same.
Provide extra precaution during Enable parent child
critical conditions (Take Off and identification.MC belongs to right
Landing). Indicate this condition to aircraft
other aircraft systems and to the Initiate 'hijack’ application when
Pilot. trigger received from 'pilot'.
Arrange to get early warning of Minimize inadvertent use of hijack
other aircraft system failures switch
affecting MC. Provide own clock for
An IMA platform (Such as the synchronizing with an external
Mission Computer) must be frequency standards.
composable (this means a new Give out a master clock reference
application will not invalidate any to external devices and buses for
verified requirements of an maintaining timing.
already integrated application). Arrange to get early warning of
external system failures. Prioritize
services accordingly. ASD
Take extra precautions whilst take
off and landing.
Maximize reuse and sharing of
OS – 03 IMA concept itself leads to cost resources by hosted applications
Business reduction due to large shared and without affecting safety.
Requirements reusable resources. In this respect IMA concept itself
Reduced Cost Design in flexibility so that it can is cost reduction Model.
of Ownership be used across other aircraft Design in flexibility and modular
Reduced cost of types. Adopt standard enclosure construction to enable its use
maintenance formats such as ATR etc. across multiple aircraft types.
Allow operational Provide means for a good IVHMS Adopt standard enclosures such
23 Page

24. from ill equipped through inbuilt networking as ATR chassis.
airport capability. Provide means for a good BIT
Provide easy access for repair /POST as part of the MC platform.
whilst installed on aircraft. Get policy of using network
Maximize DFT (Design for capabilities for IVHMS from ASD.
Testability). Provide ease of access for
Provide means for essential fault repair/removal whilst AOG if
isolation and repair by policy dictates. Seek advice that
replacement whilst AOG with the ASD will give the Fleet operator.
(Mixed Fleet, Conf Mgmt, Ill
use of Laptop based testing as
equipped airport etc)
dictated by ASD
Maximize DFT (Design For Test).
Provide means for essential fault
isolation and repair by
replacement whilst AOG with use
of Field Test Unit (FTU). FTU is to
be a laptop based unit.
Allow a CSCI be written for loading
in FTU, for use in ill-equipped
airport.
8. Author’s Profile:
Prabhakar (Pubs) Mandakolluthur is a post graduate from
Indian Institute of Science, Bangalore and the Naval College of
Engineering, Lonavala. He has over 20 years experience in the
Electrical branch of the Indian Navy during which he has held
positions such as Deputy Director of Electrical Engineering in
Naval Headquarters , Chief Instructor of Faculty of Electronics
in Naval Electrical Training School. He has followed civilian
career since 1994 in which important jobs he has held are Sr.
Program Manager in Honeywell Technology Solutions Lab,
Bangalore, VP Product Development, Aerospace System
Limited Bangalore. He is presently Advisor, Aerospace and
Defence in Tata Consultancy Services.
24 Page