8/10/2019 2. Requirements Gathering
1/25
MIS Requeriments
Gathering
March 2013
8/10/2019 2. Requirements Gathering
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
8/10/2019 2. Requirements Gathering
3/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
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
8/10/2019 2. Requirements Gathering
4/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
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.
8/10/2019 2. Requirements Gathering
5/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
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.
8/10/2019 2. Requirements Gathering
6/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
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
8/10/2019 2. Requirements Gathering
7/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
8/10/2019 2. Requirements Gathering
8/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Ai rpor t Operational Data Base
Functional requirement
First Level
Second Level Dependent requirementid
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
8/10/2019 2. Requirements Gathering
9/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Enterprise Resource Planning
Functional requirement
First Level
Second Level Dependent requirementid
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.
8/10/2019 2. Requirements Gathering
10/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Lightweight Directory Access Protocol
Functional requirement
First Level
Second Level Dependent requirementid
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.
8/10/2019 2. Requirements Gathering
11/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Records Management
Functional requirement
First Level
Second Level Dependent requirementid
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.
8/10/2019 2. Requirements Gathering
12/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Web Publications
Functional requirement
First Level
Second Level Dependent requirementid
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
8/10/2019 2. Requirements Gathering
13/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
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
8/10/2019 2. Requirements Gathering
14/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
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
8/10/2019 2. Requirements Gathering
15/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Backup
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
16/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Disaster recovery
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
17/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Extensibility
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
18/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Fault tolerance
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
19/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Interoperability
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
20/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Licensing
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
21/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Maintainability
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
22/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Performance
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
23/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Platform compatibility
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
24/25
MISRequirements gathering
Ingeniera y Economa del Transporte, S.A.
Scalability
Non-functional requirement
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
8/10/2019 2. Requirements Gathering
25/25
MISRequirements gathering
Security
Non-functional requirement
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
Top Related