Er04 - Elicitação - Como Elicitar E Documentar Requisitos.pdf

Engenharia de Requisitos Elicitação

O Processo de Engenharia de Requisitos

Engenharia de Requisitos

Elicitação • Objetivo – Entender o que o cliente espera do software

• Problemas mais comuns – Escopo variável (mas contrato fixo) – Incertezas do cliente – Volatilidade dos requisitos

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 usuário – Lista de requisitos do usuário

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.

Leitores de requisitos

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.

Definições e especificações

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 utilizados

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 Etc.

Engenharia de Requisitos Tipos de Requisitos do Usuário

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 descrever os serviços de sistema em detalhe.

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. • O sistema deve permitir que o usuário exclua um contato.

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 qualidade do software.

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.

Tipos de requisitos não funcionais

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

• Conflitos entre requisitos

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.

Documento de Requisitos de Software

O Processo de Engenharia de Requisitos

Engenharia de Requisitos

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 ‘é 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. 6. Deve-se evitar o uso de jargões de computação.

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 executável (ou em papel).

Formato sugerido pelo padrão IEEE 1.

Introdução 1. 2. 3. 4. 5.

2.

Descrição Geral 1. 2. 3. 4. 5.

3. 4. 5.

Propósito do documento de requisitos Escopo do produto Definições, acrônimos e abreviaturas Referências Visão geral do restante do documento Perspectiva do produto Funções do produto Características dos usuários Restrições gerais Suposições de dependências

Requisitos específicos (requisitos funcionais e não-funcionais) Apêndices Índice

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 em Sala • Descreva os requisitos de uma aplicação para auxiliar pessoas a se deslocarem. Podendo ser de ônibus, metrô, uber ou taxi. – Lista de requisitos funcionais – Lista de requisitos não funcionais – Quais são os requisitos que podem entrar em conflito?

Exercício Casa • Utilizando o modelo disponibilizado faça: – Documente os requisitos elicitados por sua equipe.