Elicitação
• Objetivo
– Entender o que o cliente espera do software
• Problemas mais comuns
– Escopo variável (mas contrato fixo)
– Incertezas do cliente
Elicitação
• Elementos a serem identificados
– Objetos manipulados pelo sistema
– Serviços prestados pelo sistema
– Restrições que devem ser obedecidas
– Critérios de desempenho
• Resultados esperados
– Narrativa em linguagem natural dos requisitos do
sistema
Tipos de requisitos
• Requisitos de usuário
– Declarações em linguagem natural mais diagramas de serviços que o sistema fornece e suas restrições
operacionais. Escritos para os usuários.
• Requisitos de sistema
– Um documento estruturado estabelecendo descrições detalhadas das funcionalidades, serviços e restrições operacionais do sistema. Define o que deve ser
implementado e assim, pode ser parte de um contrato entre o cliente e o desenvolvedor.
O sistema LIBSYS
• Visão geral do sistema:
– Um sistema de biblioteca que fornece uma interface única para uma série de banco de dados de artigos em
bibliotecas diferentes.
– Os usuários podem pesquisar, baixar e imprimir estes artigos para estudo pessoal.
Elicitação
• Cliente x Usuário final
– Nem sempre o cliente é o usuário final
– Cliente
• Quem contrata e paga pelo serviço. • Ex.: Administrador de um hospital
– Usuário final
• Quem usa o software no dia a dia • Ex.: Médicos e enfermeiros
– Importante
• Nunca deixe de elicitar requisitos com os usuários finais pois sem a colaboração deles, o software não será usado.
Elicitação
• Escolha dos usuários fonte
– Alguns sistemas serão utilizados por milhares ou
milhões de usuários
– Escolha usuários fonte dos requisitos que sejam
representativos
– 20% dos requisitos satisfazem a 80% dos usuários
• Escolher um usuário muito especialista pode levar a implementação de requisitos que nunca serão
Elicitação
• Maximizar a satisfação do cliente!
– Requisito normal
• O cliente lembra de falar
• O cliente ficará satisfeito se esse requisito estiver no sistema
– Requisito esperado
• Requisito implícito
• O cliente não lembra de falar
• O cliente ficará insatisfeito se esse requisito não estiver no sistema
Elicitação
• Maximizar a satisfação do cliente!
– Requisito excitante
• O cliente não lembra de falar
• O cliente não espera encontrar esse requisito no sistema
• O cliente ficará satisfeito se esse requisito estiver no sistema
Técnicas de Elicitação
• Entrevistas
• Oficinas (workshops)
• Reuniões de Brainstorming
• Prototipação
• Maquetes
• Análise de documentação existente
• Análise de sistemas existentes
• Observação de pessoas trabalhando (Etnografia)
• Análise de mercado
Engenharia de Requisitos
Tipos de Requisitos
• Requisitos Funcionais
– RF são requisitos diretamente ligados a funcionalidade do software.
• Requisitos Não Funcionais
– RNF são requisitos que expressam restrições que o
software deve atender ou qualidades específicas que o software deve ter.
Requisitos de domínio(RF ou RNF)
– Requisitos que vêm do domínio de aplicação do sistema e que refletem as características desse domínio.
Requisitos funcionais
• Descrevem a funcionalidade ou serviços de sistema.
• Dependem do tipo de software, dos usuários
esperados e o tipo de sistema onde o software é
usado.
• Requisitos funcionais de usuário podem ser
declarações de alto nível do que o sistema deve fazer
mas os requisitos funcionais de sistema devem
Exemplos de requisitos funcionais
• O sistema deve fornecer ao usuário a opção pesquisar na base de dados de produtos.
• Para todo pedido deve ser gerado um identificador único no qual o usuário poderá utilizar para fazer pesquisas e obter todas as informações referentes ao pedido.
• O sistema deve fornecer ao usuário a opção de cadastrar um contato. Um contato possui as seguintes informações: nome, telephone, link de rede social.
Requisitos não funcionais
• Definem propriedades e restrições de sistema:
– confiabilidade, tempo de resposta e requisitos de
armazenamento, capacidade de dispositivos de
E/S, etc.
• Podem ainda estar relacionados a portabilidade, de
SO, de BD, etc.
Requisitos não funcionais
• Requisitos não funcionais podem ser mais críticos do
que os requisitos funcionais. Se estes não forem
atendidos, o sistema é inútil.
• Requisitos não funcionais estão relacionados a
Classificações de requisitos não
funcionais
• Requisitos de produto
– Requisitos que especificam que o produto entregue deve se
comportar de uma maneira particular, por exemplo, velocidade de execução, confiabilidade, etc.
• Requisitos organizacionais
– Requisitos que são uma conseqüência de políticas e procedimentos da organização, por exemplo, padrões de processo usados,
requisitos de implementação, etc.
• Requisitos externos
– Requisitos que surgem a partir de fatores externos ao sistema e seu processo de desenvolvimento, por exemplo, requisitos de interoperabilidade, requisitos legais, etc.
Requisitos Não Funcionais
• Disponibilidade
– DS-1: O sistema deve ficar disponível por 99,5% do tempo nos dias úteis, das 6h às 22h
• Eficiência
– EF-1: Em condições de pico de uso, o sistema deve ter uma reserva de 25% de capacidade de processamento e
memória
– EF-2: O sistema deve finalizar o cálculo de interferência com sucesso em menos de 5 minutos
– EF-3: O módulo de parser de XML do sistema deve processar 1.000.000 de documentos por segundo
Requisitos Não Funcionais
• Flexibilidade
– FL-1: Um novo tipo de sensor deve poder ser configurado no sistema em menos de 3 horas
• Integridade
– IN-1: Transações históricas dos consumidores só poderão ser vistas por usuários com privilégios de “auditor”
• Interoperabilidade
– IT-1: O sistema deve ser capaz de importar dados tanto do MS Office (versão 2003) quanto do OpenOffice (versão 2.4)
Requisitos Não Funcionais
• Confiabilidade
– CF-1: Em cada 1000 execuções, não mais do que 2 podem apresentar falhas de software
• Robustez
– RB-1: Se acontecer uma falha antes do usuário salvar, o sistema deve recuperar uma versão não salva com perda de conteúdo menor que 1 minuto de trabalho
• Manutenibilidade
– MN-1: Todos os métodos devem ser documentados utilizando a notação Javadoc
– MN-2: Modificações corretivas devem ser feitas em menos de 5 horas
Requisitos Não-Funcionais
• Usabilidade (Facilidade no uso)
– US-1: Um usuário treinado deve ser capaz de submeter um pedido de compra em menos que 5 minutos
– US-2: Um usuário não treinado deve ser capaz de submeter um pedido de compra em menos que 30 minutos
– US-3: Todos os comandos de menu devem ter teclas de atalho associadas
• Portabilidade
– PR-1: O sistema deve poder ser executado em sistema
operacional Windows e Linux, nas arquiteturas i386, AIX e SPARC
Problemas
• Falta de clareza
– Pode ser difícil uma linguagem precisa e não
ambígua
• Confusão de requisitos
– Requisitos pode estar misturados com
informações do projeto
• Fusão de requisitos
– Diversos requisitos expressos juntos
Falta de Clareza
• Os requisitos precisam ser claros e precisos
• Requisitos ambíguos podem ser interpretados de
maneiras diferentes pelos desenvolvedores e
usuários.
• Requisito: O sistema deve ter telas apropriadas para
a exibição dos relatórios.
• Considere o termo ‘telas apropriadas’
– Intenção do usuário – tela de propósito especial para cada tipo diferente de documento;
– Interpretação do desenvolvedor – fornece uma tela de texto que mostra o conteúdo do documento.
Requisitos completos e consistentes
• Em princípio, requisitos devem ser ambos, completos e consistentes.
• Completeza
– Eles devem incluir descrições de todos os recursos requeridos.
• Consistência
– Não deve haver conflitos ou contradições nas descrições dos recursos de sistema.
• Na prática, é impossível produzir um documento de requisitos completo e consistente.
Conflito
• Requisitos não funcionais normalmente
entram em conflito com outros requisitos e é
preciso haver negociação.
– Eficiência X segurança
– Confiabilidade X Eficiência
– Usabilidade X Segurança
Requisitos de domínio
• Derivados do domínio de aplicação e descrevem
características de sistema que refletem o domínio.
• Podem restringir os requisitos funcionais existentes
ou estabelecer como cálculos especificos devem ser
realizados.
• Se os requisitos de domínio não forem satisfeitos, o
sistema pode não funcionar.
Requisitos de domínio do sistema de
bibliotecas
• Deve existir uma interface de usuário padrão para todos os bancos de dados que será baseada no padrão Z39.50.
• Devido às restrições de direitos autorais, alguns
documentos devem ser excluídos imediatamente na chegada. Dependendo dos requisitos de usuário, esses documentos serão impressos localmente no servidor de sistema para serem encaminhados manualmente para o usuário ou direcionados para uma impressora de rede.
Problemas de requisitos de domínio
• Facilidade de entendimento
– Requisitos são expressos na linguagem do
domínio de aplicação;
– Isso não é, freqüentemente, compreendido pelos
engenheiros de software que estão
desenvolvendo o sistema.
• Implícito
– Especialistas em domínio compreendem a area
tão bem que não pensam em tornar os requisitos
de domínio explícitos.
Elicitação
• Dificuldades:
• Stakeholders não sabem o que querem do sistema e não expressam o que querem
• Stakeholders expressam requisitos naturalmente usando seus próprios termos (domínio)
• Diferentes stakeholders têm diferentes requisitos
• Fatores políticos podem influenciar (mais poder para um gerente)
• Ambiente dinâmico muda constantemente. Novos requisitos podem surgir de novos stakeholders
Elicitação
• Engenheiros de software, clientes e usuários finais do
sistema e outros envolvidos (stakeholders) trabalham
para aprender
•
Sobre o domínio da aplicação
•
Quais serviços/funcionalidades o sistema deve
fornecer
•
O desempenho esperado
•
As restrições de hardware, do ambiente, do
negócio
Elicitação
• Extrair o Conhecimento Tácito
– Trivial
• Internalizado
• Nunca é lembrado!
• Problema de comunicação – Não de
requisitos!!!!
Elicitação
• Processo interativo com realimentação
contínua (cíclico)
• Atividades:
•
Obtenção de requisitos (coleta de dados)
•
Classificação e organização de requisitos
•
Priorização e negociação de requisitos
Documento de Requisitos de
Software
Documento de Especificação de
Requisitos
• O documento de requisitos do software deve ser
composto por sentenças em linguagem natural,
seguindo determinados padrões:
1. Use ‘deve’ para requisitos obrigatórios.
• Exemplo:“O sistema deve rodar em microcomputadores da linha IBM PC que possuam microprocessador 486 DX.”
2. Use ‘deveria’ ou ‘é desejável que’ para requisitos desejáveis.
• Exemplo: “É desejável que o sistema rode em microcomputadores da linha IBM PC que possuam microprocessador superior ao 486 DX.”
• Exemplo: “O sistema deveria rodar em microcomputadores da linha IBM PC que possuam microprocessador superior ao 486 DX.”
Documento de Especificação de
Requisitos
3. Os requisitos devem estar organizados logicamente, como por exemplo, inicialmente todos os requisitos de entrada, depois os de processamento e por último os requisitos de saída.
4. Cada requisito deve ter um identificador único, por exemplo, um identificador numérico, para posterior referência.
• RF01: O sistema deve permitir que o usuário com perfil administrado remova um cliente previamente cadastrado.
5. Os requisitos do software devem estar divididos em requisitos funcionais e não funcionais.
Formato da Especificação de
Requisitos
• Existem vários padrões de especificações de requisitos. • Um exemplo:
I. Visão Geral do Sistema II. Requisitos Funcionais
III. Requisitos de Qualidade
IV. Apêndice
• Padrão IEEE/ANSI 830/1998.
• A Especificação pode ser acompanhada de um PROTÓTIPO
Formato sugerido pelo padrão IEEE
1. Introdução
1. Propósito do documento de requisitos 2. Escopo do produto
3. Definições, acrônimos e abreviaturas 4. Referências
5. Visão geral do restante do documento 2. Descrição Geral
1. Perspectiva do produto 2. Funções do produto
3. Características dos usuários 4. Restrições gerais
5. Suposições de dependências
3. Requisitos específicos (requisitos funcionais e não-funcionais) 4. Apêndices
Problemas com especificação em
linguagem natural
• Ambigüidade
– Os leitores e os escritores dos requisitos devem interpretar as mesmas palavras da mesma maneira. Linguagem natural é naturalmente ambígua , por isso, muito difícil.
• Flexibilidade excessiva
– A mesma coisa pode ser dita de várias maneiras diferentes na especificação.
• Falta de modularização
– Estruturas de linguagem natural são inadequadas para estruturar requisitos de sistema.
Exercício
• Descreva os requisitos de uma agenda eletrônica
no papel
– Lista de requisitos funcionais
– Lista de requisitos não funcionais
Referências Bibliográficas
• Sommerville, Ian. Engenharia de Software. 8a edição. Pearson Education, 2007.
• Pressman, Roger S. Engenharia de Software. 6a edição. McGraw-Hill, 2006.
