Aplicação de uma metodologia AORE para elicitação de ... · Aplicação de uma metodologia AORE para elicitação de requisitos de seguran-ça/ Camila Pardo Garcia Morelli. –

Camila Pardo Garcia Morelli

Aplicação de uma metodologia AORE para

elicitação de requisitos de segurança

Campos dos Goytacazes, RJ

06 de dezembro de 2013


Aplicação de uma metodologia AORE para elicitação de

requisitos de segurança

Trabalho de Conclusão de Curso apresen-tado ao Curso de Graduação em Ciência daComputação da Universidade Estadual doNorte Fluminense Darcy Ribeiro como requi-sito para a obtenção do título de Bacharelem Ciência da Computação, sob orientaçãode Prof. Ausberto S. Castro Vera.

Universidade Estadual do Norte Fluminense Darcy Ribeyro – UENF

Centro de Ciência e Tecnologia – CCT

Laboratório de Ciências Matemáticas – LCMAT

Curso de Ciência da Computação

Orientador: Prof. Ausberto S. Castro Vera

Campos dos Goytacazes, RJ

06 de dezembro de 2013

Camila Pardo Garcia MorelliAplicação de uma metodologia AORE para elicitação de requisitos de seguran-

ça/ Camila Pardo Garcia Morelli. – Campos dos Goytacazes, RJ, 06 de dezembrode 2013-

81 p. : il. (algumas color.) ; 30 cm.

Orientador: Prof. Ausberto S. Castro Vera

Monografia (Bacharelado) – UENF-CCT-LCMAT-Ciência da Computação, 06 dedezembro de 2013.1. Engenharia de Requisitos. 2. Orientação a Aspectos. 3. Engenharia da

Segurança. 4. Confidencialidade. 5. Domínios de Requisitos. 6. Metodologia

CDU 004.41 : 004.4’2 :


Aplicação de uma metodologia AORE para elicitação derequisitos de segurança

Trabalho de Conclusão de Curso apresen-tado ao Curso de Graduação em Ciência daComputação da Universidade Estadual doNorte Fluminense Darcy Ribeiro como requi-sito para a obtenção do título de Bacharelem Ciência da Computação, sob orientaçãode Prof. Ausberto S. Castro Vera.

Trabalho aprovado. Campos dos Goytacazes, RJ, 06 de dezembro de 2013:

Prof. Ausberto S. Castro VeraOrientador

Prof. Fermín Alfredo Tang MontanéMembro da Banca

Prof. Carlos Leonardo Ramos PóvoaMembro da Banca

Campos dos Goytacazes, RJ 06 de dezembro de 2013

Este trabalho é dedicado aos meus pais, que me ensinaram a nunca desistir de lutar pelo

que desejamos e sonhamos.

Agradecimentos

Agradeço primeiro a Deus, por estar presente em minha vida iluminando-a e dando-

me forças para vencer os obstáculos e os desafios da vida.

Aos meus pais, Marissol e José, que desde sempre colocaram em prioridade meus

estudos, que me criaram e deram-me as condições para estar aqui hoje. Agradeço por

todo apoio, amor, carinho, e paciência. Em especial agradeço a minha mãe que mesmo

estando distante estava sempre acompanhando e dando motivação para que tudo desse

certo nessa trajetória.

A minha Irmã Isabelle, por todo amor, carinho e compreensão.

Ao meu avô, Manuel que me ensinou que o saber é uma algo que ninguém pode

tirar de você, e que de sua forma cuidou de mim em muitos momentos. Agradeço por

tudo!

As minhas avós, Leda e Marina que sei que estarão orgulhosas por essa conquista

e que em muitos momentos oraram por mim.

A todos os professores ao longo do curso pelos conhecimentos transmitidos, princi-

palmente ao Prof. Dr. Luiz Antônio Escriba Rivera e ao meu orientador Prof. Dr. Ausberto

Castro pelos conselhos, dedicação e disponibilidade.

A todos meus colegas de classe, principalmente as amigas Sânya e Mayra, que

me acompanharam desde o inicio do curso, nos momentos de estudos na biblioteca, na

república e nas noites de trabalhos. Em especial a Sânya por todo apoio, amizade e aos

momentos inesquecíveis que passamos. A Carol e João pelos momentos de descontração,

amizade e companheirismo. Ao Márcio Dutra pela compreensão e pelo apoio para que

este trabalho fosse concluído. Ao amigo Pedro pela amizade, companheirismo e pelos

bons momentos no estágio.

Ao Rhuan que me apoiou diversas vezes para não desistir nos obstáculos e desafios

encontrados. Afinal ”no fim tudo dá certo, e se não deu certo é porque ainda não chegou

ao fim.”

Agradeço a todos que participaram direta e indiretamente da minha caminhada

na universidade, e que de alguma forma contribuíram para meu sucesso e para meu

crescimento como pessoa. Obrigada!

"Talvez não tenha conseguido fazer o melhor, mas lutei para que o melhor fosse feito.

Não sou o que deveria ser, mas Graças a Deus, não sou o que era antes".

(Marthin Luther King)

Resumo

A Engenharia de Requisitos é uma área da computação que tem como foco o geren-

ciamento de requisitos de um sistema a ser desenvolvido. Suas atividades principais

concentram-se na coleta, análise, classificação e documentação de requisitos. Este trabalho

tem como objetivo a aplicação de uma metodologia baseada em aspectos para a constru-

ção de uma biblioteca de requisitos sobre segurança computacional, especificamente sobre

a propriedade de confidencialidade do sistema. A aplicação da metodologia orientada a

aspectos foi utilizada em dois exemplos: o primeiro, um Sistema Computacional Genérico

e, o segundo, um sistema do tipo ERP Acadêmico. A implementação e o gerenciamento da

biblioteca de requisitos desenvolvida, foi realizada utilizando a ferramenta CASE Visual

Paradigm, v.10.2.

Palavras-chaves: engenharia de requisitos. domínios e aspectos. segurança. confidencia-

lidade.

Abstract

The Requirements Engineering is an area of computing that focuses on the management

requirements of a system to be developed. Its main activities are focused on the collec-

tion, analysis, classification and documentation requirements. This paper aims to apply a

methodology based on aspects to building a library of requirements on computer security,

specifically on the propriety of confidentiality of the system. The application of aspect-

oriented methodology was used in two examples: first, Generic Computer System and

the second, a system like ERP Academic. The implementation and library management

requirements developed, was performed using the CASE tool Visual Paradigm, v.10.2.

Key-words: requirements engineering. domains and aspects. security. confidentiality.

Lista de ilustrações

Figura 1 – Engenharia de Requisitos e Engenharia de Software . . . . . . . . . . . 22

Figura 2 – Processo de Análise de Requisitos . . . . . . . . . . . . . . . . . . . . 23

Figura 3 – Etapas do processo de elicitação e análise de requisitos . . . . . . . . . 24

Figura 4 – Aspectos fundamentais da segurança computacional . . . . . . . . . . . 26

Figura 5 – Evolução do paradigma Orientado a Aspectos . . . . . . . . . . . . . . 29

Figura 6 – O conceito de aspecto e domínio . . . . . . . . . . . . . . . . . . . . . . 30

Figura 7 – Exemplo de domínio de requisitos e aspecto . . . . . . . . . . . . . . . 31

Figura 8 – Adaptação da metodologia de Sommerville (2003) . . . . . . . . . . . . 31

Figura 9 – Metodologia AORE proposta por Castro-Vera (2013) . . . . . . . . . . 33

Figura 10 – Paradigma de Desenvolvimento de sistemas seguros . . . . . . . . . . . 36

Figura 11 – Biblioteca de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Figura 12 – Sistema Computacional Genérico - Visão Geral . . . . . . . . . . . . . 37

Figura 13 – Estrutura ERP Acadêmico . . . . . . . . . . . . . . . . . . . . . . . . . 53

Figura 14 – A Classe Gestão Acadêmica . . . . . . . . . . . . . . . . . . . . . . . . 54

Figura 15 – A classe Gestão Tecnológica . . . . . . . . . . . . . . . . . . . . . . . . 54

Figura 16 – A classe Gestão Empresarial . . . . . . . . . . . . . . . . . . . . . . . . 55

Figura 17 – A classe Gestão Estratégica . . . . . . . . . . . . . . . . . . . . . . . . 55

Figura 18 – A classe Graduação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figura 19 – Domínio ERP Acadêmico . . . . . . . . . . . . . . . . . . . . . . . . . 56

Figura 20 – Domínio Gestão Acadêmica . . . . . . . . . . . . . . . . . . . . . . . . 57

Figura 21 – Domínio Graduação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Figura 22 – Versão do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Figura 23 – Ferramenta de Requisito . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Figura 24 – Ferramenta de Geração de Relatórios . . . . . . . . . . . . . . . . . . . 65

Figura 25 – Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Figura 26 – Novo projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Figura 27 – Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Figura 28 – Grade de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Figura 29 – Novo Requirements Grid . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Figura 30 – Criando um novo Requisito . . . . . . . . . . . . . . . . . . . . . . . . 69

Figura 31 – Inserindo um Requisito . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Figura 32 – Requisitos Inseridos na Grade . . . . . . . . . . . . . . . . . . . . . . . 70

Figura 33 – Especificação do Requisito . . . . . . . . . . . . . . . . . . . . . . . . . 70

Figura 34 – Dados do Requisito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Figura 35 – Adicionando uma Especificação ao Requisito . . . . . . . . . . . . . . 71

Figura 36 – Classificação do Requisito . . . . . . . . . . . . . . . . . . . . . . . . . 72

Figura 37 – Adicionar tipo a um Requisito . . . . . . . . . . . . . . . . . . . . . . . 72

Figura 38 – Buscando um Stereotypes (Domínio) . . . . . . . . . . . . . . . . . . . 73

Figura 39 – Exportando Documento . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Figura 40 – Visão da tela Generate PDF . . . . . . . . . . . . . . . . . . . . . . . 74

Figura 41 – Selecionando Diagramas para exportação . . . . . . . . . . . . . . . . . 75

Figura 42 – Editar Capa do Documento . . . . . . . . . . . . . . . . . . . . . . . . 75

Figura 43 – Capa do relatório exportado em PDF . . . . . . . . . . . . . . . . . . . 76

-

Lista de tabelas

Tabela 1 – Campos na Grade de requisitos . . . . . . . . . . . . . . . . . . . . . . 69

Lista de abreviaturas e siglas

AOSD Aspect-Oriented System Development

AORE Aspect-Oriented Requirements Engineering

CASE Computer-Aided Software Engineering

EROA Engenharia de Requisitos Orientada a Aspectos

ERP Enterprise Resource Planning

SIGE Sistemas Integrados de Gestão Empresarial

TIC Tecnologias da Informação e Comunicação

UML Unified Modeling Language

Sumário

1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.1 Objetivo e Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2 Engenharia de Requisitos e Engenharia da Segurança . . . . . . . . 17

2.1 Engenharia de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.1.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.1.2 A definição de Engenharia de Requisitos . . . . . . . . . . . . . . . . . . 20

2.1.3 Metodologia para Análise de Requisitos . . . . . . . . . . . . . . . . . . 23

2.2 Engenharia da Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.1 Segurança Computacional . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2.2 Segurança de um Sistema de Informação . . . . . . . . . . . . . . . . . 26

2.2.3 Engenharia da Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3 Uma Metodologia Orientada a Aspectos . . . . . . . . . . . . . . . 28

3.1 Referencial Teórico sobre Orientação a Aspectos . . . . . . . . . . . . . 28

3.2 Domínio de requisitos e Aspectos . . . . . . . . . . . . . . . . . . . . . 29

3.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Biblioteca de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.1 Biblioteca de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.1 Domínio de Requisitos: Sistema Computacional Genérico . . . . . . . . 37

4.2 Estudo de Caso: Sistema ERP Acadêmico . . . . . . . . . . . . . . . . 52

4.2.1 Modelagem do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.2 Aplicação da metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5 Implementação com Ferramenta CASE . . . . . . . . . . . . . . . . 63

5.1 Visual Paradigm for UML . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.2 Criação da Biblioteca no Visual Paradigm . . . . . . . . . . . . . . . . . 65

5.2.1 Ambiente de Trabalho - Interface . . . . . . . . . . . . . . . . . . . . . 65

5.2.2 Criação da Biblioteca no Visual Paradigm for UML . . . . . . . . . . . 66

5.2.3 Geração de Relatório de Requisitos . . . . . . . . . . . . . . . . . . . . 73

Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

14

1 Introdução

A dependência da nossa sociedade em relação a sistemas computadorizados tem

crescido de forma exponencial nos últimos anos. Esta evolução tecnológica é acompanhada

por novos problemas e desafios, entre muitos dos quais temos a segurança da informação.

Manter a segurança de um sistema é considerado uma tarefa difícil. Para um gestor de

TIC, o cenário costuma ser bastante complexo na hora de adotar novas tecnologias ou

políticas que facilitem o processo de trabalho, normalmente são identificadas três barreiras

principais: a segurança, a necessidade de suporte e os custos. Dentre essas barreiras o

obstáculo mais mencionado é a questão da segurança, visto que ao expandir as opções em

dispositivos, serviços ou softwares abrem-se novas brechas na segurança de um sistema.

Os ativos de TI são fundamentais para o sucesso dos negócios empresariais e devem

ser protegidos. As empresas mantém importantes informações digitais estáticas (banco

de dados, backups, homepages, etc.) e dinâmicas (e-mails, transações comerciais diárias

e interações entre cliente/servidor), tornando complexo a implementação e manutenção

da segurança. Por outro lado, as redes e os sistemas distribuídos facilitam o acesso não

autorizado, o uso indevido e a fraude, em qualquer ponto de acesso ao sistema (LAUDON;

LAUDON, 2007; The Standish Group International, 2008).

Neste contexto de insegurança, na maioria das vezes, os responsáveis pelos siste-

mas de informação, implementam políticas de prevenção e manutenção de incidentes num

sistema que não foi concebido para funcionar em um ambiente de insegurança, onde as

propriedades de confidencialidade, integridade e disponibilidade das informações é funda-

mental para atingir os objetivos de negócios do sistema.

Felizmente, nos últimos anos tem surgido a preocupação para usar ferramentas,

metodologias e tecnologias para desenvolver desde sua origem, sistemas que poderão ser

considerados seguros. Assim, já são utilizadas técnicas e ferramentas CASE para desen-

volver projetos seguros, técnicas, ferramentas e linguagens de programação para obter

códigos executáveis seguros. Porém, ainda não existem muitas pesquisas, ferramentas ou

metodologias consolidadas para as primeiras etapas do desenvolvimento de sistemas com-

putacionais seguros, isto é, para as etapas de Planejamento e Análise.

Desenvolver sistemas seguros a custo baixo e com alta qualidade desde sua ori-

gem é a preocupação conjunta da Engenharia de Sistemas e da Engenharia da Segurança.

A Engenharia de Sistemas contribui com o desenvolvimento de técnicas, ferramentas e

metodologias na Engenharia de Requisitos. A Engenharia da Segurança preocupa-se de

atender todos os requerimentos das principais propriedades ou áreas que definem o con-

ceito de segurança do sistema, entre elas a confidencialidade, integridade e disponibilidade.

Capítulo 1. Introdução 15

A grande dificuldade dos desenvolvedores de sistemas é integrar todas estas propriedades

de segurança com os processos relacionados com a Engenharia de Requisitos. Ou seja,

ainda é um problema em vias de solução, a determinação de o QUE o sistema deve ser

ou deve ter para atender os objetivos de negócios de um sistema seguro, na forma de fun-

cionalidades ou propriedades. Estas funcionalidades ou propriedades são os requisitos do

sistema. As metodologias Orientadas a Aspectos, conhecidas como metodologias AORE e

inicialmente propostas para atender as etapas de implementação, estão sendo redefinidas

para dar apoio às etapas de Análise de Requisitos.

Vale a pena ressaltar que a preocupação por desenvolvimento de técnicas e meto-

dologias para sistemas seguros é assunto da Engenharia de Sistemas, independentemente

se eles são sistemas computacionais ou não. Contudo, nossa preocupação aqui é ape-

nas o relacionado com sistemas baseados em computador formados por seis componentes

fundamentais: Hardware, Software, Pessoas, Banco de Dados, Documentos e Metodolo-

gias. Assim, os conceitos e aplicações que serão aqui abordados (sobre Engenharia de

Requisitos) estão orientados a atender estas seis componentes desde o ponto de vista da

segurança.

O ideal nestes processos de desenvolvimento e de pesquisa seria abordar todas as

áreas ou propriedades da segurança dos sistemas computacionais, porém, limitados pelo

tempo, espaço e referências bibliográficas, o aconselhável é considerar os tópicos em forma

individual. Assim, neste texto pretende-se fixar o foco na propriedade de confidenciali-

dade como parte da segurança de um sistema computacional. A confidencialidade é a

propriedade relacionada com a ocultação da informação ou dos recursos computacionais.

A confidencialidade é a propriedade pela qual um sistema ou parte dele, não está disponí-

vel ou revelado a indivíduos, entidades, processos ou sistemas não autorizados. Do ponto

de vista da Engenharia de Requisitos, o problema básico a resolver seria determinar o

conjunto de requisitos que tornam um sistema seguro considerando apenas a propriedade

de confidencialidade.

Como determinar um conjunto de requisitos de segurança implica duas questões:

primeiro, determinar qual seria o sistema mínimo a ser considerado, e segundo, que me-

todologia utilizar para determinar o conjunto de requisitos de segurança. Para isto, será

definido o conceito de domínio de requisitos e a determinação de uma metodologia de

como obter estes requisitos. Ambos conceitos resultarão numa biblioteca de requisitos

relacionados apenas com a propriedade de confidencialidade.

1.1 Objetivo e Justificativa

O objetivo geral deste trabalho é aplicar uma metodologia para elicitação de re-

quisitos baseada em aspectos e na propriedade de confidencialidade de sistemas computa-

Capítulo 1. Introdução 16

cionais, resultando em uma biblioteca de requisitos. Dois estudos de caso genéricos serão

considerados: um Sistema Computacional Genérico e um Sistema ERP Acadêmico.

Para atingir o objetivo geral desse trabalho, consideramos:

1. O estudo de conceitos básicos de Engenharia de Requisitos e da Segurança

2. Organizar e armazenar os requisitos na forma de uma biblioteca e utilizando uma

ferramenta CASE;

3. Validar a metodologia adotada através de dois estudos de caso

4. Disponibilizar o documento de requisitos (biblioteca), para ser utilizado nas outras

etapas do desenvolvimento de sistemas seguros, e servir como modelo para comple-

mentar a biblioteca com outras propriedades de segurança.

1.2 Estrutura do Trabalho

Este trabalho está estruturado em seis capítulos da seguinte maneira:

No Capítulo 2, apresenta-se uma revisão bibliográfica referente a Engenharia de

Requisitos e Engenharia da Segurança, incluindo suas classificações e diferentes taxono-

mias que envolvem no processo de desenvolvimento de um sistema.

No Capítulo 3, é apresentada uma metodologia orientada a aspectos que posteri-

ormente será utilizada para determinar os requisitos de um sistema com propriedades de

segurança.

No Capítulo 4, é implementada a biblioteca de requisitos de segurança com suas

respectivas classificações, como descrito na metodologia.

No Capítulo 5, é implementada a biblioteca de requisitos na ferramenta CASE -

Visual Paradigm for UML.

Na parte final, das conclusões, é apresentado um resumo das dificuldades para

elaborar este documento, do que foi desenvolvido, e algumas ideias para futuros trabalhos

relacionados na área de segurança de um sistema computacional.

17

2 Engenharia de Requisitos e Engenharia da

Segurança

De acordo com (PRESSMAN, 2006), um sistema baseado em computador, mais

conhecido como sistema computacional, é um conjunto ou arranjo de seis elementos orga-

nizados para atingir alguma meta predefinida por meio do processamento da informação.

Estes elementos sËĲao: software, hardware, pessoas, banco de dados, documentação e

procedimentos/metodologias.

A vulnerabilidade (fragilidade) de um sistema computacional na maioria das vezes

não é observada nas primeiras etapas do seu desenvolvimento. Considerando este contexto,

os engenheiros de software e de sistemas computacionais, devem considerar práticas de

segurança nas primeiras etapas do desenvolvimento: especificação e projeto. Tais práticas,

metodologias e processos correspondem à Engenharia de Requisitos e à Engenharia de

Segurança.

2.1 Engenharia de Requisitos

O famoso cientista da computação alemão, Manfred Broy em seu prólogo de (BE-

RENBACH et al., 2009), afirma que, a engenharia de requisitos tem sido considerada

como uma das atividades mais difíceis e críticas para o sucesso do desenvolvimento de

software, devido que, se os requisitos são inválidos então a maior parte das implementa-

ções resultará em um produto com pouca usabilidade. Além disso, se os requisitos que

forem considerados na especificação não forem realmente válidos então o produto tornar-se

desnecessariamente caro. Isto mostra a importância da engenharia de requisitos.

A crescente complexidade na manutenção dos sistemas computacionais dentro de

uma organização é contornada pela capacidade e habilidade de utilizar uma engenharia

de requisitos eficaz (HULL; JACKSON; DICK, 2011). Este ponto de vista também é um

indicativo da importância da engenharia de requisitos.

Glinz e Wieringa (2007) afirma que para construir um sistema eficiente, precisamos

reconhecer primeiramente seus requisitos e para conhecer estes requisitos, precisamos

conhecer os desejos e necessidades dos stakeholders. O termo stakeholder generaliza a

tradicional ideia de cliente ou usuário em Engenharia de Requisitos.

Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 18

Stakeholder (HULL; JACKSON; DICK, 2011)

Um indivíduo, grupo de pessoas, organização ou outra entidade que possui algum

tipo de interesse ou participação (direto/indireto) em um determinado sistema.

Interesses de stakeholders em um sistema tem sua origem no uso do sistema,

nos benefícios do sistema (lucros ou vantagens), nas desvantagens do sistema (custos ou

potenciais prejuízos), nas responsabilidades no sistema, ou algo que de alguma forma afete

ao stakeholder.

Como exemplos de stakeholders em uma organização qualquer podemos conside-

rar usuários finais, gerentes de negócios, administrador de rede, a gerencia financeira, o

departamento de recursos humanos, um operador de rede, o departamento de TIC, etc.

2.1.1 Requisitos

Informalmente podemos dizer que, um requisito em um sistema computacional é

uma descrição do que o sistema deve fazer, dos serviços que o sistema deve oferecer, e das

restrições sobre as quais o sistema deve funcionar

Os requisitos refletem as necessidades dos clientes que um determinado sistema

deve satisfazer. Por exemplo, em um sistema de informação qualquer, a necessidade de

controlar um dispositivo, a necessidade de gerar uma ordem de compra, de fazer um cadas-

tro, de imprimir um documento, de acessar internet, de enviar um email, etc. representam

requisitos.

Falar de requisitos de um sistema, significa considerar três ideias diferentes: o

requisito (o seu conceito, o que significa), a definição de requisito (a forma como se escreve

um requisito no documento de requisitos), e a especificação de requisitos (o detalhamento

do requisito para fins de implementação). A seguir apresenta-se dois conceitos encontrados

na literatura sobre o que é um requisito:

Conceito de Requisito (HULL; JACKSON; DICK, 2011)

Uma declaração que identifica um produto ou processo operacional, característica

funcional, ou desenho, ou uma restrição, a qual não é ambígua, testável ou mensu-

rável, e necessário para a aceitabilidade de um produto ou processo (por parte dos

usuários, clientes ou diretrizes internas de garantia da qualidade).


Conceito de Requisito (ISO/IEC/IEEE, 2010)

1. Uma condição ou capacidade necessária por um usuário para resolver um

problema ou alcançar um objetivo.

2. Uma condição ou capacidade que deve ser satisfeita ou possuída por um sis-

tema, produto ou componente do sistema para satisfazer um contrato, um

padrão, uma especificação, ou outro documento formalmente exigido.

3. Uma representação documentada de uma condição ou capacidade como em

(1) ou (2).

Destes conceitos podemos destacar os termos em português que indicam o sig-

nificado de requisito: condição, capacidade, produto, componente, processo operacional,

característica funcional, restrição. Os seguintes exemplos de requisitos, de diferentes sis-

temas, ilustram os termos contidos nas definições anteriores:

Programa de controle de estoque (produto)

Envio de mensagens (processo operacional)

Emissão de nota fiscal (característica funcional)

Transmissão de dados (capacidade)

Acesso não autorizado ao banco de dados (condição)

A segunda ideia associada a um requisito é a definição que faz parte do documento

de requisitos, e que apresentamos a seguir:

Definição de Requisito

É uma frase simples ou abstrata (declaração em linguagem natural, português) do

que o sistema deve fazer ou oferecer.

Sintaticamente, uma definição de requisito sempre tem o seguinte formato:

< Sujeito > < Verbo > < Complemento >

São exemplos de definições de requisito:

O sistema deverá ter acesso somente através de senha.

Os documentos podem ser acessados apenas através da permissão do usuário.

O sistema deverá suportar cabeamento estruturado.

E finalmente, a terceira idea relacionada com um requisito é a especificação, que

se define da seguinte forma:


Especificação de Requisito

É o detalhamento da definição do requisito. Cada detalhe é numerado e tem uma

ligação com a definição de requisito.

Na verdade, a especificação de um requisito, é uma sequencia detalhada de ativida-

des que devem ser consideradas na etapa do Projeto do Sistema para indicar o que deve

ser realizado na etapa de Implementação para satisfazer tal requisito.

O seguinte exemplo ilustra o uso dos termos requisito, definição de requisito e

especificação de requisito. observe-se que neste exemplo, incluímos um número (37), que

representa a identificação do requisito dentro de uma biblioteca de requisitos associada ao

sistema que será desenvolvido. Os números 37.1, 37.2, ..., 37.9 da especificação, indicam

que o detalhamento refere-se ao requisito identificado com o número 37.

Requisito

37. Acesso ao sistema.

Definição de Requisito

37. O acesso ao sistema deverá ser feito utilizando o nome do usuário e senha.

Especificação Requisito

37.1 Abrir janela inicial com interface de acesso

37.2 Ingressar informações de acesso (usuário, senha).

37.3 Verificar usuário cadastrado.

37.4 Verificar senha cadastrada.

37.5 Liberar perfil de usuário.

37.6 Liberar área e ferramentas de trabalho.

37.7 Permitir acesso à Internet.

37.8 Fazer controle de atividades de usuário.

37.9 Finalizar processo.

2.1.2 A definição de Engenharia de Requisitos

A Engenharia de Requisitos (ER) é uma área de conhecimento nova provida de

muitos assuntos, ferramentas, técnicas e livros textos. Academicamente, hoje pode ser

encontrada como uma disciplina, como uma área de pesquisa e como tema de uma uma

série de eventos. Zave (1997) cita os seguintes assuntos como materia de estudo da ER:

• Tarefas que devem ser completadas: elicitação da informação a partir dos clientes,

validação e especificação.


• Problemas que devem ser resolvidos: barreiras para a comunicação, incompleteza,

inconsistência.

• Soluções para problemas: linguagens formais e algoritmos de análise, prototipação,

métricas, seguimento.

• Maneiras de contribuir ao conhecimento: descrições das melhores práticas, casos

de estudo, experimentos controlados.

• Tipos de sistemas: sistemas embarcados, sistemas críticos e seguros, sistemas dis-

tribuídos.

Entender a definição de Engenharia de Requisitos significa entende-lo como área de

conhecimento, como um conjunto de processos praticados uma etapa de desenvolvimento

de sistemas, como uma abordagem ou ponto de vista, e como parte de outra área ou

contexto maior.

A seguir são apresentadas algumas definições de diferentes autores a respeito da

Engenharia de Requisitos:

Engenharia de Requisitos (ZAVE, 1997)

Engenharia de Requisitos é o ramo da engenharia de software relacionado com

objetivos reais sobre as funcionalidades e restrições de sistemas de software.

Obviamente, a definição de (ZAVE, 1997), está restrita apenas aos sistemas de

software.

Engenharia de Requisitos (NUSEIBEH; EASTERBROOK, 2000)

Engenharia de Requisitos é o processo de descobrir o propósito para o qual o sis-

tema de software foi planejado, pela identificação de stakeholders e suas necessida-

des, documentando-as em uma forma que seja ameno para análise, comunicação e

posterior implementação.


Engenharia de Requisitos (POHL, 2010; POHL; RUPP, 2011)

Engenharia de Requisitos é uma abordagem sistemática e disciplinada para a espe-

cificação e gerenciamento de requisitos de um sistema com os seguintes objetivos:

• conhecer os requisitos relevantes, atingir um consenso entre os stakeholders

sobre estes requisitos, documentando-os de acordo a certos padrões dados, e

gerenciar-os sistematicamente.

• compreender e documentar os desejos e necessidades dos stakeholders atra-

vés da especificação e gerenciamento de requisitos, de modo, a minimizar o

risco de entregar um sistema que não satisfaça as necessidades e desejos dos

stakeholders.

Engenharia de Requisitos (HULL; JACKSON; DICK, 2011)

Engenharia de Requisitos é um subconjunto da engenharia de sistemas relacionado

com a descoberta, desenvolvimento, seguimento, análise, qualificação, comunicação

e gerenciamento de requisitos que definem o sistema a níveis sucessivos de abstração.

É importante observar nesta última definição, que a Engenharia de Requisitos é

considerada como parte da Engenharia de Sistemas em geral e não necessariamente res-

trita apenas aos sistemas computacionais ou aos sistemas de software. Aqui é como um

super conjunto da engenharia de requisitos computacionais, e consequentemente, um su-

per conjunto da engenharia de requisitos de software. A Fig.1 ilustra graficamente esta

definição, onde R representa apenas os requisitos de Software. Evidentemente, um sistema

computacional tem requisitos de hardware, requisitos de documentos, requisitos de meto-

dologias, requisitos de pessoas, e requisitos de banco de dados. O contexto deste trabalho

é a Engenharia de Requisitos de Sistemas Computacionais e não apenas os requisitos de

Software.

Figura 1 – Engenharia de Requisitos e Engenharia de Software


2.1.3 Metodologia para Análise de Requisitos

Análise de Requisitos (AR), é considerado como a primeira etapa no processo de

desenvolvimento de um sistema e na maioria das metodologias de desenvolvimento é a a

etapa onde é definido precisamente o QUE o sistema deverá fazer.

Ainda que cada organização tenha seu próprio modelo do processo de análise

de requisitos, Sommerville (2007) considera este processo realizado por meio de uma

sequência de quatro subprocessos de alto nível: estudo de viabilidade, elicitação e análise,

especificação, e validação. Estas atividades são mostradas na Fig. 2, onde as setas de cima

para baixo indicam o fluxo normal dos processos (sequenciamento), e as setas ao contrário

indicam realimentação ou feedback

Figura 2 – Processo de Análise de Requisitos

1. Estudo de viabilidade: consiste em estabelecer um entendimento básico do problema

a ser tratado. Verifica a possibilidade de satisfazer as necessidades do usuário. Con-

sidera também se o sistema proposto será rentável a partir de um ponto de vista de

negócio.

2. Elicitação e Análise: nesta etapa são definidas atividades como a descoberta de

requisitos, classificação e organização de requisitos, priorização e negociação de re-

quisitos, e a especificação de requisitos, como podem ser observados na Fig 3.

3. Especificação: consiste na descrição detalhada do requisito de uma determinada

função do sistema. Basicamente aqui é elaborado formalmente o documento de re-

quisitos, atendendo a normas e padrões.

4. Validação: dedica-se a mostrar que os requisitos realmente definem o sistema que

o usuário deseja. A validação de requisitos está associada à descoberta de possíveis

problemas com os requisitos. Essa etapa é importante, pois erros em um documento

de requisitos podem levar a custos excessivos. O custo de correção de um problema

de requisitos é maior que a correção de erros de projeto ou de codificação. As veri-

ficações desta etapa incluem: verificações de validade, verificações de consistência,

verificações de completeza, verificações de realismo ou viabilidade, e facilidades de

verificação.


Continuando com o detalhamento da metodologia mostrada na Fig. 2, Sommerville

(2011) considera a etapa de elicitação e análise, dividida em 4 subprocessos: descoberta

de requisitos, classificação e organização de requisitos, priorização e negociação, e espe-

cificação, como mostrada na Fig. 3. O processo de elicitação e análise, como indicam as

setas, é iterativo e com continua realimentação (feedback). O ciclo do processo começa

com a descoberta de requisitos e termina com a sua documentação (documentos parciais

da especificação de requisitos). O entendimento do analista de requisitos melhora a cada

rodada do ciclo.

Figura 3 – Etapas do processo de elicitação e análise de requisitos

2.2 Engenharia da Segurança

Acompanhando a definição do dicionário Merriam Webster (WHITMAN; MAT-

TORD, 2012) pode-se dizer que segurança é a qualidade ou estado de ser seguro, isto é,

ser livre de perigo. Em outras palavras, segurança é a proteção contra adversários.

Segurança é um termo utilizado para muitas coisas (governo, pessoas, edifícios,

computadores, etc.) que as vezes envolve habilidade multidisciplinar desde algoritmos de

criptografia e dispositivos de hardware até conhecimento de outras áreas (economia, psi-

cologia aplicada e organizacional, direito), de modo que seu uso a transformou em algo

ambíguo (JACOBS, 2011). Por exemplo, Whitman e Mattord (2012), define a segurança

como a qualidade ou estado de ser seguro - ser livre do perigo, ou a proteção contra adver-

sários. Termos tais como segurança computacional, segurança da informação, segurança

de sistemas de informação, garantia da informação, governança da segurança, engenha-

ria da segurança, engenharia da segurança da informação, etc. são definidos de maneiras

diferentes. Algumas vezes a definição depende do balanço aceitável de alguns atributos

(capacidade de processamento, usabilidade, confiabilidade operacional), outras de um tipo

de perspectiva (conceito, função, áreas).

Devido ao número muito grande de conceitos e pontos de vista relacionados com

a segurança, e devido a que um sistema de informação não necessariamente é um sistema


computacional, a seguir é a presentado as definições que são de interesse apenas deste

trabalho.

2.2.1 Segurança Computacional

Lembramos aqui que quando se menciona o termo sistema computacional, estamos

nos referindo a um sistema como definido por Pressman (2006), com seis componentes

fundamentais: hardware, software, pessoas, documentos, banco de dados, e metodologias

ou procedimentos.

Segurança computacional é um conceito da Ciência da Computação relacionada

com três aspectos ou propriedades fundamentais dos sistemas computacionais seguros:

confidencialidade, integridade e disponibilidade (BISHOP, 2004; ALLEN et al., 2008;

CIAMPA, 2012; HARRIS, 2013; ANDRESS, 2011).

Confidencialidade : É a ocultação de informações ou recursos. É a propriedade que

o sistema (software ou informação) não esteja disponível ou revelada a indivíduos,

entidades, processos ou sistemas não autorizados.

Integridade : Propriedade ou qualidade de um sistema ser exato, completo e intacto

e livre de mudanças não autorizadas durante o seu desenvolvimento ou execução.

Refere-se à fidelidade dos dados ou recursos, e é geralmente entendida em termos

de prevenir mudanças improprias ou não autorizada.

Disponibilidade : Refere-se à capacidade de utilizar a informação ou os recursos deseja-

dos. Propriedade de um sistema estar acessível e utilizável por usuários autorizados

(pessoas ou sistemas) sem interferências ou instrução de ser acessado na maneira

requerida.

Relacionando a definição de requisitos com estas três propriedades, podemos afirmar que

a segurança de um sistema computacional é determinada diretamente pelo conjunto de

requisitos de confidencialidade, integridade e disponibilidade. Um esquema gráfico relacio-

nado com estas três propriedades (requisitos) da segurança é mostrado na Fig. 4, de onde,

seguindo os conceitos de diagramas de Venn para conjuntos, pode-se afirmar o seguinte:

• Alguns requisitos atendem apenas uma única propriedade de segurança. Por exem-

plo, o requisito Todo cadastro deve conter as informações mínimas do cliente, atende

somente a propriedade de integridade

• Alguns requisitos podem atender simultaneamente a duas ou mais propriedades.

Por exemplo, o requisito Os dados transmitidos devem ser criptografados e via rede

privada virtual, atende as propriedades de integridade e confidencialidade.


• Sistemas que atendem às três propriedades (interseção) podem ser considerados

sistemas totalmente seguros.

Figura 4 – Aspectos fundamentais da segurança computacional

Alguns autores consideram adicionalmente outras propriedades tais como autenticidade,

utilidade, (WHITMAN; MATTORD, 2012), responsabilidade e não reijeição (ALLEN et

al., 2008).

2.2.2 Segurança de um Sistema de Informação

De acordo com a análise de (Promon S.A., 2005), a segurança de um Sistema

de Informação (SI) é considerado como um diferencial determinante na competitividade

das corporações. As empresas cada vez mais dependem dos sistemas de informação e

da Internet para fazer negócios. Em vista disso, qualquer incidente de segurança está

diretamente relacionado com prejuízos financeiros, sejam eles ocasionados devido à parada

de um sistema por conta de um vírus ou ao furto de uma informação confidencial. Nessa

perspectiva a segurança da informação não é apenas relacionada com a esfera de novas

tecnologias e ferramentas, mas também como o suporte fundamental à estratégia de um

negócio de uma corporação.

Sêmola (2003) define a segurança da informação como uma área do conhecimento

que é dedicada à proteção de ativos da informação contra acessos não autorizados, alte-

rações indevidas ou a sua indisponibilidade.

Informalmente, segurança da informação é o processo de proteger a disponibili-

dade, privacidade e integridade dos dados (de uma instituição).

Segurança da informação (ANDRESS, 2011)

Segurança da informação é a proteção da informação e dos sistemas de informa-

ção do acesso, do uso, da divulgação (exposição), da ruptura, da modificação ou

destruição não autorizada.


2.2.3 Engenharia da Segurança

Do ponto de vista computacional, Engenharia de Segurança é uma disciplina que

unifica duas áreas importantes engenharia de sistemas computacionais e segurança. A

engenharia de sistemas está relacionada com o desenvolvimento e aplicação de métodos

para desenvolvimento, operação e manutenção de sistemas complexos e de alta qualidade,

enquanto que, a Segurança está interessada em assegurar e verificar que componentes,

subsistemas ou todo o sistema satisfaça propriedades que incluam confidencialidade, in-

tegridade e disponibilidade.

Informalmente, a Engenharia da Segurança, pode ser definida como um conjunto

de metodologias com as quais a segurança é implementada em um sistema. Engenharia

de Segurança requer experiência multidisciplinar considerando aspectos desde criptografia

e segurança computacional até métodos formais, conhecimento de aspectos econômicos,

psicologia aplicada e aspectos legais.

De modo mais formal Anderson (2008) define a Engenharia da Segurança da se-

guinte maneira:

Engenharia de Segurança (ANDERSON, 2008)

A Engenharia da Segurança é área relacionada com a construção de sistemas que

permanecem confiáveis em relação à maldade, erro ou infortúnios. Ela é uma disci-

plina que inclui ferramentas, processos e métodos necessários para projetar, imple-

mentar, e testar sistemas complexos, e para adaptar a sistemas existentes nos seus

ambientes onde eles atuam.

Entre outros aspectos que fazem parte da engenharia da segurança que podemos

citar é a segurança física, a segurança de comunicação, a segurança de redes, o gerencia-

mento da segurança da informação, as políticas da segurança, mecanismos de segurança,

incentivos de segurança, etc. Estes conceitos não serão abordados neste trabalho, mas

fazem parte da engenharia de segurança e podem ser utilizados para atingir os objetivos

relacionados com requisitos de um sistema seguro.

28

3 Uma Metodologia Orientada a Aspectos

Para desenvolver sistemas existem muitos paradigmas, cada um com uma visão

diferente sobre o ciclo de vida do desenvolvimento do sistema. Para cada etapa deste ciclo

também existem muita metodologias, cada uma com seu modelo (tipo de abstração), sua

técnica (diretrizes) e suas ferramentas. O interesse deste trabalho é usar uma metodologia

para determinar os requisitos de um sistema seguro.

Neste capítulo será apresentada uma metodologia baseada em aspectos conside-

rando a EROA - Engenharia de Requisitos Orientada a Aspectos (do inglês Aspects Ori-

ented Requirements Engineering, AORE). Na primeira parte é apresentado o contexto da

metodologia baseado na literatura existente. Na segunda parte, é descrito os conceitos teó-

ricos fundamentais para descrever a metodologia: domínios e aspectos. Na terceira parte,

é apresentada a metodologia de elicitação de requisitos usando orientação a aspectos.

3.1 Referencial Teórico sobre Orientação a Aspectos

Na literatura encontramos várias definições que tem sido criadas para compreender

o termo aspecto, desde as primeiras definições relacionadas com programação orientada

a aspectos até as últimas associadas com análise de requisitos. Em (BANIASSAD et al.,

2006), um aspecto em requisitos é definido como um assunto que corta transversalmente

um artefato de requisitos; um aspecto em arquitetura é um assunto que corta transversal-

mente artefatos de arquitetura.

O paradigma de desenvolvimento Orientado a Aspectos (do inglês Aspect Oriented

System Development, AOSD) baseado na teoria de (PARNAS, 1972) e (OSSHER; TARR,

2001), caracteriza atualmente uma nova área da engenharia de sistemas computacionais.

O conceito de desenvolvimento de software orientado a aspectos surgiu da neces-

sidade de melhorar a modularidade dos programas, promovendo uma melhor separação

de assuntos importantes (do inglês “concerns"). O termo concerns, é um termo genérico

que diz respeito a requisitos que são relevantes e precisam estar presentes nos sistemas.

IEEE Std 1471-2000 (2000) define concerns como “interesses (partes) que pertencem ao

desenvolvimento do sistema, seu funcionamento ou quaisquer outros aspectos que são crí-

ticos ou de outra forma importantes para uma ou mais stakeholders. Concerns incluem

propriedades do sistema tais como performance, confiabilidade, segurança, distribuição e

evolução adaptativa".

A Fig.5, apresenta em forma simplificada a evolução do paradigma de desenvolvi-

mento de sistema orientados a aspectos. Um dos pioneiros neste tema é (KICZALES et

Capítulo 3. Uma Metodologia Orientada a Aspectos 29

al., 1997) que no Xerox Palo Alto Research Center, introduz a programação orientada a

aspectos como um novo paradigma de programação e que posteriormente foi implemen-

tado na linguagem AspectJ (como uma extensão da linguagem Java). Outras iniciativas

seguidas foram as linguagens Aspect C++ e HiperJ. Mais tarde quando a linguagem de

programação atingiu um certo nível de maturidade, foram incorporados tais conceitos e

os fundamentos para o Desenvolvimento de Sistemas Orientados a Aspectos. O conceito

de primeiros aspectos (Early Aspects) (BANIASSAD et al., 2006) pertence a uma nova

sub-área da engenharia de sistemas computacionais, na qual foi desenvolvida para com-

por a Engenharia de Requisitos Orientada a Aspectos (AORE). Os primeiros aspectos

tem como objetivo prover técnicas e métodos para sistematicamente identificar, separar,

representar e compor características transversais nas fases de desenvolvimento anteriores

à implementação. Uma recopilação sobre Orientação a Aspectos pode ser encontrada em

(CHITCHYAN et al., 2005) e (MOREIRA et al., 2013)

Figura 5 – Evolução do paradigma Orientado a Aspectos

3.2 Domínio de requisitos e Aspectos

Tratando de entender os diferentes significados, com foco na Engenharia de Re-

quisitos, Kaindl (2008) define o termo aspecto como um meio de tratar com assuntos

transversais, e não com um sinônimo de assunto transversal. Devemos ressaltar aqui, que

o assunto transversal identificado na representação de requisitos não é necessariamente

um assunto transversal equivalente na componente de software. Essa maneira de tratar

com assuntos transversais no desenvolvimento de sistemas computacionais representa uma

metodologia orientada a aspectos.

Neste contexto Castro-Vera (2013) define um domínio de requisitos como sendo

um sistema ou conjunto de requisitos D que pode ser decomposto (particionado) em

componentes Di, de modo que:


• D = ∪ni=1

Di (união de componentes)

• Di ∩ Dj = ∅ (componentes disjuntas)

Apresentar esta definição na forma de um formalismo matemático (sistema ou conjunto)

é importante pelas seguintes razões:

• indica a natureza de interdependência entre componentes (sistema)

• apresenta uma estrutura formal bem definida (conjunto)

• cada requisito formalmente pertence a uma única componente

Este domínio pode ser construído de muitas maneiras, por exemplo, de viewpoints

(RASHID et al., 2002), utilizando decomposição funcional (YU; LEITE; MYLOPOULOS,

2004), utilizando ferramentas tais como Theme (BANIASSAD; CLARKE, 2004), etc.

Complementando a definição anterior, Castro-Vera (2013) define um aspecto como

um subconjunto de requisitos que corta (cruza, é parte de, intersecta) todas as com-

ponentes de um domínio de requisitos, i.e. a interseção do aspecto com cada uma das

componentes do domínio, não é vazia.

Figura 6 – O conceito de aspecto e domínio

Esta definição é ilustrada na Fig.6, onde no lado esquerdo, mostra que a propri-

edade que representa ao aspecto esta presente em todas as componentes do domínio, ou

seja, cada componente tem requisitos que satisfazem o aspecto. Por outro lado, interpre-

tando a parte direita da Fig.6, pode-se dizer que o aspecto esta presente em todas as

componentes, porém, não de maneira igual ou uniforme, isto é, os subconjuntos de requi-

sitos que representam o aspecto, são diferentes e disjuntos, em qualidade e quantidade.

Os conceitos de domínio e aspecto pode ser exemplificado ao considerar um sistema

computacional padrão:

• Domínio: sistema computacional padrão com seis componentes (hardware, software,

pessoas, banco de dados, documentos e procedimentos)


• Aspecto: segurança do sistema computacional.

O aspecto transversal segurança que aparece nas seis componentes de um sistema padrão

é a representação de subconjuntos de requisitos de segurança em cada componente, por

exemplo, para a componente Hardware poderia ser o subconjunto {servidores seguros,

dispositivos lacrados, cabeamento estruturado, ... }; para a componente Software poderia

ser o conjunto de requisitos {copias originais de software, sistema de backup, sistema de

acesso por senha, ... }, e assim para as outras componentes. Resumidamente, o exemplo

é mostrado na Fig 7.

Figura 7 – Exemplo de domínio de requisitos e aspecto

3.3 Metodologia

A metodologia orientada a aspectos, proposta por Castro-Vera (2013) e mostrada

na Fig. 8, é uma adaptação da metodologia apresentada por Sommerville (2003) para

levantamento e análise de requisitos.

Figura 8 – Adaptação da metodologia de Sommerville (2003)

A seguir passamos a descrever os processos desta metodologia.


1. Compreensão do Domínio

Os analistas devem desenvolver sua compreensão do domínio da aplicação. Por exem-

plo, em um sistema acadêmico o analista deverá conhecer como funciona os processos

relacionado ao aluno, ao professor.

2. Processo AORE

O processo AORE da Fig. 8 é ampliado na Fig. 9, esta formado pelas seguintes

atividades ou subprocessos:

a) Determinar o aspecto transversal.

O elemento de partida nesta metodologia para o processo de elicitação de

requisitos é a determinação do aspecto transversal a um domínio de requisitos.

É recomendável a escolha de um único aspecto para todo o processo. Esgotado

a coleta de requisitos com este aspecto em todos os domínios, pode ser escolhido

outro aspecto e repetir o processo. Neste trabalho foi escolhido como aspecto a

propriedade de confidencialidade para segurança de sistemas computacionais.

b) Determinar o domínio de requisitos.

Cada domínio é um conjunto de requisitos desde um ponto de vista particular

do analista, isto é, representa a visão do desenvolvedor e não do stakeholder.

c) Determinar as componentes do domínio.

Particionar o conjunto maior de requisitos em pequenos conjuntos disjuntos,

facilita a classificação posterior de todos os requisitos e sua atribuição a um

determinado subsistema da arquitetura.

d) Fazer a coleta de requisitos para cada componente.

O método de coleta depende de uma particular metodologia. A única restri-

ção aqui é que esta coleta so pode ser feita em função do aspecto escolhido.

Por exemplo, a coleta de requisitos, considerada neste trabalho atendem ape-

nas ao aspecto confidencialidade. Para outras propriedades como integridade e

disponibilidade, deverá ser repetido o processo (realizar outra coleta).

e) Definir cada requisito.

A definição correta do requisito é fundamental para gerar a documentação

(dos requisitos) do sistema. Por exemplo, o requisito “Acesso através de login”

não indica claramente o desejo de algum stakeholder. A definição “O acesso a

rede será unicamente através de username, login e capcha1” é um indicativo

de como será a implementação do acesso à rede. Qualquer definição de um

requisito deve ter obrigatoriamente os três elementos sequenciais: sujeito, verbo

e complemento.1 CAPTCHA é um acrônimo da expressão “Completely Automated Public Turing test to tell Computers

and Humans Apart” (Teste de Turing público completamente automatizado para diferenciação entrecomputadores e humanos)


f) Especificar cada requisito.

Nesta parte, cada requisito é detalhado de maneira que a sua implementa-

ção seja precisa (não ambígua) em relação aos projetistas e implementadores

(programadores, gerentes de infraestrutura, etc.)

Figura 9 – Metodologia AORE proposta por Castro-Vera (2013)

É importante observar que no desenvolvimento de um sistema de grande porte,

com a necessidade de considerar vários aspectos, port exemplo, confidencialidade,

disponibilidade, integridade, acesso, etc., o processo é cíclico, pois deve se repetir

todas as etapas para cada aspecto.

3. Classificação

Essa atividade considera o conjunto não estruturado dos requisitos e os organiza em

grupos coerentes.

4. Resolução de Conflitos

Quando múltiplos stakeholders estão envolvidos, os requisitos apresentaram confli-

tos. Essa atividade se ocupa de encontrar e solucionar esses conflitos. Essa atividade

se ocupa de encontrar e solucionar esses conflitos.

5. Priorização

Em qualquer conjunto de requisitos, alguns serão mais importantes do que outros.

Esse estágio envolve a interação com os stakeholders, para descobrir os requisitos

mais importantes.


6. Validação dos Requisitos

Os requisitos são verificados, a fim de se descobrir se eles são completos e consistentes

e se estão em concordância com o que os stakeholders realmente desejam do sistema.

7. Especificação dos Requisitos

A especificação de requisitos é o procedimento de escrever os requisitos do sistema

elaborando assim um documento de requisitos. É uma descrição abstrata do software

que serve de base para o projeto e a implementação.

35

4 Biblioteca de requisitos

A aplicação dos conceitos de segurança nas primeiras etapas do processo de desen-

volvimento de sistemas computacionais utilizando a metodologia de orientação a aspectos,

implica em um novo paradigma de Engenharia de Requisitos. Esta visão é uma adapta-

ção da metodologia apresentada por (SOMMERVILLE, 2003) junto com as ideias da

Engenharia de Requisitos Orientada a Aspectos.

O paradigma de desenvolvimento de sistemas seguros utilizando aspectos, como

definida por Castro-Vera (2013) e mostrado na Fig.10, está baseada na metodologia apre-

sentada no capítulo anterior junto com a construção de uma biblioteca de requisitos ori-

entada a segurança computacional. Os processos desta metodologia, inclui a construção

ou utilização de uma biblioteca de requisitos relacionada com propriedades de segurança

do sistema a ser desenvolvido.

A biblioteca de requisitos inicialmente estaria formada por requisitos comuns a

sistemas genéricos, que posteriormente seria incrementada com requisitos específicos do

sistema. O gerenciamento desta biblioteca (inclusão, remoção, classificação, pesquisa, pro-

priedades, etc.) deverá ser realizada por uma Ferramenta de Gerenciamento de Requisitos

(FGR), que ainda está em desenvolvimento como parte de um projeto de pesquisa na

UENF.

Vale a pena ressaltar que o desenvolvimento de tal biblioteca se aplica apenas

a sistemas de grande porte ou a sistemas críticos, onde requisitos não considerados ou

esquecidos, bem como, onde o erro de requisitos mal elicitados pode gerar custos muito

altos e prejuízos muitas vezes irreversíveis para a empresa.

Capítulo 4. Biblioteca de requisitos 36

Figura 10 – Paradigma de Desenvolvimento de sistemas seguros

4.1 Biblioteca de Requisitos

A construção de uma biblioteca de requisitos visando validar a metodologia pro-

posta por Castro-Vera (2013), compreende duas partes (ver Fig.11). A primeira, está

composta por requisitos que pertencem a um Sistema Computacional Genérico que po-

derá ser reutilizado para qualquer sistema computacional. A segunda, é um conjunto de

requisitos relacionados com o estudo de caso, de um sistema ERP Acadêmico.

Figura 11 – Biblioteca de Requisitos

Vale a pena ressaltar aqui, que devido ao tempo e o objetivo da pesquisa, neste

trabalho, quando menciona-se o termo seguro, apenas esta-se referindo a uma das pro-

priedades da segurança, neste caso, a confidencialidade. Assim, a parte de biblioteca de


requisitos e análise, somente é considerado a confidencialidade das componentes de cada

domínio.

4.1.1 Domínio de Requisitos: Sistema Computacional Genérico

Os componentes básicos de um Sistema Computacional Genérico (SCG), de acordo

com (PRESSMAN, 2011), são as seguintes: hardware, software, pessoas, documentos,

banco de dados e metodologia. A modelagem deste domínio utilizando a metodologia ori-

entada a objetos e a linguagem UML (diagrama de classes) facilita a determinação de ou-

tros domínios ou subdomínios. Na Fig.12, pode-se observar também outros subdomínios:

hardware (componentes: periféricos, computadores e dispositivos), software (componen-

tes: sistema operacional e aplicativos), pessoas (componentes: administradores, usuários,

outros), documentos (componentes: impressão, arquivos digitais), banco de dados, meto-

dologias (componentes: treinamentos, cópia de informação e manutenção).

Figura 12 – Sistema Computacional Genérico - Visão Geral

A seguir fazemos a elicitação (coleta) de requisitos dos domínios considerados

usando o aspecto confidencialidade de acordo com a metodologia AORE (Fig. 9). Observe-

se, sem comprometer os objetivos deste trabalho, apenas para alguns requisitos foi feita

a especificação (detalhamento).

1. Hardware

A componente Hardware é considerada aqui como outro domínio com as seguintes

componentes: periféricos, computadores e dispositivos. A seguir definimos os requi-


sitos para este domínio considerando como aspecto transversal a propriedade de

confidencialidade.

• Periféricos

Nessa componente pode-se citar alguns periféricos que comprometem a con-

fidencialidade de informações como pendrives, hd externo, antenas wireless.

Por outro lado, existem também os periféricos que ajudam na segurança e ini-

bem a presença de invasores como camera, dispositivos biométricos, cartões

magnéticos personalizados( com senhas), token, sensores de presença, etc.

Definição: Não deverá ser permitido o uso de pen drive.

Requisito 1 ( Uso de Pen Drive)

Definição: Não deverá ser permitido o uso de HD externo.

Requisito 2 ( Uso de HD externo)

Definição: Não será permitida a tendência BYODa.

a Bring your own device. Tendência dos funcionários levarem seus próprios dispositivos paradentro da empresa.

Requisito 3 (Tendência BYOD)

Definição: O sistema deverá possuir dispositivo biométrico.

Requisito 4 ( Uso de dispositivo biométrico)

Definição: O sistema deverá possuir sensores de presença.

Requisito 5 ( Sensores de presença)


Definição: O sistema deverá possuir câmeras para monitoramento.

Requisito 6 ( Câmeras)

Definição: O sistema deverá possuir cartões magnéticos.

Requisito 7 ( Cartões Magnéticos)

• Computadores

Na componente computadores são listados alugns requisitos que pode compor

um computador como: unidade usb, drive de mídia e placa firewall.

Definição: O computador não deverá ter a porta USB habilitada.

Requisito 8 ( USB computador)

Definição: O computador não deverá ter unidade de mídia de grava-

ção.

Requisito 9 ( Unidade de mídia do computador)

Definição: O computador deverá ter uma placa de firewall.

Requisito 10 ( Placa firewall no computador)

• Dispositivos de Comunicação

Na componente dispositivos de Comunicação é compreendido tudo que permite

a transmissão de dados e a comunicação, como por exemplo roteadores, swit-

ches, hubs, cabeamento de telefone, cabeamento de impressoras entre outros.

Definição: Os computadores deverão estar conectados em rede por

meio de um cabeamento não visível.

Requisito 11 ( Cabeamento dos computadores)


Definição: As impressoras deverão estar conectadas em rede por meio

de um cabo não visível.

Requisito 12 ( Cabeamento da impressora)

Definição: Os cabeamento dos telefones deverão estar não visíveis.

Requisito 13 ( Cabeamento dos Telefones)

Definição: O roteador não deverá ficar em um local de fácil acesso.

Requisito 14 ( Roteador)

2. Software

A componente Software é considerada aqui como outro domínio com as seguintes

componentes: sistema operacional e aplicativos. A seguir definimos os requisitos para

este domínio considerando como aspecto transversal a propriedade de confidencia-

lidade.

• Sistema Operacional (S.O)

O sistema operacional de uma máquina, deve ser configurado de forma a ga-

rantir a segurança ao acesso pessoal, possibilitando que o usuário cadastrado

tenha acesso apenas aos seus próprios dados. A seguir são descritos os requisitos

referente a essa componente:

Definição: O acesso ao sistema operacional deverá ser realizado ape-

nas por meio de usuário e senha.

Requisito 15 ( Login no Sistema Operacional)


Definição: O sistema operacional, após entrar em estado de hiber-

nação deverá ir para a tela de logout do usuário.

a) O sistema deverá ir para a tela do usuário após um determinado tempo.

b) O acesso a sessão iniciada só deverá ser possível por meio de senha do

usuário.

c) O usuário entrará com sua senha de acesso.

d) O sistema realizará a validação dos dados inseridos.

e) O sistema verificará os dados inseridos permitindo ou negando o acesso.

Requisito 16 ( Estado de Hibernação do S.O)

Autentificação, requisito 17, é uma das propriedades da confidencialidade. É

através dela que é realizada a autenticidade do usuário, garantindo assim a

confidencialidade das informações deste no sistema ou no software utilizado.

Definição: O acesso ao sistema operacional deverá ser realizado atra-

vés de algum dispositivo que permita reconhecer o usuário.

Requisito 17 ( Autentificação através de dispositivos biométrico )

Um Certificado Digital, visto no requisito 18, é um arquivo no computador

que identifica você. Alguns aplicativos de software,como por exemplo browsers,

utilizam esse arquivo para comprovar sua identidade para outra pessoa ou outro

computador.

Definição: Transações on line deverão ser feitas por meio de um

certificado digital.

Requisito 18 ( Certificado digital )

• Aplicativos

Aplicativos/Softwares, engloba um conjunto de programas que permitem o

usuário executar uma série de tarefas no computador ou em dispositivos móveis

como smartphones e tablets.


Definição: Todo aplicativo deve ter opção de histórico do uso.

Requisito 19 ( Histórico do aplicativo )

Definição: Todo o aplicativo deve ter um arquivo que armazene o

histórico do uso.

Requisito 20 ( Histórico do Uso )

Definição: O arquivo do histórico só pode ser acessado pelo gerente

do sistema.

Requisito 21 ( Arquivo do Histórico )

Definição: O arquivo do histórico só pode ser salvo numa área con-

fidencial.

Requisito 22 ( Salvar Arquivo de Histórico )

Definição: O browser deve ter a opção de apagar o histórico.

Requisito 23 ( Apagar Histórico )

Definição: Não permitir um browser sem a opção de histórico.

Requisito 24 ( Browser com Histórico )

Definição: Aplicativo com acesso a banco de dados confidenciais

deverá possuir login do usuário.

Requisito 25 ( Login em aplicativo )


a Definição: Os cookies dos sites não deverão ser armazenados para

preservar as informações confidenciais do usuário.

a Cookie é o termo designado para os dados que são enviados de um website e armazenadono navegador do usuário durante o acesso do mesmo.

Requisito 26 ( Armazenamento de Cookies)

Definição: O dispositivo móvel com dados confidenciais deverá per-

mitir bloquear a tela para impedir acesso não autorizado.

Requisito 27 ( Bloqueio da Tela )

3. Pessoas

Nesta componente é listado requisitos relacionados com a identificação e o acesso

de pessoas a um sistema. A seguir definimos os requisitos para este domínio consi-

derando como aspecto transversal a propriedade de confidencialidade.

Definição: O sistema operacional deve permitir que apenas as pessoas

cadastradas acessem o sistema.

Requisito 28 ( Acesso por Usuário)

Definição: A identificação dos usuários com acesso a informações

confidenciais também deve ser confidencial.

Requisito 29 ( Identificação do Usuário)

Definição: O usuário deverá ter a opção de escolher sua própria

senha.

Requisito 30 ( Criação da senha )


Definição: O usuário para modificar a sua senha deverá possuir uma

pergunta adicional.

Requisito 31 ( Modificar Senha)

Definição: O usuário deverá ser responsável pela sua senha e esta é

de uso pessoal e intransferível.

Requisito 32 (Responsabilidade da Senha )

4. Documentos

Na componente documentos é considerado documentos de caracter digital. A se-

guir os requisitos definidos para este domínio considerando o aspecto transversal a

propriedade de confidencialidade.

Definição: Os arquivos salvos devem ser colocados apenas em pastas

confidenciais.

Requisito 33 ( Documentos Salvos no computador )

Definição: Os arquivos salvos devem estar visíveis apenas para os

usuários habilitados.

Requisito 34 ( Visibilidade dos Arquivos )

Definição: A cópia de documentos digitais devem ser de responsabi-

lidade do usuário.

Requisito 35 (A cópia de documentos confidenciais )


Definição: O usuário deve manter o sigilo de documentos confiden-

ciais.

Requisito 36 (Manter documentos confidenciais )

5. Banco de Dados

É no banco de dados, Sistema de Gerenciamento de Banco de Dados (SGBDs), que

todos os dados fundamentais da instituição ou empresa se encontram. Possuir infor-

mação hoje em dia é ganhar agilidade, competitividade e dinamismo, em resumo é

ter uma vantagem competitiva. Nesse contexto a confidencialidade das informações

em um banco de dados é de prioridade máxima. Pois qualquer alteração, destruição

ou divulgação sem a devida autorização pode acarretar prejuízos para a institui-

ção/empresa, como também para seus usuários e clientes.

O controle de acesso é um meio que assegura que todos os acessos diretos ao sistema

ocorram exclusivamente de acordo com as modificações e as regras pré-estabelecidas

e observadas por políticas de proteção.

Os requisitos 37, 38 e 39 garantem a confidencialidade no acesso e no controle de

um sistema de gerenciamento de banco de Dados.


Definição: O SGBDs deverá possuir controle no acesso de operações.

a) Abrir janela inicial com interface de acesso

b) O usuário insere os dados(usuário, senha) Banco de Dados.

c) O sistema verifica se o usuário está cadastrado.

d) O sistema verifica se a senha está cadastrada.

e) O sistema é acessado.

f) O usuário realiza uma requisição( por exemplo um comando drop, select)

ao Banco de Dados.

g) O sistema verifica cada requisição realizada pelo usuário.

h) O sistema verifica os privilégios que o usuário possui.

i) Possuindo o privilégio o sistema realiza a operação.

Requisito 37 ( Controle no Acesso do SGBDs)

Definição: O controle de acesso do SGBDs deverá conter Regras de

acesso.

Requisito 38 ( Regras de acesso no SGBDs )

Definição: O controle de acesso do SGBDs deverá conter políticas de

segurança.

Requisito 39 ( Políticas de Segurança no SGBDs )

Ao se realizar a manutenção do banco de dados uma rotina é importante: o backup.

Para se realizar o backup do banco de dados são utilizados mídias (fitas e discos),

requisito 40. Logo deve existir um plano de manutenção dessas mídias, requisito

41 , para que esses dados sejam guardados ou reciclado de modo correto de forma

que não prejudique a confidencialidade dos dados presente nelas.


Definição: As mídias de backup do banco de dados devem ter um

plano de controle e gerenciamento.

Requisito 40 ( Armazenamento/ reciclagem de mídias de Backup )

Definição: A manutenção do Banco de Dados deverá ser realizada

apenas por pessoas autorizadas.

Requisito 41 ( Manutenção do Banco de Dados )

O backup, requisito 42, deve ser feito, porém respeitando a confidencialidade dos

dados presentes, ou seja sua cópia deverá permanecer em local confidencial, com

acesso apenas por pessoas autorizadas.

Definição: O backup do banco de dados só poderá ser realizado por

pessoas autorizadas.

Requisito 42 (Backup do Banco de Dados)

A Auditoria em Banco de dados, requisito 43 é um meio utilizado para checar o

que os usuários estão realizando, e para garantir que os mesmos não estejam aces-

sando uma parte não autorizada do banco. O banco de dados contém a maioria das

informações críticas, requisito 44 de uma empresa, portanto sua confidencialidade

é crucial.

Definição: A auditoria do banco de Dados deverá ser realizada para

ratificar o acesso não autorizado.

Requisito 43 ( Auditoria no Banco de Dados )

Definição: O acesso aos arquivos armazenados deverão ser restrito

ao Banco de Dados.

Requisito 44 ( Acesso ao Sistema de Arquivos no Banco de Dados)


A Criptografia é uma técnica onde a informação é codificada por meio de um algo-

ritmo de forma que apenas o seu destinatário poderá extrair o conteúdo da mensa-

gem da sua forma cifrada. Com ela podemos manter a confidencialidade da infor-

mação que está no Banco de Dados como no requisito 45.

Definição: As informações do Banco de Dados deverão ser criptogra-

fadas.

Requisito 45 ( A criptografia dos Dados )

6. Metodologias

A componente Metodologias é considerada aqui como outro domínio com as seguin-

tes componentes: treinamento, cópia de informação e manutenção. Esse domínio é

composto por um conjunto de práticas e ações que ao serem aplicadas em um sistema

computacional tem como objetivo a privacidade do sistema. A seguir definimos os

requisitos para este domínio considerando como aspecto transversal a propriedade

de confidencialidade.

• Treinamento

A seguir os requisitos correspondentes a componente treinamento.

Definição: A equipe responsável pela segurança da rede deve ser

treinada constantemente com o propósito de obter melhor qualificação

sobre a confidencialidade necessária e práticas a serem tomadas no dia

a dia.

Requisito 46 (Treinar equipe)

Definição: A instituição/empresa deverá realizar palestras sobre o

conceito de confidencialidade para usuários que utilizam o sistema.

Requisito 47 (Palestras para usuários)


Definição: A instituiçao/empresa deverá realizar palestras para os

profissionais que trabalham com a manutenção do sistema.

Requisito 48 (Palestras para profissionais da manutenção)

• Cópia de Informação

Na componente cópias de informações pode-se listar os seguintes requisitos:

Definição: Os sistema deverá ter desabilitado a função printscreen.

Requisito 49 (Printscreen da Tela )

Definição: Os sistema não deverá permitir que programas capturem

as imagens da tela.

Requisito 50 (Cópia das informações por meio de softwares)

Definição: Os dados do projeto deverão ser confidenciais.

Requisito 51 ( Informações e dados do projeto )

Definição: A marca com informações sobre o patrimônio dos com-

putadores deve ser colocado em lugares menos visíveis.

Requisito 52 ( Informações do computador )

Definição: Toda documentação de implementação de um Sistema

deve ser restrito as pessoas requisitantes ou instituição.

Requisito 53 (Documentação da implementação)

• Manutenção

Com o propósito de obter falhas na confidencialidade do sistema mostra-se a


importância de realizar por meio de ferramentas análise de vulnerabilidade e

testes de invasão, a fim de descobrir potenciais pontos de falha e corrigi-los.

Definição: A equipe responsável pela segurança da rede deve executar

testes de vulnerabilidade.

Requisito 54 (Executar procedimentos de análise de vulnerabilidade)

Definição: A manutenção do sistema deverá ser realizada por pessoas

responsáveis do setor

Requisito 55 (Manutenção do sistema)

Definição: O histórico do browser deverá ser apagado a cada sessão

iniciada.

Requisito 56 ( Histórico do Browser)

Definição: As senhas não deverão ser memorizadas automaticamente

pelo browser.

Requisito 57 ( Senhas no Browser)

Definição: A posição dos computadores em uma sala deverá ser pla-

nejada.

Requisito 58 (Posição dos computadores)

Definição: O envio de dados confidenciais entre dispositivos móveis

deverá ser criptografado.

Requisito 59 (Envio de dados)


• Outros

Definição: O sistema deverá ter cadastrado todos os computadores

que tem acesso a rede.

Requisito 60 ( Cadastrar computador)

Definição: O servidor deverá ter uma senha de acesso apenas para

pessoas autorizadas.

Requisito 61 ( Acesso ao servidor )

Definição: Os computadores deverão possuir um termo de compro-

misso a respeito da confidencialidade dos dados contidos no HD da

máquina.

Requisito 62 ( Termo de compromisso do computador )

Definição: O local do servidor deverá ser conhecido apenas por pes-

soas autorizadas.

Requisito 63 ( Acesso restrito a sala do servidor )

Definição: O uso de celular e dispositivos eletrônicos pessoais não

devem ser permitidos nas salas que se tem acesso ao banco de dados

mantendo a confidencialidade dos mesmos.

Requisito 64 (Uso de celular e dispositivos eletrônicos pessoais)


Definição: Os telefones deverão utilizar um serviço que criptografe

as conversas e os envio de mensagem(SMSa).

a SMS,Serviço de Mensagens Curtas do inglês, Short Message Service, é um serviço disponívelem telefones móveis que permite o envio de mensagens curtas, conhecidos popularmentecomo mensagens de texto.

Requisito 65 ( Criptografar dados e mensagens)

Definição: A rede WiFia deverá ter seu nome de rede ocultado.

a WiFi é uma tecnologia que permite dispositivos eletrônicos realize troca de dados ou de seconectar a internet sem fio através de ondas de radio.

Requisito 66 (Rede WiFi) )

Definição: A rede WiFi deverá usar criptografia.

Requisito 67 ( Segurança da rede WiFi )

Definição: Documentos confidenciais não poderão ser enviados para

impressão na rede.

Requisito 68 (Impressão em rede)

4.2 Estudo de Caso: Sistema ERP Acadêmico

Na seção 4.1.1 foi descrito a biblioteca por meio de um modelo genérico de requi-

sitos. Nesta seção é modelado uma biblioteca de requisitos baseando-se no estudo de caso

de um sistema acadêmico, que pode ser implementados em qualquer instituição de ensino

superior (universidades, centros universitários , faculdades).

4.2.1 Modelagem do Sistema

O sistema em estudo visa integrar os diferentes elementos que compõem a estrutura

de uma instituição de ensino superior (IES). A Fig. 13 mostra os quatro elementos ( gestão

acadêmica, gestão tecnológica, gestão empresarial e gestão estratégica) que compõe a


estrutura de um ERP1 Acadêmico padrão. A modelagem utilizada é orientada a objetos

de modo que cada elemento representa uma classe e foi realizada utilizando o Visual

Paradigm (ver Sec. 5.1).

Uma classe genérica gestão acadêmica corresponde toda a infraestrura de uma

IES: alunos, professores, registro acadêmico, biblioteca, laboratórios, cursos, faculdades,

instituto, turmas. Uma classe genérica gestão tecnológica refere-se a todos que tem como

área de atuação a gestão e manutenção da tecnologia. Uma classe genérica gestão em-

presarial é encarregada da parte financeira, administrativa e ao atendimento do público.

Uma classe genérica gestão estratégica refere-se a relatórios, mapas e gráficos.

Figura 13 – Estrutura ERP Acadêmico

A seguir serão descritas as classes e as subclasses que compõe o caso ERP Acadê-

mico que foi modelado.

A classe genérica Gestão Acadêmica é composta em quatro subclasses Graduação,

Pós-Graduação, Educação a Distância (EAD) e Biblioteca ( ver Fig 14).1 ERP são as iniciais do termo em inglês Enterprise Resource Planning para um Sistema Integrado de

Gestão Empresarial


Figura 14 – A Classe Gestão Acadêmica

A classe Gestão Tecnológica é composta em quatro subclasses: Banco de dados,

Relatórios, Suporte técnico, Sites e Formulários, como apresentado Fig. 15.

Figura 15 – A classe Gestão Tecnológica

A classe Gestão Empresarial é composta pelas cinco subclasses: Financeiro (contas

a pagar, contas a receber, tesouraria), Atendimento ao Cliente, Recursos Humanos (RH),

Contábil (patrimônios, impostos), Suprimentos (estoques, pedido de compra), como mos-

trado na Fig. 16


Figura 16 – A classe Gestão Empresarial

A classe da Gestão Estratégica (Fig. 17) é composta por três subclasses: Relatórios,

Mapas e Gráficos.

Figura 17 – A classe Gestão Estratégica

Por último a classe Gestão Acadêmica (Fig. 18) é composta por cinco subclasses:

Aluno, Professor, Funcionário, Assistência Estudantil e Registro Acadêmico.


Figura 18 – A classe Graduação

O processo de composição de classes na modelagem do sistema ERP Acadêmico

pode continuar para outros níveis, mais internos, porém não é objetivo deste trabalho

fazer uma modelagem completa e sim apresentar a metodologia de coleta de requisitos

para este sistema. Em tal sentido serão apresentados exemplos de requisitos apenas de

uma subclasse das mostradas nas figuras anteriores.

4.2.2 Aplicação da metodologia

Utilizando a modelagem da seção 4.2.1, passamos a descrever a metodologia ori-

entada a aspectos utilizando o conceito de domínios (de requisitos). O primeiro domínio

a ser considerado será o domínio genérico ERP Acadêmico formada pelas componentes

Gestão Acadêmica, Gestão Tecnológico, Gestão Empresarial e Gestão Estratégica.

Figura 19 – Domínio ERP Acadêmico

O segundo domínio é a Gestão Acadêmica que é composto pela seguintes compo-

nentes Graduação, Pós-Graduação, EAD e Biblioteca.


Figura 20 – Domínio Gestão Acadêmica

O terceiro domínio Graduação é composto pelas seguintes componentes: Aluno,

Professor, Funcionário, Assistência Estudantil e Registro Acadêmico.

Figura 21 – Domínio Graduação

A seguir serão definidos os requisitos referente à componente Aluno do domínio

Graduação como na Fig. 21:

• Aluno

A componente Aluno representa o sistema de informações do Portal do Aluno do

sistema ERP Acadêmico. Neste subsistema é possível consultar dados e informações

relacionadas com a vida acadêmica de um estudante tais como: visualizar plano de

estudo, solicitar e retirar declarações, consultar histórico, realizar inscrições online,

plano de estudos e visualizar avisos da coordenação. Todas essas ações e informações

deste subsistema são de caráter pessoal, de modo que a proteção de sua confidenci-

alidade é fundamental.

Entre as principais funcionalidade desse subsistema verificar seu horário individual

de aulas, consultar o calendário acadêmico (eventos, provas, etc.), consultar ma-

terial do professor disponibilizado para download, visualizar e efetuar pedidos de

matrícula, consultar seu histórico escolar entre outros. Todas essas funcionalidades

podem ser expressas em formas de requisitos.


Definição: O acesso do aluno ao sistema deverá ser feito utilizando

login e senha.

69.1 Abrir janela inicial com interface de acesso.

69.2 Ingressar informações de acesso (usuário, senha).

69.3 Verificar usuário cadastrado.

69.4 Verificar senha cadastrada.

69.5 Liberar perfil de usuário.

69.6 Liberar área e ferramentas de trabalho.

69.7 Permitir acesso à Internet.

69.8 Fazer controle de atividades de usuário.


Requisito 69 (Acesso do Aluno)


Definição: O sistema deverá permitir que o aluno escolha sua própria

senha.

70.1 Abrir tela com interface de acesso

70.2 Realizar Login.

70.3 Em configurações pessoais deverá ter a opção alterar senha

70.4 Ao acessar alterar senha

70.5 O sistema deverá verificar se o usuário esta cadastrado.

70.6 O sistema deverá realizar as seguintes perguntas:em que ano nasceu, nome

da mãe,dia do aniversário, sexo do aluno, mês que nasceu.

70.7 O sistema deverá validar os dados inseridos.

70.8 Feita a validação deverá gerar uma nova senha.

70.9 A nova senha é enviada ao email do aluno.


Requisito 70 (Alterar a senha)

Definição: O sistema deverá permitir que o aluno edite seus dados

pessoais.

71.1 Efetuar o login no sistema.

71.2 Na opção perfil do usuário deverá possuir uma opção editar dados cadas-

trados.

71.3 Os dados que poderão ser editados pelo aluno são: email, telefone e ende-

reço.

Requisito 71 (Atualizar dados cadastrais)


Definição: O sistema deverá permitir que cada aluno acesse apenas

o seu próprio histórico escolar.

Requisito 72 (Histórico escolar do Aluno)

Definição: O sistema deverá permitir que cada o aluno tenha acesso

apenas a sua própria declaração de regularidade de matricula.

Requisito 73 (Declaração de Regularidade de Matricula)

Definição: O sistema deverá permitir que cada aluno visualize apenas

os avisos da coordenação que estão relacionados com o seu login.

Requisito 74 (Avisos da coordencação)

Definição: O sistema deverá permitir que o aluno tenha acesso apenas

ao seu próprio extrato escolar.

Requisito 75 (Extrato escolar do Aluno)

Definição: O sistema deverá permitir que o aluno tenha acesso apenas

ao seu próprio plano de estudo.

Requisito 76 (Plano de estudo do Aluno)

Definição: O sistema deverá permitir que apenas o aluno possa rea-

lizar a sua inscrição.

Requisito 77 (Inscrição online)


Definição: O sistema após ficar inativo por um tempo mínimo deverá

fazer o logout automático.

Requisito 78 ( Logout automático do sistema)

Definição: O sistema deverá permitir a inserção de arquivos pessoais

privados.

Requisito 79 ( Inserir Arquivos)

Os requisitos 80 e 81, estão associados as URLs2 dos RSS feed3. Através de RSS

feed é possível que usuários acessem áreas na plataforma as quais não deveriam.

Para manter a confidencialidade das informações o usuário deve possuir uma chave

de segurança que é restrita a ele.

Definição: As URLs dos RSS feeds deverá conter um token, gerado

no primeiro acesso ao portal, que identifica a qual usuário pertencem.

Requisito 80 ( Chave de segurança)

Caso o usuário que ache que o seu token de RSS feed foi comprometido de alguma

forma, ele poderá requisitar um novo, como no requisito 81

Definição: O sistema deverá possuir a opção de requisitar um novo

token de RSS feed.

Requisito 81 (Gerar Token )

2 URL do termo em inglês Uniform Resource Locator, também conhecido como endereço web,http://www.

3 RSS do termo em inglês Rich Site Summary, também conhecido como feed RSS, permite aos respon-sáveis de sites e blogs divulgarem notícias ou novidades. Para isso, o link e o resumo da notícia éarmazenado em um arquivo de extensão .xml, .rss ou .rdf. Esse arquivo é conhecido como RSS feeds


Definição: A senha deve ter ao menos 8 caracteres, ao menos 1

dígito(s), ao menos 1 letra(s) minúscula(s), ao menos 1 letra(s) maiús-

cula(s), ao menos 1 caracater(es) não alfanumérico.

Requisito 82 ( Senha forte)

Definição: O sistema deverá permitir que o aluno escolha quais dados

podem ser vistos (por exemplo endereço de e-mail).

Requisito 83 ( Dados que podem ser vistos)

Definição: O sistema deverá permitir que apenas os aluno cursando

a disciplina acesse os arquivos disponibilizados pelos professores.

Requisito 84 ( Arquivos disponibilizados)

Para a obtenção dos requisitos foram consultados algumas IES: UENF (www.uenf.br),

UFF (www.uff.br) e IFF (www.iff.br) e outros ERPs.

63

5 Implementação com Ferramenta CASE

Ferramentas CASE (Computer Aided Software Engineering) são utilizadas para o

suporte no desenvolvimento de software, as quais oferecem um conjunto de serviços para

apoiar uma ou mais etapas do ciclo de desenvolvimento de software. Podemos mencionar

algumas delas como: IMB Rational, Papyrus UML2 Modeler, StarUML - UML/MDA

Plataform, Enterprise Architect, Visual Paradigm, etc.

Neste capitulo é construído um tutorial com a ferramenta Visual Paradigm, demos-

trando como o software foi utilizado para a elaboração da biblioteca descrita no capítulo

4.Inicialmente será abordado a respeito da ferramenta e posteriormente o tutorial exem-

plificado com a biblioteca criada.

5.1 Visual Paradigm for UML

O Visual Paradigm for UML (VP-UML) é uma ferramenta CASE (Fig. 22), atual-

mente na versão 10.2 (<http://www.visual-paradigm.com/>), desenvolvido pela Visual

Paradigm International (Hong Kong) e disponível apenas em inglês. O VP-UML é uma

ferramenta bastante completa, na qual apresenta as características que são importantes

e fundamentais para a análise, projeto e desenvolvimento de sistemas complexos. Além

disso apresenta uma boa visualização e manipulação de diagramas UML, o que facilita a

modelagem de um sistema.

Capítulo 5. Implementação com Ferramenta CASE 64

Figura 22 – Versão do Software

As funcionalidades principais da ferramenta para trabalhar com requisitos são:

análise textual, diagrama de requisitos, diagrama básico, grade de requisitos e dicionário

de requisitos, Fig.23. A seguir uma descrição sucinta de cada uma:

• Textual Analysis

É um editor de texto, para ajudar a gravar as informações textuais, além de um

editor de texto simples, pode se identificar termos ou objetos (por exemplo, classe,

caso de uso) importantes da descrição do problema.

• Requirement Diagram

É projetado especificamente para atender a linguagem SysML (Systems Modeling

Language).

• Requirement Grid

Requirements Grid é uma tabela com a lista de requisitos que permite o acesso a

todos requisitos de um projeto ou diagrama.

• Glossary Grid

Glossary grid é uma tabela aonde pode-se identificar o glossário de termos específi-

cos.

• CRC Card Diagram

Class-Responsibility Collaborator (CRC) visualiza classes, é um formato parecido


com o cartão. Cada cartão contem informações de uma classe ( descrição atributos,

responsabilidades).

Figura 23 – Ferramenta de Requisito

Uma das funcionalidades mais importantes é a geração de relatórios de requisitos

em vários formatos: MS Word (*.docx), Portable Document Format (*.pdf), HTML, MS

Publisher (*.pub), Fig.24.

Figura 24 – Ferramenta de Geração de Relatórios

5.2 Criação da Biblioteca no Visual Paradigm

5.2.1 Ambiente de Trabalho - Interface

O ambiente de trabalho do Visual Paradigm apresenta a estrutura mostrada na

Fig.25 onde apresenta a barra de menu e a barra de ferramentas, barra de navegação,

propriedades da janela, janela de mensagens e a janela de projetos.


Figura 25 – Interface

1. Barra de menu e barra de ferramentas: permite selecionar e executar diversas ope-

rações no Visual Paradigm for UML.

2. Barra de navegação: local aonde os diagramas são listados, e é possível criar e acessar

diagramas de base em seus tipos.

3. Propriedades da janela: propriedades do modelo escolhido são mostrados quando as

propriedades da janela são selecionados.

4. Janela de mensagem: nessa janela são mostrados notificações e avisos.

5. Janela de projetos: são exibidos os projetos abertos.

5.2.2 Criação da Biblioteca no Visual Paradigm for UML

A seguir são descritos os passos para a construção da biblioteca de requisitos no

VP-UML.

• Criando um Projeto

A criação de um novo projeto é descrito nos passos a seguir:

1. Iniciar Visual Paradigm for UML.

2. Criar um novo projeto selecionando File → New Project da barra de menu,

Fig.26.


Figura 26 – Novo projeto

3. Após a criação no Diagram Navigator aparecerá os módulos que podem ser

criados no projeto como: UML Diagrams, Requirements Capturing, Database

Modeling, SysML e Others, como em Fig.27

Figura 27 – Interface

• Requisitos

Na ferramenta requisitos (Requirement) é possível criar uma nova grade, inserir

requisitos na grade, realizar a especificação do requisito e buscar o requisito por um

domínio.

– Criando uma nova Grade de requisitos


1. Na Barra de ferramentas clicar em Requirement → Requirements

Grid, para criar a grade de requisitos, Fig.28. Essa Tabela irá conter todos

os requisitos da biblioteca.

Figura 28 – Grade de Requisitos

2. A visão inicial ao criar a grade de requisito, é vista na Fig. 29. O requisito

possui os campos: id, nome, e stereotype.

Figura 29 – Novo Requirements Grid

3. As ferramentas relacionadas com a grade de requisitos são descritas na

tabela 1.


Tabela 1 – Campos na Grade de requisitos

– Inserindo Requisito na Grade de Requisitos

Após a tabela criada, deve-se inserir um novo requisito nela. A seguir os passos

para inserir um requisito na grade de requisitos:

1. Clicar em New Requirement (inserir), como na Fig. 30.

Figura 30 – Criando um novo Requisito

2. Ao inserir um novo requisito um id automático é gerado. No campo Name

é atribuído o nome do novo requisito, e em Stereotype é definido o tipo do

requisito inserido (Fig. 31).

Figura 31 – Inserindo um Requisito

3. A grade com os requisitos adicionados é vista na Fig. 32.


Figura 32 – Requisitos Inseridos na Grade

– Especificação de Requisito

A seguir são descritos os passos para adicionar a especificação a um requisito.

1. Clicar em Open Specification, como na Fig.33.

Figura 33 – Especificação do Requisito

2. A tela de especificação do requisito é aberta, Fig.34.

Figura 34 – Dados do Requisito


3. Na aba General é possível editar todos os dados e incluir a especificação

do requisito criado. Um exemplo de um requisito preenchido, é visto na

Fig.35.

Figura 35 – Adicionando uma Especificação ao Requisito

4. Na aba Stereotypes → All , é listado as classificação dos requisitos:

banco de dados, hardware, software, pessoas, metodologias e documentos,

como na Fig.36.


Figura 36 – Classificação do Requisito

5. No campo All selecionar o tipo (Banco de dados, Documentos, Hardware,

Metodologia, Pessoa e Software).

Clicar em Add Selected, como na Fig.37.

Figura 37 – Adicionar tipo a um Requisito


– Buscando um Domínio (Stereotype) de Requisito

A seguir é descrito os passos para realizar uma busca pelo stereotype na grade

de requisitos.

1. Clicar no ícone Find. Após isso o usuário poderá escolher como encontrar

o requisito: id, name, stereotypes (domínio) ou documentation. Na Fig.38

a busca foi feita pelo o domínio.

Figura 38 – Buscando um Stereotypes (Domínio)

5.2.3 Geração de Relatório de Requisitos

O Visual Paradigm for UML permite criar uma documentação de tudo que foi

desenvolvido no projeto. A seguir como criar um relatório de requisitos:

1. Clicar em Barra de ferramentas → Tools → Report→ Generate PDF Re-

port, como na Fig.39.


Figura 39 – Exportando Documento

2. A tela Generate PDF é aberta.

Figura 40 – Visão da tela Generate PDF

3. Na aba Content no campo Diagrams é possível selecionar o que será exportado do

documento. Para a exportação é selecionada a grade de requisitos, como na Fig.41


Figura 41 – Selecionando Diagramas para exportação

4. Em Generate PDF na aba Cover Page, é possível padronizar a capa do docu-

mento a ser exportado, Fig.42.

Figura 42 – Editar Capa do Documento


5. O arquivo gerado em PDF, é visualizado na Fig.43.

Figura 43 – Capa do relatório exportado em PDF

77

Conclusão

As conclusões deste trabalho podem ser divididas em três partes: sobre as difi-

culdades encontradas no desenvolvimento do TCC, sobre o que foi feito para atingir os

objetivos, e sobre o que poderá ser feito no futuro para melhorar ou complementar a

pesquisa na direção deste trabalho.

Sobre as dificuldades encontradas podemos mencionar as seguintes:

Material de estudo : os principais livros, artigos e os relatórios relacionados no tra-

balho como também a ferramenta Visual Paradigm encontravam-se em inglês. A

dificuldade encontrada não foi na leitura em inglês, mas sim na tradução de termos

específicos da área que na maioria das vezes não possuía um correspondente ou

adequado termo em português, por exemplo, Early Aspects, concerns, design, entre

outros.

Compreensão da Metodologia : a metodologia apresentada no trabalho aborda uma

nova maneira de capturar requisitos diferentes da já consolidada por autores como,

por exemplo, Sommerville (2011) ou Pressman (2011).

O processo do TCC : Entre outras, consideramos as quatro seguintes:

• A determinação do domínio de requisitos: inicialmente foi listado vários domí-

nios, alem do sistema computacional genérico (SCG). A fim de reduzir o espaço

amostral e melhorar a coleta de requisitos foi decidido escolher apenas o SCG.

• Determinação das componentes do domínio: após a determinação do domínio e

de suas componentes a dificuldade foi em coletar os requisitos para cada com-

ponente. Visto que o componente Hardware, Software e Metodologias incluem

um grupo vasto de requisitos. Para reduzir as opções de requisitos foi adotado

que cada componente seria um domínio com subdomínios.

• Coletar requisitos para cada componente: separar os requisitos em suas res-

pectivas componentes foi uma dificuldade enfrentada também. Muitas vezes

o mesmo requisito se encaixava em duas componentes. Para resolver isso o

requisito e sua definição tinha que ser a mais clara possível para assim estar

visível a qual componente pertencia. Por exemplo, na componente Pessoas, o

requisito criação de senha, esse requisito poderia ser da componente Software

também, mas ao colocar na definição: ”O usuário deverá ter a opção de

escolher sua própria senha”, deixa claro que é um requisito relacionado à

componente Pessoa.

Conclusão 78

• Definição de cada requisito: a dificuldade encontrada na definição do requisito

foi a limitação do requisito ser apenas de confidencialidade, muitas vezes o

requisito elicitado pertencia a requisitos de segurança, porém não se encon-

trava diretamente relacionado com o aspecto confidencialidade, e sim a outras

propriedades da segurança, portanto, tinha-se que descartar tal requisito.

Neste trabalho foi considerado o estudo de alguns aspectos teórico-práticos da en-

genharia de requisitos e da segurança computacional. A aplicação da metodologia AORE

foi utilizada em dois exemplos (domínios), um genérico, Sistema Computacional Genérico

e outro um modelo baseado no caso ERP Acadêmico.

No primeiro domínio SCG, a elicitação dos requisitos das seguintes componentes:

hardware, software, pessoas, banco de dados, documentos e metodologias foi a etapa mais

difícil do desenvolvimento do trabalho, pois os requisitos deste domínio tinham que ser

de caracter genérico e com a restrição de ser confidencial, dificultando assim a coleta de

requisitos. A componente metodologia, por apresentar requisitos relacionados a métodos

e ações praticadas, foi onde se obteve mais requisitos. No estudo de caso realizado, apli-

camos a metodologia descrita para a construção do sistema, como já havia o modelo com-

putacional genérico algumas componentes (por exemplo pessoas) pertencentes ao domínio

poderão ser reutilizadas (por meio de adaptação). Em geral os requisitos encontrados no

caso ERP Acadêmico, foram mais específicos, o que facilitou o descobrimento desses.

Vale a pena observar que por razões práticas desse trabalho, no estudo de caso não

foram consideradas todos os domínios modelados para a coleta de requisitos. Isto pode

ser feito em outros trabalhos.

A metodologia utilizada, facilitou a descoberta e a classificação dos mesmos, pois

foi observado que quanto mais específico era o domínio estabelecido mais fácil ficava de

elicitar e classificar os mesmos. A ferramenta Visual Paradigm for UML no desenvolver

do trabalho foi importante, pois com ela facilitou o gerenciamento dos requisitos através

de armazenamento e manipulação na forma de biblioteca.

Em futuros trabalhos, considerando que parte da biblioteca de requisitos já se

encontra implementada, ela poderá subsidiar as atividades do desenvolvimento de um

sistema que priorize a segurança (confidencialidade) como uma propriedade fundamental.

Além disso, podem ser elaborados e implementados outros domínios para os dois sistemas

considerados tais como: ciclo de vida (definição, projeto, construção e manutenção), na-

tureza (componentes: física e lógica) e também outras propriedades da segurança como a

disponibilidade e responsabilidade.

79

Referências

ALLEN, J. H. et al. Software Security Engineering: A guide for Project Managers. 1. ed.Boston, MA: Addison-Wesley, 2008. 368 p. (The SEI Series in Software Engineering).Citado 2 vezes nas páginas 25 e 26.

ANDERSON, R. Security Engineering: A Guide to Building Dependable DistributedSystems. 2. ed. Indianapolis, IN, USA: Wiley Publishing, 2008. 1080 p. Citado napágina 27.

ANDRESS, J. The basics of Information Security: Understanding the Fundamentals ofInfoSec in Theory and Pratice. 1. ed. Waltham, MA: Syngress, 2011. 208 p. Citado 2vezes nas páginas 25 e 26.

BANIASSAD, E.; CLARKE, S. Theme: An approach for aspect-oriented analysis anddesign. In: ICSE 04 - Proceedings of the 26th International Conference on SoftwareEngineering. Edinburgh, United Kingdom: [s.n.], 2004. p. 158–167. Citado na página 30.

BANIASSAD, E. et al. Discovering early aspects. IEEE Software, IEEE Software, v. 23,n. 1, p. 61–70, January-February 2006. Citado 2 vezes nas páginas 28 e 29.

BERENBACH, B. et al. Software & Systems Requirements Engineering: In Pratice. 1.ed. New York: McGraw-Hill Osborne Media, 2009. 356 p. Citado na página 17.

BISHOP, M. Introduction to Computer Security. 1. ed. Boston, MA: Pearson Education,Inc, 2004. 784 p. Citado na página 25.

CASTRO-VERA, A. S. Engenharia de requisitos e segurança: uma metodologia orientadaa aspectos. (Notas de Pesquisa). UENF-CCT-LCMAT-C.Computação. 2013. Citado 7vezes nas páginas 9, 29, 30, 31, 33, 35 e 36.

CHITCHYAN, R. et al. Survey of Analysis and Design Approaches. [S.l.], 2005. Citadona página 29.

CIAMPA, M. Security + Guide to Network Security Fundamentals. 4. ed. Boston, MA:Cengage Learning, 2012. 656 p. Citado na página 25.

GLINZ, M.; WIERINGA, R. J. Stakeholders in requirements engineering. IEEE Software,v. 24, n. 2, p. 18–20, March/April 2007. Citado na página 17.

HARRIS, S. CISSP All-in-One Exam Guide. 6. ed. New York: McGraw-Hill OsborneMedia, 2013. 1456 p. Citado na página 25.

HULL, E.; JACKSON, K.; DICK, J. Requirements Engineering. 1. ed. London: Springer,2011. 217 p. Citado 3 vezes nas páginas 17, 18 e 22.

IEEE Std 1471-2000. IEEE Std 1471-2000 - IEEE Recommended Practice forArchitectural Description of Software-Intensive Systems. New York, 2000. Aprovado porIEEE-SA Standards Board em 21 September 2000. Citado na página 28.

Referências 80

ISO/IEC/IEEE. ISO/IEC/IEEE 24765 - System and Software engineering- Vocabulary.2010. Citado na página 19.

JACOBS, S. Engineering Information Security - The application of Systems EngineeringConcepts to Achieve Information Assurance. 1. ed. Hoboken, NJ, USA: Wiley-IEEEPress, 2011. 728 p. (IEEE Press Series on Information and Communication NetworksSecurity). Citado na página 24.

KAINDL, H. What is an aspect in aspect-oriented requirements engineering? In:Proceedings of EMMSAD 2008, Thirteenth International Workshop on ExploringModeling Methods for Systems Analysis and Design. Montpellier, France: [s.n.], 2008. p.164–170. Citado na página 29.

KICZALES, G. et al. Aspect-oriented programming. In: ECOOP. [S.l.: s.n.], 1997. p.220–242. Citado na página 29.

LAUDON, K. C.; LAUDON, J. P. Sistemas de Informacao Gerenciais. 7. ed. São Paulo:Pearson Prentice Hall, 2007. 480 p. Citado na página 14.

MOREIRA, A. et al. Aspect-Oriented Requirements Engineering. 2013. ed. [S.l.]:Springer-Verlag, 2013. 376 p. Citado na página 29.

NUSEIBEH, B.; EASTERBROOK, S. Requirements engineering : A roadmap. ProceedingICSE ’00 Proceedings of the Conference on The Future of Software Engineering, p. 35 Ű46, 2000. Citado na página 21.

OSSHER, H.; TARR, P. Using multidimensional separations of concerns to (re) shapeevolving software. Communications of the ACM, v. 44, n. 10, p. 43–50, October 2001.Citado na página 28.

PARNAS, D. L. On the criteria to be used in decomposing systems into modules.Communcaions of te ACM, v. 15, n. 12, p. 1053–1058, December 1972. Citado na página28.

POHL, K. Requirements Engineering - Fundamentals, Principles and Techniques. Berlin:Springer-Verlag, 2010. 830 p. Citado na página 22.

POHL, K.; RUPP, C. Requirements Engineering Fundamentals: a study guide for theCertified Professional for Requirements Engineering Exam. Rocky Nooc Inc. 1. ed.SantaBarbara, CA, USA: Rocky Nook Inc., 2011. 181 p. Citado na página 22.

PRESSMAN, R. S. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.Citado 2 vezes nas páginas 17 e 25.

PRESSMAN, R. S. Engenharia de Software - Uma Abordagem Profissional. 7. ed. PortoAlegre: AMGH Editora Ltda, 2011. 780 p. Citado 2 vezes nas páginas 37 e 77.

Promon S.A. Segurança da Informaçãoo. 2005. Promon Business & Techonology Review.Citado na página 26.

RASHID, A. et al. Early aspects: a model for aspect-oriented requirements engineering.In: Proceedings of the IEEE Joint International Conference on Requirements Engineering(RE 02). Essen, Germany: IEEE, 2002, (Proceedings). p. 199–202. Citado na página 30.

Referências 81

SÊMOLA, M. Gestão da Segurança da Informação. [S.l.: s.n.], 2003. Citado na página26.

SOMMERVILLE, I. Engenharia de Software. 6. ed. São Paulo: Addison Wesley, 2003.606 p. Citado 3 vezes nas páginas 9, 31 e 35.

SOMMERVILLE, I. Engenharia de Software. 8. ed. São Paulo: Pearson Addson Wesley,2007. 566 p. Citado na página 23.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall,2011. 543 p. Citado 2 vezes nas páginas 24 e 77.

The Standish Group International. The Trends in Optimization report. [S.l.], 2008.Citado na página 14.

WHITMAN, M. E.; MATTORD, H. J. Principles of Information Security. 4. ed. Boston,MA: Cengage Learning, 2012. 656 p. Citado 2 vezes nas páginas 24 e 26.

YU, Y.; LEITE, J. C. S. do P.; MYLOPOULOS, J. From goals to aspects: discoveringaspects from requirements goal models. In: Proceedings of the 12th IEEE InternationalRequirements Engineering Conference (REŠ04). Kyoto: The IEEE Computer SocietyPress, 2004, (Proceedings). p. 38–47. Citado na página 30.

ZAVE, P. Classification of research efforts in requirements engineering. ACM ComputingSurveys, v. 29, n. 4, p. 315–321., december 1997. Citado 2 vezes nas páginas 20 e 21.

Documents

Aplicação de uma metodologia AORE para elicitação de ... · Aplicação de uma metodologia AORE para elicitação de requisitos de seguran-ça/ Camila Pardo Garcia Morelli. –