Вы находитесь на странице: 1из 25
March 2013 MIS Requeriments Gathering
March 2013 MIS Requeriments Gathering

March 2013

March 2013 MIS Requeriments Gathering
March 2013 MIS Requeriments Gathering

MIS Requeriments Gathering

Index M I S Requirements gathering INTRODUCTION 3 REQUIREMENTS GATHERING 4 REQUIREMENT 5

Index

MIS Requirements gathering

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

Ingeniería y Economía del Transporte, S.A.

M I S Requirements gathering Introduction The main goal of this document is to gather

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

Ingeniería y Economía del Transporte, S.A.

Requirements gathering M I S Requirements gathering The requirements gathering process is the first phase

Requirements gathering

MIS 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.

Ingeniería y Economía del Transporte, S.A.

Requirement M I S Requirements gathering A common Requirement definition drawn from IEEE-STD-1220-1998 (IEEE 1998):

Requirement

MIS Requirements gathering

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.

Ingeniería y Economía del Transporte, S.A.

Functional requirements M I S Requirements gathering To simplify the collect of MIS project requirements,

Functional requirements

MIS Requirements gathering

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

Complete

o

Specific, unambiguous.

o

Testable or measurable

o

Prioritized

o

Achievable, realistic

o

Connected

o

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

Dependent requirement id

Name

 

Id

 

Date

 

Description

 

Acceptance Measure

 

Tester

 

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Ingeniería y Economía del Transporte, S.A. M I S Requirements gathering

Ingeniería y Economía del Transporte, S.A.

MIS Requirements gathering

Airport Operational Data Base M I S Requirements gathering Functional requirement First Level ☒  

Airport Operational Data Base

MIS Requirements gathering

Functional requirement

First Level

 

Second Level

Dependent requirement id

 

Name

Airport Operational Data Base (AODB)

 

Id

F-0001

Date

 

Description

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, company’s 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.

Acceptance Measure

The solution proposed must write down all airport operations and their associate information, and AODB must contain with methods to be interoperable.

Tester

TBD

Extra information

MIS team was informed about TIA airport has already installed a similar solution in their IT systems, which probably

Ingeniería y Economía del Transporte, S.A.

Enterprise Resource Planning M I S Requirements gathering Functional requirement First Level ☒  

Enterprise Resource Planning

MIS Requirements gathering

Functional requirement

First Level

 

Second Level

Dependent requirement id

 

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 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.

Ingeniería y Economía del Transporte, S.A.

M I S Requirements gathering Lightweight Directory Access Protocol Functional requirement First Level ☒

MIS Requirements gathering

Lightweight Directory Access Protocol

Functional requirement

First Level

 

Second Level

Dependent requirement id

 

Name

Lightweight Directory Access Protocol (LDAP)

Id

F-0003

Date

 

Description

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.

Acceptance Measure

All security policies defined will be able to be implemented in the corporate LDAP System.

Tester

TBD

Extra information

LDAP is specified using the description language. This language is well-documented in several places, and is easy to learn.

Ingeniería y Economía del Transporte, S.A.

Records Management M I S Requirements gathering Functional requirement First Level ☒   Second Level

Records Management

MIS Requirements gathering

Functional requirement

First Level

 

Second Level

Dependent requirement id

 

Name

Records management (RM)

 

Id

F-0004

 

Date

 
 

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

Description

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.

 

All

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

must be managed by this system, and all of them must be

Acceptance Measure

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

TBD

 
 

With this kind of system, it is guaranteed always that the

Extra information

latest and the most updated information are checked in all

the

times that this piece of information is needed.

Ingeniería y Economía del Transporte, S.A.

Web Publications M I S Requirements gathering Functional requirement First Level ☒   Second Level

Web Publications

MIS Requirements gathering

Functional requirement

First Level

 

Second Level

Dependent requirement id

 

Name

F-0005

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

TBD

Tester

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

 

Ingeniería y Economía del Transporte, S.A.

M I S Requirements gathering Non-functional requirements or technical requirements In computer engineering terms, 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 non- functional 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

Execution qualities, such as security and usability, which are observable at run time.

o

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

Ingeniería y Economía del Transporte, S.A.

Availability M I S Requirements gathering   Non-functional requirement Name   Availability Id

Availability

MIS Requirements gathering

 

Non-functional requirement

Name

 

Availability

Id

NF-0001

Date

 
 

The system availability is the feature to explain the amount of time that a system has to be accessible and working in

Description

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

Acceptance Measure

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.

Tester

 

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Backup M I S Requirements gathering   Non-functional requirement Name Backup Id NF-0002 Date

Backup

MIS Requirements gathering

 

Non-functional requirement

Name

Backup

Id

NF-0002

Date

 

Description

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.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Disaster recovery M I S Requirements gathering   Non-functional requirement Name Disaster recovery Id

Disaster recovery

MIS Requirements gathering

 

Non-functional requirement

Name

Disaster recovery

Id

NF-0003

Date

 

Description

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.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Extensibility M I S Requirements gathering   Non-functional requirement Name Extensibility Id

Extensibility

MIS Requirements gathering

 

Non-functional requirement

Name

Extensibility

Id

NF-0004

Date

 

Description

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.

Acceptance Measure

The solution will be implemented following this principle, taking into account future improvements and product integrations.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Fault tolerance M I S Requirements gathering   Non-functional requirement Name Fault tolerance Id

Fault tolerance

MIS Requirements gathering

 

Non-functional requirement

Name

Fault tolerance

Id

NF-0005

Date

 

Description

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.

Acceptance Measure

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

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Interoperability M I S Requirements gathering   Non-functional requirement Name Interoperability Id

Interoperability

MIS Requirements gathering

 

Non-functional requirement

Name

Interoperability

Id

NF-0006

Date

 

Description

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.

Acceptance Measure

The solution will be interoperable between the agreed devices, and the maximum number of functionalities will be accessible from the less power devices.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Licensing M I S Requirements gathering   Non-functional requirement Name Licensing Id NF-0007

Licensing

MIS Requirements gathering

 

Non-functional requirement

Name

Licensing

Id

NF-0007

Date

 

Description

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.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Maintainability M I S Requirements gathering   Non-functional requirement Name Maintainability Id

Maintainability

MIS Requirements gathering

 

Non-functional requirement

Name

Maintainability

Id

NF-0008

Date

 

Description

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.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Performance M I S Requirements gathering   Non-functional requirement Name Performance Id NF-0009

Performance

MIS Requirements gathering

 

Non-functional requirement

Name

Performance

Id

NF-0009

Date

 

Description

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.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Platform compatibility M I S Requirements gathering   Non-functional requirement Name Platform

Platform compatibility

MIS Requirements gathering

 

Non-functional requirement

Name

Platform compatibility

Id

NF-0010

Date

 

Description

The platforms compatibility feature is the system capability of run into different platforms without penalties in performance neither extra configuration.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Scalability M I S Requirements gathering   Non-functional requirement Name Scalability Id NF-0011

Scalability

MIS Requirements gathering

 

Non-functional requirement

Name

Scalability

Id

NF-0011

Date

 

Description

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.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.

Security M I S Requirements gathering   Non-functional requirement Name Security Id NF-0012

Security

MIS Requirements gathering

 

Non-functional requirement

Name

Security

Id

NF-0012

Date

 

Description

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.

Acceptance Measure

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.

Tester

TBD

Extra information

 

Ingeniería y Economía del Transporte, S.A.