FACULDADE FARIAS BRITO
CIÊNCIA DA COMPUTAÇÃO
JOÃO BATISTA DE SOUSA FILHO
SISREQUI – Sistema Especialista para Auxílio no Processo
da Engenharia de Requisitos.
Fortaleza, 2011
JOÃO BATISTA DE SOUSA FILHO
SISREQUI – Sistema Especialista para Auxílio no Processo
da Engenharia de Requisitos.
Monografia apresentada para obtenção dos
créditos da disciplina Trabalho de Conclusão do
Curso da Faculdade Farias Brito, como parte das
exigências para graduação no Curso de Ciência
da Computação.
Orientador: José Helano Matos Nogueira, Msc.
Fortaleza, 2011
SISREQUI – SISTEMA ESPECILISTA PARA AUXÍLIO
NO PROCESSO DA ENGENHARIA DE REQUISITOS.
João Batista de Sousa Filho
PARECER __________________
NOTA:
Data: /
/
BANCA EXAMINADORA:
MSc. José Helano Matos Nogueira
Orientador
Dr. Paulo Benicio Melo de Sousa
Examinador
MSc. Ricardo Wagner Cavalcante Brito
Examinador
FINAL (0 – 10): _______
Dedico este trabalho à minha família, pois representa a
motivação central para a conclusão do mesmo.
AGRADECIMENTOS
Ao Orientador Msc. Helano Matos, por ter aceitado a ideia inicial deste trabalho e pela
paciência, coordenação, disponibilidade e ajuda.
A todos os colegas de trabalho (Alexsandro Dórea, Cassiano Mourão, Fernando Pinto,
Renan Sousa e Santana Magalhães) que me ajudaram na criação da base de conhecimento do
SISREQUI.
Aos professores e colegas da faculdade que ajudaram de maneira direta ou indireta para
a minha formação.
A minha mãe que sempre acreditou em mim e me apoio nos momentos que mais
precisei.
A Santana Magalhães que me indicou a fazer um curso com o Paulo Vieira, onde este
me ajudou a me conhecer melhor e assim tive a força e garra para terminar este trabalho e
assim realizar um de meus sonhos.
A Deus, meu grande e amado pai que ao meu lado vem me ajudando e me orientado nos
caminhos da vida.
E a todos que puderam contribuir de alguma forma.
RESUMO
As empresas desenvolvedoras de software estão cada vez mais tentando melhorar
os seus processos de desenvolvimento de software. Ao Adotar processos definidos por
instituições nacionais e/ou internacionais. Mas mesmo com a adoção de tais processos, os
projetos de software tendem a falhar. Pesquisas realizadas por instituições de avaliação de
risco e referenciadas por alguns autores apontam que os problemas que ocorrem nos projetos
estão relacionados à não utilização correta dos princípios da disciplina de engenharia de
requisitos. A disciplina tem uma série de conceitos desde a explicação do que são os
requisitos do software, requisitos de usuário e requisitos de sistema, como descrevê-los
corretamente nos documentos de requisitos, as formas de descobertas, validação, verificação e
analise de mudanças dos requisitos. Uma série de conceitos, que somados à complexidade dos
sistemas e à falta de experiência na área, acabam se tornando uma tarefa muito complexa.
Mas por outro lado, tem crescido nos últimos anos a criação e/ou utilização de softwares que
simulam o comportamento de especialistas humanos de uma determinada área, que resolvem
problemas complexos na resolução de problemas complexos, denominados Sistemas
Especialistas. Neste contexto inseriu-se esta monografia que apresenta uma proposta de
criação de um sistema especialista, com o auxílio de uma ferramenta de criação de sistemas
especialistas, para auxiliar a Analistas de Requisitos, Analistas de Sistemas e Analistas de
Negócio, na aplicabilidade dos conceitos da Engenharia de Requisitos. Este trabalho tem sua
contribuição no fornecimento de meio de aprendizado dos conceitos da disciplina, ressaltando
quais são as melhores alternativas a se tomar em determinadas situações.
SUMÁRIO
INTRODUÇÃO ..................................................................................................................................................... 1
1.
A DISCIPLINA DE ENGENHARIA DE REQUISITOS .......................................................................... 5
1.1 Requisitos de Software........................................................................................................................ 5
1.1.1 Requisitos de Usuário ............................................................................................................................. 6
1.1.1.1
Requisitos Funcionais .................................................................................................................... 6
1.1.1.2
Requisitos Não Funcionais ............................................................................................................. 7
1.1.2 Requisitos de Sistema ............................................................................................................................ 7
1.2 Documentos de requisitos de software ............................................................................................... 8
1.2.1 RUP e seus artefatos ............................................................................................................................ 10
1.2.1.1
Visão ............................................................................................................................................ 11
1.2.1.2
Especificação Suplementar .......................................................................................................... 12
1.2.1.3
Glossário ...................................................................................................................................... 12
1.2.1.4
Regras de negócios ...................................................................................................................... 13
1.2.1.5
Caso de Uso ................................................................................................................................. 13
1.2.1.6
Especificação de Requisitos de Software ..................................................................................... 13
1.2.2 Extreme Programming (XP) e as estórias de usuários ......................................................................... 14
1.2.3 Scrum e o Backlog do produto ............................................................................................................. 14
1.2.4 Pontos Positivos e Negativos Sobre os Modelos .................................................................................. 16
2.
PROCESSO DE ENGENHARIA DE REQUISITOS .............................................................................. 18
2.1 Elicitação de requisitos .......................................................................................................................18
2.1.1 Entrevistas............................................................................................................................................ 19
2.1.2 Tempestade de idéias (Brainstorm) ..................................................................................................... 20
2.1.3 Cenários ............................................................................................................................................... 21
2.1.4 Etnografia ............................................................................................................................................ 22
2.2
Verificação e validação de requisitos..................................................................................................22
2.3 Gerenciamento de requisitos .............................................................................................................23
2.3.1 Rastreabilidade de requisitos ............................................................................................................... 24
3.
SISTEMAS ESPECIALISTAS .................................................................................................................. 25
3.1
Introdução aos Sistemas Especialistas ................................................................................................25
3.2 Expert SINTA ......................................................................................................................................26
3.2.1 Arquitetura de um sistema especialista no Expert SINTA .................................................................... 27
3.2.2 Representação do Conhecimento ........................................................................................................ 28
3.2.2.1
Regras de Produção..................................................................................................................... 29
3.2.2.2
Cálculo Probabilístico dos Sistemas Especialistas ....................................................................... 31
4. SISTEMA ESPECIALISTA PARA AUXÍLIO NO PROCESSO DA ENGENHARIA DE
REQUISITOS ...................................................................................................................................................... 37
4.1 Projeto SISREQUI ................................................................................................................................37
4.1.1 Estudo de viabilidades.......................................................................................................................... 38
4.1.2 Formalização do Especialista em Engenharia de Requisitos ................................................................ 39
4.1.3 Aquisição de conhecimento ................................................................................................................. 40
4.2 Implementação do SISREQUI ..............................................................................................................41
4.2.1 Implementando o sistema.................................................................................................................... 42
4.2.1.1
Base de conhecimento................................................................................................................. 43
4.2.1.1.1
Variáveis ................................................................................................................................. 43
4.2.1.1.2
Objetivos ................................................................................................................................. 45
4.2.1.1.3
Interface com o usuário .......................................................................................................... 46
4.2.1.1.4
Regras ..................................................................................................................................... 47
4.2.1.2
Informações adicionais................................................................................................................ 49
4.3 Consultando o SISREQUI .....................................................................................................................49
4.3.1 Consultas .............................................................................................................................................. 50
4.3.2 Acompanhamento................................................................................................................................ 52
4.3.3 Janela de Resultados Atingidos ............................................................................................................ 53
4.3.4 Garantindo a relevância do SISREQUI .................................................................................................. 56
5.
CONCLUSÕES ........................................................................................................................................... 59
REFERÊNCIAS BIBLIOGRÁFICAS............................................................................................................... 61
ANEXOS I – QUESTIONÁRIO UTILIZADO NA CRIAÇÃO BASE DE CONHECIMENTO DO
SISREQUI ............................................................................................................................................................ 67
ANEXOS II – RESPOSTAS DO QUESTIONÁRIO UTILIZADO NA CRIAÇÃO BASE DE
CONHECIMENTO DO SISREQUI .................................................................................................................. 70
ANEXOS III – BASE DE CONHECIMENTO SISREQUI ............................................................................. 75
LISTA DE FIGURAS
Figura 1– Fatores na conclusão de projetos. Fonte: The Standish Group. .............................................. 2
Figura 2 – Fatores críticos para o sucesso dos projetos. Fonte: The Standish Group. ............................ 2
Quadro 1 – Especificação de requisito de sistema. Fonte: Sommerville, 2008, Modificado. ................. 8
Figura 3 - Interessados presentes na ERS. Fonte: Sommerville, 2008, pag. 91. ..................................... 9
Figura 4 – Rastreabilidade de requisitos. Fonte: Sayão e Leite, 2005. ................................................. 24
Figura 5 – Arquitetura Simplificada do Expert SINTA. Fonte: Lia, 1999. ........................................... 27
Figura 6 – Exemplo de tratamento probabilístico do caso 1. ................................................................ 32
Figura 7 - Exemplo de tratamento probabilístico do caso 2. ................................................................. 33
Figura 8 - Exemplo de tratamento probabilístico do caso 3. ................................................................. 34
Figura 9 - Exemplo de tratamento probabilístico do caso 4. ................................................................. 34
Figura 10 - Exemplo de regra com mais de um objetivo. ..................................................................... 35
Figura 11 – Ambiente do Expert SINTA. Fonte: Lia, 1999. ................................................................. 38
Figura 12 – Criando uma nova Base de Conhecimento no Expert SINTA. .......................................... 42
Figura 13 – Janela KIB. Fonte: Lia, 1999, Modificado. ....................................................................... 43
Figura 14 – Janela de criação de variáveis. Fonte: Lia, 1999, Modificado. .......................................... 44
Figura 15 – Janela de seleção de variáveis objetivos do SISREQUI. Fonte: Lia, 1999, Modificado. .. 45
Figura 16 – Janela de seleção de variáveis perguntas do SISREQUI. Fonte: Lia, 1999, Modificado. . 46
Figura 17 – Caixa de seleção de Ordem e modelo de regra. Fonte: Lia, 1999...................................... 47
Figura 18 – Tela de criação de regra de produção. Fonte: Lia, 1999. ................................................... 47
Figura 19 – Tela de inserção de premissas. Fonte: Lia, 1999. .............................................................. 48
Figura 20 – Tela de inserção de objetivos. Fonte: Lia, 1999. ............................................................... 48
Figura 21 – Janela de informações adicionais do SISREQUI. Fonte: Lia, 1999, Modificado. ............. 49
Figura 22 – Menu de controle de consultas. Fonte: Lia, 1999. ............................................................. 50
Figura 23 – Tela de abertura do SISREQUI.......................................................................................... 50
Figura 24 – Interface SISREQUI. ......................................................................................................... 51
Figura 25 – Resposta do SISREQUI com respectivo grau de confiança. ............................................. 51
Figura 26 – Tela de ajuda do SISREQUI. ............................................................................................. 52
Figura 27 – Execução do SISREQUI pelo modo depurador. ................................................................ 53
Figura 28 – Tela de Resultados. ............................................................................................................ 54
Figura 29 – Arvore de pesquisa............................................................................................................. 54
Figura 30 – Todos os resultados............................................................................................................ 55
Figura 31 – Regras do SISREQUI. ....................................................................................................... 55
Figura 32 – Gráfico de teste do SISREQUI em projetos concluídos. ................................................... 57
Figura 33 – Gráfico de teste do SISREQUI em projetos não concluídos. ............................................ 57
Figura 34 – Média de resultados. .......................................................................................................... 58
LISTA DE QUADROS
Quadro 1 – Especificação de requisito de sistema. Fonte: Sommerville, 2008, Modificado. ................. 8
Quadro 2 – Estória de Usuário .............................................................................................................. 14
Quadro 3 – Exemplo de um Backlog do produto .................................................................................. 15
LISTA DE SIGLAS
AR – Analista de Requisitos.
ASE – Arcabouços de Sistema Especialista.
CMMI - Modelo Integrado de Maturidade e de Capacidade.
IA – Inteligência Artificial.
IBM – International Business Machine.
MPS.Br - Melhoria de Processo do Software Brasileiro.
SE – Sistema Especialista.
XP – Extreme Programming.
GLOSSÁRIO
Analista de Requisitos (AR): Responsável pela coleta, análise, validação e documentação dos
requisitos junto ao cliente e passar esses requisitos coletados para os desenvolvedores (RUP, 2006).
Artefato: Artefatos são produtos de trabalhos, finais ou intermediários, produzidos e usados para
capturar e transmitir informações do projeto (RUP, 2006). Um artefato pode ser um dos seguintes
elementos:

Um documento, como Caso de Negócio ou Documento de Arquitetura de Software;

Um modelo, como o Modelo de Casos de Uso ou o Modelo de Projeto;

Um elemento do modelo, ou seja, um elemento existente em um modelo, como uma classe ou
um subsistema.
Ator: É uma entidade de fora do sistema que interage com o mesmo. Os atores podem ser os usuários
do sistema, outros sistemas de computador ou eventos externos (RUP, 2006).
Backlog do produto: É documento contendo todos os requisitos detalhadamente, com o tempo
estimado para desenvolvimento dos requisitos assim como os responsáveis pelo desenvolvimento dos
mesmos, agrupados de acordo com as suas prioridades.
CMMI: Modelo Integrado de Maturidade e de Capacidade, voltado à melhoria de processo, composto
pelas melhores práticas de desenvolvimento de projetos, abordando o ciclo de vida do produto desde a
concepção até a entrega e manutenção.
Documento de visão: Artefato RUP, que define as necessidades e características dos envolvidos e
usuários-alvo do projeto (RUP, 2006).
Documento Especificação de caso de uso: Consiste na descrição detalhada, mostrando passo a passo
uma funcionalidade do sistema e a comunicação com os atores (RUP, 2006).
Especificação de Requisitos de Software (ERS): Documento que descreve todos os requisitos de
software que o sistema terá ou parte deles. Quando a modelagem de casos de uso é utilizada, os casos
de uso aplicáveis estarão descritos no ERS (RUP, 2006).
Especificação suplementar: Artefato RUP, que conterá todos os requisitos não funcionais necessários
ao desenvolvimento do projeto (RUP, 2006).
Estórias de Usuário (User Stories): são descrições textuais sucintas a respeito das funcionalidades do
sistema.
Extreme Programming (XP): Processo ágil de desenvolvimento de software, que visa o trabalho em
equipe com foco a agilidade para se atingir a total satisfação do cliente.
Interessados (Stakeholders): Termo utilizado para designar todos aqueles que, de alguma maneira,
estão envolvidas no projeto (pessoas ou organizações).
Organização Internacional para a Padronização (ISO 9001 (2008)): Norma voltada em promover a
adoção de uma abordagem de processo para aumentar a qualidade no desenvolvimento,
implementação e melhoria no atendimento aos requisitos do cliente.
Melhoria de Processo do Software Brasileiro (MPS.Br): Em desenvolvimento desde dezembro de
2003, pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX). O programa
tem como base melhorar o processo de requisitos com base nos princípios da Engenharia de Software.
Metodologias Ágeis: Abordagens de desenvolvimento que buscam descobrir as melhores, mais
rápidas e eficientes maneiras de desenvolver softwares. As metodologias ágeis têm as seguintes
características:

Maior comunicação e participação do cliente, ao invés de negociações de contratos;

Maior interação entre pessoas do projeto, que processos e ferramentas;

Responder a mudanças mais que seguir um plano;

Software em funcionando ao invés de extensas documentações.
Processo Unificado (UP): Plataforma de processo de desenvolvimento de software desenvolvida
inicialmente pela Rational Software, Inc.; Hoje controlada pela IBM.
Rational Unified Process (RUP): O RUP é um processo de engenharia de software que tem uma
abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organização
de desenvolvimento de software com foco em garantir a produção de software de alta qualidade que
atenda às necessidades dos usuários dentro de um cronograma e com orçamento previsível (RUP,
2006).
SCRUM: Metodologia ágil de projetos de software. No Scrum, os projetos são divididos em sprints,
que são ciclos mensais ou semanais.
SHELL: Shell é o nome dado a uma família de ferramentas e não à linguagens de programação, que
tem o objetivo de apoiar e simplificar o processo de construção de Sistemas Especialistas.
Standish group: Grupo de profissionais altamente dedicados com anos de experiência prática na
avaliação do risco, custo de retorno e valor de Tecnologia da Informação (TI) que tem como visão:
coletar informações sobre o caso na vida real, falhas em ambientes de TI e ajudar a mostrar o caminho
para melhorar as taxas de sucesso e aumentar o valor dos investimentos na TI das empresas.
Story Points: Unidade de estimativa utilizada no Scrum, para calcular a quantidade de dias que um
desenvolvedor trabalhou em uma determinada estória de usuário. Onde o cálculo da story points é
feito em cima da quantidade de dias levados para a conclusão de uma estória, multiplicado pela
quantidade de pessoas que trabalharam no desenvolvimento da estória.
Sistemas Especialistas: Conceito utilizado na IA para definir programas que auxiliam na resolução de
problemas de uma determinada área de conhecimento com a mesma qualidade e rapidez que um
especialista humano.
1
INTRODUÇÃO
Atualmente, as organizações estão buscando formas de melhorarem seus
processos, seja através de modelos nacionais ou internacionais, tais como CMMI, ISO 9001
(2008) ou MPS.BR (ZANETTI, MONTONI e ROCHA, 2009). O objetivo é ter um melhor
aperfeiçoamento dos seus serviços e produtos com maior qualidade (REINALDO, 2006).
Contudo, mesmo com a utilização de tais modelos, podem existir problemas decorrentes de
falhas na execução do processo ou manutenção de software, em grande parte devido à não
utilização correta dos princípios da análise de requisitos (MEDEIROS, BELCHIOR e
FARIAS, 2005). O processo de desenvolvimento de software se inicia a partir da fase de
Análise de requisitos (MEDEIROS, BELCHIOR e FARIAS, 2005). Nessa fase de
descobertas (PRESSMAN, 2005; CAMPELO, 2009), ocorre a elicitação de requisitos, onde
são identificadas as necessidades que o software tem que atender e a complexidade de um
problema do mundo real (SOMMERVILE, 2008; SWEBOK, 2004; CAMPELO, 2009).
Apesar de hoje os softwares desenvolvidos estarem cada vez mais sofisticados,
diminuindo a complexidade dos problemas do mundo real, os problemas que ocorrem no
processo de desenvolvimento ainda trazem enormes dificuldades aos envolvidos
(MEDEIROS, BELCHIOR e FARIAS, 2005). Oliveira (2008) comenta que, para minimizar
os problemas que ocorrem no ciclo de desenvolvimento de software, basta a utilização da
análise de requisitos, pois, segundo o mesmo, 37% dos problemas que ameaçam os projetos
estão relacionados a requisitos. Uma pesquisa anterior do Standish Group reforça as palavras
ditas por Oliveira (2008), pois segundo pesquisa realizada em 1995 por esta instituição,
apenas 16% dos projetos são finalizados com sucesso, 31% dos projetos fracassam por algum
motivo, enquanto mais de 53% dos projetos extrapolam o tempo, custos e/ou não satisfazem
os clientes conforme figura 1.
2
Projetos
Bem sucedidos
31%
Problemáticos
Fracassados
16%
53%
Figura 1– Fatores na conclusão de projetos. Fonte: The Standish Group.
Essa pesquisa teve o intuito de identificar as falhas dos projetos de softwares, os
fatores causadores das falhas e os meios de se evitar as falhas dos projetos. O envolvimento
dos usuários no projeto, suporte da gerência executiva e estabelecimento claro dos requisitos,
foram apontados pela pesquisa como os fatores responsáveis pelo sucesso dos projetos,
conforme mostrados na figura 2.
Fatores de Sucesso
Envolvimento dos Usuários
16%
14%
Suporte da gerência
executiva
57%
13%
Estabelecimento claro dos
requisitos
Outros (planejamento
apropriado, equipe
competente
comprometimento, outros)
Figura 2 – Fatores críticos para o sucesso dos projetos. Fonte: The Standish Group.
3
Nos projetos problemáticos e/ou fracassados os maiores problemas estão na falta
de um levantamento completo dos requisitos e/ou no não tratamento correto na mudança de
requisitos. Portanto, com o intuito de se chegar ao desenvolvimento correto de um software,
evitando ou reduzindo casos de falhas no processo de criação e gerando mais tarde gastos
com manutenção e correção de erros, é fundamental o correto entendimento e aplicação da
disciplina de Engenharia de Requisitos. Mas, entender e aplicar corretamente os princípios da
análise de requisitos para analistas que não sejam especialistas na área acaba se tornando uma
tarefa muito complexa.
Por outro lado, recentemente, tem crescido bastante a quantidade de softwares que
capturam e simulam o comportamento de especialistas humanos, estes denominados Sistemas
Especialistas (NOGUEIRA e SILVA, 1997; DIEHL, 2000). A utilização de sistema
especialista voltado para a área de engenharia de requisitos iria auxiliar os analistas a tratarem
de problemas complexos, onde a solução só seria alcançada com a ajuda de um especialista na
área de requisitos. Segundo os autores citados anteriormente, a utilização de um sistema
especialista se torna necessária devido a diversos fatores tecnológicos e econômico-sociais
tais como:

Dificuldade de acesso a especialistas humanos em determinadas regiões;

Armazenamento e formalização do conhecimento de vários especialistas
humanos;

Ferramenta de apoio à tomada de decisões por parte do especialista;

Treinamento de profissionais e imparcialidade na tomada de decisões.
Por essas razões este trabalho tem com objetivo principal a criação de um sistema
especialista com o auxílio do Expert SINTA para a área de engenharia de requisitos
denominado SISREQUI. O SISREQUI não tem o intuito de retirar do homem o trabalho
abordado na fase de requisitos, o objetivo do SISREQUI e o de auxiliar e/ou treinar analistas
de sistemas, analistas de requisitos e analistas de negócios no correto desenvolvimento e
aplicabilidade da engenharia de requisitos no processo de desenvolvimento de sistemas
computacionais, diminuindo assim a complexidade e facilitando a utilização eficiente e eficaz
dos conceitos de engenharia de requisitos.
4
Este trabalho está estruturado em quatro capítulos, onde o primeiro capítulo
aborda os conceitos da disciplina de engenharia de requisitos, explicando o que são requisitos
de softwares e quais os seus documentos. Já o segundo capítulo descreve o processo da
engenharia de requisitos abordando desde o levantamento dos requisitos junto ao cliente até a
validação dos requisitos e o gerenciamento dos mesmos. O terceiro capítulo comenta sobre o
uso de ferramentas automatizadas geradoras de sistema especialistas, onde é exemplificado o
uso do Expert SINTA1. Também é apresentada a arquitetura básica de um sistema especialista
com suas regras de produção. O quarto capítulo descreve o Sistema de Requisitos proposto,
SISREQUI. Neste capítulo é detalhado como será a base de conhecimento do sistema, quais
as variáveis, objetivos, regras e interfaces com o usuário o mesmo terá. Ao final do capítulo
são apresentados os resultados que foram atingidos com o sistema.
1
Ferramenta criada pelo Laboratório de Inteligência Artificial da Universidade Federal do Ceará – LIA/UFC
(www.lia.ufc.br)
5
1. A DISCIPLINA DE ENGENHARIA DE REQUISITOS
O objetivo deste capítulo é apresentar a disciplina de Engenharia de Requisitos,
mostrando o que são requisitos de software, abordados na seção 1.1 e mostrando os
documentos de requisitos, seção 1.2, com seus modelos definidos em processos de
desenvolvimento de software, tais como RUP, XP e SCRUM.
1.1 Requisitos de Software
Com a globalização do mercado e a alta competividade existente entre as
organizações desenvolvedoras de software tem crescido, nessas organizações, a necessidade
de se criar softwares em menos tempo e com poucos recursos, com maior qualidade que atinja
a satisfação dos clientes (ZANETTI; MONTONI e ROCHA, 2009). Meira (2008) comenta
que as organizações consideram as áreas de especificação de requisitos e a gerência de
requisitos do cliente como os principais focos de problemas no desenvolvimento do software.
Melhorar os processos de descobertas, documentação e controle de requisitos do cliente são
fatores críticos para o sucesso do negócio (PRESSMAN, 2005).
O sucesso no processo de engenharia de requisitos se torna possível quando se
consegue entender as diferenças entre os requisitos de usuário e dos requisitos de sistema
(SOMMERVILLE, 2008). Os requisitos de usuário e de sistema podem ser definidos da
seguinte maneira:

Requisitos de usuário são declarações, em uma linguagem natural,
contendo os serviços que são esperados pelo sistema e suas restrições.

Requisitos de sistema são descrições detalhadas de como serão exatamente
implementados as funções, serviços e as restrições do sistema.
6
A seguir tais modelos são mostrados e exemplificados com maiores detalhes.
1.1.1
Requisitos de Usuário
Os requisitos de usuário devem descrever os requisitos funcionais e não
funcionais do sistema. Estes requisitos devem ser descritos o mais próximo da linguagem
natural, evitando-se o máximo a utilização de termos técnicos, de modo que sejam
compreensíveis para a leitura de usuários que irão utilizar o sistema. Eles devem especificar
apenas detalhes externos do sistema, evitando-se características de projeto (SOMMERVILLE,
2008).
1.1.1.1 Requisitos Funcionais
Os requisitos funcionais detalham ações que o sistema deve ter, sem levar em
consideração as restrições físicas (SEWBOOK, 2004). Os requisitos funcionais dependem do
tipo de software que está sendo desenvolvido e dos usuários aos quais o software se destina.
Quando expressos como requisitos de usuários, eles são descritos de forma abstrata, mas,
como requisitos funcionais, eles devem ser descritos com maior nível de detalhamento,
descrevendo suas entradas, saídas e exceções. (SOMMERVILLE, 2008). Por exemplo, um
requisito funcional de funcionamento de um sistema de locadora de filmes, na rotina de
pesquisa de um filme pelo título poderia ser descrito como:
1. Quando o usuário solicitar a pesquisa de algum filme ele informa alguma
palavra como chave;
2. O sistema deve buscar no banco de dados todos os filmes que tenham no
título ou sinopse a palavra informada pelo usuário em seguida deve exibir
os 20 primeiros resultados em ordem alfabética.
Este requisito funcional foi um exemplo de como é feita a interação entre usuário
e sistema. Os requisitos podem ser descritos em diferentes níveis, como no exemplo acima,
contanto que seu entendimento fique claro a quem o ler. Geralmente, os requisitos funcionais
são descritos em um documento de casos de uso.
7
1.1.1.2 Requisitos Não Funcionais
Os requisitos não funcionais são relacionados às características restritivas dos
sistemas, tais como: confiabilidade, tempo de resposta, desempenho, interface, espaço de
armazenamento (RUP, 2006). Tais restrições podem afetar tanto na implementação dos
requisitos funcionais quanto nos componentes do sistema (SWEBOOK, 2004; OLIVEIRA,
2008).
Por exemplo, no mesmo sistema de locadora de filmes, um requisito não
funcional seria:
1. A interface do sistema deve ser leve, para que o acesso seja possível por
uma conexão de internet de no mínimo 60 kbps.
2. O tempo de resposta no sistema em uma pesquisa não poderá ser superior
a 60 milissegundos.
1.1.2
Requisitos de Sistema
O comportamento externo do sistema, bem como suas restrições operacionais, são
formas de descrição de requisitos de sistema (SWEBOOK, 2004). Sommerville (2008)
comenta que especificar completamente um sistema de software complexo no nível de detalhe
necessário é uma prática inviável, pois, em alguns casos, os sistemas terão de interagir com
outros sistemas existentes, restringindo o projeto e impondo requisitos ao novo sistema.
Para a descrição de requisitos de sistemas, como também de usuários, deve-se
utilizar a linguagem natural. Contudo, como os requisitos de sistemas são mais detalhados que
os requisitos de usuários, as especificações em linguagem natural podem acabar ficando mais
confusas e difíceis de serem compreendidas. Logo, pode-se escrever os requisitos de sistema
usando notações mais especializadas como casos de uso, diagramas de classes, sequencia ou
até formulários padrões (SOMMERVILLE, 2008).
8
Um exemplo de especificação de requisito de sistema utilizando um formulário
padrão para o sistema de locadora de filmes seria:
Função: Calcular o valor de filmes.
Descrição: Calcular o valor dos filmes solicitados para empréstimo.
Entradas: Código do Filme e Nome ou CPF do cliente.
Saídas: Valor calculado.
Destino: Controle financeiro.
Ação: O valor será calculado [ se o cliente não possuir nenhum débito negativo com a
empresa. Se o mesmo possuir algum débito, será impresso uma nota promissora informando
o valor que está em atraso.] Caso contrário o valor dos filmes e calculado e impresso.
Requer: Fornecimento do código do filme e o nome ou CPF do cliente.
Pré-Condição: O cliente possuir cadastro e não ter nenhum débito negativo com a locadora.
Pós-Condição: Valor calculado e nota promissória impressa.
Quadro 1 – Especificação de requisito de sistema. Fonte: Sommerville, 2008, Modificado.
1.2 Documentos de requisitos de software
A Especificação de Requisitos tem por finalidade estabelecer e manter um
entendimento comum sobre o sistema entre de todos os envolvidos (SOMMERVILLE, 2008).
Ela deve abranger todos os requisitos do sistema, definir a interface de usuário para o sistema,
determinar as fronteiras, custos e o tempo de desenvolvimento do sistema (RUP, 2006). Para
se conseguir atingir essas metas, é importante compreender o problema para saber se é
possível resolvê-lo com o sistema a ser construído. As solicitações dos usuários são
recolhidas, reunidas e analisadas, que posteriormente se tornarão os requisitos de software que
o sistema terá. Os requisitos de software são descritos em um documento chamado de
especificação de requisitos de software.
A Especificação de Requisitos de Software (ERS), também conhecida como
documento de especificação de software, é o documento que contém todos os requisitos de
software que envolvem o projeto, ou seja, é a declaração do que os desenvolvedores do
sistema devem implementar (SEWBOOK, 2004), podendo incluir também os casos de uso,
9
requisitos funcionais e não funcionais (RUP, 2006; CAMPELO, 2009). O documento de ERS
abrange vários tipos de usuários, desde os patrocinadores até os responsáveis pelo
desenvolvimento de software (SEWBOOK, 2004). A ERS controla a evolução do sistema em
toda a fase de desenvolvimento do projeto. Mesmo quando novos recursos são adicionados ou
modificados, eles são elaborados dentro da ERS (RUP, 2006).
A figura 3 ilustra alguns dos grupos de interessados que contribuem com a ERS e
seus respectivos focos de atenção.
Figura 3 - Interessados presentes na ERS. Fonte: Sommerville, 2008, pag. 91.
A quantidade de possíveis interessados presentes na ERS significa que a escrita da
mesma deve estar compreensível para todos. O nível de detalhamento do documento
dependerá das características do sistema que será desenvolvido e do processo de
desenvolvimento que está sendo utilizado. Sommerville (2008) explica que grandes
organizações como o IEEE definiram padrões para as ERS. Um dos mais conhecidos é
IEEE/ANSI 830-1998 o qual de acordo com Sommerville (2008), possui a seguinte estrutura:
1. Introdução
1.1. Propósito do documento de requisitos
1.2. Escopo do produto
1.3. Definições, acrônimos de abreviaturas
10
1.4. Referências
2. Descrição geral
2.1. Perspectiva do produto
2.2. Funções do produto
2.3. Características dos usuários
2.4. Restrições gerais
2.5. Suposições gerais
2.6. Suposições e dependências
3. Requisitos específicos abrangem requisitos funcionais, não funcionais e de interface.
4. Apêndices
5. Índice
Embora o padrão não seja o ideal, ele contém boas recomendações de como
descrever requisitos, evitando-se problemas futuros. O padrão é muito geral e acaba não
sendo pouco adotado pelas instituições. Todavia, pode ser adaptado e modificado para a
realidade de cada instituição (SOMMERVILLE, 2008).
A ERS é indispensável quando o sistema está sendo desenvolvido por uma equipe
externa. Os métodos ágeis de desenvolvimento apontam que os requisitos mudam tão
frequentemente que a ERS ficaria desatualizada rapidamente e mantê-la atualizada resultaria
em esforço inútil. Sommerville (2008) comenta que em situações como a descrita
anteriormente, a descrição de requisitos de usuário e mais aconselhável utilizar a abordagem
dos métodos ágeis, como a Extreme Programming (XP) e SCRUM onde se priorizam apenas
os requisitos que serão implementados.
1.2.1
RUP e seus artefatos
O RUP tem vários documentos a serem utilizados em processos de
desenvolvimento de softwares. Smith (2003) explica que para utilizar o RUP, as empresas não
necessitam utilizar todos os artefatos, pois a seleção e adaptação de artefatos é uma parte
11
necessária no processo. O próprio RUP oferece orientações sobre como adaptá-lo à realidade
da empresa desenvolvedora de software (SMITH, 2003).
Para o RUP, os objetivos da disciplina de requisitos são:

Estabelecer a concordância com todos os envolvidos sobre o que o sistema
a ser desenvolvido;

Oferecer aos desenvolvedores do sistema um entendimento sobre
requisitos do sistema;

Definir as fronteiras do sistema;

Fornecer uma base para planejar o conteúdo técnico das repetições;

Fornecer uma base para estimar o custo e o tempo de desenvolvimento do
sistema;

Definir uma interface de usuário para o sistema, com base nas
necessidades e metas dos usuários;
Artefatos necessários para se chegar esses objetivos são:

Documento de Visão;

Especificação suplementar;

Glossário;

Regras de negócios;

Casos de uso;

Especificação de requisitos de software.
Esses documentos são utilizados como formas de se descrever o sistema, em projetos
nos quais os interessados são vistos como fontes de informações (RUP, 2006).
1.2.1.1 Visão
O documento de visão tanto fornece uma visão completa do negócio a ser
atendido pelo desenvolvimento do sistema, como também serve de auxílio para o contrato
entre cliente e a organização de desenvolvimento. O documento de visão é uma referência que
12
contem as expectativas capturadas entre os envolvidos (RUP, 2006). A visão é escrita com
base nas perspectivas dos clientes, focalizando as características cruciais do sistema, os níveis
desejáveis de qualidade e descrição das características dos sistemas, tanto as que serão
incluídas, bem como aquelas que foram consideradas, mas não incluídas (RUP, 2006).
Ela também deve especificar as capacidades operacionais, como tempo de
resposta e os usuários que utilizarão o sistema. O documento de visão fornece uma base
contratual com os envolvidos para os requisitos visíveis que terá o sistema, podendo ser
modificada conforme os requisitos sejam entendidos com maiores detalhes. O documento de
visão pode também ser expresso em casos de uso (RUP, 2006).
1.2.1.2 Especificação Suplementar
A especificação suplementar é um modelo que contém todos os requisitos
funcionais e não funcionais essenciais para o sistema que não são descritos imediatamente nos
documentos de casos de uso (RUP, 2006). Entre os requisitos estão incluídos requisitos de
regulamentação e padrões de aplicativo, atributos de qualidade do sistema, requisitos de
usabilidade, confiabilidade, desempenho, suportabilidade, segurança, portabilidade, restrições
computacionais dentre outras, sistemas operacionais e ambientes (RUP, 2006).
1.2.1.3 Glossário
Nas fases de elicitação e/ou descrição dos requisitos, termos técnicos podem
surgir e para que esses requisitos possam ser entendidos, modelados e desenvolvidos, se torna
necessário que o significado dos mesmos sejam descritos em um glossário. Nele são descritos
todos os termos necessários para entender a modelagem do negócio e termos específicos do
projeto.
Com o glossário se cria um vocabulário que contem os termos e as expressões
mais comuns com todas as descrições textuais do negócio, evitando-se mal-entendidos entre
os envolvidos no projeto sobre o uso e o significado dos termos (RUP, 2006).
13
1.2.1.4 Regras de negócios
No documento de regras de negócios são descritas as regras de negócios impostas
com base em leis e regulamentos ou padrões da empresa utilizados para o correto
desenvolvimento dos requisitos que o software precisa atender. As regras de negócios são
descritas em uma linguagem rigorosa e formal (RUP, 2006). A descrição das regras de
negócios deve conter informações de como se obter alguma informação especifica para
alguma ação do sistema, regras de como deve ser feito algum cálculo específico,
comportamento e exibição de campos, dentre outras.
No documento de regras de negócios é descrito o comportamento dos requisitos
de negócios e das ferramentas de negócios, podendo estes requisitos e ferramentas serem leis
e regulamentos impostos ao negócio, como também arquitetura e o estilo de negócio
escolhidos para o sistema (RUP, 2006).
1.2.1.5 Caso de Uso
O documento de caso de uso é um modelo das funções pretendidas do sistema e
seu ambiente, uma descrição de como será a funcionalidade do sistema (RUP, 2006). Casos
de uso definem principalmente os requisitos funcionais do sistema refinados por fluxos de
eventos mais detalhados durante a fase de construção (RUP, 2006). Por ser um instrumento de
planejamento bastante importante, o documento de casos de uso é usado em todas as fases do
ciclo de desenvolvimento (RUP, 2006).
1.2.1.6 Especificação de Requisitos de Software
A Especificação de Requisitos de Software no RUP contem todos os requisitos de
software para o sistema ou para uma parte dele. O esquema de ERS é parecido com um
projeto que utiliza modelagem de casos de uso. A ERS consiste em um pacote contendo casos
de uso e Especificações Suplementares aplicáveis, além de outras informações de suporte
(RUP, 2006).
14
1.2.2
Extreme Programming (XP) e as estórias de usuários
Na Extreme Programming (XP), os requisitos são feitos a partir das estórias de
usuário, criadas pelos clientes. As estórias de usuário têm o mesmo propósito dos casos de
uso, mas possuem diferenças. Beck (2002) comenta que as estórias de usuário são utilizadas
em vez de um documento de requisitos, já que as mesmas são escritas pelos clientes com as
funcionalidades que o sistema precisa fazer por eles (BECK, 2002). Elas são semelhantes aos
casos de usos, exceto que elas não se limitam a descrever termos técnicos.
Estórias de usuário só fornecem detalhes suficientes para fazer uma estimativa de
quanto tempo ela levará para ser desenvolvida. No momento da implementação, o
desenvolvedor responsável pela estória de usuário, conversa com o cliente para receber uma
descrição mais detalhada dos requisitos (WELLS, 1999), conforme quadro 1.

Estória 01
Implementar a funcionalidade da pesquisa de filmes.
Estimativa Inicial: 4 horas
Quadro 2 – Estória de Usuário
Wells (1999), afirma que um dos maiores mal-entendidos com as estórias de
usuário é como elas diferem das especificações tradicionais. A maior diferença está no nível
de detalhe (WELLS, 1999). Outra diferença, segundo Wells (1999), entre as estórias de
usuário e um documento de requisitos está no foco nas necessidades do usuário evitando-se
detalhes de uma tecnologia específica, leiaute base de dados e algoritmos mantendo as
estórias focadas nas necessidades do usuário (WELLS, 1999).
1.2.3
Scrum e o Backlog do produto
O Scrum também utiliza estórias de usuário como forma de armazenar os
requisitos (MARTINS, SZALVAY, 2007), mas, diferente do XP, no Scrum as estórias de
usuário são descritas com maiores detalhes no Backlog do produto. O Backlog do produto é
uma lista de alto nível, definida pelo analista e/ou cliente, que contém todos os requisitos
15
funcionais, não funcionais e requisitos técnicos desejados pelo cliente para o sistema
(KNIBERG, 2007). No início do projeto, o Backlog do produto deve descrever apenas os
requisitos mais importantes. Com o tempo, o Backlog do produto cresce e muda à medida que
o cliente descreve melhor os requisitos (MARTINS, SZALVAY, 2007).
O documento é compartilhado com todos os membros da equipe, normalmente em
algum local da rede da empresa ou em planilhas na rede. No Backlog do produto, os requisitos
são numerados, batizados, priorizados e descritos. A lista do produto do backlog é estruturada
da seguinte maneira, conforme quadro 3:
ID
01
Nome
Cadastro de Filmes
02
Cadastro de Cliente
Estimativa Inicial
9 (Story Points)
Importância
120
Descrição
O sistema deve pesquisar antes se
o filme que está sendo cadastrado
já possui cadastro. Caso possua, o
sistema deve exibir uma
mensagem avisando ao usuário.
Caso contrário, o sistema deve
efetuar o cadastro.
9 (Story Points)
120
O sistema deve verificar se o
cliente já está cadastrado,
avisando ao usuário caso esteja.
Caso contrário, o sistema deve
efetuar o cadastro.
Quadro 3 – Exemplo de um Backlog do produto
Os tópicos do backlog do produto, segundo KNIBERG (2007), são os seguintes:

ID: Numeração da estória de usuário. Identificador utilizado para evitar
que se perca o controle sobre as estórias, caso o nome delas seja
modificado;

Nome: Frase que descreve o que é a estória de usuário;

Estimativa Inicial: Estimativa inicial em story points da quantidade de
tempo necessário para a implementação da estória de usuário. Exemplo:
Digamos que 3 dias é o tempo que 3 desenvolvedores trabalhando junto
levariam para desenvolver uma determinada estória. Então temos 3 dias
trabalhados X 3 pessoas = 9 story points. Os valores dependem muito do
processo adotado pela empresa;
16

Importância: Importância da estória de usuário para o Analista, quanto
maior o número, maior a importância;

Descrição: É a descrição em alto nível, linguagem natural, de como o
requisito deve se comportar.
O Backlog do produto geralmente é feito em uma planilha e é de responsabilidade do
AR, mas pode ser visualizado pelos demais membros e até editado, como por exemplo, um
desenvolvedor que deseje alterar a estimativa (KNIBERG, 2007).
1.2.4
Pontos Positivos e Negativos Sobre os Modelos
A utilização de todos os artefatos da disciplina de requisitos pelo RUP implica em
softwares de qualidade que atendem aos princípios da engenharia de software (RUP, 2006),
tendo como principais vantagens:

Rápida correção de problemas;

Rápido desenvolvimento de melhorias;

Melhor entendimento sobre o negócio;

Melhor visão sobre as funcionalidades do sistema;

Requisitos mais definidos e explicados.
Contudo, a utilização dos artefatos também possui suas desvantagens:

Necessidade de um conhecimento formal sobre como preencher e manter
os documentos;

Documentos muito extensos;

Os artefatos necessitam estar sempre atualizados.
Documentar requisitos através de estórias conforme utilizado no XP e SCRUM
resolve as principais desvantagens na utilização dos artefatos do RUP. Contudo, as estórias
não descrevem com maiores detalhes os requisitos e muitos detalhes acabam passando
despercebidos (RUP, 2006), o que acaba requerendo que o desenvolvedor tenha um vasto
conhecimento sobre o negócio a ser desenvolvido. Segundo Smith (2003), métodos ágeis não
17
proíbem a utilização de documentos ou outros artefatos com as estórias. Os métodos ágeis
apenas produzem os artefatos que realmente irão ser utilizados.
18
2. PROCESSO DE ENGENHARIA DE REQUISITOS
O objetivo deste capítulo e explicar as atividades presentes no processo de engenharia
de requisitos. São abordados pontos sobre a elicitação de requisitos e quais as principais
técnicas utilizadas para se coletar os requisitos. Será explicada a validação dos requisitos e
como se gerenciar os requisitos. O capítulo está organizado da seguinte maneira: A seção 2.1
aborda a elicitação de requisitos e as principais técnicas utilizadas para o correto
levantamento dos requisitos. Na seção 2.2 aborda o processo de verificação e validação de
requisitos. Finalmente o gerenciamento de requisitos é abordado na seção 2.3.
2.1 Elicitação de requisitos
A elicitação de requisitos é a atividade em que todos os (interessados) envolvidos
no projeto trabalham juntos com o intuito de aprender mais sobre como deve ser o sistema
(SOMMERVILLE, 2008). Na elicitação são identificados os requisitos do sistema, chegandose a um entendimento mais completo do software (OLIVEIRA, 2008). Oliveira (2008)
ressalta que a fase de elicitação de requisitos não consiste apenas em perguntar aos clientes o
que eles querem, e sim fazer um levantamento cuidadoso do domínio e do processo de
negócio que o sistema deverá ter. Todavia, a elicitação, segundo Sommerville (2008), acaba
se tornando difícil pelas seguintes razões:

Os interessados não sabem o que querem;

Os interessados utilizam seus próprios termos com conhecimento implícito
sobre os requisitos cabendo ao Analista de Requisitos o conhecimento e o
domínio para entender esses requisitos;
19

Diferentes interessados possuem diferentes formas de expressar os
requisitos. O AR deve saber entender os pontos em comum nos requisitos
expressados;

Fatores políticos podem influenciar nos requisitos do sistema. Por
exemplo, um secretário de saúde pode solicitar um requisito que
aumentará sua influência no estado;

Os requisitos mudam constantemente durante o processo, mudando
também a importância de determinados requisitos. Novos requisitos de
novos interessados podem surgir.
A elicitação de requisitos não se resume à simples transferência de conhecimento
das pessoas para documentos de requisitos. Na realidade, acaba se tornando um processo
muito mais complexo devido aos fatores descritos anteriormente. Portanto, a elicitação de
requisitos não é simplesmente “pescar” os requisitos, mas um complexo processo de
negociação envolvendo todos os interessados envolvidos no projeto (OLIVEIRA, 2008).
Para conseguir chegar ao entendimento completo do software são utilizadas
algumas técnicas, dentre as quais se destacam: entrevistas, tempestade de ideias, cenários e
etnografia.
2.1.1
Entrevistas
Entrevistas formais ou informais com todos os interessados, segundo Sommerville
(2008), ocorrem na maioria dos processos de engenharia de requisitos. Nessas entrevistas os
ARs formulam questões para os interessados sobre o sistema que eles usam e/ou o sistema
que será desenvolvido. Os requisitos vão sendo formulados conforme os interessados forem
respondendo as questões. As entrevistas, segundo Oliveira (2008), podem ser de dois tipos:

Entrevistas fechadas, onde os ARs perguntam aos interessados uma lista
de perguntas já elaboradas.

Entrevistas abertas, nas quais não existem perguntas predefinidas. Os ARs
exploram vários assuntos com os interessados, de forma a adquirir uma
compreensão maior sobre a necessidade dos mesmos.
20
Na prática, as entrevistas são uma mistura dos dois tipos. As entrevistas são úteis para
conhecer melhor as atividades dos interessados, como eles podem interagir com o sistema e as
dificuldades que eles têm com os sistemas atuais (OLIVEIRA, 2008). No entanto, as
entrevistas não são úteis para entender o domínio da aplicação (SOMMERVILLE, 2008).
Elicitar o domínio da aplicação com entrevistas e muito complicado, pois, os interessados
especialistas do domínio não conseguem explicar os requisitos sem termos específicos, ou
então acham que os domínios são tão fundamentais que não vale a pena mencioná-los o que
acaba provocando um mau entendimento ou não é levado em consideração por parte dos ARs
(SOMMERVILLE, 2008).
As informações obtidas através das entrevistas, que muitas vezes são a única forma de
conhecimento do sistema, complementam outras informações sobre o sistema, como
documentos. Para uma correta elicitação, Sommerville (2008) comenta que as entrevistas
devem ser aplicadas junto com outras técnicas para a elicitação de requisitos, pois apenas as
entrevistas, pode levar a perda de informações essenciais para o sistema.
2.1.2
Tempestade de idéias (Brainstorm)
A tempestade de idéias é uma das mais antigas técnicas para geração de idéias em
reuniões em grupo. O princípio básico consiste em reunir um conjunto de interessados
especialistas em sistemas e negócios (APARECIDO e CARVALHO, 2002). Na reunião,
todos os interessados dão ideias para contribuir para a resolução do problema, cabendo ao AR
filtrar as ideias sugeridas e exploradas nestes encontros. No início da fase de
desenvolvimento, quando se tem pouco conhecimento do negócio, a aplicação da técnica se
torna necessária para o surgimento de novas idéias (OLIVEIRA, 2008). Esta técnica é usada
para gerar novas ideias, deixando a mente livre para aceitar todas as ideias criativas que forem
sugeridas. O resultado de uma sessão bem-sucedida é a solução do problema com um
conjunto de ideias, propostas por todos que participaram da sessão (APARECIDO e
CARVALHO, 2002).
Em termos de tempo, a tempestade de idéias pode ter um custo baixo, já que uma
sessão não leva mais que uma hora, principalmente se os envolvidos já tiverem experiência
21
com a técnica e forem criativos. Já em termos de esforços, a tempestade de idéias pode ter um
custo relativamente alto, pois requer um número significativo de pessoas, o que não é
indicado. O aconselhável é incluir pessoas chaves com diferentes perfis (APARECIDA e
CARVALHO, 2002; OLIVEIRA, 2008). Entretanto, segundo Aparecido e Carvalho (2002),
levando-se em conta a quantidade de informação coletada com o custo para obtê-la, o uso da
técnica tempestade de idéias acaba sendo uma ótima escolha.
2.1.3
Cenários
Os usuários e demais interessados acham mais simples relatar os exemplos do trabalho
assim descrever as funcionalidades que deverão existir no sistema. No cenário, eles podem
interagir, compreendendo e/ou criticando como seriam as funcionalidades do sistema
(OLIVEIRA, 2008). A utilização de cenários para descrever os requisitos do sistema e como o
sistema poderá ser utilizada é bastante usado em metodologias ágeis com as estórias ou no
RUP com os casos de uso.
Um sistema muito grande terá também um número muito grande e complexo de
cenários. Os cenários devem incluir pelo menos uma das seguintes informações, segundo
Oliveira (2008) e Sommerville (2008):

Uma descrição do estado do sistema antes de entrar no cenário;

O fluxo normal de eventos no cenário;

Uma descrição dos possíveis fluxos de exceções;

Informações sobre outras atividades que podem ocorrer no mesmo
momento;

Uma descrição do estado do sistema após concluir o cenário.
Os cenários podem ser descritos na forma de textos, diagramas e imagens.
22
2.1.4
Etnografia
A etnografia é uma técnica de observação utilizada para obter os requisitos
organizacionais e os requisitos de sistema que podem ficar omitidos. A técnica consiste
basicamente em o Analista de Requisitos se inserir no ambiente de trabalho para o qual o
sistema será desenvolvido (OLIVEIRA, 2008).
O AR observa o dia a dia de trabalho das pessoas envolvidas, anotando e construindo
imagens de como é o trabalho delas. A etnologia ajuda o AR a descobrir e entender os
requisitos reais e implícitos que o sistema deverá ter (SOMMERVILE, 2008). Portanto, o
etnógrafo deve ser uma pessoa com boa habilidade de observação e transformação dessa
observação em cenários como casos de uso (OLIVEIRA, 2008). Oliveira (2008) comenta que
dentre as diretrizes para a etnografia, deve-se preocupar sempre em procurar formas não
padronizadas de trabalho, tomar nota de forma detalhada de todas as práticas de trabalho,
analisando-as e chegando a uma conclusão e, sempre que possível, combinar a etnografia com
entrevistas abertas e outras técnicas de elicitação.
2.2 Verificação e validação de requisitos
A validação de requisitos tem o intuito de mostrar que os requisitos atendem realmente
ao que o sistema precisa. A validação de requisitos está relacionada à descoberta de
problemas que os requisitos possam ter, evitando-se custos excessivos com retrabalho
(OLIVEIRA, 2008). O custo de correção de requisitos é o maior dentre as outras partes do
processo como projeto ou desenvolvimento, pois um erro de requisito implica que o projeto e
o desenvolvimento á que ser mudados e o sistema deverá ser novamente testado
(SOMMERVILLE, 2008).
Sommeville (2008) comenta que para se ter sucesso no processo de validação de
requisitos, se torna necessária a realização de verificações nos requisitos. Essas verificações
incluem alguns pontos como:
23

Verificar se o sistema está atendendo a todas as necessidades dos
interessados, pois o sistema terá diferentes usuários e cada usuário terá
necessidades diferentes;

Verificar se os documentos (de requisitos) descrevem todos os requisitos e
restrições dos usuários, não gerando conflito entre estes os requisitos;

Verificar se os requisitos podem realmente ser desenvolvidos com a
tecnologia escolhida no prazo e orçamento estipulados, e;

Verificar se a descrição dos requisitos está entendível.
Os problemas encontrados na validação de requisitos não podem ser subestimados.
Conflitos, contradições, erros e omissões nos requisitos devem ser apontados e negociados
entre os interessados para se chegar a uma solução para os problemas identificados
(SOMMERVILLE, 2008).
2.3 Gerenciamento de requisitos
Os requisitos de sistemas de software estão sempre mudando, conforme os
interessados têm novos entendimentos sobre os problemas existentes. Cabe aos ARs adaptar
os requisitos a esses novos entendimentos. Conforme os usuários utilizem os sistemas, novos
requisitos irão surgir (LUIZA e OLIVEIRA, 2008). Luiza e Oliveira (2008) comentam que o
gerenciamento de requisitos consiste em compreender e controlar as mudanças dos requisitos.
O controle deve ser iniciado a partir do momento que se tiver um documento de requisitos
pronto. Os requisitos devem ser acompanhados individualmente, mantendo as ligações dos
requisitos que dependem dos requisitos.
Sommerville (2008) comenta que a mudança de requisitos quando o sistema já está em
operação com o cliente é inevitável. Mudanças no ambiente de trabalho ocorrem e os
requisitos evoluem para atender a essas modificações. Para se gerenciar corretamente essas
mudanças, o planejamento deve ser feito. O AR deve verificar a validade da solicitação de
modificação, as dependências entre os requisitos que podem sofrer modificações, estimar os
custos das mudanças, acordar com os usuários os custos de tal mudança e utilizar ferramentas
para auxiliar na rastreabilidade destes requisitos (LUIZA e OLIVEIRA, 2008).
24
2.3.1
Rastreabilidade de requisitos
A rastreabilidade de requisitos é dita como o centro da atividade de gerenciamento de
requisitos. A técnica consiste em acompanhar o ciclo de vida do requisito. A dificuldade da
técnica, segundo Luiza e Oliveira (2008), está no grande volume de informações que
precisam ser levantadas, associadas e referenciadas, atividade muito complexa que sem o
auxílio de ferramentas não conseguirá ser concluída.
As informações da rastreabilidade são freqüentemente representadas por meio de
matrizes de rastreabilidade (LUIZA e OLIVEIRA, 2008). Nessas matrizes, requisitos são
registrados em uma linha e uma coluna da matriz. As dependências dos requisitos são
registradas na interseção da linha com a coluna (SOMMERVILLE, 2008). A matriz de
rastreabilidade auxilia na manutenção e acompanhamento de requisitos que são criados a
partir de planos de negócios e reuniões com os clientes, pré-rastreabilidade, e dos requisitos
que são criados a partir de artefatos já definidos e códigos, pós-rastreabilidade, (SAYAO e
LEITE, 2005), conforme mostrado na figura 4.
Figura 4 – Rastreabilidade de requisitos. Fonte: Sayão e Leite, 2005.
25
3. SISTEMAS ESPECIALISTAS
O objetivo deste capítulo é explicar o que são sistemas especialistas e sua utilização. É
abordada uma introdução sobre os sistemas especialistas, mostrando a utilização dos mesmos
e comentando o desafio de se criar um sistema especialista. O capítulo está organizado da
seguinte maneira: A seção 3.1 aborda os sistemas especialistas e suas áreas de aplicação do
conhecimento. A seção 3.2 aborda um software gerador de sistemas especialistas, chamado de
Expert Sinta, mostrando como é a sua arquitetura e como é dividido a sua base de
conhecimento.
3.1 Introdução aos Sistemas Especialistas
Sistemas Especialistas (SE’s) são programas capazes de resolver tarefas específicas de
uma área de conhecimento supostamente com a mesma qualidade que um especialista
humano. Os SE’s começaram a ser estudados por volta da década de 60 quando as pesquisas
na área da IA, segundo Reategui (1993), eram bastante audaciosas, pois visavam criar
“resolvedores de problemas” com interfaces em uma linguagem natural. Contudo os
resultados não eram muito satisfatórios. As pesquisas com a IA começaram a ter melhores
resultados a partir do momento em que o foco passou a ser tratar problemas mais restritos de
uma área de conhecimento (REATEGUI, 1993). Assim. começou a ser desenvolvido
programas que reproduzissem o comportamento humano na resolução de problemas do
mundo real (BITTENCOURT, 2006), armazenando, sequenciando informações e autoaprendendo com base nos experimentos práticos impostos pelas situações em estudo
(FIGUEIREDO, 2011).
Figueiredo (2011) comenta que para um SE entrar em funcionamento, o mesmo deve
ser “alimentado” com informações especificas e orientado a executar determinadas tarefas
para a qual se requer o seu uso como também devem ser construídas bases com o
26
conhecimento de um especialista da área ao qual o problema se relaciona, programando as
variáveis usadas e posteriormente simuladas com base no conhecimento do especialista, de tal
forma que ao final o SE seja capaz de oferecer sugestões e conselhos aos usuários e, também,
adquirir novos conhecimentos e heurísticas com essa interação (PY, 2006). Portanto, o estudo
dos problemas que o SE terá de tratar torna-se essencial. Um SE pode ser aplicado nas mais
diversas áreas do conhecimento, como: agricultura, química, sistemas de computadores,
eletrônica, engenharia, gerenciamento de informações, etc. (FIGUEIREDO, 2011).
Contudo, para se criar um SE, é necessário um software que auxilie no processo,
segundo Nogueira e Silva (1997), a construção de um software para a geração de sistemas
especialistas não é fácil, pois o software deve ser capaz de tratar e resolver os problemas da
mesma maneira que um especialista humano quando se depara com algum problema
equivalente. O software também deverá permitir que a captura do conhecimento através de
sua interface seja de fácil utilização, que para manusear o mesmo não seja necessário ter um
conhecimento aprofundado em informática. O Expert SINTA possui todas estas
características e muitas outras, conforme descrito na seção seguinte.
3.2 Expert SINTA
O Expert SINTA é, segundo LIA (1999), uma ferramenta utilizada para geração
automática de sistemas especialistas com o auxílio de técnicas de Inteligência Artificial. Esta
ferramenta possibilita a criação de modelos de representação do conhecimento baseados em
regras de produção e probabilidades, possibilitando uma economia de tempo e simplificação
do trabalho aos desenvolvedores de sistemas especialistas, construção automática de telas e
menus, tratamento das regras de produção e criação de menus de ajuda com explicações sobre
a base de conhecimento modelada (LIA, 1999). Um sistema especialista com este tipo de
modelo é bastante útil em problemas de classificação, pois o usuário responde a uma
sequência de menus e o sistema se encarrega de fornecer respostas que se encaixem no quadro
apontado pelo usuário.
Mendes (1997), afirma que a grande diferença entre um sistema especialista e um
simples programa de banco de dados está no uso de raciocínio lógico para resolução de
problemas. Os sistemas especialistas utilizam regras de produção SE e ENTÃO, seguido por
27
conectivos relacionados dentro do âmbito do assunto em questão e o uso da probabilidade. A
estrutura básica de um sistema especialista é a interface com o usuário, o motor de inferência,
e a base de conhecimento.
3.2.1
Arquitetura de um sistema especialista no Expert SINTA
O Expert SINTA tem como objetivo simplificar as etapas de criação de um SE
completo, oferecendo uma máquina de inferência básica, fundamentada no encadeamento
para trás. O encadeamento para trás é utilizado em problemas que possuem um número muito
grande de soluções, mas os meios pelos quais as respostas são alcançadas são restritos (LIA,
1999).
Os SE’s gerados no Expert SINTA tem sua arquitetura composta basicamente pelos
seguintes componentes:

Bases de conhecimentos;

Editor de bases;

Máquina de inferência;

Banco de dados global.
Tais componentes estão interligados, conforme exemplificado na figura 5.
Figura 5 – Arquitetura Simplificada do Expert SINTA. Fonte: Lia, 1999.
28
Flores (2003) e LIA (1999) definem cada um dos componentes da seguinte maneira:

Base de conhecimento: encontra-se o conhecimento do especialista,
dividido entre fatos e regras, modelado de acordo com o domínio de
representação computacional;

Editor de bases: é o meio em que ocorre a implementação das bases
desejadas. É responsável pela atualização da base de conhecimentos;

Máquina de inferência: é a parte do SE responsável pelas deduções sobre a
base de conhecimentos, examinando o conteúdo da base de conhecimentos
e decidindo a ordem das inferências;

Banco de dados global: Possui as evidências apontadas pelo usuário do
sistema especialista durante uma consulta.
3.2.2
Representação do Conhecimento
Parte mais sensível e crítica no desenvolvimento de um SE (NOGUEIRA e SILVA,
1997; BITTENCOURT, 2006), a representação do conhecimento não se limita apenas a
adicionar novos elementos à base de conhecimentos, mesclando os novos conhecimentos,
com os conhecimentos já armazenados na base (BITTENCOURT, 2008). A representação do
conhecimento, segundo Diehl (2000), constitui de um conjunto de mecanismos utilizados no
armazenamento e manipulação do conhecimento, modelando de forma eficiente ao ponto de
serem utilizados em um sistema inteligente.
Existem várias formas de se modelar o conhecimento de um especialista, tais como,
lógica matemática, regras de produção, raciocínio baseado em casos, redes probabilísticas,
entre outros (FLORES, 2003; DIEHL, 2000). As mais utilizadas, segundo Nogueira e Silva
(1997), são as regras de produção (ou regras de realização), que utilizam a teoria das
probabilidades, garantindo assim uma maior legibilidade da base de conhecimentos.
29
3.2.2.1 Regras de Produção
Uma regra em si é um conjunto de premissas, normalmente escritas com sintaxe
próxima à linguagem natural, que realizam as conclusões indicadas na mesma. Estas regras
têm o formato SE - ENTÃO, permitindo-se o uso dos conectivos lógicos (E, OU, NÃO, e
outros desejados).
Como por exemplo:
1. SE cliente tem cadastro em outras locadoras = sim
2. OU reside no mesmo endereço a mais de 5 anos = sim
3. E situação = adimplente
4. ENTÃO crédito = liberado sem perdas [90%]
O “SE” é o corpo da regra, também conhecido como parte antecedente ou lado
esquerdo, avaliado em relação à base de conhecimento como um todo. Existindo o ajuste, é
feito uma busca no mecanismo de avaliação pela ação correspondente especificada no lado
direito, ou a parte consequente, é executada. As condições na parte antecedente da regra
devem ser satisfeitas para que a ação, na parte consequente, seja considerada. Se qualquer
premissa falhar, o lado direito também falha (DIEHL, 2000; NOGUEIRA e SILVA, 1997).
As regras de produção possuem algumas vantagens, segundo LIA (1999), como:

Modularidade: cada regra pode ser considerada como uma peça de
conhecimento independente;

Facilidade de edição: novas regras podem ser incluídas e regras antigas
podem modificadas com relativa independência;

Transparência do sistema: garante maior legibilidade das bases de
conhecimentos.
Resumindo, uma regra é um par ordenado de símbolos que representa algum
conhecimento sobre um determinado assunto (DIEHL, 2000). Uma das grandes vantagens da
30
utilização de regras é a facilidade na demonstração de como se chega à solução através do
rastreamento das regras pela máquina de inferência (NOGUEIRA e SILVA, 1997).
Quando se estiver criando bases de conhecimento com o Expert SINTA devem ser
levados em consideração alguns critérios na estrutura das premissas e conclusão das regras,
conforme descrito por Diehl (2000):

<CONECTIVO>
O modelo para cada premissa deve seguir a seguinte estrutura:
<ATRIBUTO>
<OPERADOR>
<VALOR>
 Conectivo: São os elementos (E, NÃO, OU) utilizados para unir a
sentença ao conjunto de premissas que formam a seção de
antecedentes de uma regra;
 Atributo: É uma variável capaz de assumir um ou uma lista de
valores no decorrer da consulta à base de conhecimento;
 Operador: São as ligações entre o atributo e o valor da premissa,
definindo o tipo de comparação a ser realizada. Os operadores
podem ser: =, >, <=, >=, <>, entre outros;
 Valor: é um item de uma lista, a qual foi previamente criada e
relacionada a um atributo.

Já a estrutura da conclusão deve seguir o seguinte modelo, conforme
Nogueira e Silva (1997):
<ATRIBUTO>
=
<VALOR>
<GRAU DE CONFIANÇA>
 Atributo: Mesmo atributo utilizado nas premissas;
 “=”: é um operador de atribuição. O atributo receberá o valor que
lhe está sendo atribuído;
 Valor: Mesmo valor utilizado nas premissas;
 Grau de confiança: Percentual indicando a confiabilidade da
conclusão da regra com base nas premissas. Varia de 0% à 100%.
31
3.2.2.2 Cálculo Probabilístico dos Sistemas Especialistas
Para se efetuar o tratamento do raciocínio, evidência e aquisição automática de
conhecimento, um sistema especialista necessita de um mecanismo para se tratar destes
problemas. Nogueira e Silva (1997) exaltam o Expert SINTA como a ferramenta ideal para
este tipo de situação, pois segundo os mesmos, o Expert Sinta utiliza a teoria das
probabilidades em conjunto com a teoria das possibilidades na resolução dos problemas de
forma automática e transparente ao usuário.
Examinando uma das cabeças da regra mostrada como exemplo na seção anterior,
verifica-se a presença de um grau de confiança na decisão de que a liberação do crédito pode
ser efetuada. Contudo um ponto critico está no grau de confiabilidade da regra imposto pela
da base de conhecimento estar apenas em 90%, sem levar em consideração a confiabilidade
das demais premissas, levantando assim a dificuldade de se representar a confiabilidade das
seguintes informações, segundo Lia (1999):

Os
especialistas
humanos
não
utilizam
estimativas
definidas
matematicamente;

Os resultados gerados através de cálculos matemáticos de probabilidade
nem sempre são a melhor resposta para aquela aplicação prática.
O Expert SINTA modela os tratamentos probabilísticos utilizando quatro casos como
base onde o cálculo varia de acordo com o objetivo que se deseja podendo ser para se
descobrir o valor final atribuído a uma regra, calcular o grau de confiança quando se tem o
operador E embutido na regra ou calcular o grau de confiança quando se tem o operador OU
na regra. Para melhor exemplificar os casos disponíveis no Expert SINTA, será mostrado o
cálculo utilizando as regras retiradas da base do Sistema Especialista de Requisitos,
SISREQUI.
32
Caso 1: Quando queremos saber o valor final atribuído às variáveis na conclusão de
um regra (LIA, 1999).
O grau de confiança de uma regra R, será o número atribuído a C1 ao final da
premissa de R, onde na conclusão de R, temos expressões como “Var = value CNF C2”.
Onde:

Var é uma variável;

value é um termo qualquer que pode ser substituído pela variável;

C2 é um número real no intervalo de 0 a 100, que representa o grau de
confiança da atribuição;
O resultado final e dependente da premissa, pois “C2” é apenas uma referência. Assim
a operação a ser realizada é “Var = value CNF C1*C2”.
Como por exemplo:
Figura 6 – Exemplo de tratamento probabilístico do caso 1.
Então, na execução da regra mostrada na figura 6, o usuário digitando o grau de
confiança da premissa “Problemas no desenvolvimento do sistema” = sim com 80%, tem-se
que o atributo “Para esta situação o mais indicado é” receberá o valore “Verificar se o
documento de Requisitos está claro”, com o respectivo grau de confiança da regra de 60%. O
valor final da regra atribuída pelos valores fornecidos e obtido pelo cálculo = 0.80 * 0.60 =
0.48 = 48%.
33

Caso 2: Cálculo do grau de confiança com o conectivo E (LIA, 1999).
A regra possuindo duas igualdades var1 = value1 e var2 = value2, com os respectivos
graus de confiança c1 e c2, temos a sentença var1 = value1 E var2 = value2, ficando como
valor de confiança o resultado a multiplicação de C1 por C2.
Como por exemplo:
Figura 7 - Exemplo de tratamento probabilístico do caso 2.
Ao executar a regra da figura 7, digamos que o grau de confiança para “Projeto
Complexo” = Sim é 60% e o grau de confiança pra “Problemas no desenvolvimento do
sistema” = sim é 90%. Chega-se ao valor de 56%, obtido pelo seguinte cálculo 0.60*0.90 =
0.54. Com o valor do cálculo entre as premissas, agora se multiplica pelo grau de confiança
da regra de 80%, ficando o valor final da regra em 43,2%.

Caso 3: Cálculo do grau de confiança com o conectivo OU (LIA, 1999).
Possuindo duas igualdades var1 = value1 e var2 = value2, com seus respectivos graus
de confiança c1 e c2, obtêm-se a sentença var1 = value1 OU var2 = value2. O valor de
confiança é obtido com o seguinte cálculo c1 + c2 – (c1* c2).
Como por exemplo:
34
Figura 8 - Exemplo de tratamento probabilístico do caso 3.
Na execução da regra exemplificada na figura 8, digamos que o valor para o grau de
confiança da igualdade “Projeto Complexo” = sim é 80% e o grau de confiança da igualdade
“Requisitos Claros” = sim é 90%, então obtêm-se um valor de 98%, através do seguinte
cálculo ((0.80 + 0.90) – (0.80 * 0.90)) = (1.7 - 0.72) = 0.98. Como valor das premissas, o
passo seguinte e multiplica-lo com o grau de confiança da regra de 70%, obtendo o valor final
da regra de 68,6%.

Caso 4: Cálculo do grau de confiança com o conectivo NÃO (MATOS, 2011).
Negando uma ou mais igualdades var = value, com seus respectivos graus de
confiança c, obtêm-se a sentença “NÃO var = value”. O valor de confiança é obtido com o
seguinte cálculo: (1 – c).
Como por exemplo:
Figura 9 - Exemplo de tratamento probabilístico do caso 4.
35
A regra mostrada na figura 9 possui o grau de confiança de 90% fornecido pelo
usuário para o atributo “Cliente tem certeza sobre os Requisitos” = Sim, mas como a premissa
foi negada inicialmente com o operador NÃO, o valor real da premissa será 10%, de acordo
com o cálculo 1 – 0.90. Com o resultado da premissa, aplicasse a regra do caso 2, pois na
premissa seguinte possui o conectivo E. O valor do atributo “Envolvidos no projeto com total
entendimento” e de 60%. Ao final do calculo entre as premissas, 0.10 * 0.60, chegasse ao
valor de 6%. Já o valor final da regra será o valor o grau de confiança das premissas 6%
multiplicado pelo grau de confiança da regra de 40%. Chegando ao valor final de 24%.
A partir dos casos base de modelagem de tratamento probabilístico, mostrados,
podem-se criar vários outros casos simplesmente acrescentando conectivos diferentes em uma
mesma regra, lembrando que a ordem de prioridade dos conectivos é: NÃO primeiro, seguido
do E, e após o OU. Vale lembrar também que toda regra possui um objetivo final, mas com o
Expert SINTA é possível ter mais de um objetivo na mesma regra. A ferramenta efetua o
cálculo do grau de confiança das premissas e, ao final, multiplica o valor encontrado por cada
um dos objetivos da regra. Como por exemplo, na regra abaixo retirada da base de
conhecimento do SISREQUI.
Figura 10 - Exemplo de regra com mais de um objetivo.
Conforme mostrado na figura 10, a regra 50 possui três objetivos onde cada um possui
seu respectivo grau de confiança. Para exemplificar melhor daremos para cada atributo os
36
seguintes valores na mesma ordem dos atributos: 80 %, 90%, 50 % e 70%. Para o cálculo das
premissas, como em todas possui apenas o conectivo E, se aplica apenas a regra do caso 2,
obtendo em seguida o valor de 25,2 %. Em seguida, o Expert SINTA irá multiplicar o valor
de 25,2 % por cada um dos objetivos da regra, chegando ao seguintes valores:

Para esta situação o mais adequado
 Negociar mais tempo com o cliente. 17,64%, referente ao cálculo
de 25,2% * 70%;
 Validar com o cliente o requisito coletado. 17, 64 %, referente ao
cálculo de 25,2% * 70%;

Técnica de Elicitação de Requisitos mais adequada
 Etnografia. 22,68%, referente ao cálculo de 25,2% * 90%.
37
4. SISTEMA ESPECIALISTA PARA AUXÍLIO NO PROCESSO DA ENGENHARIA
DE REQUISITOS
O objetivo deste capítulo e mostrar o processo de criação do sistema especialista para
a disciplina de requisitos, discutindo as etapas básicas na elaboração do sistema especialista, a
implementação do sistema e as consultas do mesmo. O capítulo está organizado da seguinte
maneira: A seção 4.1 aborda sobre o projeto do SISREQUI, com o estudo de viabilidade e a
formalização do conhecimento. A seção 4.2 aborda sobre a implementação do SISREQUI e a
seção 4.3 aborda os resultados alcançados com o SISREQUI.
4.1 Projeto SISREQUI
Os Sistemas que são da área científica não possuem uma usabilidade e interface
amigável com o usuário. Nos dias atuais as ferramentas que possibilitam uma fácil interação
entre homem e máquina, ajudam no aumento da produtividade e no rápido desenvolvimento
no processo de criação de um software. Boa parte das ferramentas hoje disponíveis para a
criação de sistemas especialistas, não possibilitam que ocorra uma maior comunicação entre o
responsável pela criação do sistema especialista.
A ferramenta que irá auxiliar na criação de um sistema especialista deve ter uma fácil
utilização, possuindo uma interface autoexplicativa, permitindo que qualquer pessoa
familiarizada com um computador possa criar o conhecimento especializado de acordo com a
linguagem de representação do conhecimento disponível (BITTENCOURT, 2006).
Com o Expert SINTA é possível criar rapidamente todas as variáveis e seus possíveis
valores, como também os objetivos do sistema para, em seguida, iniciar a criação das regras
de produção, conforme verificado na figura 11.
38
Figura 11 – Ambiente do Expert SINTA. Fonte: Lia, 1999.
Assim como o Expert SINTA, existem outras ferramentas que ajudaram segundo
Bittencourt (2006), na disseminação dos sistemas especialistas, denominadas Arcabouços de
Sistemas Especialistas, ASE. Os ASE’s dividem os SE’s entre a ferramenta de criação do
conhecimento que define as regras e aspectos operacionais, do conhecimento de domínio.
4.1.1
Estudo de viabilidades
Criar um sistema especialista para auxiliar em processos complexos como o da
disciplina de Engenharia de Requisitos não pode ser resolvido facilmente. Por isso serão
utilizados como base na criação do sistema as metodologias utilizadas por autores que tem um
embasamento muito mais profundo sobre sistemas especialistas, tais como Nogueira e Silva
(1997), LIA (1999) e Bittencourt (2006).
As metodologias utilizadas pelos autores consistem em saber se “o sistema especialista
é a resposta na resolução de um problema”. Nogueira e Silva (1997) afirmam que se torna
necessário na definição da resposta, os seguintes parâmetros:
39

A tarefa não necessita de senso comum? Já que computadores têm uma
enorme dificuldade em lidar com senso comum. Mas sistemas
especialistas são quase que totalmente desprovidos de bom senso, então
não sofrem grandes prejuízos ao tratarem do assunto (NOGUEIRA E
SILVA, 1997);

Existem modos de formalização para o conhecimento desejado? O sistema
deve ser validado por diversos especialistas no assunto (NOGUEIRA E
SILVA, 1997);

Existem especialistas disponíveis que possam colaborar com o
desenvolvimento do sistema? Presença ativa de profissionais com alto
grau de conhecimento do problema em estudo é vital para obtenção de
resultados funcionais (NOGUEIRA E SILVA, 1997);

A aplicação é relevante? O sistema só valerá a pena se o mesmo não for
para resolução de tarefas triviais ou de pouca importância (NOGUEIRA E
SILVA, 1997).
Também deve ser levado em consideração o público alvo, afinal de contas o sistema
tem como missão validar uma informação da mesma forma que um especialista humano,
treinar novos analistas com as melhores respostas dos principais problemas já vivenciados por
outros especialistas.
Para se chegar a estes objetivos se torna necessária uma boa
formalização do conhecimento, conforme descrito a seguir.
4.1.2
Formalização do Especialista em Engenharia de Requisitos
O grande problema na criação de um sistema especialista está na dificuldade de se
conseguir elaborar corretamente o conhecimento dos especialistas. Nogueira e Silva (1997)
indicam uma boa entrevista com os especialistas da área em que esteja querendo coletar as
informações, pois segundo os mesmos é difícil se criar regras com base nas conclusões feitas
pelos Especialistas, quando os mesmos lidam com novas situações, onde se torna necessário,
uma boa experiência ou até mesmo na dificuldade de comunicação quando se utiliza muitos
termos técnicos.
40
Por causa dos problemas descritos acima, foram utilizados na formalização do
conhecimento para a base do SISREQUI, dois métodos para extração do conhecimento dos
especialistas em requisitos. Os métodos são os seguintes:

O Método da Observação, onde o desenvolvedor do sistema especialista
deve assistir ao dia a dia de trabalho de um especialista na resolução dos
problemas (NOGUEIRA E SILVA, 1997);

Método Intuitivo, onde é feito um estudo e interação tanto com o
especialista em requisitos quanto com a literatura básica sobre o assunto
(NOGUEIRA E SILVA, 1997).
Além dos métodos de observação e intuitivo descritos acima, também foi elaborado
um questionário com alguns problemas típicos do dia a dia de um analista de sistema, e
enviados a alguns Analistas para que os mesmos dessem suas contribuições. A formalização
do conhecimento utilizado na criação da base de conhecimento do SISREQUI é descrita com
maiores detalhes na seção 4.1.3.
4.1.3
Aquisição de conhecimento
O SISREQUI é um sistema especialista voltado a suporte na resolução de problemas
relacionados a conceitos da engenharia de requisitos. Seu principal objetivo e o de auxiliar a
analista de requisitos, analistas de sistemas e analistas de negócio na correta aplicabilidade
dos conceitos da engenharia de requisitos, podendo também ser utilizado como treinamento a
novos membros de uma equipe responsável pela coleta de requisitos. A modelagem do
conhecimento requer uma série de refinamento (NOGUEIRA E SILVA, 1997) aumentando a
imparcialidade das respostas do sistema.
O refinamento do conhecimento, obtido com as técnicas descritas na seção 4.1.2,
sobre requisitos utilizados na versão inicial do SISREQUI feito da seguinte maneira:

Método da Observação
41
 Foi observado durante um período de 5 meses a rotina de trabalho
de especialistas em requisitos nas empresas de desenvolvedoras de
software, analisando e documentando o trabalho dos especialistas.

Método Intuitivo
 A partir do levantamento bibliográfico sobre a disciplina de
requisitos de software foi feito um documento com as melhores
práticas sobre o assunto descrito pelos autores. O Documento
possuía algumas frases, que se tornaram as variáveis da
SISREQUI, que abordavam diversos temas relacionados a
disicplina.

Questionário
 As perguntas contidas no questionário eram voltadas as melhores
práticas no processo de requisitos, abordando sobre as técnicas de
elicitação, validação e gerenciamento. O questionário serviu como
base para a criação do grau de confiança atribuído aos objetivos
das regras.
4.2 Implementação do SISREQUI
Em LIA (1999), é descrito a praticidade e facilidade que o Expert SINTA, proporciona
ao desenvolvedor do sistema especialista na implementação da base de conhecimento
desejada. Uma base de conhecimento no Expert SINTA envolve os seguintes conjuntos de
atributos que devem ser criados na base:

Variáveis são os atributos que serão utilizados nas regras;

Regras são formadas por um conjunto de premissas com um grau de
confiança;

Perguntas são variáveis que irão aparecer ao usuário como forma de
perguntas;

Objetivos são variáveis que irão estar na conclusão das regras;

Informações adicionais, local onde são colocados as informações de
apresentação do sistema especialista, nome do sistema e nome dos autores.
42
Só quando esses elementos estiverem definidos, se torna possível utilizar o sistema
especialista.
4.2.1
Implementando o sistema
Com a base de conhecimento já levantada, deve-se abrir o Expert SINTA e criar uma
nova base de conhecimento, através do Menu  Arquivo  Nova base. Conforme figura 12.
Figura 12 – Criando uma nova Base de Conhecimento no Expert SINTA.
O Expert SINTA, inicialmente irá abrir uma nova janela, denominada Knowledge-ina-box, KIB (LIA, 1999). Com a KIB aberta, é possível elaborar todos os elementos
necessários para o Sistema Especialista. Conforme figura 13.
43
Figura 13 – Janela KIB. Fonte: Lia, 1999, Modificado.
4.2.1.1 Base de conhecimento
Na criação da base de conhecimento do SISREQUI, é necessária primeiramente a
criação das variáveis que serão utilizadas no sistema. Dessas variáveis devem ser separadas as
que irão se tornar objetivos e as que serão as perguntas, para finalmente dar início a criação
das regras de produção que serão utilizadas no sistema. Todo o processo de criação das
variáveis, separação das variáveis objetivos das variáveis perguntas e criação das regras será
explicado na seção seguinte.
4.2.1.1.1
Variáveis
A criação de variáveis do SISREQUI pelo Expert SINTA é bastante simples. Após ter
definido quais serão os problemas ou situações mais vivenciadas por especialistas em
requisitos de software, basta a partir da janela KIB, selecionar o botão Variáveis. Logo em
seguida irá ser carregada a janela de criação e edição de variáveis conforme figura 14.
44
Figura 14 – Janela de criação de variáveis. Fonte: Lia, 1999, Modificado.
Onde:
1:
Referisse a campo onde serão exibidas as variáveis que o sistema terá;
2:
Será exibido o valor referente a uma determinada variável;
3:
Campo de descrição com o nome da variável;
4:
Campo com o valor que a variável terá;
5:
O botão com formato de “V”, serve para confirmar a inclusão ou alteração
da variável. Enquanto o no formato de “X” cancela a alteração ou
inclusão;
6:
Tipos das variáveis, onde:
 Numérica: Não podem ter valores pré-definidos. Será exibido o
intervalo de números reais no formato a;b. Onde “a” deve ser
menor ou igual a “b”;
 Multivalorada: São variáveis que podem assumir vários valores,
onde estes valores são exibidos em forma de listagem ao lado do
nome da variável;
 Univalorada: Variáveis lógicas que só podem receber um valor por
vez, 0-Sim, 1-Não. Por padrão o Expert SINTA cria as variáveis
como univaloradas;
7:
Botões de criação e exclusão de variáveis e seus valores.
45
LIA (1999), aconselha a nunca mudar o tipo de uma variável não numérica para
numérica, pois pode implicar em perda de valores ou mesmo excluir alguma variável ou seu
valor, pois esta exclusão irá invalidar qualquer regra que esteja com aquela variável.
Após definir todas as variáveis, seus tipos e valores, o próximo passo na criação do
SISREQUI é separar das variáveis criadas, quais serão os objetivos nas regras.
4.2.1.1.2
Objetivos
O objetivo em uma regra, é a resposta que um especialista daria como solução a
determinado problema (LIA, 1999). A diferença é que no Expert SINTA os problemas são
representados por variáveis que por sua vez se tornam variáveis objetivos. O SISREQUI,
assim como qualquer sistema especialista, antes de sua execução necessita que sejam
definidas quais são as suas variáveis objetivos, pois sem esta definição, seria o mesmo que
perguntar alguma coisa a um especialista e o mesmo não a responder (LIA, 1999).
A determinação dos objetivos é feita a partir da janela KIB, selecionado a opção
Objetivos. Em seguida aparecerá uma janela com uma lista contendo as variáveis comuns e
outra com as variáveis objetivos, conforme mostrado na figura 15.
Figura 15 – Janela de seleção de variáveis objetivos do SISREQUI. Fonte: Lia, 1999, Modificado.
46
Ao definir as variáveis objetivos, o próximo passo é a criação da interface com o
usuário. A interface é a forma como as variáveis irão ser exibidas aos usuários do sistema, e
como serão feitas as perguntas aos usuários.
4.2.1.1.3
Interface com o usuário
O SISREQUI se comunica com o usuário final através de menus de múltipla escolha.
Os menus são construídos automaticamente pelo Expert SINTA, restando apenas ao criador
do sistema especialista definir as variáveis perguntas e para cada variável pergunta criar uma
questão e um motivo de ajuda, que irá auxiliar o usuário quando o mesmo não souber sobre
do que se trata a pergunta (LIA, 1999).
Na janela de seleção e criação de perguntas do Expert SINTA, figura 16 aparece as
variáveis criadas em um lado e as variáveis perguntas do outro. O Expert SINTA não proíbe
que uma variável definida como objetivo se torne uma variável pergunta, ele não permite e
que esta mesma variável seja referenciada em uma regra como variável pergunta e objetivo.
Figura 16 – Janela de seleção de variáveis perguntas do SISREQUI. Fonte: Lia, 1999, Modificado.
Com a seleção das variáveis, a criação das perguntas e definição dos motivos para o
SISREQUI, o próximo passo e o mais complexo é a criação das regras de produção com seus
respectivos graus de confiança.
47
4.2.1.1.4
Regras
A modelagem do conhecimento no Expert SINTA é feita através das regras de
produção. Na janela KIB, aparecem todas as regras que o sistema tem. A criação de regras é
iniciada a partir da seleção da opção “Nova Regra” na janela KIB (LIA, 1999), surgindo em
seguida uma tela informando a ordem da regra, que se refere ao número da regra, e o modelo,
referente à criação de uma nova regra com as mesmas informações de uma já criada,
conforme figura 17.
Figura 17 – Caixa de seleção de Ordem e modelo de regra. Fonte: Lia, 1999.
A tela seguinte, caso não seja selecionado nenhum modelo de regra, virá apenas com a
estrutura “SE”, “ENTÃO”, conforme figura 18.
Figura 18 – Tela de criação de regra de produção. Fonte: Lia, 1999.
48
A partir dela, se torna possível a criação da regra que irá compor o sistema.
Lembrando que a criação da regra, deve possuir a mesma estrutura abordada na seção de
regras de produção do capítulo anterior. No Expert SINTA, as variáveis criadas e definidas
como perguntas, serão os atributos das regras. E são inseridas no bloco correspondente à
silaba “SE”. As variáveis Objetivos devem ser inseridas no bloco correspondente à silaba
“ENTÃO”. Para incluir uma variável, primeiramente deve-se selecionar a opção “Incluir”.
Após a escolha, será exibida uma caixa de seleção com o item de regra, onde o mesmo é uma
lista contendo todas as variáveis criadas, o operador e o valor que irá receber aquela variável.
Após ser inserida a primeira premissa da regra, o Expert SINTA permite que sejam inseridos
os conectivos “E” e “OU”; o “NÃO” já é liberado para ser utilizado na primeira premissa.
Figura 19 – Tela de inserção de premissas. Fonte: Lia, 1999.
Inseridas todas as premissas do bloco “SE”, o próximo passo é inserir o objetivo da
regra, bloco “ENTÃO”. A caixa de seleção do bloco é um pouco parecida com a anterior, só
que nesta tela é selecionado apenas o objetivo da regra, o seu respectivo valor e seu graus de
confiança, conforme figura 20.
Figura 20 – Tela de inserção de objetivos. Fonte: Lia, 1999.
Se por ventura se chegar a errar na criação de alguma regra, seleciona-se a premissa e
clica na opção alterar. Após a criação das regras, o SISREQUI já esta com sua base de
conhecimento completa, restando apenas consulta-la e verificar os resultados alcançados.
49
4.2.1.2 Informações adicionais
Antes de executar o SISREQUI, se torna necessário criar uma tela de abertura para o
sistema. A criação da tela foi através da opção Informações da janela KIB. A opção abriu uma
tela onde foi possível inserir o nome do Sistema, assim como os autores e uma breve
descrição sobre o SISREQUI, conforme figura 21.
Figura 21 – Janela de informações adicionais do SISREQUI. Fonte: Lia, 1999, Modificado.
LIA (1999), comenta que também é possível a criação de arquivos de ajuda online,
definir preferências na execução dos conectivos, formulas matemáticas e proteção por senha
para o sistema especialista.
Em uma versão futura do SISREQUI, poderá ser agregada algumas destas
funcionalidades presentes no Expert SINTA.
4.3 Consultando o SISREQUI
Antes de mostrar as consultas, primeiramente serão mostrados alguns comandos
básicos do Expert SINTA, ou, conforme Lia (1999), um conjunto de operações básicas.
50
Existem dois menus de acompanhamento de consultas no Expert SINTA (LIA, 1999), mas
este trabalho se focou em explicar o menu já presente na barra de ferramentas do Expert
SINTA, conforme mostrado na figura 22.
Figura 22 – Menu de controle de consultas. Fonte: Lia, 1999.
4.3.1
Consultas
Iniciando a consulta, a primeira tela que irá aparecer será a tela de abertura do sistema.
A tela mostra uma pequena descrição sobre o SISREQUI, figura 23.
Figura 23 – Tela de abertura do SISREQUI.
51
Após a tela de abertura irão aparecer as perguntas criadas. A base de conhecimento do
SISREQUI possui 50 regras e foi elaborada com variáveis univaloradas, então as perguntas
irão aceitar apenas uma opção a ser selecionada, que conforme seja selecionada permite ao
sistema solicitar qual o grau de confiança naquela resposta, conforme mostrado nas figuras 24
e 25.
Figura 24 – Interface SISREQUI.
Figura 25 – Resposta do SISREQUI com respectivo grau de confiança.
Contudo, caso o analista que esteja utilizando o SISREQUI, não saiba o que a
pergunta significa, basta consultar a ajuda selecionando a opção “Por que?”. O SISREQUI irá
mostrar ao analista o porque de estar fazendo aquela pergunta, conforme figura 26.
52
Figura 26 – Tela de ajuda do SISREQUI.
Mas se mesmo com a tela de ajuda o Analista não souber como responder a pergunta,
simplesmente poder passar a pergunta só escolhendo a opção “OK”. Independente da escolha,
o SISREQUI irá auxiliar o Analista na melhor maneira.
4.3.2
Acompanhamento
O acompanhamento das consultas do SISREQUI pode ser feito através do depurador.
O depurador exibe uma caixa de listagem com todas as regras que formam a base de
conhecimento do sistema (LIA, 1999), destacando a premissa que está sendo analisada pela
maquina de inferência naquele momento, conforme mostrado na figura 27.
53
Figura 27 – Execução do SISREQUI pelo modo depurador.
Para utilizar o modo depurador o analista deve executar o SISREQUI apertando a tecla
F8, e para cada resposta efetuada, continuar apertando a tecla. Assim e possível ver como o
SISREQUI funciona na escolha das regras.
4.3.3
Janela de Resultados Atingidos
Ao final de uma busca de objetivos, o SISREQUI apresenta uma janela de resultados.
LIA (1999), comenta que esta janela se divide em quatro partes:

A de resultados, onde são apresentados todos os objetivos atingidos, com
seus respectivos graus de confiança, conforme mostrado na figura 28;

Histórico: onde é exibido todo o caminho realizado pelo sistema
especialista até atingir a solução, conforme mostrado na figura 29;

Todos os valores: que é uma generalização da primeira página, pois exibe
todos os valores de todas as variáveis do SISREQUI, conforme figura 30;
54

O sistema: onde exibe todas as regras contidas no SISREQUI, mostrado na
figura 31.
Figura 28 – Tela de Resultados.
Figura 29 – Arvore de pesquisa.
55
Figura 30 – Todos os resultados.
Figura 31 – Regras do SISREQUI.
56
O SISREQUI possui em sua versão atual, quatro objetivos onde os tópicos abordados
em cada um deles e o seguinte:

Para esta situação o mais adequado é, trata as melhores práticas sobre
requisitos de software definidas por autores consagrados como
Sommeville (2008) e Pressman (2005);

Técnica de Elicitação Requisitos mais adequada, aborda sobre as melhores
técnicas de elicitação de requisitos de acordo com levantamento feito por
especialistas na área e autores consagrados como Sommeville (2008) e
Pressman (2005);

Validação de Requisitos mais adequada, trata sobre as melhores técnicas
de validação de requisitos de acordo com levantamento feito por
especialistas na área e autores consagrados como Sommeville (2008) e
Pressman (2005);

Técnica de Gerenciamento de requisitos mais adequada, aborda sobre as
melhores técnicas de gerenciamento de requisitos de acordo com
levantamento feito por especialistas na área e autores consagrados como
Sommeville (2008) e Pressman (2005).
A disciplina de requisitos por ser muito complexa e lidar muito com o senso comum,
se torna necessário garantir a relevância da base do SISREQUI.
4.3.4
Garantindo a relevância do SISREQUI
A garantia da funcionalidade na versão atual do SISREQUI tem o intuito de verificar
se os objetivos sugeridos pelo sistema realmente ajudaram os analistas em suas rotinas de
trabalho. Para efetuar os testes, foram aplicados a partir de projetos complexos já concluídos
ou em processos de conclusão.
O primeiro teste, figura 32, efetuado com o sistema foi em relação a um projeto já
concluído. O intuito foi verificar se os objetivos que SISREQUI chegou, atingiram qual o
porcentagem em relação à solução adotada pelos analistas para se chegar à conclusão do
sistema. No momento do teste foram levadas em consideração as situações que ocorreram na
57
época que o projeto estava sendo elicitado e desenvolvido. O segundo teste, figura 33, foi
aplicado em um projeto ainda em desenvolvimento. O intuito do teste foi verificar se os
objetivos atingidos pelo SISREQUI satisfazem as necessidades nos analistas no projeto.
Figura 32 – Gráfico de teste do SISREQUI em projetos concluídos.
Figura 33 – Gráfico de teste do SISREQUI em projetos não concluídos.
58
Após analisar os resultados dos testes detectaram-se quais os objetivos do SISREQUI
estão mais próximos dos utilizados pelos analistas e quais precisam ser melhorados, conforme
figura 34.
Figura 34 – Média de resultados.
59
5. CONCLUSÕES
A popularização dos sistemas especialistas vem da facilidade na construção dos
mesmos. Tudo isso graças a criação das ferramentas que auxiliam no processo de construção
dos sistemas. Estas ferramentas que possuem mecanismos de raciocínio incerto despertou o
interesse de estudos e pesquisas. No decorrer dos estudos e criação do projeto, foi possível
perceber que existem poucas ferramentas que deem suporte na criação dos sistemas
especialistas e modo interativo com o usuário. O curto tempo necessário também
impossibilitou que fosse sugerida a criação de uma melhoria para a ferramenta utilizada na
criação do sistema especialista. No entanto para se conseguir gerar a primeira versão do
sistema, foram necessários estudos relacionados a sistema especialistas, como sua história,
seus principais conceitos. Também foi necessário pesquisar sobre engenharia de requisitos,
estudo esse que forneceu as bases do conhecimento necessárias para conclusão do trabalho.
Para se chegar aos objetivos finais do trabalho foi necessária uma série de entrevistas com
especialistas na área, além-observações e estudo dos principais autores sobre o assunto além
de testes para garantir a funcionalidade da base do SISREQUI.
Como contribuições acadêmicas e científicas, este trabalho abordou a criação de
um sistema especialista para a disciplina de requisitos de software com o auxílio de uma
ferramenta geradora de Sistemas especialistas, com base em um referencial teórico e prático
que contempla os principais conceitos da disciplina. É válido destacar que o sistema necessita
sempre ter sua base de conhecimento alimentada, com novas informações, conforme for
sendo utilizado e corrigido as suas falhas. Papel este que rende estudos aprofundados em
várias universidades e centros de pesquisas do mundo inteiro tanto na área de requisitos de
softwares como em sistemas especialistas. É esperado que este trabalho possa auxiliar
também esses estudantes e pesquisadores.
60
Como trabalhos futuros sugerem-se melhorar a base de conhecimento do
SISREQUI melhorando a imparcialidade de seus objetivos e incluir novos objetivos que na 1ª
versão acabaram não sendo tratados.
61
REFERÊNCIAS BIBLIOGRÁFICAS
APARECIDO, Edinelson Batista; CARVALHO, Ariadne M. B. R. Uma Taxonomia
Facetada para Técnicas de Elicitação de Requisitos. 2002. Disponível em: <
http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER03/edinelson_batista.pdf>.
Acessado em 09 Set. 2010.
BECK, K. Et al. Manifesto for Agile Software Development. 2001. Disponível em:
<http://www.agilemanifesto.org/>. Acesso em: 12 Agos. 2010.
BITTENCOURT, Guilherme. Inteligência Artificial: Ferramentas e Teorias. 3. ed. UFSC:
Florianópolis, 2006. 371 p..
BITTENCOURT,
Guilherme.
Sistemas
Especialistas.
2008.
Disponível
em:
<
https://disciplinas.dcc.ufba.br/pastas/MATA64/Tutoriais/siesp.pdf>. Acesso em: 12 Fev.
2011.
CAMPELO, Pablo Rodrigo Alves. Engenharia de Requisitos para Aplicações WEB.
Recife: UFPE, 2009. 28 p. Trabalho de Pós-Gaduação, Centro de Informática, Universidade
Federal
de
Pernambuco,
Recife,
2009.
Disponível
em:
<
http://www.cin.ufpe.br/~in1020/arquivos/monografias/2009_1/pablo.pdf>. Acesso em: 15
Abr. 2010.
DIEHL, Vera Alice. Protótipo para Gerenciamento de programa da qualidade (5s)
utilizando Sistemas Especialistas. Blumenau: FERB, 2000. 71 p. Trabalho de Conclusão de
Curso, Universidade Reginal de Blumenau, Blumenau, 2000. Disponível em: <
http://campeche.inf.furb.br/tccs/2000-II/2000-2veraalicediehlvf.pdf>. Acesso em: 15 fev.
2011.
FIGUEIREDO, Ciro Jardim et al. Uso de Sistemas Especialistas para a avaliação de um
processo
agroindustrial.
2011.
Disponível
em:
<
62
http://ojs.ingepro.com.br/index.php/ingepro/article/download/344/303>. Acesso em: 12 Fev.
2011.
FLORES, Cecília Dias. Fundamentos dos Sistemas Especialistas. In: Dante Augusto Couto
Barone. (Org.). Sociedades Artificiais: A Nova Fronteira da Inteligência nas Máquinas. 1 ed.
Porto Alegre, 2003, v. 1, p. 127-154.
FRANÇA, Juliana Baptista dos Santos; MORAES, Karla Luraschy. Um estudo sobre
levantamento de informações para modelagem de processos de negócio. Rio de Janeiro:
UNIRIO, 2009. 95 p. Trabalho Conclusão de Curso, Universidade Federal do Estado do Rio
de
Janeiro,
Rio
de
Janeiro,
2009.
Disponível
em:
<http://np2tec.uniriotec.br:9093/np2tec/publicacoes/Projeto%20Final%20%20Juliana%20Baptista%20dos%20Santos%20Franca%20e%20Karla%20Luraschy%20de%
20Moraes%20-%202009.pdf >. Acesso em: 20 Set. 2010.
KNIBERG, Henrik. Scrum e XP direto das Trincheiras. C4Media, Publicado por
InfoQ.com, 2007. 145 p. Disponível em: <http://www.infoq.com>. Acesso em: 24 fev. 2011.
LIA, Laboratório de Inteligência Artificial. Expert SINTA : uma ferramenta para criação
de sistemas especialistas. 1999. Disponível em: <http://www.lia.ufc.br>. Acessado em 10
Jan. 2011.
LUIZA, Ana Ávila; OLIVEIRA, Rodrigo Spinola. Introdução à Engenharia de Requisitos.
Revista Engenharia de
Software [online]. Março
de
2008.
Disponível
em:
<
http://sites.google.com/site/pasqueline/EngenhariadeRequisitosDevMedia.pdf >. Acesso em:
14 Ago. 2010.
MARTINS. José Carlos Cordeiro. Técnicas para Gerenciamento de Projetos de Software.
Rio de Janeiro: Brasport, 2007. 552 p.
MATOS, Helano. Sistemas Especialistas. Inteligência Artificial. Outubro de 2010.
Disponível em: <http://ffb.virtual.ufc.br/solar/>. Acesso em: 14 fev. 2011.
63
MEDEIROS, Raul de Abreu Junior; BELCHIOR, Arnaldo Dias; FARIAS, Pedro Porfirio
Muniz. Uma Ontologia para Engenharia de Requisitos de Software. Disponível em: <
http://www.sbc.org.br/bibliotecadigital/download.php?paper=298>. Acesso em: 10 Jun. 2010.
MEIRA, Aliny Figueirêdo. Melhoria do Processo de Engenharia de Requisitos. Recife:
UFPE, 2008. 46 p. Trabalho de Pós-Gaduação, Centro de Informática, Universidade Federal
de
Pernambuco,
Recife,
2008.
Disponível
em:
<
http://www.cin.ufpe.br/~in1020/arquivos/monografias/2007-2/monografiaAlinyMeira.doc >.
Acesso em: 15 Abr. 2010.
MENDES, Raquel Dias. Inteligência Artificial: Sistemas Especialistas no Gerenciamento da
Informação.
Disponível
em:
<
http://www.scielo.br/scielo.php?pid=S0100-
19651997000100006&script=sci_arttext>. Acesso em: 14 Fev. 2011.
NOGUEIRA, José Helano Matos; SILVA, Ricardo Bezerra A. Geração Automática de
Aplicações Especialistas Usando o Expert SINTA. Anais do Simpósio Brasileiro de
Engenharia de Software, São Carlos, 1997.
OLIVEIRA, Alexandre José Henrique Luna. Abordagem da engenharia de requisitos em
projetos de desenvolvimento de software para telessaúde/telemedicina. Recife: UFPE,
2008. 79 p. Trabalho de Pós-Gaduação, Centro de Informática, Universidade Federal de
Pernambuco,
Recife,
2008.
Disponível
em:
<
http://www.cin.ufpe.br/~in1020/arquivos/monografias/20081/IN1020_EngRequisitos_Monografia_EngRequisitos%20na%20Telemedicina%20e%20Tele
ssaude_Alexluna_v1.15.pdf >. Acesso em: 15 Abr. 2010.
OLIVEIRA, Susana Brunoro C.; TANAKA, Astério K.; VIANA, Dalessandro S. Avaliação
de Ferramentas para Controle Automatizado de Versões de Artefatos de Requisitos de
Software. Workshop de Engenharia de Requisitos - WER 2006, 2006, Rio de Janeiro.
Disponível
em:
<
http://wer.inf.puc-
rio.br/WERpapers/pdf_counter.lua?wer=WER06&file_name=susana_oliveira.pdf>.
em: 14 Set. 2010.
Acesso
64
PÁDUA, Silvia Inês Dallavalle. Investigação do Processo de Desenvolvimento de Software
a partir da Modelagem Organizacional, enfatizando regas de negócio. São Carlos: USP,
2001. 156 p. Tese de mestrado, Escola de Engenharia de São Carlos, Universidade de São
Paulo,São
Carlos,
2001.
Disponível
em:
<
http://www.teses.usp.br/teses/disponiveis/18/18140/tde-09122008154855/publico/DissertacaoSilviaInesDallavallePadua.pdf >. Acesso em: 25 Set. 2010.
PRESSMAN, Roger S. Engenharia de software. São Paulo: Pearson Makron Books, 2005.
1056 p. ISBN 85-346-0237-9. Português.
PY, Mônica Xavier. Sistemas Especialistas: uma Introdução. 2006. Disponível em: <
http://www.inf.ufrgs.br/gppd/disc/cmp135/trabs/mpy/sistemasespecialistas.pdf>. Acesso em:
12 Fev. 2011.
REATEGUI, Elisio Berni. Um modelo para Sistemas Especialistas Conexionistas
Híbridos. Universidade Federal do Rio Grande do Sul, 1993. 123 p. Tese de mestrado,
Instituto de Informática, Universidade Federal do Rio Grande do Sul, Porto Alegre, 1993.
Disponível
em:
<
http://www.lume.ufrgs.br/bitstream/handle/10183/25522/000060983.pdf?sequence=1>.
Acesso em: 25 Jan. 2011.
REINALDO, Leonardo Monteiro. Abordagem comparativa entre modelos de melhoria
para processo de software. Recife: UFPE, 2006. 71 p. Trabalho de Conclusão de Curso,
Centro de Informática, Universidade Federal de Pernambuco, Recife, 2006. Disponível em:
<http://www.cin.ufpe.br/~tg/2006-2/lmr.pdf>. Acesso em: 05 Abr. 2010.
ROVER, Aires J. Sistemas Legais: Uma solução inteligente para o direito. Disponível em: <
http://www.scribd.com/doc/15097015/Sistemas-especialistas-legais-uma-solucao-inteligentepara-o-direito>. Acesso em: 14 de Fev. 2011.
RUP. Rational Unified Process. Disponível em: <http://www.wthreex.com/rup/>. Acesso
em: 14 Agost. 2010.
65
SAYAO, Miriam; LEITE, Julio Cesar Sampaio do Prado. Rastreabilidade de Requisitos.
Monografias em Ciência da Computação Nº 20/05. 2005.
Disponível em: <
http://www.dbd.puc-rio.br/depto_informatica/05_20_sayao.pdf >. Acesso em: 20 Agost.
2010.
SILVA, Carlo Giovano Pires; SOUZA, Gabriela Telles; BELCHIOR, Arnaldo Dias. Padrões
de Requisitos para Especificação de Casos de Uso em Sistemas de Informação.
Disponível
em:
<
http://www.atlantico.com.br/sites/default/files/biblioteca/padroes-de-
requisitos-para-especificacao-de-casos-de-uso-em-sistemas-de-informacao.pdf>. Acesso em:
14 Agost. 2010.
SILVA, Marco Aurélio Graciotto. Uma ferramenta Web colaborativa para apoiar a
engenharia de requisitos em software livre. São Carlos: USP, 2005. 164 p. Tese de
Mestrado, Instituto de Ciências Matemáticas e de Computação, Universidade de São Paulo,
São Carlos, 2005. Disponível em: < http://www.teses.usp.br/teses/disponiveis/55/55134/tde28042006-080550/pt-br.php>. Acesso em: 20 Set. 2010.
SMITH, John. A Comparison of the IBM Rational Unified Process and eXtreme
Programming.
2003.
Disponível
em:
<ftp://ftp.software.ibm.com/software/rational/web/whitepapers/2003/TP167.pdf>. Acesso em:
12 Agos. 2010.
SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo: Pearson Education do
Brasil, 2008. 552 p.
SWEBOK, Guide to the Software Engineering Body of Knowledge. Disponível em: <
http://www.computer.org/portal/web/swebok >. Acesso em: 10 Ago. 2010.
SZALVAY.
Victor.
Glossary
os
Scrum
Terms.
2007.
Disponível
em:
<
http://www.scrumalliance.org/articles/39-glossary-of-scrum-terms>. Acesso em: 20 Agost.
2010.
66
WELLS, Don. eXtreme Programming: A gentle introduction. 1999. Disponível em: <
http://www.extremeprogramming.org/>. Acesso em: 12 Agos. 2010.
ZANETTI, David; MONTONI, Mariano; ROCHA, Ana Regina. Benchmarking em
Iniciativas
de
Melhorias
em
Processos
de
Software.
<http://www.cin.ufpe.br/~tg/2006-2/lmr.pdf>. Acesso em: 14 Agost. 2010.
Disponível
em:
67
ANEXOS I – Questionário utilizado na criação base de conhecimento do SISREQUI
PROCESSO PARA CRIAÇÃO DA BASE DE CONHECIMENTO DO SISREQUI
As respostas das perguntas a seguir, serão utilizadas para a criação da base de conhecimento do
sistema especialista SISREQUI que estou desenvolvendo para o meu trabalho de conclusão de curso.
O SISREQUI é um sistema especialista que terá como missão auxiliar no processo de requisitos de
software.
1) Em um projeto onde os requisitos mudam constantemente, que metodologia você
utilizaria no processo de desenvolvimento?

RUP

Metodologias ágeis

Outro
2) Por quê?
3) Das técnicas de elicitação de requisitos, selecione a que você acha a mais completa? A
elicitação de requisitos se resume à simples transferência de conhecimento das pessoas
para documentos de requisitos.

Entrevistas

Tempestade de idéias (Brainstorm)

Cenários

Etnografia

Mapa Mental
68

Junção de algumas das técnicas descritas acima
4) Você está reunido com vários usuário com o intuito de entender o problema do cliente
e coletar os requisitos necessários para resolução do mesmo. Mas os vários usuários
tem diferentes formas de enxergar o problema e descrever os requisitos. Como você
sairia dessa situação?
5) Qual a melhor maneira de validação dos requisitos? A validação de requisitos tem o
intuito de mostrar que os requisitos atendem realmente ao que o sistema precisa.

Verificar se todos os requisitos coletados estão descritos nos documentos de
requisitos

Verificar se o sistema atende a todas as necessidades dos interessados

Verificar se os novos requisitos não irão conflitar com os requisitos já
existentes
6) O cliente utiliza os artefatos do RUP como forma de validação dos requisitos. E com
no decorrer do processo um novo requisito foi incluindo. Você terá tempo para
desenvolvê-lo, mas não terá como inclui-lo em todos os artefatos que sofrerão
modificações. Como você negociaria com o cliente o tempo para atualizar os
artefatos?
7) Digamos que o cliente não entende nada sobre termos técnicos da área de informática
e você precisa mostra-lo os requisitos coletados, para que o mesmo os valide e aprove.
De que forma você apresentaria os requisitos a este cliente? A validação representa a
atividade em que obtemos o aceite do cliente.

Através de documentos de Casos de Uso (Metodologia RUP)

Diagramas de Casos de uso
69

User Storys (Metodologias ágeis)

Diagrama de Fluxo de Dados (DFD)

Fluxogramas

Outro
8) Que técnicas você utilizaria para ter um total controle no gerenciamento dos
requisitos? Requisitos são por natureza voláteis. Diversos fatores contribuem para sua
instabilidade ao longo do tempo.

Baseline

Rastreabilidade

Outro
9) O que faria se no momento da entrega das novas funcionalidades ao cliente, você
percebesse que faltou um requisito ser implementado. E este requisito é necessário
para o correto funcionamento das demais funcionalidades do sistema?
70
ANEXOS II – Respostas do questionário utilizado na criação base de conhecimento
do SISREQUI
1) Em um projeto onde os requisitos mudam constantemente, que metodologia você
utilizaria no processo de desenvolvimento?
2) Por quê?
“O RUP engessa os processos e faz com que as entregas demorem.”
“Metodologias ágeis trabalham com foco em metas e resultados efetivos, reduzindo o
re-trabalho.”
“São as metodologias que mais se aplicam à requisitos modificados constantemente.”
“RUP por exemplo, engessa demasiadamente todas as etapas (doc e a&p).”
“Devido ao menor impacto de mudança, tanto dos artefatos de desenvolvimento,
quanto no custo. Por que não segue um padrão.”
71
3) Das técnicas de elicitação de requisitos, selecione a que você acha a mais completa? A
elicitação de requisitos se resume à simples transferência de conhecimento das pessoas
para documentos de requisitos.
4) Você está reunido com vários usuários com o intuito de entender o problema do
cliente e coletar os requisitos necessários para resolução do mesmo. Mas os vários
usuários têm diferentes formas de enxergar o problema e descrever os requisitos.
Como você sairia dessa situação?
“Faça os usuários escreverem o que querem, e o mais importante: tenha especialistas
da área de negócio do cliente trabalhando no seu time.”
“Procurando definir um novo padrão para os clientes onde eles tenham um resultado
satisfatório e produtivo de automação.”
“Tomando as rédeas da discussão e destacando algumas idéias, citando pontos
positivos e negativos, implicitamente sugerindo uma delas.”
72
“Coletava todas informações mesmo as divergentes, e no final apresentaria uma
solução os pontos importantes consolidados. Inclusive apresentando o fluxo de
funcionamento na forma que entendi.”
“Entender tudo e tentar a melhor forma de resolução.”
5) Qual a melhor maneira de validação dos requisitos? A validação de requisitos tem o
intuito de mostrar que os requisitos atendem realmente ao que o sistema precisa.
6) O cliente utiliza os artefatos do RUP como forma de validação dos requisitos. E com
no decorrer do processo um novo requisito foi incluindo. Você terá tempo para
desenvolvê-lo, mas não terá como inclui-lo em todos os artefatos que sofrerão
modificações. Como você negociaria com o cliente o tempo para atualizar os
artefatos?
“Ou o prazo para entrega é estendido, ou o cliente ficará com algo incompleto.
Simples assim, e eu não trabalho mais de oito horas por dia a menos que seja muito
bem recompensado por isso.”
73
“Conversa franca com o cliente, contrabalanceando informações boas com
informações ruins.”
“Não há muito o que negociar, é NECESSÁRIO que o requisito seja replicado nos
artefatos, justamente devido à utilização do RUP. A proposta seria basicamente: ou a
atualização será feita no decorrer do processo ou imediatamente antes do
desenvolvimento (o que não é aconselhável).”
“A depender da necessidade do cliente e do grau de importância deste novo requisito,
negociaria uma única entrega com todo o software desenvolvido”.
“Vale ressaltar que se o novo requisito não impactasse no correto funcionamento do
software, sendo apenas informações adicionais, poderíamos sim entregar de forma
particionada.”
7) Digamos que o cliente não entende nada sobre termos técnicos da área de informática
e você precisa mostra-lo os requisitos coletados, para que o mesmo os valide e aprove.
De que forma você apresentaria os requisitos a este cliente? A validação representa a
atividade em que obtemos o aceite do cliente.
74
8) Que técnicas você utilizaria para ter um total controle no gerenciamento dos
requisitos? Requisitos são por natureza voláteis. Diversos fatores contribuem para sua
instabilidade ao longo do tempo.
9) O que faria se no momento da entrega das novas funcionalidades ao cliente, você
percebesse que faltou um requisito ser implementado. E este requisito é necessário
para o correto funcionamento das demais funcionalidades do sistema?
“Devolveria ao cliente todo o dinheiro investido e demitiria o responsável pelo erro.”
“Diria pra ele é fudeu...”
“Jogo de cintura: ou o prazo é esticado para implementação do requisito ou, caso seja
um requisito que não será imediatamente utilizado pelo cliente, entra no escopo de
uma entrega à parte, após a atual entrega.”
“Mais uma vez depende da importância deste requisito para o funcionamento do
sofware.”
75
ANEXOS III – Base de Conhecimento SISREQUI
A seguir, as regras que compõem a base de conhecimento do SISREQUI.

Objetivos:
 Para esta situação o mais adequado é
 Técnica de Elicitação Requisitos mais adequada
 Validação de Requisitos
 Técnica de Gerenciamento de requisitos mais adequada

Regras:
REGRA 01
SE Problemas no desenvolvimento do sistema= Sim
ENTÃO Para esta situação o mais adequado é = Verificar se o documento de
Requisitos está claro. CNF [60%]
REGRA 02
SE Projeto Complexo = Sim
E Problemas no desenvolvimento do sistema= Sim
ENTÃO Para esta situação o mais adequado é = Verificar se o documento de
Requisitos está claro. CNF [80%]
REGRA 03
SE Projeto Complexo = Não
OU Requisitos claros = Sim
ENTÃO Para esta situação o mais adequado é = Validar com o cliente o requisito
coletado. CNF [70%]
REGRA 04
SE NÃO Documento de requisito abordando todos os requisitos = Sim
ENTÃO Validação dos requisitos = Leitura do documento de requisitos. CNF
[40%]
76
REGRA 05
SE Requisitos claros = Não
E Documento de requisito abordando todos os requisitos = Sim
OU dificuldades na comunicação entre cliente e analista = Sim
ENTÃO Técnica de Elicitação Requisitos mais adequada = Etnografia. CNF
[80%]
REGRA 06
SE NÃO Cliente tem certeza sobre os Requisitos = Sim
E Envolvidos no projeto com total entendimento = Não
ENTÃO Técnica de Elicitação Requisitos mais adequada = Tempestade de idéias.
CNF [85%]
REGRA 07
SE NÃO Cliente tem certeza sobre os Requisitos = Não
OU contato direto com cliente = Não
ENTÃO Técnica de Elicitação Requisitos mais adequada = Cenários. CNF [70%]
REGRA 08
SE NÃO contato direto com cliente = Sim
E Envolvidos no projeto com total entendimento = Sim
OU dificuldades na comunicação entre cliente e analista = Não
ENTÃO Técnica de Elicitação Requisitos mais adequada = Entrevista. CNF
[70%]
REGRA 09
SE novas solicitações = Sim
E conhecimento dos requisitos = Não
OU conhecimento dos requisitos = Desconhecido
ENTÃO
Técnica
de
Gerenciamento
Rastreabilidade de requisitos. CNF [90%]
REGRA 10
de
requisitos
mais
adequada
=
77
SE novas solicitações = Não
E conhecimento dos requisitos = Sim
E cliente tem certeza sobre os requisitos = Sim
ENTÃO Validação = Verificar se a descrição dos requisitos está entendível. CNF
[90%]
REGRA 11
SE novas solicitações = Desconhecido
E requisitos claros = Sim
OU projeto complexo = Desconhecido
E dificuldades na comunicação entre cliente e analista = Desconhecido
ENTÃO Técnica de Elicitação Requisitos mais adequada = Cenários. CNF [80%]
REGRA 12
SE projeto complexo = Sim
E Envolvidos no projeto com total entendimento = Sim
E Requisito invalida outro requisito = Sim
ENTÃO Para esta situação o mais adequado é = Negociar mais tempo com o
cliente. CNF [80%]
REGRA 13
SE Documento de requisitos criado = Sim
E Requisitos validados = Não
ENTÃO Validação de requisitos = Criar um mapa mental com todos os requisitos.
CNF [70%]
REGRA 14
SE Documento de requisitos criado = Sim
E Requisitos validados = Não
ENTÃO Validação de requisitos = Criar um mapa mental com todos os requisitos.
CNF [70%]
REGRA 15
SE Cliente conhecimento Técnico = Não
78
OU Documento de requisitos criado = Desconhecido
ENTÃO Para esta situação o mais adequado é = Criar o documento de requisitos.
CNF [70%]
REGRA 16
SE Requisitos estáticos = Não
E Conhecimento dos requisitos = Não
OU dificuldades na comunicação entre cliente e analista = Desconhecido
ENTÃO Técnica de Elicitação Requisitos mais adequada = Etnografia. CNF
[70%]
REGRA 17
SE Requisitos estáticos = Sim
OU Conhecimento dos requisitos = Sim
OU dificuldades na comunicação entre cliente e analista = Não
OU Projeto complexo = Não
E Requisitos validados = Desconhecido
ENTÃO Validação = Verificar se a descrição dos requisitos está entendível. CNF
[70%]
REGRA 18
SE Projeto complexo = Sim
OU NÃO Requisito complexo = Sim
E Requisito depende outro requisito = Sim
ENTÃO Técnica de Gerenciamento de requisitos mais adequada = Baseline dos
requisitos. CNF [60%]
REGRA 19
SE Projeto complexo = desconhecido
E Requisito depende outro requisito = Não
E Requisito invalida outro requisito = Sim
ENTÃO Para esta situação o mais adequado é = Negociar mais recursos com o
cliente. CNF [60%]
79
REGRA 20
SE Requisito depende outro requisito = Desconhecido
E Requisito invalida outro requisito = Desconhecido
ENTÃO
Técnica
de
Gerenciamento
de
requisitos
mais
adequada
=
Rastreabilidade de requisitos. CNF [80%]
REGRA 21
SE Requisito invalida outro requisito = Não
E NÃO Novas solicitações = Sim
OU Envolvidos no projeto com total entendimento = Desconhecido
ENTÃO Validação de Requisitos = Verificar se a descrição dos requisitos está
entendível. CNF [80%]
REGRA 22
SE Problemas no desenvolvimento do sistema = Não
E Requisitos claros = desconhecido
ENTÃO Para esta situação o mais adequado é = criar documento de requisitos.
CNF [50%]
REGRA 23
SE Problemas no desenvolvimento do sistema = Desconhecido
E Documento de requisito abordando todos os requisitos = Não
ENTÃO Para esta situação o mais adequado é = Refazer documento de requisitos.
CNF [70%]
REGRA 24
SE Documento de requisito abordando todos os requisitos = Desconhecido
E Envolvidos no projeto com total entendimento = Não
ENTÃO Para esta situação o mais adequado é = Verificar se o documento de
Requisitos está claro. CNF [60%]
REGRA 25
SE Conhecimento dos requisitos = Desconhecido
E cliente tem certeza sobre os requisitos = Não
80
ENTÃO Técnica de Elicitação Requisitos mais adequada = etnografia. CNF [90
%]
REGRA 26
SE novas solicitações = Não
E Cliente conhecimento Técnico = Sim
ENTÃO validação = Leitura do documento de requisitos. CNF [50%]
REGRA 27
SE Requisitos validados = Sim
E Requisitos estáticos = desconhecido
ENTÃO
Técnica
de
Gerenciamento
de
requisitos
mais
adequada
=
Rastreabilidade de requisitos. CNF [60%]
REGRA 28
SE Cliente conhecimento Técnico = Desconhecido
E projeto complexo = Não
ENTÃO Técnica de Elicitação Requisitos mais adequada = Cenários. CNF [70%]
REGRA 29
SE cliente tem certeza sobre os requisitos = Desconhecido
E Documento de requisitos criado = Não
ENTÃO Técnica de Elicitação Requisitos mais adequada = Etnografia. CNF
[80%]
REGRA 30
SE Requisitos validados = Sim
E análise e negociação de requisitos concluída = Não
ENTÃO Validação de requisitos = Checklist com questões sobre os requisitos.
CNF [80%]
REGRA 31
SE Sistema aborda as necessidades dos clientes = Sim
E O Sistema irá realmente suporta a automatização do trabalho = Não
81
ENTÃO Para esta situação o mais adequado é = Refazer documento de requisitos.
CNF [60%]
REGRA 32
SE Sistema aborda as necessidades dos clientes = Desconhecido
E O cliente já aprovou o protótipo = Não
ENTÃO Validação de requisitos = Checklist com questões sobre os requisitos.
CNF [50%]
REGRA 33
SE análise e negociação de requisitos concluída = Sim
E O Sistema irá realmente suporta a automatização do trabalho = Desconhecido
ENTÃO Validação de requisitos = Checklist com questões sobre os requisitos.
CNF [75%]
REGRA 34
SE O cliente já aprovou o protótipo = Sim
E Sistema aborda as necessidades dos clientes = Não
ENTÃO Para esta situação o mais adequado é = Refazer documento de requisitos.
CNF [70%]
REGRA 35
SE análise e negociação de requisitos concluída = Desconhecido
OU O cliente já aprovou o protótipo = Desconhecido
E O Sistema irá realmente suporta a automatização do trabalho = Sim
ENTÃO Validação de requisitos = Verificar se o sistema está atendendo a todas
as das necessidades dos interessados. CNF [80%]
REGRA 36
SE O cliente já aprovou o protótipo = Não
E O Sistema irá realmente suporta a automatização do trabalho = Não
ENTÃO Para esta situação o mais adequado é = Verificar se o documento de
Requisitos está claro. CNF [50%]
82
Para esta situação o mais adequado é = Refazer documento de requisitos.
CNF [50%]
REGRA 37
SE Cliente tem certeza sobre os Requisitos = Não
E Projeto Complexo = Não
E Problemas no desenvolvimento do sistema= Sim
OU análise e negociação de requisitos concluída = Não
ENTÃO Técnica de Elicitação Requisitos mais adequada = Etnografia. CNF
[80%]
Técnica de Elicitação Requisitos mais adequada = Cenários. CNF [80%]
Técnica de Elicitação Requisitos mais adequada = Entrevistas [60%]
REGRA 38
SE Cliente tem certeza sobre os Requisitos = Não
E Envolvidos no projeto com total entendimento = Não
E dificuldades na comunicação entre cliente e analista = Sim
ENTÃO Técnica de Elicitação Requisitos mais adequada = Tempestade de idéias.
CNF [50%]
Para esta situação o mais adequado é = Negociar mais tempo com o
cliente. CNF [50%]
Para esta situação o mais adequado é = criar documento de requisitos.
CNF [50%]
REGRA 39
SE análise e negociação de requisitos concluída = Sim
E O cliente já aprovou o protótipo = Sim
E Novas solicitações = Sim
E Requisito invalida outro requisito = Desconhecido
OU Requisito depende outro requisito = Desconhecido
ENTÃO Técnica de Gerenciamento de requisitos mais adequada = Baseline dos
requisitos. CNF [60%]
Técnica de Gerenciamento de requisitos mais adequada = Efetuar a
rastreablidade dos requisitos. CNF [60%]
83
Para esta situação o mais adequado é = Refazer documento de requisitos.
CNF [70%]
REGRA 40
SE requisitos claros = Sim
OU Conhecimento dos requisitos = Sim
E Requisitos validados = Sim
E Novas solicitações = Sim
E requisitos claros = Não
E Conhecimento dos requisitos = Desconhecido
ENTÃO Técnica de Gerenciamento de requisitos mais adequada = Efetuar a
rastreablidade dos requisitos. CNF [60%]
Técnica de Elicitação Requisitos mais adequada = Tempestade de idéias.
CNF [40%]
REGRA 41
SE análise e negociação de requisitos concluída = Sim
OU O cliente já aprovou o protótipo = Sim
E O Sistema irá realmente suporta a automatização do trabalho = Sim
E Novas solicitações = Sim
ENTÃO Técnica de Elicitação Requisitos mais adequada = Tempestade de idéias.
CNF [60%]
Técnica de Elicitação Requisitos mais adequada = Etnografia. CNF
[60%]
REGRA 42
SE O cliente já aprovou o protótipo = Desconhecido
E O Sistema irá realmente suporta a automatização do trabalho = Sim
ENTÃO Validação de requisitos = Verificar se o sistema está atendendo a todas
as das necessidades dos interessados. CNF [40%]
REGRA 43
SE O Sistema irá realmente suporta a automatização do trabalho = Sim
E Sistema aborda as necessidades dos clientes = Sim
84
E Documento de requisito abordando todos os requisitos = Não
ENTÃO Para esta situação o mais adequado é = Refazer documento de requisitos.
CNF [95%]
REGRA 44
SE O cliente já aprovou o protótipo = Desconhecido
E Documento de requisito abordando todos os requisitos = Sim
ENTÃO Validação de requisitos = Verificar se o sistema está atendendo a todas
as das necessidades dos interessados. CNF [70%]
REGRA 45
SE Projeto Complexo = Não
E Requisitos validados = Sim
E novas solicitações = Sim
E Projeto Complexo = Sim
ENTÃO Para esta situação o mais adequado é = Negociar mais recursos com o
cliente. CNF [80%]
Para esta situação o mais adequado é = Negociar mais tempo com o
cliente. CNF [80%]
REGRA 46
SE contato direto com cliente = Sim
E Cliente tem certeza sobre os Requisitos = Sim
E dificuldades na comunicação entre cliente e analista = Sim
ENTÃO Técnica de Elicitação Requisitos mais adequada = Entrevistas. CNF
[80%]
Técnica de Elicitação Requisitos mais adequada = Cenários. CNF [80%]
REGRA 47
SE Documento de requisito abordando todos os requisitos = Sim
E Cliente tem certeza sobre os Requisitos = Sim
E Cliente conhecimento Técnico = Não
ENTÃO Validação dos requisitos = Protótipo do sistema. CNF [40%]
85
Validação dos requisitos = Leitura do documento de requisitos. CNF
[50%]
REGRA 48
SE Documento de requisito abordando todos os requisitos = Desconhecido
OU Cliente tem certeza sobre os Requisitos = Sim
E Cliente conhecimento Técnico = Sim
ENTÃO Validação dos requisitos = Leitura do documento de requisitos. CNF
[80%]
REGRA 49
SE Cliente tem certeza sobre os Requisitos = Desconhecido
OU Cliente conhecimento Técnico = Desconhecido
E Documento de requisitos criado = Não
ENTÃO Técnica de Elicitação Requisitos mais adequada = etnografia. CNF [90
%]
Para esta situação o mais adequado é = Criar o documento de requisitos.
CNF [90%]
REGRA 50
SE Requisitos validados = Sim
E análise e negociação de requisitos concluída = Não
E O Sistema irá realmente suporta a automatização do trabalho = Não
E Novas solicitações = Sim
ENTÃO Para esta situação o mais adequado é = Negociar mais tempo com o
cliente. CNF [70%]
Técnica de Elicitação Requisitos mais adequada = Etnografia. CNF [90%]
Para esta situação o mais adequado é = Validar com o cliente o requisito
coletado. CNF [70%]