Engenharia de Software
Requisitos de Software Capitulo 5 e 6 PLT
https://sites.google.com/site/thiagoaalves/
Aula
Requisitos Funcionais;
Requisitos Não Funcionais; Regras de Negócio.
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)
Manha
2-Debora - Workshop
1-Muller - Reuniões Formais 7-Felipe - FAST
4-Elaine - Questionarios 3-Yasser - JAD
6-Reginaldo - Reuniões Infor 5-Marcelo - Brainstorming
Relembrando
Você lembra o que é um requisito?
Qual a importância dos requisitos para o
software?
Engenharia de Software
“Requisitos: Condição necessária para a
obtenção de certo objetivo, ou para o preenchimento de certo objetivo.”
Um Porshe 911 Carrera tem mais ou
menos as mesmas funções de um Fiat 147c, mas muito, muitos atributos
Engenharia de Software
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
Engenharia de Software
Exemplo:
◦ 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;
◦ As cores utilizadas devem ser vermelho e preto; ◦ O tempo de resposta na elaboração do relatório
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.
Engenharia de Software
A Análise de Requisitos deve ser:
◦ Correta: Quando cada requisito expresso nela for encontrado no software;
◦ Não Ambígua: Cada requisito deve ter somente uma interpretação;
◦ Completa: Quando incluir todos os requisitos significativos relacionados as funcionalidades e requisitos relacionados a qualidade do serviço
(também conhecidos como requisitos não funcionais)
◦ Consistente: Quando não existir conflito entre os requisitos;
◦ Verificável: Quando for possível verificar/validar cada requisito;
◦ Modificável: Quando os requisitos podem ser facilmente alterados.
Engenharia de Software
O que são requisitos do cliente?
◦ Requisitos não falam sobre o sistema, mas sobre os efeitos do sistema;
◦ O requisito se refere a um problema que existe no mundo, não na máquina;
◦ O software é uma solução para algum
Engenharia de Software
Tipos de requisitos
◦ Funcionais;
◦ Restrições de projeto;
◦ Restrições de processo;
◦ Requisitos de qualidade ou não-funcionais;
Engenharia de Software
Requisitos funcionais
Definem a funcionalidade esperada do
sistema:
◦ O que o sistema deve fazer?
◦ Quando ele deve atuar?
◦ Que tipo de cálculos devem ser realizados?
◦ Como o sistema deve reagir a eventos externos?
Engenharia de Software
Requisitos funcionais
Também definem informações sobre os
dados:
◦ Qual deve ser o formato dos dados de entrada e saída?
Engenharia de Software
Restrições de projeto
São restrições relativas a fatores externas
ao sistema, como:
◦ ambiente de desenvolvimento;
◦ ambiente de execução;
◦ interfaces com outros sistemas;
Engenharia de Software
Restrições de projeto Ambiente:
◦ Onde vai ficar o equipamento?
◦ Há restrições de temperatura, humidade, ou outras?
◦ Há restrições no tamanho do sistema?
◦ Há restrições na linguagem de programação usada, devido a outros sistemas existentes?
Engenharia de Software
Restrições de projeto Interfaces
◦ O sistema receberá entrada de outros sistemas? ◦ O sistema enviará dados para algum outro
sistema?
◦ Que meios o sistema deve usar para interagir com o usuário?
Usuários
◦ Quem usará o sistema?
◦ Haverá diversos tipos de usuário?
Engenharia de Software
Restrições de Processo
São restrições relativas à forma como o
desenvolvimento do sistema será conduzido:
◦ recursos disponíveis;
◦ documentação exigida;
◦ normas a serem seguidas;
◦ processo de desenvolvimento de software a ser seguido.
Engenharia de Software
Restrições de Processo Recursos
◦ Há restrições de materiais ou pessoas disponíveis para o projeto?
◦ Qual o nível esperado de capacidade dos desenvolvedores?
Documentação
◦ Quanta documentação é necessária?
Engenharia de Software
Restrições de Processo Normas
◦ Existem normas (IEEE, etc.) que devem ser seguidas?
Processos
◦ O sistema precisa ser desenvolvido seguindo algum processo (RUP, etc.)?
Engenharia de Software
Requisitos de Qualidade
Também chamados de requisitos não funcionais.
Descrevem características desejadas do
sistema.
Engenharia de Software
Desempenho
◦ Há restrições no tempo de execução ou de resposta do sistema?
◦ Qual o volume de dados que o sistema deve ser capaz de processar em um dado intervalo de tempo?
◦ Com que freqüência os dados serão recebidos ou enviados?
Engenharia de Software
Requisitos de Qualidade
Capacidade
◦ Com quantos itens de dados o sistema consegue lidar durante a sua vida?e durante um certo momento?
◦ Quantos novos itens de dados ele pode receber em um determinado intervalo de tempo?
◦ Quantos usuários podem utilizar o sistema
simultaneamente sem degradação de desempenho?
◦ Quantos relatórios podem ser produzidos por hora?
Todo requisito de capacidade deve
terminar com uma afirmação: ... sem degradação do tempo de resposta.
Engenharia de Software
Requisitos de Qualidade
Degradação
◦ Define o que é esperado do comportamento do sistema quando os requisitos de capacidade são violados.
◦ Todas as requisições a partir na 100ª serão ignoradas, terão degradação no tempo de resposta conforme tabela abaixo:
Requisição Degradação
101 10%
Engenharia de Software
Usabilidade
◦ O quão fácil deve ser para um usuário compreender e usar o sistema?
◦ O quão difícil deve ser para um usuário usar incorretamente o sistema?
Engenharia de Software
Segurança
◦ O acesso ao sistema ou à informação deve ser controlado?
◦ Os dados de um usuário devem ser isolados dos dados dos outros?
◦ Que precauções devem ser tomadas contra o uso indevido do sistema?
Engenharia de Software
Confiabilidade:
◦ O sistema deve detectar e/ou corrigir falhas?
◦ Qual é a tolerância para o tempo médio entre falhas?
Engenharia de Software
Manutenibilidade / Adaptabilidade
◦ A manutenção prevista envolve apenas
correção de erros ou também melhorias ao sistema?
◦ Em que maneiras se espera que o sistema seja alterado no futuro?
◦ O quão simples deve ser a adição de novas funcionalidades ao sistema?
◦ O sistema deve ser portável a outras plataformas?
Engenharia de Software
Podemos resumir os requisitos de
qualidade ou não funcionais da seguinte forma:
Performance:
◦ Tempo de resposta
Segurança:
◦ Uso de senhas, certificados digitais e etc..
Usabilidade:
◦ Identidade Visual e Interfaces amigáveis
Disponibilidade:
◦ O software deve estar disponível para usuário 24x7.
Engenharia de Software
Flexibilidade:
◦ Capacidade de adaptação quando um requisito muda
Portabilidade:
◦ Capacidade de se adaptar a outros ambientes (sistemas operacionais)
Escalabilidade:
◦ Capacidade de responder aumento de carga (novos usuários)
Exemplos de Requisitos Não
Funcionais
Desempenho ("Ao registrar um item
sendo vendido, a descrição e preço devem aparecer em, no máximo, 2 segundos");
Volume de utilização, incluindo número
de usuários, número de transações, ... ("O sistema deverá suportar uma carga máxima de 2000 usuários simultâneos com
degradação de desempenho de, no máximo, 10% em qualquer operação");
Exemplos de Requisitos Não
Funcionais
Disponibilidade ("O sistema estará
disponível pelo menos 99,7% do tempo em dias de semana entre 06:00 e meia-noite e pelo menos 99,95% entre 16:00 e 18:00");
Flexibilidade ("Um programador de
manutenção com pelo menos 6 meses de experiência no suporte ao produto deverá ser capaz de dar suporte a um outro
dispositivo de interconexão em não mais do que 1 hora de trabalho");
Exemplos de Requisitos Não
Funcionais
Integridade/segurança ("Apenas usuários
com privilégios de acesso de Auditor
poderão visualizar históricos de transações de clientes");
Interoperabilidade ("O Sistema de
Rastreamento de Produtos Químicos deverá ser capaz de importar qualquer estrutura química válida das ferramentas ChemiDraw e Chem-Struct");
Exemplos de Requisitos Não
Funcionais
Compatibilidade com outras versões e
necessidades de migração ("O sistema deverá reconhecer arquivos de versões antigas e transformar os arquivos para o novo formato automaticamente, após
confirmação pelo usuário");
Confiabilidade ("Não mais do que 5
experimentos químicos em cada 1000 podem ser perdidos devido a falhas de software");
Exemplos de Requisitos Não
Funcionais
Robustez ("Todas as variáveis de entrada
terão valores default e tais valores serão usados sempre que dados de entrada
estiverem faltando ou inválidos");
Tolerância a falha ("O sistema deve fazer
log dos pagamentos autorizados via cartão de crédito em 24 horas, mesmo com falhas de energia ou de dispositivo");
Exemplos de Requisitos Não
Funcionais
Usabilidade ("Um novo usuário deverá ser
capaz de fazer um pedido de compra de um novo produto químico após não mais do
que 30 minutos de orientação");
Tipo de interface desejada ("O sistema
deverá ser acessado completamente via browser HTTP/HTML");
Exemplos de Requisitos Não
Funcionais
Hardware e software alvo ("O produto
será desenvolvido para ambientes Windows e para máquinas com pelo menos 128 MB de memória");
Necessidades de
internacionalização ("O produto será
disponibilizado em inglês, mas de forma a permitir que versões em línguas latinas
possam ser produzidas sem necessidade de ter acesso ao código fonte");
Exemplos de Requisitos Não
Funcionais
Documentação necessária ("A
documentação on-line incluirá um Tutorial e um Manual de Referência");
Uso de padrões ("O produto deverá dar
suporte aos protocolos SNMP versões 1, 2 e 3");
Exemplos de Requisitos Não
Funcionais
Aspectos legais ("O sistema deverá seguir
regras do documento XPTO-12X/2001 do Banco Central no que diz respeito à
auditibilidade das transações efetuadas");
Preço da solução ("O produto deverá ser
desenvolvido de forma a possibilitar um
Exemplos de Requisitos Não
Funcionais
Packaging ("O produto será distribuído
exclusivamente pela Internet, sem opção para aquisição de CDROM ou de manuais
impressos. O tamanho máximo do download deve ser de 10 MB");
Requisitos de instalação ("O Produto deve ser instalável através do instalador RPM do
Linux")
Business rules ("Apenas usuários com cargos de supervisão podem aceitar retorno de
Engenharia de Software
Como saber se cada requisito foi
satisfeito?
Critérios de aceitação para requisitos não
funcionais devem ser mensuráveis.
Se você não conseguir achar um
critério de aceitação mensurável
para um requisito não funcional, ele não pode ser um requisito.
Reflexão
E fácil mensurar a Qualidade?
Engenharia de Software
Exemplo: requisito não funcional de
desempenho as transações de compra de livros devem ter desempenho aceitável;
Critérios de aceitação:
◦ 80% das transações de compra de livro devem ser executadas em no máximo 0,5 segundo;
Engenharia de Software
Exemplo: requisito não funcional de
usabilidade ,deve ser fácil aprender a usar o sistema;
Critério de aceitação:
◦ um usuário especialista deve ser capaz de realizar em menos de 5 minutos qualquer tarefa disponibilizada pelo sistema após um
Engenharia de Software
Exemplo: requisito de projeto, O sistema
deve minimizar o tráfego de dados pela rede;
Critério de aceitação:
◦ o volume de dados total enviado pelos nodos do sistema não deve ser superior a 1 Gb em um período qualquer de 24 horas.
Engenharia de Software
Exemplo: requisito de processo, a
especificação de requisitos do sistema deve seguir a norma IEEE 830-1998;
Critério de aceitação:
◦ a especificação será inspecionada por um
consultor licenciado pela IEEE que fornecerá um certificado de conformidade com a norma 830-1998.
Engenharia de Software
Ambigüidade
Muitas vezes um requisito está sujeito
a mais de uma interpretação;
Sempre que isso for o caso, é necessário
esclarecer melhor o requisito para que seu entendimento seja uniforme;
Definir critérios de aceitação ajuda a
Engenharia de Software
Se eu não tiver animais, eu não posso entrar? Se eu não tiver sapatos, tudo bem, não
Engenharia de Software
Cuidado com palavras que indicam
imprecisão ou múltiplas possibilidades, como:
◦ aceitável, adequado, suficiente; ◦ Dependendo;
◦ eficiente, rápido, fácil, flexível, robusto, elegante; ◦ melhor, superior;
◦ normalmente, de preferência;
Engenharia de Software
Vamos ver alguns exemplos de requisitos
que podem apresentar varias interpretações:
Engenharia de Software
Depois de 3 ou 4 dias, deve-se cancelar a reserva;
◦ afinal de contas, são 3 dias, ou 4 dias?
Deve haver uma reserva para todos os viajantes;
◦ é uma reserva só para todos, ou uma para cada viajante?
O valor da passagem é impresso no bilhete em quase 100% dos casos;
◦ em quais casos ele não deve ser impresso?
a cada trinta minutos, um funcionário faz a vistoria
das engrenagens;
◦ é sempre o mesmo funcionário, ou são funcionários diferentes?
Engenharia de Software
Correção dos requisitos ambíguos:
◦ Deve-se cancelar a reserva após 3 dias durante a alta temporada, ou após 4 dias durante a baixa temporada;
◦ Cada um dos os viajantes deve ter sua própria reserva;
◦ O valor da passagem é sempre impresso no bilhete, exceto quando o passageiro usa o
programa de milhas como forma de pagamento; ◦ a cada trinta minutos, o supervisor encarregado
Engenharia de Software
Contradições / Inconsistências
Dois ou mais requisitos podem fazer
exigências que são impossíveis de se satisfazer simultaneamente;
Em geral cabe ao cliente resolver a
contradição, e não ao analista;
Resolve-se de duas formas:
◦ Alterando um dos requisitos;
◦ Acrescentando condições para a aplicação de cada requisito.
Engenharia de Software
req 1: “todos que são clientes há mais de 10 anos têm
direito a isenção de tarifas”;
req 2: “nenhum cliente que já teve 5 ou mais cheques
devolvidos tem direito a isenção de tarifas”;
◦ o que fazer com aqueles que são clientes há mais de 10 anos e tem 5 ou mais cheques devolvidos?
Resolução das contradições
req 1: “todos que são clientes há mais de 10 anos têm direito a isenção de tarifas”;
req 2: “nenhum cliente que já teve 5 ou mais cheques devolvidos tem direito a isenção de tarifas, exceto os que forem clientes há mais de 10 anos” ;
Engenharia de Software
req1: “conceder exatamente uma pipoca grátis para quem alugar 3 filmes ou menos, no mesmo dia”;
req 2: “conceder exatamente duas pipocas grátis para quem alugar 3 filmes ou mais, no mesmo dia”;
◦ quantas pipocas deve ganhar quem leva 3 filmes? Resolução das contradições
req1: “conceder exatamente uma pipoca grátis para
quem alugar 3 filmes ou menos, no mesmo dia”;
req 2: “conceder exatamente duas pipocas grátis para
Engenharia de Software
Lembrando:
Cabe ao Cliente resolver as
contradições;
Engenharia de Software
Regras de Negocio
Regras do Negócio são declarações sobre
a forma da empresa fazer negócio.
Elas refletem políticas do negócio.
Organizações têm políticas para satisfazer os
objetivos do negócio,satisfazer clientes, fazer bom uso dos recursos, e obedecer às leis ou convenções gerais do negócio.
Engenharia de Software
É a regra de negócio que especifica as
particularidades das funcionalidades a serem desenvolvidas.
As regras de negocio ajudam a entender o
funcionamento da empresa e obviamente o funcionamento do sistema.
Engenharia de Software
Regras do Negócio tornam-se requisitos,
ou seja, podem ser implementados em um sistema de software como uma forma de requisitos de software desse sistema.
Representam um importante conceito dentro
do processo de definição de requisitos
para sistemas de informação e devem ser vistas como uma declaração genérica sobre a
Engenharia de Software
As regras de negócio definem como o seu
negócio funciona, podem abranger diversos assuntos como suas políticas, interesses,
objetivos, compromissos éticos e sociais,
obrigações contratuais, decisões estratégicas, leis e regulamentações entre outros.
Reflexão
Como Diferenciar : ◦ Requisitos? ◦ RNF? ◦ Regras de Negocio; Resposta:◦ São Ações que o meus sistema tem que apresentar;
◦ São características do meu sistema;
◦ Normalmente tem haver com o problema em sí e não ao sistema.
Dica de Ouro
Para saber se um Regra de Negocio e
uma Regra de Negocio ou um Requisito, basta tirar o sistema dela, se ela ainda
Extra Point (Não e ponto extra)
Recomendo escutar os seguintes
PODCAST: http://www.ricardo- vargas.com/pt/podcasts/project-quality-requirements/ http://www.ricardo-vargas.com/pt/podcasts/escopopreliminar/ http://www.ricardo-vargas.com/pt/podcasts/quality_req_crit/
Exercício
Pegando como base o seguinte cenário
realize o levantamento de requisitos para atender o problema:
◦ Requisitos Funcionais;
◦ Requisitos Não Funcionais;
◦ Regras de Negocio;
◦ Restrições de Projeto;
Engenharia de Software
Uma cooperativa de taxistas solicitou a construção de um sistema de
informação para facilitar e agilizar o seu funcionamento. Esta cooperativa possui vários associados e motoristas. A diferença existente entre estas duas categorias está na propriedade do veículo. Assim, o associado é dono de pelo menos um táxi, enquanto o motorista não necessariamente
precisa possuir um táxi para estar vinculado à cooperativa. O cadastro dos associados e motoristas da cooperativa, assim como de seus veículos, deverá fazer parte do sistema que será desenvolvido. Além disso, a
cooperativa mantém vários convênios. O cadastro destes convênios
também deverá fazer parte do sistema. No momento do cadastro de um convênio, deverão ser informados os modelos e as marcas de veículos aceitos pelo convênio. Cada veículo pode atender a mais de um convênio. Quando uma solicitação de táxi for cadastrada no sistema, um táxi deverá ser alocado para atendê-la. Para que um táxi seja selecionado para
atender a uma solicitação, é necessário que seu modelo e sua marca sejam aceitos pelo convênio. A verificação dessas restrições, assim como a
atribuição de um táxi para atender a uma solicitação também devem ser incorporados ao sistema. Considere que esta cooperativa de taxistas atende apenas convênios.
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 Books,
2007. http://homepages.dcc.ufmg.br/~figueiredo/dis ciplinas/aulas/req-funcional-rnf_v01.pdf acessado em 01/05/2015 as 22:30 http://www.dsc.ufcg.edu.br/~jacques/cursos/ proj/gerenciadesenv/naofuncionais.htm acessado em 01/05/2015 as 22:50
