Requisitos do usuário, do sistema e do software [Sommerville, 2004]

Transcrição

1 Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que o usuário possa resolver um problema ou atingir um objetivo para atender as necessidades ou restrições da organização ou de outros componentes do sistema. Requisitos do usuário, do sistema e do software [Sommerville, 2004] Requisitos do usuário Declarações, em linguagem natural e diagramas, sobre os serviços que o sistema oferece e as restrições para a sua operação. Escrito para os clientes. Requisitos do sistema Estabelecem detalhadamente as funções e restrições do sistema. O documento de requisitos, chamado de especificação funcional, pode servir como um contrato entre cliente e desenvolvedor. Especificação de software Especificação abstrata e precisa do software, indicando o que ele deve fazer (sem dizer como) que serve de base para o design e implementação. Acrescenta mais detalhes à especificação funcional e é escrito para a equipe de desenvolvimento.

2 Definição e especificação Definição dos requisitos do usuário O software deve fornecer um meio de representar e acessar arquivos externos criados por outras ferramentas. Especificação dos requisitos do sistema O usuário deve dispor de recursos para definir o tipo dos arquivos externos. Cada tipo de arquivo externo pode ter uma ferramenta associada que pode ser aplicada a ele. Cada tipo de arquivo externo pode ser representado por um ícone. Quando um usuário seleciona um ícone, o efeito desta seleção é aplicar a ferramenta associada com o tipo de arquivo. Quem são os interessados nos requisitos? Requisitos do usuário Gerentes e contratantes da organização cliente Usuários finais Engenheiros da organização cliente Arquitetos de sistema Requisitos do sistema Usuários finais Engenheiros da organização cliente Arquitetos de sistema Engenheiros de software Especificação de software Engenheiros da organização cliente (possivelmente) Arquitetos de sistema Engenheiros de software

3 Problemas comuns Os envolvidos* não sabem o que eles realmente querem. Se expressam num vocabulário diferente dos desenvolvedores. Os envolvidos podem ter requisitos conflitantes. Fatores organizacionais e políticos podem influenciar os requisitos. Novos requisitos podem surgir durante o processo de levantamento/análise/especificação. Novos envolvidos podem vir a participar do process. Podem haver mudanças externas ambiente ou regras de negócios. *Stakeholders: Envolvidos ou partes interessadas Como descrever os requisitos? A especificação dos requisitos deve ser: Completa deve descrever tudo o que é necessário Consistente não deve haver conflitos e contradições Não-ambígua não deve levar a interpretações diferentes por desenvolvedores e usuários. Difícil de atingir considerando que existem diferentes tipos de envolvidos. Depende da precisão da linguagem utilizada Linguagem natural, informal apropriada para os requisitos do usuário e do sistema. Linguagens gráficas, semi-formais apropriada para os requisitos do sistema e do software. Linguagens formais apropriada para uma especificação formal de software em métodos formais.

4 Requisitos funcionais Descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça Casos de Uso Exemplos: "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal". "o software deve emitir relatórios de compras a cada quinze dias" "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo. Requisitos não-funcionais Propriedades de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras São exemplos de requisitos não-funcionais: "a base de dados deve ser protegida para acesso apenas de usuários autorizados". "o tempo de resposta do sistema não deve ultrapassar 30 segundo". "o software deve ser operacionalizado no sistema Linux" "o tempo de desenvolvimento não deve ultrapassar seis meses".

5 Tipos de requisitos não-funcionais Non-functional Product Or ganizational External Ef ficiency Reliability Portability Interoperability Ethical Usability Delivery Implementation Standards Legislative Performance Space Privacy Safety Requisitos não-funcionais e métricas Velocidade Transações processadas/segundo Tempo de resposta ao usuário Tamanho Tamanho em bytes do software final Memória Facilidade de uso Tempo de treinamento necessário Número de telas de ajuda Confiabilidade Tempo médio para falhar Taxa de ocorrência de falhas. Probabilidade de indisponibilidade. Robustez Tempo de reinício após falha Porcentual de eventos que causam falhas Portabilidade Número de ambientes operacionais nos quais o sistema pode rodar.

6 Engenharia de Requisitos 1/2 Requisitos mudam sempre! Requisitos precisam ser levantados, analisados, especificados, rastreados, verificados e documentados. Estas atividades ocorrem ao longo de todo o ciclo-de-vida do software. A Engenharia de Requisitos propõe modelos, métodos, técnicas e ferramentas para a realização destas atividades Engenharia de Requisitos 2/2 Estudo de viabilidade Levantamento Análise Especificação Gerenciamento Rastreamento Verificação e Validação Documentação

7 O processo de engenharia de requisitos Fonte: Ian Sommerville Estudo de viabilidade Decide se o sistema proposto é vantajoso e lucrativo. Deve verificar se: O sistema contribui para os objetivos organizacionais. O sistema pode ser construído com a tecnologia corrente e com o orçamento disponível. O sistema pode ser integrado com os outros sistemas em utilização. Questões a serem respondidas por clientes e usuários: E se o sistema não for implementado? Quais os problemas atuais? Como o sistema irá ajudar? Quais serão os problemas de integração? Novas tecnologias são necessárias? Quais habilidades? Quais facilidades deve ser providas pelo sistema proposto?

8 Levantamento de requisitos Obter os requisitos dos especialistas no domínio clientes e usuários Principal problema: comunicação Usuários e especialistas não compartilham o mesmo vocabulário Técnicas de Comunicação Entrevistas Observação direta Encontros Análise de requisitos A análise possui dois propósitos: Permite julgamentos sobre a qualidade dos requisitos do sistema Elaborar um modelo de alto-nível do sistema com os principais componentes e suas interfaces Abordagens para a análise Análise Estruturada OMT UML: Casos de Uso e Diagramas de classes

9 Especificação de requisitos Descrição objetiva, precisa e completa dos requisitos do software A especificação de um requisito funcional deve determinar o que se espera que o software faça, sem a preocupação de como ele faz Requisitos funcionais podem ser descritos por Diagramas de Casos de Uso UML Requisitos não-funcionais são descritos textualmente. Verificação e Validação de Requisitos Validação Estamos construindo o sistema certo? Verificação Estamos construindo certo o sistema? Consistência Os requisitos não devem ser contraditórios. Completeza Os requisitos devem considerar todas as necessidades e restrições do envolvidos. Viabilidade Existe tecnologia e recursos suficientes?

10 Abordagens para levantamentoanálise-especificação Etnografia Técnica de observação da antropologia. Considera que os requisitos são derivados do contexto social e organizacional. O engenheiro-analista se insere no ambiente de trabalho. Cenários Descrição de possíveis situações de uso. Estimula o questionamento (5W 1H) Casos de Uso Baseada em cenários mais diagramas. Parte da UML e fundamental para o RUP. Definição de Requisitos Orientada a Pontos-de-Vista (VORD) Analisa e descreve os requisitos a partir dos pontos-devistas dos envolvidos. Gerenciamento de requisitos Requisitos mudam durante e depois do desenvolvimento (média de 1%/mês) Causas: Novas necessidades de clientes e usuários Mudanças na tecnologia utilizada Mudanças em leis, normas ou padrões As mudanças nos requisitos podem causar impacto nos requisitos relacionados As técnicas de gerenciamento visam rastrear e controlar estas mudanças

11 O processo de levantamento-análiseespecificação-validação. Documentação Normas e padrões ANSI/IEEE STD MIL-STD-2167A e MIL-STD-498 Tópicos comuns Descrição geral Interfaces externas Requisitos funcionais Requisitos de desempenho Restrições de design Atributos de qualidade

12 Documento de requisitos do IEEE Introdução Propósito do documento de requisitos Escopo do produto Definições, acrônimos e abreviações Referências Visão geral do restante do documento Descrição Geral Perspectiva do produto Funções do produto Características dos usuários Restrições gerais Suposições e dependências Requisitos específicos Esta é a parte substancial do documento, mas não existe uma estrutura padrão, variando de acordo com o método utilizado. Deve conter a arquitetura do sistema, interfaces externas e as funções (serviços) que o sistema oferece. Os requisitos não funcionais são colocados aqui também. Apêndices Indices