MIS Requeriments

Gathering

March 2013

MIS Requirements gathering

Index
INTRODUCTION............................................................................................... 3
REQUIREMENTS GATHERING........................................................................... 4
REQUIREMENT ................................................................................................. 5
FUNCTIONAL REQUIREMENTS ......................................................................... 6
Airport Operational Data Base ...................................................................................... 8
Enterprise Resource Planning ...................................................................................... 9
Lightweight Directory Access Protocol ........................................................................ 10
Records Management................................................................................................. 11
Web Publications ........................................................................................................ 12
NON-FUNCTIONAL REQUIREMENTS OR TECHNICAL REQUIREMENTS ........... 13
Availability................................................................................................................... 14
Backup ....................................................................................................................... 15
Disaster recovery ........................................................................................................ 16
Extensibility ................................................................................................................. 17
Fault tolerance ............................................................................................................ 18
Interoperability ............................................................................................................ 19
Licensing .................................................................................................................... 20
Maintainability ............................................................................................................. 21
Performance ............................................................................................................... 22
Platform compatibility .................................................................................................. 23
Scalability ................................................................................................................... 24
Security....................................................................................................................... 25

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Introduction
The main goal of this document is to gather the main needs detected in the future
organization of CAAN and the new future organization, and, according with these, to try
to design a MIS system to cover all of them.
It is important to highlight that the focus of this document will be the new future
organization. New roles will be created and some of the old roles will be transformed
Computerization is a complex process that allows making easier the daily tasks and,
obviously, some tasks and functions will be affected by this new way of work.
This document will be structured following the comments and indications that the
different involved teams that Ineco has in the whole project have demanded during
these months.
Several meeting have been taking during these months in order to collect all
these requirements and needs that the organization that is being designed will have.
There are transversal requirements that affect to several departments, and some other
requirements are concrete and are owned just of a single department. All of them must
be covered in the future MIS system, and have the same priorization

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Requirements gathering
The requirements gathering process is the first phase of software develop and consist
on collecting whichever necessity to improve the business process of the company.
Establishing the requirements is the first step to agree on and visualise the right
product. A requirement gathering is a vital part of the systems engineering process. At
the beginning, it defines the problem scope and after that, it links all the relative
information to them through their functional analysis.
The Requirements gathering task is known to be critical to success in any project. Any
requirement must be collected clearly and all stakeholders in the project must be
involved in this task.
This kind of tasks are open while the project is alive, and frequently new requirements
appear in any of phases of the project (definition, analysis, develop, test, maintenance,
etc.), in other words, requirements gathering belongs to life cycle workflow of projects
and never finishes completely.

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Requirement
A common Requirement definition drawn from IEEE-STD-1220-1998 (IEEE 1998):
Requirement is a statement that identifies a product or process operational, functional,
or design characteristic or constraint, which is unambiguous, testable or measurable,
and necessary for product or process acceptability (by stakeholders).
Requirements are the basis of any project, defining what the stakeholders users,
customers, suppliers, developers, businesses in a new (or legacy) potential system
need from it, and also what the system must do in order to satisfy that need.
One of the goals of this document is to present a standardized template to collect
requirements and MIS team will use it to be able to collect all requirements orderly.
There are two kinds of requirements: functional and non-functional. The Definitions and
main differences between them will be discussed in further sections of this document.

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Functional requirements
To simplify the collect of MIS project requirements, two different kinds of requirements
will be used, as we described below:

First level requirements: this kind of requirements defines high level

necessities. In other words, one first level requirement will identify business
requirements to improve tasks, productivity or enhance workflows. Every first
level requirement will match with a whole application to solve a business
necessity. In fact, they will be "the product vision process" for a new tool. These
types of requirements have to be detected and have to be estimated roughly in
time and budget by CAAN staff.

Second level requirements: through an analysis of "product vision" these

kinds of requirements will appear. Stakeholders of a new application must
collect requirements of every functionality that they need, to cover their
functional necessities. Every one of these requirements must satisfy the
following list of features:
o
o
o
o
o
o
o

Complete
Specific, unambiguous.
Testable or measurable
Prioritized
Achievable, realistic
Connected
Signed off by the client

It is not mandatory that all requirements must be considered as a new application (first
level requirements) or they must be included in the final product (second level
requirements). All of them must be analyzed and estimated in cost and effort to
determinate if they are affordable.
To maintain minimum traceability between requirements is very important to highlight
every dependence between requirements. This approach allows maintaining a
requirements hierarchy.
This is the template to fill up in order to define a new functional requirement.
Functional requirement
First Level

Second Level

Name
Id
Date
Description
Acceptance Measure
Tester
Extra information
Ingeniera y Economa del Transporte, S.A.

Dependent requirement
id

MIS Requirements gathering

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Airport Operational Data Base

Functional requirement
First Level

Second Level

Name

Airport Operational Data Base (AODB)

Id

F-0001

Dependent requirement
id

Date

Description

Acceptance Measure
Tester
Extra information

Air Operational database (AODB) is a type of database in

which all the air operations of a concrete area are
recorded.
It is known that in TIA Airport there is a kind of this type of
software, installed by a Dutch company. This database
might be enough to cover this software requirement.
It must be taken into account that this information might
increase its size rapidly. This data model should be
evaluated in order to determine if it is only valid for the TIA
airport, or it could be expanded to entire model information
of air operations in Nepal.
This operational information is crucial to make reports and
predictions. The airport master plans are based on
historical information, and this information must be stored
in a single place, centralised and easy to access to
allowed users.
Operational mistakes and non-coordinated information will
be reduced if an AODB is created and used. The
information stored on that database might be exploited in
very different ways, giving information to create new
routes, total passengers amounts, companys information
and so on.
In order to facilitate the queries to this kind of database,
some queries might be stored, and executed during the
night or in low loaded periods. Reports and graphs could
be generated using this information.
This data base will be one of the key of the IT
infrastructure, it will be interoperable with the purpose of all
of the CAAN applications can connect with it.
The solution proposed must write down all airport
operations and their associate information, and AODB
must contain with methods to be interoperable.
TBD
MIS team was informed about TIA airport has already
installed a similar solution in their IT systems, which
probably

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Enterprise Resource Planning

Functional requirement
First Level

Second Level

Name
Id

Dependent requirement id
Enterprise resource planning (ERP)

Date

F-0002

Dependent requirement
id

Description

Acceptance Measure

Enterprise resource planning (ERP) systems integrate

internal and external management information across an
entire
organization,
embracing
finance/accounting,
manufacturing, sales and service, customer relationship
management, etc.
ERP systems automate this activity with an integrated
software application. The purpose of ERP is to facilitate
the flow of information between all business functions
inside the boundaries of the organization and manage the
connections to outside stakeholders.
In concrete, this software is demanded by the financial
Team in order to organize the accounting tasks of the
future organization. Not only the providers expenses but
the companies taxes are included on this software
requirement.
This system has to be accessible only by the financial
department of the new organization. There will be some
information just accessible by certain members of the staff,
so in addition, LDAP is demanded.

Tester

The solution proposed allow to manage the accounting of

both organizations separately.

Extra information

TBD
An important task in this requirement will be inquiry and
choose the suitable commercial product.

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Lightweight Directory Access Protocol

Functional requirement
First Level

Second Level

Name

Lightweight Directory Access Protocol (LDAP)

Id

F-0003

Dependent requirement
id

Date

Description

Acceptance Measure
Tester
Extra information

The Lightweight Directory Access Protocol (LDAP) is an

application protocol for accessing and maintaining
distributed directory information services over a network.
Directory services may provide any organized set of
records, often with a hierarchical structure, such as a
corporate email directory.
LDAP is required in order to maintain the security access
to information. This is a transversal requirement in all the
teams, in order to guarantee the data protection. LDAP is
an electronic representation of the corporative structure.
This structure is currently being defined and will determine
roles and grants.
Anyway, it is possible to assign special permissions to
concrete information or document to a single user. These
exceptions are defined over the standard hierarchical
definition of the entire organization, and must be
continuously reviewed in order to keep the information
control access up to date.
LDAP is a key concept in any sharing information system,
and must be defined carefully. Ineco offers its experience
to CAAN staff to show how it works, and how to define the
different roles and permissions.
All the systems that are going to be installed will delegate
its access rules to the LDAP.
All security policies defined will be able to be implemented
in the corporate LDAP System.
TBD
LDAP is specified using the description language. This
language is well-documented in several places, and is
easy to learn.

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Records Management
Functional requirement
First Level

Second Level

Name

Records management (RM)

Id

F-0004

Dependent requirement
id

Date

Description

Records management is the practice of maintaining the

records of an organization from the time they are created
up to their eventual disposal. This may include classifying,
storing, securing, and destruction (or in some cases,
archival preservation) of records and reports in any kind of
format (doc, xls, pdf, ect.).
A more concrete definition of an EDRM (Electronic
document and records management system) would be an
automatic system that is used to create original or
versioned documents, track and store them through an
organization.
These kinds of systems are used to keep documents in an
organization that has the need of sharing and updating
documents through different agents. During this process,
the document is created, updated, reviewed, versioned or
just read.
This kind of system is always based on a hierarchical
permissions system that only allows the access to a
document to users that are granted to do it.
In CAAN there is a need of sharing information. One of the
big problems of the current organization is the duplicity of
the same information because the information is not
centralised. With this kind of software, all the different
versions of the same document will be tracked. All the
changes done by a user might be reviewed and the same
file will be distributed through the system in order to
reduce to zero the loss of information.

Acceptance Measure

All kind of reports, records, documents, etc. generated,

must be managed by this system, and all of them must be
available to be shared with someone else (distributed
document) or whoever has been allowed (working
document).
All the teams involved in the future organization design will
demand this software to guarantee the information integrity
and the access control.

Tester
Extra information

TBD
With this kind of system, it is guaranteed always that the
latest and the most updated information are checked in all
the times that this piece of information is needed.

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Web Publications
Functional requirement
First Level

Second Level

Name

F-0005

Dependent requirement
id

Id

Date

Nowadays, websites are the public face in front of the

world.
This websites represent the image that an organization
wants to show to the rest of the world.
The CAAN website is not only this image. CAAN website
must be the place where important information about
Nepal and its air navigation must be collected and share
with the general public.
In concrete, there is some information that must be shared
and published by law. Following the indications of air
navigation experts, Ineco encourage to public AIS
information on the website firmly and regularly.
Therefore, there is a need to create channels to public
information on the current or future websites.
Not only general information must be shown on these
websites, but technical information might be required.
Some of the reports based on AODB data could be share
too, in order to give accuracy information to the potential
visitors or air navigation experts around the world.

Description

AIS documents will be published under the laws related,

with the purpose of enforce the law.

Acceptance Measure
Tester

TBD
Some technique to do publications in real time can be
implemented to publish in CAAN or TIA websites, but AIS
publication won't be necessary to be real time.

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Non-functional requirements or technical requirements

In computer engineering terms, a non-functional requirement is a requirement that
define the desired system behaviour rather than specific behaviour or functions. The
plan for implementing functional requirements is detailed in the system design and
determines what a system is supposed to do, whereas the plan for implementing nonfunctional requirements is detailed in the system architecture and determines how a
system is supposed to be.
Non-functional requirements are often called qualities of a system, and are defined
based on qualities like stability and portability. Non-functional requirements can be
divided into two main categories:
o
o

Execution qualities, such as security and usability, which are observable

at run time.
Evolution qualities, such as testability, maintainability, extensibility and
scalability, which are embodied in the static structure of the software
system

This is the template to fill up in order to define a new non-functional requirement.

Non-functional requirement template
Name
Id
Date
Description
Acceptance Measure
Tester
Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Availability
Non-functional requirement
Availability

Name
Id

NF-0001

Date

Description

Acceptance Measure

Tester

The system availability is the feature to explain the amount

of time that a system has to be accessible and working in
a proper way. Availability is the proportion of time a system
is in a functioning condition. This ratio between the total
time and the time that the system was available is the unit
to measure this capability.
The solution proposed must be 24 hours available, 7 days
a week. That means that the application must be alive and
working in any single moment. Therefore, deny of service
periods must be avoided. To get this goal the entire
infrastructure must be replicated and the electricity supply
must be guaranteed in the DPC.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Backup
Non-functional requirement
Backup

Name
Id

NF-0002

Date

Description

Acceptance Measure

Tester

The system backups are the automatic regular copies of

the crucial information in a system. All the key pieces of
information must be stored regularly, in order to have
recovery copies just in case an incident happened. These
recovery copies must be storage in separate units, and
must be accessible by the system administrators. These
administrators will be in charge to recover the system to
the most updated state when the system fails.
There is another reason to keep this security copies. The
information existed in a moment must be accessible in a
determinate amount of time in order to get the real state of
this moment and analyse a temporal incident or decision.
The solution proposed must storage the DDBB and the
crucial file system daily, in order to reduce the risk of loss
information. In addition of that, the information must be
kept during one month in order to rebuild the system
situation in a concrete moment and analyse its behaviour.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Disaster recovery
Non-functional requirement
Disaster recovery

Name
Id

NF-0003

Date

Description

Acceptance Measure

Tester

The disaster recovery feature is the system capacity that

enables a system to reboot working fine just after a system
complete fail. When an incident happen it is important to
have a clear protocol that explains what to do and how and
what to recover. This protocol must be accessible in any
moment (even with the system down), and the system
administrators must know it.
The elapsed time since the system fail and the system
working again is important to define this protocol. Actually,
is a QA (Quality assurance), and it is important to define
this time in order to determine subsequent measures
related to it, as back-up policies or the real reliability of the
system.
The solution proposed must recover its proper state in any
solution in less than 24h. The optimal situation should
require less than this time, but the SLA will depend on the
type of error and the critical grade of the application part
that has failed.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Extensibility
Non-functional requirement
Extensibility

Name
Id

NF-0004

Date

Description

Acceptance Measure
Tester

The Extensibility principle is the feature that means that

the implementation takes into consideration future growth.
It is a systemic measure of the ability to extend a system
and the level of effort required to implement and fully
integrate the extension. Extensions can be through the
addition of new functionality or through modification of
existing functionality. The central theme is to provide for
change while minimizing impact to existing system
functions.
The solution will be implemented following this principle,
taking into account future improvements and product
integrations.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Fault tolerance
Non-functional requirement
Fault tolerance

Name
Id

NF-0005

Date

Description

Acceptance Measure

Tester

The fault-tolerant design is a design that enables a system

to continue operation, possibly at a reduced level, rather
than failing completely, when some part of the system
fails. The term is most commonly used to describe
computer-based systems designed to continue more or
less fully operational with, perhaps, a reduction in
throughput or an increase in response time in the event of
some partial failure. That is, the system as a whole is not
stopped due to problems either in the hardware or the
software.
The solution must be failure tolerant, and must be strong
enough to guarantee the service during the time the
application is on. To get this goal, this software should
emit a signal when a potential problem was detected, in
advance, giving enough time to take preventives measures
to solve it without service interruption
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Interoperability
Non-functional requirement
Interoperability

Name
Id

NF-0006

Date

Description

Acceptance Measure
Tester

Interoperability is the feature that describes the facility to

interchange information between different systems, and
the capacity to use it.
Another definition to this principle is "Being able to
accomplish end-user applications using different types of
computer systems, operating systems, and application
software, interconnected by different types of local and
wide area networks."
This feature must be taken into account when a system is
defined, knowing previously which type of devices are
going to access to the information and its capabilities.
The solution will be interoperable between the agreed
devices, and the maximum number of functionalities will be
accessible from the less power devices.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Licensing
Non-functional requirement
Licensing

Name
Id

NF-0007

Date

Description

Acceptance Measure
Tester

The license is the feature that any product has in order to

protect the intellectual property of its creators. With a
license, a licensor may grant a license under intellectual
property laws to authorise a use (such as copying software
or using a (patented) invention) to a licensee, sparing the
licensee from a claim of infringement brought by the
licensor. A license under intellectual property commonly
has several components beyond the grant itself, including
a term, territory, renewal provisions, and other limitations
deemed vital to the licensor.
The solution must be licensed and this license must be
legal. That means that this software will be legal to use
and distribute among the organization.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Maintainability
Non-functional requirement
Maintainability

Name
Id

NF-0008

Date

Description

Acceptance Measure
Tester

In engineering, maintainability is the ease with which a

product can be maintained in order to isolate defects and
correct them, build up new requirements and make easier
its future maintenance, and cope with a changed
environment
In some cases, maintainability involves a system of
continuous improvement - learning from the past in order
to improve the ability to maintain systems, or improve
reliability of systems based on maintenance experience.
The solution proposed will be easy to maintain. The
software designed will follow maintenance patterns to
reduce the impact of new requirements and isolate the
potential bugs.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Performance
Non-functional requirement
Performance

Name
Id

NF-0009

Date

Description

Acceptance Measure
Tester

The system performance is the capacity to keep the

optimal behaviour of the system components in any time,
and any physical or logical circumstances (load,
temperature, disk occupation, network concurrence)
This performance level must be constant in any
concurrence and situation. This goal can be prevented
using enough resources to cover all these situations, or
adding resources dynamically when an overload situation
is happening, in advance.
The solution will keep the performance in the agreed
situations. When an overload situation is detected, the
solution will emit a signal to the application administrators
to alert about an overload situation.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Platform compatibility
Non-functional requirement
Platform compatibility

Name
Id

NF-0010

Date
Description

Acceptance Measure
Tester

The platforms compatibility feature is the system capability

of run into different platforms without penalties in
performance neither extra configuration.
The solution proposed will be platform independent,
because it will be installed over a virtual machine, and this
virtual machine gives an additional abstraction layer over
the platform in order to minimize this impact.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Scalability
Non-functional requirement
Scalability

Name
Id

NF-0011

Date

Description

Acceptance Measure
Tester

The scalability feature is the ability of a system to handle a

growing amount of work in a capable manner or its ability
to be enlarged to accommodate that growth. It may refer to
the capability of a system to increase total throughput
under an increased load when hardware resources are
added.
Scalability, as a property of systems, is generally difficult to
define and in any particular case it is necessary to define
the specific requirements for scalability on those
dimensions that are deemed important. A system, whose
performance improves after adding hardware,
proportionally to the capacity added, is said to be a
scalable system.
The solution proposed will be scalable. If a lack of
resources is detected, it will be easy to solve this problem
just adding new resources to the bottle neck.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.

MIS Requirements gathering

Security
Non-functional requirement
Security

Name
Id

NF-0012

Date

Description

Acceptance Measure
Tester

The Security in the field of computer science is a very

broad concept. It may be defined as the ability to
guarantee the integrity of the information providing by the
system, and the access control to it.
The control policies that determine which entities can see
what information is a concept that is also associated with
this field.
The solution will guarantee the information integrity, and it
will provide a mechanism to the information access control
and the definitions of users and groups of users.
TBD

Extra information

Ingeniera y Economa del Transporte, S.A.