Engenharia de Software
Requisitos de Software Capitulo 5 e 6 PLT
https://sites.google.com/site/thiagoaalves/ thiago.augusto2@anhanguera.com
Aula
Visão Geral de Requisitos;
Entendimento dos Requisitos; Problemas;
Engenharia de Software
Analise de Requisitos de Software Dentro da Engenharia de Software e um
Engenharia de Software
Um entendimento completo dos
requisitos de software é 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
Engenharia de Software
Análise de requisitos é um processo de
descoberta, refinamento, modelagem e especificação.
Engenharia de Software
O escopo do software, inicialmente
estabelecido pelo 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.
Reflexão
Por que na Analise de Requisitos o
Analista e o Usuário tem um papel importante?
Quais Problemas podem ocorrer se os
Engenharia de Software
O cliente (ou usuário) tenta reformular um
conceito de função e desempenho de
software, às vezes nebuloso, sem detalhes concretos. O analista age como indagador, consultor e solucionador de problemas.
Entretanto, a análise e especificação de
requisitos pode parecer uma tarefa
relativamente simples, mas as aparências enganam. O grau comunicação é elevado. Daí, surgem as oportunidades de
interpretações errôneas e informações falsas. A ambigüidade é provável.
Reflexão
Por que o Analista e considerado um
solucionador de problemas?
Por que ele não pode chegar já com a
Engenharia de Software
O dilema com o qual se depara um
analista pode ser mais bem entendido, repetindo-se a declaração de um cliente anônimo:
“Sei que você acredita que entendeu o
que acha que eu disse, mas não estou certo que percebeu que aquilo que
ouviu não é o que eu pretendia dizer...”
Engenharia 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.
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
Engenharia de Software
O que pode acontecer quando os
requisitos estão mal feitos?
Ariane 5; Therac-25;
Engenharia de Software
Foguete Ariane 5
Projeto da Agência Espacial Europeia que
custou:
◦ 10 Anos;
Engenharia de Software
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.
Engenharia de Software
Aconteceu um problema de overflow
durante conversão de ponto flutuante p/ inteiro, fazendo com que os sistema
principal junto com o sistema de backup se desligassem simultaneamente.
Computação que causou o acidente por
que desnecessário os calculos após a decolagem!
Engenharia de Software
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. 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.
Engenharia de Software
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 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;
Engenharia de Software
◦ 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:
◦ 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
Engenharia de Software
◦ 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;
◦ O software considerava que os
sensores sempre funcionavam corretamente, e não havia como verificar isto;
Engenharia de Software
◦ 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 para os controles (o que levava a aplicação das doses letais);
◦ Overflows podiam fazer o software
não executar procedimentos de segurança;
Engenharia de Software
London Ambulance System
Despacho de ambulâncias em Londres,
1992.
Morte de pessoas que não foram
Engenharia de Software
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
Engenharia de Software
É 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.
Tempo de reparar um defeito:
◦ Gastando 30 minutos na fase de requisitos se economiza em media : 5 a 17 horas na fase de testes .
Engenharia de Software
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 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.
Engenharia 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,
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. "
Engenharia de Software
Apesar de parecer simples, trata-se de um processo extremamente complexo. Algumas das razões desta dificuldade:
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;
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 negócio, omitem informações que
julgam óbvias e etc.
Problemas de volatilidade:
Engenharia de Software
Para ajudar a superar estes problemas, os
desenvolvedores devem abordar os requisitos de forma simples, prática e organizada. Alguns passos são
recomendados para atividade de
Engenharia de Software
◦ Avaliar a viabilidade técnica e de negócio para o sistema proposto;
◦ 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;
Engenharia de Software
◦ Definir um ou mais métodos de elicitação de requisitos;
◦ 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.
Engenharia 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.
Engenharia de Software
Para a maioria dos sistemas, estes
documentos de 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;
Engenharia de Software
◦ Lista de requisitos e as regras de domínio aplicáveis a cada um.
◦ 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.
Engenharia 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
Um mapa geral do processo de
Engenharia 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 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.
Engenharia 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 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
Cuidado
Cuidado com :” geralmente tem uma
abordagem intuitiva.”
Sua intuição pode não ser
Engenharia 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;
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
Engenharia de Software
Elicitação Boa Elicitação Ruim
Bom Diagnóstico Diagnóstico ineficiente
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
Engenharia de Software
As informações podem ser identificadas ou
encontradas em diversas fontes: ◦ Usuários; ◦ Documentos; ◦ Especificações técnicas; ◦ Clientes; ◦ Sistemas legados ◦ Patrocinadores; ◦ Analista de Negócio;
◦ “Domain Experts” - Especialista em uma ou mais área de negócio.
Engenharia 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; Entrevistas; Questionários; Workshop; Brainstorming;
JAD (Join Application Development) Fast;
Análise de Documentos;
Engenharia 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 são:
◦ Entendimento do problema, identificação
da lista dos principais usuários, lista dos principais Requisitos, identificação dos
Engenharia de Software
Daí 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;
◦ Identificação dos Requisitos;
◦ Identificação dos Riscos ;
Engenharia 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:
É 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.
◦ 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
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:
O que o software deve fazer ?
Engenharia de Software
Devemos identificar também as principais
características do software como: ◦ Performance:
Qual é tempo de resposta adequado ?
◦ 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
Engenharia de Software
Os requisitos encontrados não devem ser
descritos neste momento, precisamos apenas identificá-los, ou seja, é uma
Engenharia de Software
Identificação dos Requisitos: Tipos
de Requisitos
Os requisitos podem ser divididos em
Engenharia de Software
Identificação dos Requisitos: Tipos
de Requisitos
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
Exemplo:
◦ Cadastrar Clientes;
◦ Fazer Análise de Crédito;
◦ Fazer uma Transação com Banco de Dados;
◦ Cadastrar um Registro de Atendimento;
Engenharia de Software
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 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.”
Engenharia de Software
Podem ser Classificados como:
- Confidencialidade; - Portabilidade; - Confiabilidade; - Precisão;
- Performance; - Integridade;
- Qualidade; - Segurança;
Engenharia de Software
Identificação dos Requisitos: Os requisitos de software podem ser
identificados no texto da “declaração do
problema” (geralmente são verbos que
Engenharia de Software
Exemplo: Vamos pensar em um
sistema acadêmico.
Declaração do Problema
Exemplo: Acompanhamento das
estatísticas de aprendizado do aluno e da turma (professor)
Informação: Relatório de aproveitamento do
Engenharia de Software
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.
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
Engenharia de Software
Requisitos Não-Funcionais:
O sistema deve usar gráficos comparativos
do aproveitamento do aluno com a média da turma
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.
Engenharia de Software
Identificação das Restrições:
Definem o conjunto de restrições impostas sobre o desenvolvimento do software.
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.
Engenharia de Software
Exemplo de Restrição:
Quando o projeto requer uma
determinada tecnologia, tal como WebServices.
Ou quando o software necessita de algum
hardware ou software em especifico. Tal como um servidor exclusivo para banco de dados.
Exercício
Faça o Levantamento dos Requisitos
Funcionais e Não Funcionais para o seguinte Problema:
“A escola XYZ, precisa de um sistema para
lançamento das notas dos alunos do seu
curso de Informática. Cada aluno e alocado a turma e cada turma e associado somente a um professor.”
Trabalho Parte 1
A partir do sorteio realizado em sala de
aula, levantar os pontos mais importantes dos seguintes métodos utilizados para o levantamento de requisitos.
Apresentar:
◦ Ideia;
◦ Como funciona;
Trabalho Parte 1 – Manha
◦ Reuniões formais; ◦ Reuniões informais; ◦ Entrevistas; ◦ Questionários; ◦ Workshop; ◦ Brainstorming;◦ JAD (Join Application Development)
Trabalho Parte 1 – Noite
◦ Reuniões formais; ◦ Reuniões informais; ◦ Entrevistas; ◦ Questionários; ◦ Workshop; ◦ Brainstorming;◦ JAD (Join Application Development)
Referencias
SOMMERVILLE, Ian (org.). Engenharia
de Software. 9ª ed. São Paulo:
PEARSON, 2011.
PRESSMAN, Roger S.. Engenharia de
Software. 7ª ed. São Paulo: Makron
