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
Camila Pardo Garcia Morelli
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 :
Camila Pardo Garcia Morelli
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ËIJao: 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).
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 19
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:
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 20
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.
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 21
• 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.
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 22
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
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 23
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.
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 24
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
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 25
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.
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 26
• 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.
Capítulo 2. Engenharia de Requisitos e Engenharia da Segurança 27
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:
Capítulo 3. Uma Metodologia Orientada a Aspectos 30
• 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)
Capítulo 3. Uma Metodologia Orientada a Aspectos 31
• 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.
Capítulo 3. Uma Metodologia Orientada a Aspectos 32
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)
Capítulo 3. Uma Metodologia Orientada a Aspectos 33
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.
Capítulo 3. Uma Metodologia Orientada a Aspectos 34
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
Capítulo 4. Biblioteca de requisitos 37
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-
Capítulo 4. Biblioteca de requisitos 38
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)
Capítulo 4. Biblioteca de requisitos 39
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)
Capítulo 4. Biblioteca de requisitos 40
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)
Capítulo 4. Biblioteca de requisitos 41
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.
Capítulo 4. Biblioteca de requisitos 42
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 )
Capítulo 4. Biblioteca de requisitos 43
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 )
Capítulo 4. Biblioteca de requisitos 44
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 )
Capítulo 4. Biblioteca de requisitos 45
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.
Capítulo 4. Biblioteca de requisitos 46
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.
Capítulo 4. Biblioteca de requisitos 47
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)
Capítulo 4. Biblioteca de requisitos 48
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)
Capítulo 4. Biblioteca de requisitos 49
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
Capítulo 4. Biblioteca de requisitos 50
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)
Capítulo 4. Biblioteca de requisitos 51
• 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)
Capítulo 4. Biblioteca de requisitos 52
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
Capítulo 4. Biblioteca de requisitos 53
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
Capítulo 4. Biblioteca de requisitos 54
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
Capítulo 4. Biblioteca de requisitos 55
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.
Capítulo 4. Biblioteca de requisitos 56
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.
Capítulo 4. Biblioteca de requisitos 57
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.
Capítulo 4. Biblioteca de requisitos 58
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.
69.9 Finalizar processo.
Requisito 69 (Acesso do Aluno)
Capítulo 4. Biblioteca de requisitos 59
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.
70.10 Finalizar processo.
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)
Capítulo 4. Biblioteca de requisitos 60
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)
Capítulo 4. Biblioteca de requisitos 61
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
Capítulo 4. Biblioteca de requisitos 62
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
Capítulo 5. Implementação com Ferramenta CASE 65
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.
Capítulo 5. Implementação com Ferramenta CASE 66
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.
Capítulo 5. Implementação com Ferramenta CASE 67
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
Capítulo 5. Implementação com Ferramenta CASE 68
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.
Capítulo 5. Implementação com Ferramenta CASE 69
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.
Capítulo 5. Implementação com Ferramenta CASE 70
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
Capítulo 5. Implementação com Ferramenta CASE 71
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.
Capítulo 5. Implementação com Ferramenta CASE 72
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
Capítulo 5. Implementação com Ferramenta CASE 73
– 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.
Capítulo 5. Implementação com Ferramenta CASE 74
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
Capítulo 5. Implementação com Ferramenta CASE 75
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
Capítulo 5. Implementação com Ferramenta CASE 76
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.