Академический Документы
Профессиональный Документы
Культура Документы
Gathering
March 2013
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
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
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.
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.
Functional requirements
To simplify the collect of MIS project requirements, two different kinds of requirements
will be used, as we described below:
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
Functional requirement
First Level
Second Level
Name
Id
F-0001
Dependent requirement
id
Date
Description
Acceptance Measure
Tester
Extra information
Second Level
Name
Id
Dependent requirement id
Enterprise resource planning (ERP)
Date
F-0002
Dependent requirement
id
Description
Acceptance Measure
Tester
Extra information
TBD
An important task in this requirement will be inquiry and
choose the suitable commercial product.
Second Level
Name
Id
F-0003
Dependent requirement
id
Date
Description
Acceptance Measure
Tester
Extra information
Records Management
Functional requirement
First Level
Second Level
Name
Id
F-0004
Dependent requirement
id
Date
Description
Acceptance Measure
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.
Web Publications
Functional requirement
First Level
Second Level
Name
F-0005
Dependent requirement
id
Id
Date
Description
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
Availability
Non-functional requirement
Availability
Name
Id
NF-0001
Date
Description
Acceptance Measure
Tester
Extra information
Backup
Non-functional requirement
Backup
Name
Id
NF-0002
Date
Description
Acceptance Measure
Tester
Extra information
Disaster recovery
Non-functional requirement
Disaster recovery
Name
Id
NF-0003
Date
Description
Acceptance Measure
Tester
Extra information
Extensibility
Non-functional requirement
Extensibility
Name
Id
NF-0004
Date
Description
Acceptance Measure
Tester
Extra information
Fault tolerance
Non-functional requirement
Fault tolerance
Name
Id
NF-0005
Date
Description
Acceptance Measure
Tester
Extra information
Interoperability
Non-functional requirement
Interoperability
Name
Id
NF-0006
Date
Description
Acceptance Measure
Tester
Extra information
Licensing
Non-functional requirement
Licensing
Name
Id
NF-0007
Date
Description
Acceptance Measure
Tester
Extra information
Maintainability
Non-functional requirement
Maintainability
Name
Id
NF-0008
Date
Description
Acceptance Measure
Tester
Extra information
Performance
Non-functional requirement
Performance
Name
Id
NF-0009
Date
Description
Acceptance Measure
Tester
Extra information
Platform compatibility
Non-functional requirement
Platform compatibility
Name
Id
NF-0010
Date
Description
Acceptance Measure
Tester
Extra information
Scalability
Non-functional requirement
Scalability
Name
Id
NF-0011
Date
Description
Acceptance Measure
Tester
Extra information
Security
Non-functional requirement
Security
Name
Id
NF-0012
Date
Description
Acceptance Measure
Tester
Extra information