2. Requirements Gathering

8/10/2019 2. Requirements Gathering

1/25

MIS Requeriments

Gathering

March 2013


2/25

MISRequirements gathering

Ingeniera y Economa del Transporte, S.A.

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


3/25



Introduction

The main goal of this document is to gather the main needs detected in the futureorganization 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 futureorganization. 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 thedifferent 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 allthese requirements and needs that the organization that is being designed will have.

There are transversal requirements that affect to several departments, and some otherrequirements are concrete and are owned just of a single department. All of them mustbe covered in the future MIS system, and have the same priorization


4/25



Requirements gathering

The requirements gathering process is the first phase of software develop and consiston collecting whichever necessity to improve the business process of the company.

Establishing the requirements is the first step to agree on and visualise the rightproduct. A requirement gathering is a vital part of the systems engineering process. Atthe beginning, it defines the problem scope and after that, it links all the relativeinformation to them through their functional analysis.

The Requirements gathering task is known to be critical to success in any project. Anyrequirement must be collected clearly and all stakeholders in the project must beinvolved in this task.

This kind of tasks are open while the project is alive, and frequently new requirementsappear in any of phases of the project (definition, analysis, develop, test, maintenance,etc.), in other words, requirements gathering belongs to life cycle workflow of projectsand never finishes completely.


5/25



Requirement

A common Requirement defin it ion drawn f rom 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 systemneed 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 collectrequirements 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.


6/25



Functional requirements

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

First level requirements: this kind of requirements defines high levelnecessities. In other words, one first level requirement will identify businessrequirements to improve tasks, productivity or enhance workflows. Every firstlevel requirement will match with a whole application to solve a businessnecessity. In fact, they will be "the product vision process" for a new tool. Thesetypes of requirements have to be detected and have to be estimated roughly intime and budget by CAAN staff.

Second level requirements: through an analysis of "product vision" thesekinds of requirements will appear. Stakeholders of a new application mustcollect requirements of every functionality that they need, to cover their

functional necessities. Every one of these requirements must satisfy thefollowing list of features:

o Completeo Specific, unambiguous.o Testable or measurableo Prioritizedo Achievable, realistico Connectedo Signed off by the client

It is not mandatory that all requirements must be considered as a new application (firstlevel requirements) or they must be included in the final product (second levelrequirements). All of them must be analyzed and estimated in cost and effort todeterminate if they are affordable.

To maintain minimum traceability between requirements is very important to highlightevery dependence between requirements. This approach allows maintaining arequirements hierarchy.

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

Functional requirement

First Level

Second Level Dependent requirementid

Name

Id

Date

Description

Acceptance Measure

Tester

Extra information


7/25




8/25



Ai rpor t Operational Data Base


First Level


Name Airpor t Operational Data Base (AODB)

Id F-0001

Date

Description

Air Operational database (AODB) is a type of database inwhich all the air operations of a concrete area arerecorded.

It is known that in TIA Airport there is a kind of this type ofsoftware, installed by a Dutch company. This databasemight be enough to cover this software requirement.

It must be taken into account that this information mightincrease its size rapidly. This data model should beevaluated in order to determine if it is only valid for the TIAairport, or it could be expanded to entire model informationof air operations in Nepal.

This operational information is crucial to make reports andpredictions. The airport master plans are based onhistorical information, and this information must be stored

in a single place, centralised and easy to access toallowed users.

Operational mistakes and non-coordinated information willbe reduced if an AODB is created and used. Theinformation stored on that database might be exploited invery different ways, giving information to create newroutes, total passengers amounts, companys informationand so on.

In order to facilitate the queries to this kind of database,some queries might be stored, and executed during thenight or in low loaded periods. Reports and graphs couldbe generated using this information.

This data base will be one of the key of the ITinfrastructure, it will be interoperable with the purpose of allof the CAAN applications can connect with it.

Acceptance MeasureThe solution proposed must write down all airportoperations and their associate information, and AODBmust contain with methods to be interoperable.

Tester TBD

Extra informationMIS team was informed about TIA airport has alreadyinstalled a similar solution in their IT systems, whichprobably


9/25



Enterprise Resource Planning


First Level


Name Dependent requirement id

Id Enterprise resource planning (ERP)

Date F-0002

Description

Acceptance Measure

Enterprise resource planning (ERP) systems integrate

internal and external management information across anentire organization, embracing finance/accounting,manufacturing, sales and service, customer relationshipmanagement, etc.

ERP systems automate this activity with an integratedsoftware application. The purpose of ERP is to facilitatethe flow of information between all business functionsinside the boundaries of the organization and manage theconnections to outside stakeholders.

In concrete, this software is demanded by the financialTeam in order to organize the accounting tasks of the

future organization. Not only the providers expenses butthe companies taxes are included on this softwarerequirement.

This system has to be accessible only by the financialdepartment of the new organization. There will be someinformation just accessible by certain members of the staff,so in addition, LDAP is demanded.

TesterThe solution proposed allow to manage the accounting ofboth organizations separately.

Extra information TBD

An important task in this requirement will be inquiry and

choose the suitable commercial product.


10/25



Lightweight Directory Access Protocol


First Level


Name Lightweight Directory Access Protocol (LDAP)

Id F-0003

Date

Description

The Lightweight Directory Access Protocol (LDAP) is anapplication protocol for accessing and maintainingdistributed directory information services over a network.

Directory services may provide any organized set ofrecords, often with a hierarchical structure, such as acorporate email directory.

LDAP is required in order to maintain the security accessto information. This is a transversal requirement in all theteams, in order to guarantee the data protection. LDAP isan electronic representation of the corporative structure.This structure is currently being defined and will determineroles and grants.

Anyway, it is possible to assign special permissions toconcrete information or document to a single user. Theseexceptions are defined over the standard hierarchicaldefinition of the entire organization, and must be

continuously reviewed in order to keep the informationcontrol access up to date.

LDAP is a key concept in any sharing information system,and must be defined carefully. Ineco offers its experienceto CAAN staff to show how it works, and how to define thedifferent roles and permissions.

All the systems that are going to be installed will delegateits access rules to the LDAP.

Acceptance Measure All security policies defined will be able to be implementedin the corporate LDAP System.

TesterTBD

Extra informationLDAP is specified using the description language. Thislanguage is well-documented in several places, and iseasy to learn.


11/25



Records Management


First Level


Name Records management (RM)

Id F-0004

Date

Description

Records management is the practice of maintaining therecords of an organization from the time they are createdup 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 (Electronicdocument and records management system) would be anautomatic system that is used to create original orversioned documents, track and store them through anorganization.

These kinds of systems are used to keep documents in anorganization that has the need of sharing and updatingdocuments through different agents. During this process,the document is created, updated, reviewed, versioned orjust read.

This kind of system is always based on a hierarchicalpermissions system that only allows the access to adocument to users that are granted to do it.

In CAAN there is a need of sharing information. One of thebig problems of the current organization is the duplicity ofthe same information because the information is notcentralised. With this kind of software, all the differentversions of the same document will be tracked. All thechanges done by a user might be reviewed and the samefile will be distributed through the system in order toreduce 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 beavailable to be shared with someone else (distributeddocument) or whoever has been allowed (workingdocument).

All the teams involved in the future organization design willdemand this software to guarantee the information integrityand the access control.

Tester TBD

Extra information

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


12/25



Web Publications


First Level


Name F-0005

Id

Date

Nowadays, websites are the public face in front of theworld.

This websites represent the image that an organizationwants to show to the rest of the world.

The CAAN website is not only this image. CAAN websitemust be the place where important information aboutNepal and its air navigation must be collected and sharewith the general public.

In concrete, there is some information that must be sharedand published by law. Following the indications of airnavigation experts, Ineco encourage to public AISinformation on the website firmly and regularly.

Therefore, there is a need to create channels to publicinformation on the current or future websites.

Not only general information must be shown on thesewebsites, but technical information might be required.

Some of the reports based on AODB data could be sharetoo, in order to give accuracy information to the potentialvisitors or air navigation experts around the world.

DescriptionAIS documents will be published under the laws related,with the purpose of enforce the law.

Acceptance Measure TBD

TesterSome technique to do publications in real time can beimplemented to publish in CAAN or TIA websites, but AISpublication won't be necessary to be real time.

Extra information


13/25



Non-functional requirements or technical requirements

In computer engineering terms, a non-functional requirement is a requirement thatdefine the desired system behaviour rather than specific behaviour or functions. The

plan for implementing functional requirements is detailed in the system design anddetermines what a system is supposed to do, whereas the plan for implementing non-functional requirements is detailed in the system architecture and determines how asystem is supposed to be.

Non-functional requirements are often called qualities of a system, and are definedbased on qualities like stability and portability. Non-functional requirements can bedivided into two main categories:

o Execution qualities, such as security and usability, which are observableat run time.

o

Evolution qualities, such as testability, maintainability, extensibility andscalability, which are embodied in the static structure of the softwaresystem

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

Non-functional requirement template

Name

Id

Date

DescriptionAcceptance Measure

Tester

Extra information


14/25



Availabi li ty

Non-functional requirement

Name Availabi li ty

Id NF-0001

Date

Description

The system availability is the feature to explain the amountof time that a system has to be accessible and working ina proper way. Availability is the proportion of time a systemis in a functioning condition. This ratio between the totaltime and the time that the system was available is the unitto measure this capability.

Acceptance Measure

The solution proposed must be 24 hours available, 7 daysa week. That means that the application must be alive andworking in any single moment. Therefore, deny of service

periods must be avoided. To get this goal the entireinfrastructure must be replicated and the electricity supplymust be guaranteed in the DPC.

Tester TBD

Extra information


15/25



Backup


Name Backup

Id NF-0002

Date

Description

The system backups are the automatic regular copies ofthe crucial information in a system. All the key pieces ofinformation must be stored regularly, in order to haverecovery copies just in case an incident happened. Theserecovery copies must be storage in separate units, andmust be accessible by the system administrators. Theseadministrators will be in charge to recover the system tothe most updated state when the system fails.

There is another reason to keep this security copies. Theinformation existed in a moment must be accessible in adeterminate amount of time in order to get the real state ofthis moment and analyse a temporal incident or decision.

Acceptance Measure

The solution proposed must storage the DDBB and thecrucial file system daily, in order to reduce the risk of lossinformation. In addition of that, the information must bekept during one month in order to rebuild the systemsituation in a concrete moment and analyse its behaviour.

Tester TBD

Extra information


16/25



Disaster recovery


Name Disaster recovery

Id NF-0003

Date

Description

The disaster recovery feature is the system capacity thatenables a system to reboot working fine just after a systemcomplete fail. When an incident happen it is important tohave a clear protocol that explains what to do and how andwhat to recover. This protocol must be accessible in anymoment (even with the system down), and the systemadministrators 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 definethis time in order to determine subsequent measuresrelated to it, as back-up policies or the real reliability of thesystem.

Acceptance Measure

The solution proposed must recover its proper state in anysolution in less than 24h. The optimal situation shouldrequire less than this time, but the SLA will depend on thetype of error and the critical grade of the application partthat has failed.

Tester TBD

Extra information


17/25



Extensibility


Name Extensibility

Id NF-0004

Date

Description

The Extensibility principle is the feature that means thatthe implementation takes into consideration future growth.It is a systemic measure of the ability to extend a systemand the level of effort required to implement and fullyintegrate the extension. Extensions can be through theaddition of new functionality or through modification ofexisting functionality. The central theme is to provide forchange while minimizing impact to existing system

functions.

Acceptance MeasureThe solution will be implemented following this principle,taking into account future improvements and productintegrations.

Tester TBD

Extra information


18/25



Fault tolerance


Name Fault tolerance

Id NF-0005

Date

Description

The fault-tolerant design is a design that enables a systemto continue operation, possibly at a reduced level, ratherthan failing completely, when some part of the systemfails. The term is most commonly used to describecomputer-based systems designed to continue more orless fully operational with, perhaps, a reduction inthroughput or an increase in response time in the event ofsome partial failure. That is, the system as a whole is not

stopped due to problems either in the hardware or thesoftware.

Acceptance Measure

The solution must be failure tolerant, and must be strongenough to guarantee the service during the time theapplication is on. To get this goal, this software shouldemit a signal when a potential problem was detected, inadvance, giving enough time to take preventives measuresto solve it without service interruption

Tester TBD

Extra information


19/25



Interoperability


Name Interoperability

Id NF-0006

Date

Description

Interoperability is the feature that describes the facility tointerchange information between different systems, andthe capacity to use it.

Another definition to this principle is "Being able toaccomplish end-user applications using different types ofcomputer systems, operating systems, and applicationsoftware, interconnected by different types of local andwide area networks."

This feature must be taken into account when a system isdefined, knowing previously which type of devices aregoing to access to the information and its capabilities.

Acceptance MeasureThe solution will be interoperable between the agreeddevices, and the maximum number of functionalities will beaccessible from the less power devices.

Tester TBD

Extra information


20/25



Licensing


Name Licensing

Id NF-0007

Date

Description

The license is the feature that any product has in order toprotect the intellectual property of its creators. With alicense, a licensor may grant a license under intellectualproperty laws to authorise a use (such as copying softwareor using a (patented) invention) to a licensee, sparing thelicensee from a claim of infringement brought by thelicensor. A license under intellectual property commonlyhas several components beyond the grant itself, including

a term, territory, renewal provisions, and other limitationsdeemed vital to the licensor.

Acceptance MeasureThe solution must be licensed and this license must belegal. That means that this software will be legal to useand distribute among the organization.

Tester TBD

Extra information


21/25



Maintainability


Name Maintainability

Id NF-0008

Date

Description

In engineering, maintainability is the ease with which aproduct can be maintained in order to isolate defects andcorrect them, build up new requirements and make easierits future maintenance, and cope with a changedenvironment

In some cases, maintainability involves a system ofcontinuous improvement - learning from the past in orderto improve the ability to maintain systems, or improve

reliability of systems based on maintenance experience.

Acceptance Measure

The solution proposed will be easy to maintain. Thesoftware designed will follow maintenance patterns toreduce the impact of new requirements and isolate thepotential bugs.

Tester TBD

Extra information


22/25



Performance


Name Performance

Id NF-0009

Date

Description

The system performance is the capacity to keep theoptimal 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 anyconcurrence and situation. This goal can be preventedusing enough resources to cover all these situations, oradding resources dynamically when an overload situation

is happening, in advance.

Acceptance Measure

The solution will keep the performance in the agreedsituations. When an overload situation is detected, thesolution will emit a signal to the application administratorsto alert about an overload situation.

Tester TBD

Extra information


23/25



Platform compatibility


Name Platform compatibility

Id NF-0010

Date

DescriptionThe platforms compatibility feature is the system capabilityof run into different platforms without penalties inperformance neither extra configuration.

Acceptance Measure

The solution proposed will be platform independent,because it will be installed over a virtual machine, and thisvirtual machine gives an additional abstraction layer overthe platform in order to minimize this impact.

Tester TBD

Extra information


24/25



Scalability


Name Scalability

Id NF-0011

Date

Description

The scalability feature is the ability of a system to handle agrowing amount of work in a capable manner or its abilityto be enlarged to accommodate that growth. It may refer tothe capability of a system to increase total throughputunder an increased load when hardware resources areadded.

Scalability, as a property of systems, is generally difficult todefine and in any particular case it is necessary to define

the specific requirements for scalability on thosedimensions that are deemed important. A system, whoseperformance improves after adding hardware,proportionally to the capacity added, is said to be ascalable system.

Acceptance MeasureThe solution proposed will be scalable. If a lack ofresources is detected, it will be easy to solve this problemjust adding new resources to the bottle neck.

Tester TBD

Extra information


25/25


Security


Name Security

Id NF-0012

Date

Description

The Security in the field of computer science is a verybroad concept. It may be defined as the ability toguarantee the integrity of the information providing by thesystem, and the access control to it.

The control policies that determine which entities can seewhat information is a concept that is also associated withthis field.

Acceptance MeasureThe solution will guarantee the information integrity, and itwill provide a mechanism to the information access controland the definitions of users and groups of users.

Tester TBD

Extra information

Documents

2. Requirements Gathering