Fundamentos de Engenharia
de Software
UFRPE
Processo de Engenharia de
Requisitos de Software
O que é mesmo um
Requisito de Software?
Descrição dos serviços fornecidos
pelo sistema e suas restrições
operacionais.
Reflete a necessidade dos clientes de
um sistema que ajuda a resolver
algum problema.
Processos de Engenharia de
Requisitos
Tem variação?
Variam
amplamente
dependendo
do
domínio
de
aplicação,
das
pessoas
envolvidas
e
da
organização
que
desenvolve os requisitos.
Processos de Engenharia de
Requisitos
Qual é o objetivo?
Criar e manter um documento de requisitos do
Processos de Engenharia de
Requisitos
O
processo
geral
inclui
quatro
subprocessos:
Estudo de viabilidade;
Elicitação e análise;
Especificação;
Processos de Engenharia de
Requisitos
O
processo
geral
inclui
quatro
subprocessos:
Estudo de viabilidade
Avaliar se o sistema é útil para a empresa,
Processos de Engenharia de
Requisitos
O
processo
geral
inclui
quatro
subprocessos:
Elicitação e análise
Processos de Engenharia de
Requisitos
O
processo
geral
inclui
quatro
subprocessos:
Especificação
Conversão dos requisitos em alguma forma
Processos de Engenharia de
Requisitos
O
processo
geral
inclui
quatro
subprocessos:
Validação
Verificar se os requisitos realmente definem
Processo de Engenharia de
Requisitos
Modelo em Espiral dos Processo de
Engenharia de Requisitos
Processos de Engenharia de
Requisitos
As atividades do processo não estão
somente
relacionadas
à
obtenção
,
documentação
e
verificação.
O requisitos mudam, as pessoas envolvidas
adquirem um compreensão maior do que desejam que o software faça, o software
muda, o hardware muda...
1. Estudo de Viabilidade
Recebe como entrada:
Um conjunto preliminar de requisitos de negócio;
Um esboço da descrição do sistema;
E o modo como o sistema pretende apoiar os
processos de negócio.
Ele deve recomendar se é válido ou não
prosseguir
com o desenvolvimento do
sistema.
1. Estudo de Viabilidade
Estudo breve e focado para responder a
1. Estudo de Viabilidade
Envolve a avaliação de informações, sua
coleta e a elaboração de relatório, chamado
de
estudo de viabilidade
.
Para
essa
atividade,
podem
ser
consultados:
Gerentes de Departamentos;
Engenheiros de Software familiarizados com o
negócio;
Especialistas em TI;
1. Estudo de Viabilidade
Questões para as pessoas da organização:
O que faria se o sistema não fosse implementado? Quais são os problemas com processo atuais?
1. Estudo de Viabilidade
Questões para as pessoas da organização:
Quais serão os problemas de integração?
Tecnologia nova é necessária? Quais habilidades? Quais recursos devem ser apoiados pelo sistema
2. Elicitação e Análise de
Requisitos
Estágio onde os engenheiros de
software trabalham com o cliente e
usuários finais para aprender sobre:
O domínio da aplicação
Quais serviços o sistema deve fornecer
O desempenho esperado do sistema
Restrições de hardware
e outras
2. Elicitação e Análise de
Requisitos
Envolve,
de
preferência,
todos
os
stakeholders, ou seja, todo os interessado
e/ou afetados (in)diretamente pelo sistema.
Problemas
Os stakeholders não sabem ao certo o que
querem do sistema.
Os stakeholders expressam os requisitos em
seus próprios termos e com o conhecimento
2. Elicitação e Análise de
Requisitos
Problemas (continuação)
Diferentes stakeholders possuem diferentes
requisitos que podem ser conflitantes.
Fatores políticos podem influenciar os requisitos do sistema.
O ambiente econômico e de negócios é dinâmico
fazendo com que requisitos mudem ou surjam novos requisitos.
Processo de Elicitação e Análise
de Requisitos
2. Elicitação e Análise de
Requisitos
Atividades do processo de elicitação
e análise:
1. Obtenção de requisitos, processo de interação com os stakeholders para coletar os seus requisitos.
2. Classificação e organização de requisitos,
coleta os requisitos, agrupa os que são relacionados e os organiza em conjuntos coerentes.
2. Elicitação e Análise de
Requisitos
Atividades do processo de elicitação
e análise:
3. Priorização e negociação de requisitos, visa
priorizar os requisitos mais importantes e resolver conflitos entre requisitos por meio de negociação.
4. Documentação de requisitos, os requisitos
Obtenção de Requisitos
É o processo que reúne informações sobre o sistema proposto e os existentes para obter os requisitos de usuário e de sistema.
Algumas técnicas para obtenção de requisitos são: Ponto de vista; Entrevista; Cenários; Casos de uso; Etnografia.
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Pontos de vista
Reconhece várias perspectivas e facilita a resolução de conflitos.
Tipos
Pontos de vista de interação, pessoas ou outros sistemas que interagem diretamente com o sistema.
Pontos de vista indiretos, stakeholders que não usam o sistema diretamente.
Pontos de vista de domínio, representam características e restrições de domínio que influenciam os requisitos do sistema.
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Exemplo de pontos de vista para um sistema
de caixa eletrônico
Pontos de vista de interação - clientes do banco e o banco de dados de contas.
Pontos de vista indiretos - gerência do banco.
Pontos de vista de domínio - padrões desenvolvidos para comunicação entre bancos.
2. Elicitação e Análise de
Requisitos
Exemplo de pontos de vista para o LIBSYS
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Entrevista
A equipe de engenharia de requisitos formula
questões para os stakholders
Entrevista podem ser:
Fechadas (respondem a perguntas predefinidas) Abertas (não existe roteiro, são explorados
assuntos)
O engenheiro de requisitos discute, de forma aberta, o que os stakeholders querem do sistema.
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Entrevista
Técnica útil para:
Obter um entendimento geral dos que os
stakholders fazem.
Como eles podem interagir com o sistema. As dificuldades dos sistema atuais.
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Entrevista
Não são tão úteis para compreender os
requisitos do domínio da aplicação.
Os especialistas usam terminologia e
jargões específicos.
Alguns conhecimentos são tão familiares
que:
São difíceis de se explicar ou São tão
2.
Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Cenários
São exemplos reais de como um sistema pode
ser usado.
Os usuários podem compreender e criticar um
determinado cenário
Eles devem incluir:
Descrição da situação inicial; Fluxo normal de eventos;
Descrição do que pode dar errado;
Informação sobre outras atividades concorrentes;
2. Elicitação e Análise de
Requisitos
2. Elicitação e Análise de
Requisitos
O usuário deseja imprimir uma cópia de um artigo de uma revista médica Obtenção de Requisitos
Casos de uso
Os casos de uso constituem uma técnica
baseada em cenários UML que identificam
os agentes em uma interação, e que
descrevem a interação em si.
Diagramas de seqüência podem ser usadas
para adicionar detalhes aos casos de uso,
mostrando a seqüência de processamento
de eventos no sistema.
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Casos de uso
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Etnografia
Técnica de observação que pode ser usada para
compreender fatores sociais e organizacionais.
Um analista se insere no ambiente de trabalho
onde o sistema será utilizado.
Ele observa o trabalho do dia a dia e anota as
tarefas reais nas quais os participantes são envolvidos.
Ajuda a descobrir requisito implícitos.
2. Elicitação e Análise de
Requisitos
Obtenção de Requisitos
Etnografia
Pode ser combinada com outra técnica como
prototipação.
Nem sempre conseguem identificar novas
características a serem incluídas no sistema.
2. Elicitação e Análise de
Requisitos
Conversão dos requisitos obtidos em alguma
forma padrão.
Documentos de Especificação de Requisitos.
4. Validação de Requisitos
Dedica-se a mostrar que os requisitos
realmente definem o sistema que o usuário
deseja.
Está
relacionada
à
descoberta
de
problemas com os requisitos.
Importante pois um erro no documento de
requisitos leva a custos excessivos de
retrabalho
quando
descobertos
no
desenvolvimento ou na execução.
4. Validação de Requisitos
Durante o processo de validação
devem ser verificados
Verificações de validade, se os requisitos são válidos entre os diferentes stakeholders.
Verificações de consistência, se os requisitos não são conflitantes.
Verificações de completeza, deve incluir requisitos que definam todas as funções e restrições desejadas pelos usuários.
4. Validação de Requisitos
Durante o processo de validação
devem ser verificados
Verificações de realismo: Deve verificar se os requisitos podem de fato ser realizados. Deve levar em consideração o orçamento e o prazo para o desenvolvimento do sistema, além da tecnologia disponível.
Facilidade de verificação: Os requisitos devem ser fáceis de serem testados. É necessária a redução de divergência entre os stakeholders.
4. Validação de Requisitos
Algumas
técnicas
podem
ser
utilizadas na validação de requisitos
Revisões de requisitos: Processo manual que envolve pessoas das organizações do cliente e do fornecedor.
Prototipação: Apresentação de um modelo executável do sistema
Geração de casos de teste:
Desenvolvimento
de testes para requisitos.
os requisitos devem ser testáveis e tais testes revelarão frequentemente problemas de requisitos.
Gerenciamento de Requisitos
Motivação
Os requisitos tendem de alguma forma a ser
incompletos ou modificados durante o
desenvolvimento. As mudanças são
ocasionadas, em sua maioria por:
Diversidade de usuários, principalmente em
sistemas de grande porte
As pessoas que pagam pelo software são
normalmente diferentes das que utilizam
O ambiente de negócio e técnico do sistema
Gerenciamento de Requisitos
O gerenciamento de requisitos é um
processo para compreender e controlar as
mudanças dos requisitos de sistema.
Deve haver um acompanhamento individual
Manter ligações entre os requisitos, de modo
que seja possível avaliar o impacto das
mudanças
Esse processo deve iniciar juntamente
com a elicitação dos requisitos
Não somente na documentação dos
Gerenciamento de Requisitos
Do ponto de vista da evolução, os
requisitos podem ser divididos em duas
classes:
Requisitos permanentes: relativamente estáveis e relacionados ao domínio do sistema. Ex.: em um hospital sempre existirá médico, paciente...
Requisitos voláteis: provavelmente irão mudar durante o processo de desenvolvimento. Ex.: políticas de saúde do governo que devem ser implementadas nos hospitais
Gerenciamento de Requisitos
Planejamento de Gerenciamento dos
Requisitos
É o primeiro estágio, essencial no processo e
bastante dispendioso
Durante o gerenciamento, deve-se decidir
sobre:
1. Identificação dos Requisitos
2. Processo de Gerenciamento de Mudanças
3. Políticas de Rastreabilidade
Gerenciamento de Requisitos
Planejamento de Gerenciamento do Requisitos 1. Identificação dos Requisitos
Cada requisito deve ser identificado unicamente de
modo que possa ser feita a referência cruzada entre este e outros requisitos
2. Processo de Gerenciamento de Mudanças
Conjunto de atividades que avaliam o impacto e
custo das mudanças
3. Políticas de Rastreabilidade
Define os relacionamentos entre os requisitos e entre
os requisitos e o projeto do sistema e como devem ser registrados
Gerenciamento de Requisitos
Planejamento de Gerenciamento do Requisitos 3. Apoio de Ferramenta CASE
O gerenciamento de requisitos envolve o
processamento de grande quantidades de informações. Uso de ferramentas é essencial
Ferramentas são necessárias para
Armazenamento dos Requisitos Gerenciamento das Mudanças
Gerenciamento da Rastreabilidade
Ferramentas conhecidas
RequisitePro
Gerenciamento de Requisitos
Formas de Rastreabilidade dos Requisitos
Informações de rastreabilidade da origem
Liga os requisitos aos stakeholders que os propuseram, registrando o motivo de criação
Serve para encontrar os responsáveis pelo requisito
Informações de rastreabilidade de requisitos
Liga os requisitos que dependem de outro requisito Ligação mais comum e mais importante para avaliar
o impacto de uma mudança em um requisito
Informações de rastreabilidade da projeto
Liga os requisitos ao módulos do projeto, nos quais esses requisitos são implementados.
Gerenciamento de Requisitos
Matriz de Rastreabilidade dos Requisitos
As informações de rastreabilidade são
organizadas em
matrizes
Difíceis de serem mantidas manualmente
Para sistemas de grande porte, necessidade
de ferramentas específica, BD
ID Requisito REQ1 REQ2 REQ3
REQ1 Depende
REQ2 Relaciona
Gerenciamento de Requisitos
Processo de Gerenciamento de Mudanças
Análise do problema e especificação de mudanças Análise de mudanças e estimativa de custo Implementação das mudanças problema
identificado requisito revisado
Mudanças solicitadas com urgência, quase sempre não
passam por esse processo!! Os requisitos são
implementados e os documentos ficam
