Aula 4 - Engenharia de Software - Requisitos

Prévia do material em texto

Engenharia de Software e
Gerência de Projetos
Prof. Ivan Fontainha
ivan.fontainha.googlepages.com
ialvaren@gmail.com
Aula 4
Bibliografias
Padrão
• SOMMERVILLE, Ian. Engenharia de Software. 9ª ed. : Pearson,
2011.
Básicas
• KOSCIANSKI André; SOARES Michel dos S (orgs ) Qualidade de
2
• KOSCIANSKI, André; SOARES, Michel dos S. (orgs.). Qualidade de
Software : Aprenda as Metodologias e Técnicas mais Modernas
para o Desenvolvimento de Software. 2ª ed. São Paulo: Novatec,
2009.
• PRESSMAN, Roger S.. Engenharia de software. 1ª ed. São Paulo:
Pearson, 2010.
� Visão Geral de Requisitos;
� Entendimento dos Requisitos;
Conteúdos desta aula
3
� Problemas;
Análise de Requisitos de Software
� Dentro da Engenharia de Software e um dos processos
mais fundamentais.
� Um entendimento completo dos requisitos de software é
Engenharia de Software
4
essencial para o sucesso do desenvolvimento do
software.
� Não importa quão bem projetado ou quão bem
codificado seja, um sistema mal analisado e
especificado frustrará o usuário.
Análise de Requisitos de Software
� Análise de requisitos é um processo de descoberta,
refinamento, modelagem e especificação.
� O escopo do software, inicialmente estabelecido pelo
Engenharia de Software
5
Analista de Sistemas e refinado durante o planejamento
do projeto de software, é aperfeiçoado em detalhes.
� Modelos, diagramas, fluxos são criados para ajudar na
compreensão do problema.
� O analista e o usuário desempenham um papel ativo
na análise e especificação de requisitos.
Análise de Requisitos de Software
� Reflexão:
� Por que na Analise de Requisitos o Analista e o
Usuário tem um papel importante?
Engenharia de Software
6
� Quais Problemas podem ocorrer se os dois não
tiverem uma boa comunicação?
Análise de Requisitos de Software
� O cliente (ou usuário) tenta reformular um conceito de
função e desempenho de software, às vezes nebuloso,
sem detalhes concretos.
Engenharia de Software
7
� O analista age como indagador, consultor e
solucionador de problemas.
Análise de Requisitos de Software
� Entretanto, a análise e especificação de requisitos pode
parecer uma tarefa relativamente simples, mas as
aparências enganam.
Engenharia de Software
8
� O grau comunicação é elevado.
� Daí, surgem as oportunidades de interpretações
errôneas e informações falsas.
� A ambigüidade é provável.
Análise de Requisitos de Software
� Reflexão:
� Por que o Analista e considerado um solucionador
de problemas?
Engenharia de Software
9
� Por que ele não pode chegar já com a solução?
Análise de Requisitos de Software
Engenharia de Software
10
Análise de Requisitos de Software
� Da perspectiva da Engenharia de Software, a
“elicitação” de requisitos é talvez a mais parte mais
critica do processo de desenvolvimento de software.
Engenharia de Software
11
� Estudos indicam que os requisitos, só detectados depois
do software implementado ou erros na análise de
requisitos, são até 20 vezes mais caros de se corrigir
que qualquer outro tipo de erro.
Engenharia de Software
12
Análise de Requisitos de Software
� O que pode acontecer quando os requisitos estão mal
feitos?
� Exemplos:
Engenharia de Software
13
� Foguete Ariane 5;
� Therac-25;
� London Ambulance System ;
Foguete Ariane 5
� Projeto da Agência Espacial Européia que custou:
� 10 Anos;
Engenharia de Software
14
� 8 Bilhões de Dólares.
� Problema: Explosão 40 segundos após a
decolagem, destruição do foguete e carga
avaliando uma perda de aproximadamente 500
milhões de dólares.
Foguete Ariane 5
� Aconteceu um problema de overflow durante conversão
de ponto flutuante por inteiro, fazendo com que os
sistema principal junto com o sistema de backup se
desligassem simultaneamente.
Engenharia de Software
15
� Computação que causou o acidente por que executava
cálculos desnecessário após a decolagem!
Therac-25
� Therac-25 era uma máquina de radioterapia, controlada
por computador, muito moderna para sua época, por
permitir a utilização do mesmo equipamento para a
aplicação de diversas doses de radiação nos pacientes.
Engenharia de Software
16
� Houve uma série de pelo menos 6 acidentes entre 1985
e 1987, nos quais os pacientes receberam overdose de
radiação.
� Pelo menos cinco mortes aconteceram devido aos
acidentes, causados por erros no software que
controlava a máquina.
� Este acidente mostrou o perigo que reside em softwares
que controlam operações de segurança.
Therac-25
� Causas de alguns problemas:
� O código do software não havia sido
revisado/testado independentemente;
� O projeto do software não havia sido documentado
Engenharia de Software
17
com detalhes suficientes para permitir o
entendimento dos erros;
� A documentação do sistema fornecida aos
usuários não explicava o significado dos códigos
de erro que a máquina retornava;
Therac-25
� A primeira reação dos funcionários da AECL (fabricante
da máquina) foi negar a existência de erros.
� Os pesquisadores também encontraram diversos
problemas de engenharia:
Engenharia de Software
18
� O projeto não continha travas de hardware para
prevenir que o feixe de elétrons de alta intensidade
fosse aplicado sem o filtro estar em seu lugar;
� O software de modelos mais antigos havia sido
reutilizado sem se considerar as diferenças no
hardware;
Therac-25
� Os modelos antigos possuíam travas de hardware,
quando o defeito se manifestava nestes modelos, eles
reiniciavam, o que sempre havia sido visto como algo
perturbador, mas nunca foi investigado;
Engenharia de Software
19
� O software considerava que os sensores sempre
funcionavam corretamente, e não havia como verificar
isto;
Therac-25
� O sistema de controle não operava sincronizado com a
interface usada pelo operador da máquina, e caso o
operador mudasse a configuração da máquina muito
rapidamente, o sistema não atribuía os valores digitados
Engenharia de Software
20
para os controles (o que levava a aplicação das doses
letais);
� Overflows podiam fazer o software não executar
procedimentos de segurança;
London Ambulance System
� Despacho de ambulâncias em Londres, 1992.
� Morte de pessoas que não foram socorridas em tempo.
Engenharia de Software
21
� Responsáveis contrataram uma empresa desconhecida
cujo valor cobrado era menor que os cobrados pelas
empresas de renome;
� Colocaram o sistema no ar sem os devidos testes;
� Não foi feita uma migração correta do sistema antigo
para o novo;
É melhor prevenir do que remediar:
� Para cada dólar gasto com a prevenção de defeitos,
Custo total de reparo de defeitos é reduzido de 3 a 10
dólares.
Engenharia de Software
22
Tempo de reparar um defeito:
� Gastando 30 minutos na fase de requisitos se
economiza em media : 5 a 17 horas na fase de testes .
Definições de requisito (segundo IEEE*)
1. Uma condição ou uma capacidade de que o usuário
necessita para solucionar um problema ou alcançar um
objetivo.
2. Uma condição ou uma capacidade que deve ser
Engenharia de Software
23
alcançada ou possuída por um sistema ou componente
do sistema, para satisfazer um contrato, um padrão,
uma especificação ou outros documentos impostos
formalmente.
3. Uma representação documentada de uma condição ou
capacidade.
* IEEE - Instituto de Engenheiros Eletricistas e Eletrônicos
Análise de Requisitos de Software
� A elicitação de requisitos corresponde a identificar junto
aos clientes/usuários quais são os objetivos do sistema,
o que deve ser acompanhado, como o sistema se
encaixa ‟no contexto das necessidades do negócio e,
Engenharia de Software
24
finalmente, como será a utilização do sistema no dia-a-
dia.”
� “A parte mais árdua na construção de um software
consiste exatamente em identificar o que construir.
� Nenhuma outra parte do trabalho compromete tanto o
resultado do trabalho se elaborado de forma
incorreta.
� Nenhuma outra parte oferece tanta dificuldade para
efetuar correções posteriores. "
Análise de Requisitos de Software
� Apesar de parecersimples, trata-se de um processo
extremamente complexo. Algumas das razões desta
dificuldade:
Engenharia de Software
25
� Problemas de escopo:
� Os limites do sistema são geralmente definidos de
forma incompleta, ou os clientes/usuários
especificam detalhes técnicos desnecessários;
Análise de Requisitos de Software
� Problemas de compreensão:
� Os clientes/usuários geralmente não estão
completamente certos das necessidades, têm uma
pouca compreensão ou do domínio do seu
Engenharia de Software
26
negócio, omitem informações que julgam óbvias e
etc.
� Problemas de volatilidade:
� Os requisitos mudam o tempo todo.
Análise de Requisitos de Software
� Para ajudar a superar estes problemas, os
desenvolvedores devem abordar os requisitos de forma
simples, prática e organizada.
Engenharia de Software
27
� Alguns passos são recomendados para atividade de
Elicitação de Requisitos de Software.
Análise de Requisitos de Software
� Passos são recomendados para atividade de Elicitação
de Requisitos de Software:
� Avaliar a viabilidade técnica e de negócio para o
sistema proposto;
Engenharia de Software
28
� Identificar as pessoas que vão auxiliar a especificar
os requisitos e compreender seus preconceitos
organizacionais;
� Definir o ambiente técnico no qual o sistema será
instalado;
� Identificar regras de domínio que limitam a
funcionalidade ou desempenho do software que será
construído;
Análise de Requisitos de Software
� Passos são recomendados para atividade de Elicitação
de Requisitos de Software:
� Definir um ou mais métodos de elicitação de
requisitos;
Engenharia de Software
29
� Solicitar participação de várias pessoas para que os
requisitos sejam definidos a partir de diversos
pontos de vista;
� Identificar claramente a justificativa de existência
para cada requisito registrado;
� Identificar requisitos ambíguos que serão candidatos
a prototipação.
Análise de Requisitos de Software
� Os documentos criados como consequência da
atividade de elicitação de requisitos irão depender do
tamanho do software/sistema que será construído.
� Para a maioria dos sistemas, estes documentos de
Engenharia de Software
30
trabalho incluem:
� As necessidades e viabilidade estruturadas;
� O limite de escopo do software/sistema;
� Lista de clientes, usuários e outros stakeholders
que participaram da atividade de elicitação de
requisitos;
� Descrição do ambiente técnico do sistema;
Análise de Requisitos de Software
� Para a maioria dos sistemas, estes documentos de
trabalho incluem:
� Lista de requisitos e as regras de domínio
aplicáveis a cada um.
Engenharia de Software
31
� Conjunto de cenários de uso capazes de prover
uma idéia do uso do sistema ou produto sob
diferentes condições de operação;
� Qualquer protótipo que eventualmente tenha sido
desenvolvido para melhor definir os requisitos.
� Cada um destes documentos deve ser revisado
por todas as pessoas que tenham participado da
elicitação de requisitos.
Análise de Requisitos de Software
� Objetivos da Elicitação de Requisitos:
� Obter conhecimento relevante para o problema e
prover o mais correto entendimento de o que é
esperado do software/sistema;
Engenharia de Software
32
Análise de Requisitos de Software
� Identificação e Elicitação de Requisitos
� Identificação e elicitação de requisitos é uma tarefa
que parece simples, mas, não devemos nos
Engenharia de Software
33
enganar, às vezes, para obtermos algumas
informações é exigido muita dedicação,
persistência e técnica.
� Esta parte apresenta e discute as principais
técnicas para identificação e elicitação de
requisitos de software.
Análise de Requisitos de Software
� Por que o “elicitação” é importante:
� O sucesso no desenvolvimento de um projeto de
software depende basicamente da elicitação de
requisitos, pois, é a base que permitirá ao Analista
Engenharia de Software
34
tirar conclusões sobre as situações, problemas ou
fenômenos e, assim, sugerir propostas que
possam contribuir para a solução do problema.
� Entretanto, esta atividade, nem sempre está
presente no processo de desenvolvimento,
raramente ela é elaborada de forma metodológica,
geralmente tem uma abordagem intuitiva.
Análise de Requisitos de Software
� Cuidado com :” geralmente tem uma abordagem
intuitiva.”
� Sua intuição pode não ser realmente o que o cliente
Engenharia de Software
35
deseja.
Análise de Requisitos de Software
� Principais características de uma “boa elicitação de
requisitos”:
� Definir as técnicas de coleta de requisitos
baseadas em fatores operacionais, táticos e
financeiros;
Engenharia de Software
36
financeiros;
� Criar um planejamento com objetivo de alcançar as
metas estabelecidas, tais como: Prazos, Custos e
Qualidade;
� Promover a integração e o comprometimento de
todos os envolvidos no processo, por exemplo:
Clientes, Fornecedores, Usuários e o Patrocinador.
� Identificar os documentos e procedimentos que
definem as políticas de negócios da empresa.
Análise de Requisitos de Software
Engenharia de Software
Elicitação Boa Elicitação Ruim
Bom Diagnóstico Diagnóstico ineficiente
37
Soluções eficientes Soluções medíocres
Satisfação dos usuários Insatisfação dos usuários
Melhoria dos processos e
redução de custo
Problemas operacionais e
financeiros
Análise de Requisitos de Software
� As informações podem ser identificadas ou encontradas
em diversas fontes:
� Usuários;
� Documentos;
� Especificações técnicas;
Engenharia de Software
38
� Especificações técnicas;
� Clientes;
� Sistemas legados
� Patrocinadores;
� Analista de Negócio;
� “Domain Experts” - Especialista em uma ou mais
área de negócio.
Análise de Requisitos de Software
� Existem várias técnicas, todas elas possuem seus
próprios conceitos, vantagens e desvantagens, que
podem ser usada nesta atividade entre elas estão:
� Reuniões formais;
� Reuniões informais;
Engenharia de Software
39
� Reuniões informais;
� Entrevistas;
� Questionários;
� Workshop;
� Brainstorming;
� JAD (Join Application Development)
� Fast;
� Análise de Documentos;
� Manual de Sistemas Legados.
Análise de Requisitos de Software
� Quais as informações que devo identificar, levantar e
coletar ?
� Após a atividade de Identificação/Elicitação de
Requisitos, através de alguma técnica formal ou
informal as seguintes informações que devemos obter
Engenharia de Software
40
informal, as seguintes informações que devemos obter
são:
� Entendimento do problema,
� Identificação da lista dos principais usuários,
� Lista dos principais Requisitos,
� Identificação dos Riscos e
� Restrições do software.
Análise de Requisitos de Software
� Podemos organizar as informações da seguinte
maneira:
� Contexto (Declaração do problema e Diagrama de
Contexto);
� Identificação dos usuários e entidades externas;
Engenharia de Software
41
� Identificação dos usuários e entidades externas;
� Identificação dos Requisitos;
� Identificação dos Riscos ;
� Identificação das Restrições.
Análise de Requisitos de Software
� Contexto:
� Após o entendimento do problema podemos escrever
a Declaração do Problema e também desenhar um
diagrama de contexto.
� Declaração do problema:
Engenharia de Software
42
� Declaração do problema:
� É uma “descrição narrativa”, que apresenta de forma
concisa e clara às necessidades dos usuários.
� Esta narrativa também deve descrever o cenário
atual e as necessidades futuras.
� A linguagem usada neste documento pode ser
técnica ou de negócios, entretanto, evite o usar
jargões que não se enquadram no escopo do
problema.
Análise de Requisitos de Software
� Diagrama de Contexto:
� Estabelece quais são as fronteiras do software e
principais funcionalidades, ou seja, onde as
responsabilidades do software começam e quando
acabam
Engenharia de Software
43
acabam.
Identificação dos Requisitos:
� Identificar as funcionalidades do software que deve ter
para atender as necessidades do usuário.
� Para identificar você pode fazer as seguintes perguntas:Engenharia de Software
44
� O que o software deve fazer ?
� Quais funcionalidades ele deve ter ?
Identificação dos Requisitos:
� Devemos identificar também as principais características
do software como:
� Performance:
� Qual é tempo de resposta adequado ?
� Segurança:
Engenharia de Software
45
� Segurança:
� Quais são os requisitos de segurança que o
software precisa?
� Usabilidade:
� O software deve seguir a identidade visual da
empresa,as interfaces devem ser intuitivas e
amigáveis?
Identificação dos Requisitos:
� Os requisitos encontrados não devem ser descritos
neste momento, precisamos apenas identificá-los, ou
seja, é uma informação de alto nível.
� Os requisitos podem ser divididos em duas categorias:
Engenharia de Software
46
� Os requisitos podem ser divididos em duas categorias:
� Requisitos Funcionais.
� Requisitos Não – Funcionais.
Identificação dos Requisitos:
Engenharia de Software
47
Identificação dos Requisitos - Tipos:
� Requisitos Funcionais:
� Os requisitos funcionais descrevem o que o
sistema deve fazer, isto é, as funções necessárias
para atender os objetivos do sistema.
Engenharia de Software
48
� Exemplo:
� Cadastrar Clientes;
� Fazer Análise de Crédito;
� Fazer uma Transação com Banco de Dados;
� Cadastrar um Registro de Atendimento;
� Imprimir Relatório...
Identificação dos Requisitos - Tipos:
� Requisitos Não - Funcionais:
� Os requisitos não funcionais dizem respeito as
características do software, exemplos:
performance, portabilidade, segurança, usabilidade
e etc Estas características descrevem também a
Engenharia de Software
49
e etc. Estas características descrevem também a
qualidade do serviço (QoS).
� A não consideração ou esquecimento desses
fatores na “Workflow de Requisitos” constitui uma
das principais razões de uma eventual insatisfação
dos usuários com relação a um software.
� Os requisitos não funcionais também são
chamamos de “RNF” ou “Requisito
Suplementares.”
Identificação dos Requisitos - Tipos:
� Requisitos Não – Funcionais podem ser classificados
como:
Engenharia de Software
- Confidencialidade; - Portabilidade;
C fi bilid d P i
50
- Confiabilidade; - Precisão;
- Performance; - Integridade;
- Qualidade; - Segurança;
- Usabilidade; - etc.
Identificação dos Requisitos - Tipos:
� Os requisitos de software podem ser identificados no
texto da “declaração do problema” (geralmente são
verbos que identificam algumas ações).
� Exemplo: Um sistema acadêmico
Engenharia de Software
51
� Exemplo: Um sistema acadêmico.
� Declaração do Problema : Acompanhamento das
estatísticas de aprendizado do aluno e da turma
(professor)
� Informação: Relatório de aproveitamento do aluno e da
turma (s)
Identificação dos Requisitos - Tipos:
Requisitos Funcionais:
� O sistema deve registrar as principais ações de cada usuário.
� O sistema deve fornecer um relatório do aproveitamento do
aluno
Engenharia de Software
52
aluno.
� O relatório de aproveitamento do aluno deve conter o tempo
de uso do software, o número de exercícios feitos, o número
de acertos e o de erros.
� O sistema deve fornecer um relatório do aproveitamento da
turma.
� O relatório de aproveitamento da turma deve conter a média
e o desvio-padrão dos seguintes dados: tempo de uso do
software, número de exercícios feitos, número de acertos e
erros de cada exercício.
Identificação dos Requisitos - Tipos:
Requisitos Não -Funcionais:
� O sistema deve usar gráficos comparativos do
aproveitamento do aluno com a média da turma.
Engenharia de Software
53
� O sistema deve usar cores na construção dos gráficos.
� O tempo de resposta na elaboração do relatório não pode ser
superior a 15 segundos.
Identificação dos Requisitos - Tipos:
Identificação das Retrições
� Definem o conjunto de restrições impostas sobre o
desenvolvimento do software.
� Restrições definem por exemplo a adequação a custos e
Engenharia de Software
54
Restrições definem, por exemplo, a adequação a custos e
prazos, a plataforma tecnológica, aspectos legais
(licenciamento), limitações sobre a interface com usuário,
componentes de hardware e software a serem adquiridos etc.
� Nesta momento apenas identificamos as restrições e criamos
uma Lista das Restrições, esta lista podem ser divida em
partes como:
� Restrições de Hardware, Restrições de Software e Restrições
de Ambiente e Tecnologia.
Identificação dos Requisitos - Tipos:
Exemplo de Retrições:
� Quando o projeto requer uma determinada tecnologia,
tal como WebServices.
Engenharia de Software
55
� Ou quando o software necessita de algum hardware ou
software em especifico. Tal como um servidor exclusivo
para banco de dados.
Exercícios
56