Requisitos de Software

Transcrição

1 Requisitos de Software (Cap 6 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Requisitos funcionais e não funcionais No levantamento de requisitos, devemos estar atentos a dois tipos: Requisitos Funcionais: As declarações de serviços que o sistema deve fornecer; Como deve reagir a entradas específicas; Como o sistema deve se comportar em determinadas situações; Em alguns casos, os requisitos funcionais podem também estabelecer explicitamente o que o sistema não deve fazer. Descrição abstrata dos requisitos do usuário Descrição detalhada/precisa dos requisitos do sistema Inclui os requisitos de domínio Requisitos funcionais e não funcionais No levantamento de requisitos, devemos estar atentos a dois tipos: Requisitos Não Funcionais: São restrições sobre os serviços ou as funções oferecidas pelo sistema Incluem restrições de timing, restrições sobre o processo de desenvolvimento e padrões Aplicam-se normalmente a todo o sistema Normalmente não se aplicam às características ou serviços individuais de sistema Podem descrever propriedades emergentes do sistema, como a confiabilidade, tempo de resposta, espaço para armazenamento. Ainda, capacidade dos dispositivos de entrada/saída e as representações dos dados nas interfaces Requisitos funcionais e não funcionais Tipos de requisitos não funcionais: Requisitos Organizacionais Requisitos de produto Requisitos de Entrega Requisitos de facilidade de uso Requisitos de Implementação Requisitos de eficiência Requisitos de Padrões Requisitos de desempenho Requisitos Externos Requisitos de Espaço Requisitos de interoperabilidade Requisitos de confiabilidade Requisitos éticos Requisitos de portabilidade Requisitos legais Requisitos de privacidade Requisitos de segurança 1

2 Tamanho Robustez Métricas para especificar requisitos não funcionais Propriedade Velocidade Facilidade de uso Confiabilidade Portabilidade Transações processadas/segundo Tempo de resposta de usuário/evento Tempo de atualização da tela Kbytes Número de chips de RAM Medida Tempo de treinamento Número de frames de ajuda Tempo médio de falha Probabilidade de indisponibilidade Taxa de ocorrência de falhas Disponibilidade Tempo para reiniciar após falha Porcentagem de eventos que causam falhas Probabilidade de corrupção de dados por falhas Porcentagem de declarações dependentes do sistema-alvo alvo Número de sistemas-alvo alvo Devem fornecer os requisitos funcionais e não funcionais, de modo que eles sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado. Descrevem e especificam apenas o comportamento externo do sistema Não usar jargões de software, notações estruturadas ou formais, nem descrever os requisitos por meio da implementação do sistema. Usar linguagem simples, tabelas, formulários simples, diagramas intuitivos. Problemas do uso da linguagem natural na especificação de requisitos: Falta de clareza: às vezes, é difícil usar a linguagem de maneira precisa e não ambígua. Confusão de requisitos: Requisitos funcionais, requisitos não funcionais, metas de sistema e informações de projeto podem não estar claramente diferenciados. Fusão de requisitos: Diversos requisitos diferentes podem ser expressos juntos como um único requisito. Para minimizar os mal-entendidos na elaboração dos requisitos, é recomendável adotar um padrão de escrita. Segue uma sugestão... Dicas para padrão de escrita de requisitos: 1. Invente um formato padrão e assegure-se que todas as definições de requisitos estejam nesse formato. O objetivo aqui é facilitar a identificação. Descreva o requisito de forma clara e objetiva Incluir uma justificativa lógica Referência (link) para a especificação de requisitos do sistema Fonte do requisito ou nome de quem propôs o requisito 2. Use a linguagem de forma consistente. Sempre faça distinção entre requisitos obrigatórios e desejáveis Use a palavra DEVE em requisitos obrigatórios; Use a palavra PODE em requisitos desejáveis. 2

3 Dicas para padrão de escrita de requisitos: (cont) 3. Use destaque no texto (negrito, itálico, cor, sublinhado) para ressaltar as partes principais do requisito. 4. Evite o uso de jargões da informática. Quando usar, descreva-os entre parêntesis. O mesmo vale para os termos técnicos. 5. Exemplo: 3.Exemplo: 2.6 Recursos de grade O editor deve fornecer um recurso de grade no qual uma matriz de linhas horizontais e verticais fornecem um fundo para a janela do editor. Essa grade deve ser passiva e o alinhamento das entidades é de responsabilidade do usuário. Justificativa lógica: Uma grade ajuda o usuário a criar um diagrama bem organizado com entidades bem espaçadas. Embora uma grade ativa, na qual as entidades saltam as linhas de grade, possa ser útil, o posicionamento é impreciso. O usuário é a melhor pessoa para decidir onde as entidades devem ser posicionadas. Especificação: Eclipse/WS/Tools/DE/FS Seção 5.6 Fonte: Ray Wilson, escritório de Glasgow Requisitos de sistema São versões expandidas dos requisitos de usuário usados pelos engenheiros de software como ponto de partida para o projeto do sistema. Adicionam detalhem e explicam como os requisitos de usuário devem ser fornecidos pelo sistema Podem ser usados como parte do contrato para a implementação do sistema e devem, portanto, ser uma especificação completa e consistente de todo o sistema. De forma geral, descreve o comportamento externo do sistema e suas restrições operacionais Usar a linguagem natural, porém com mais detalhes na descrição dos requisitos Requisitos de sistema Contudo, cuidado com ambigüidades do português: Sapados devem ser usados Cachorros devem ser carregados Por esse e outros motivos, você pode usar uma linguagem mais especializada na especificação desses requisitos. Linguagem natural estruturada Modelos gráficos dos requisitos (casos de uso, especificações matemáticas formais) Fazer diagramas de ações/ de seqüência 3

4 Documento de requisitos de software O documento de especificação de requisitos de software inclui: Requisitos do usuário Especificação detalhada dos requisitos de sistema Dependendo do volume, separar ou não os requisitos do usuário com os requisitos de sistema Pensar nos usuários de um documento de requisitos: Clientes de sistema (usuários) Gerentes Engenheiros de Sistema Engenheiros de Teste de Sistema Engenheiros de Manutenção de sistema Requisitos de sistema Considere na escrita de requisitos de sistema os itens: Função do requisito Descrição objetiva em português A entrada e origem da função A saída e destinos Ação descrita em detalhes (pode-se ilustrar e usar português estruturado) Precondição Pós-condição Efeitos colaterais Requisitos de interface tipos de interfaces que podem ser definidas: Interfaces de procedimentos nas quais programas ou subsistemas existentes oferecem uma série de serviços acessados pela chamada de procedimentos de interface (APIs) Estruturas de dados que são passadas de um subsistema para outro. Modelos gráficos de dados(veremos em outras aulas) É a declaração oficial do que os desenvolvedores de sistema devem implementar. Inclui: os requisitos de usuário Especificação detalhada dos requisitos de sistema Atenção para diversidade de usuários do documento Existe algum padrão para esse documento? Existe o padrão IEEE/ANSI , mas pode ser melhorado conforme a necessidade. 4

5 Introdução Propósito do documento de requisitos Escopo do produto Definições, acrônimos e abreviaturas 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 (padrão IEEE/ANSI ) Requisitos específicos (mais importante) (padrão IEEE/ANSI ) Abrangem requisitos funcionais, não funcionais e de interface. Inclua também interfaces externas, funcionalidades e desempenho do sistema, requisitos lógicos para o banco de dados, restrições de projeto, características de qualidade. Apêndices Índice Embora o padrão IEEE seja interessante, Sommerville e Pressman recomendam as seguintes estruturas: Prefácio Deve definir o público-alvo do documento e descrever seu histórico de versões, incluindo uma justificativa lógica para a criação da nova versão e um resumo das mudanças feitas em cada versão. Introdução Deve descrever a necessidade do sistema. Deve descrever brevemente suas funções e explicar como o sistema irá funcionar com outros sistemas. Deve descrever como o sistema atende aos objetivos gerais de negócios e estratégicos da organização que encomendou o software. Glossário Deve definir os termos técnicos usados no documento. Você não deve fazer suposições sobre a experiência ou as habilidades do leitor. Não complique. Definição de requisitos de usuário Os serviços fornecidos ao usuário e os requisitos não funcionais do sistema devem ser descritos nesta seção. Essa descrição pode usar a linguagem natural, diagramas e outras notações compreensíveis pelos clientes. Padrões de produto e de processo a serem seguidos devem ser especificados. 5

6 Arquitetura de Sistema Este capítulo deve apresentar uma visão geral de alto nível da arquitetura prevista do sistema, mostrando a distribuição das funções nos módulos do sistema. Os componentes de arquitetura reusados devem ser destacados. Especificação de requisitos de sistema Deve descrever os requisitos funcionais e não funcionais mais detalhadamente. Caso necessário, mais detalhes podem também ser adicionados aos requisitos não funcionais; por exemplo, interfaces com outros sistemas devem ser definidas. Modelos de sistema Deve estabelecer um ou mais modelos de sistema, mostrando os relacionamentos entre os componentes e o sistema e seu ambiente. Podem ser modelos de objetos, modelos de fluxos de dados e modelos semânticos de dados. Evolução de sistema Deve descrever das hipóteses fundamentais sobre as quais o sistema está baseado, além de mudanças previstas devido à evolução do hardware, mudança das necessidades do usuário etc. Apêndices Deve fornecer informações detalhadas e específicas relacionadas à aplicação que está sendo desenvolvida. Exemplos de apêndices que podem ser incluidos são descrições de hardware e de banco de dados. Os requisitos de hardware definem as configurações mínima e ideal para o sistema. Os requisitos de banco de dados definem a organização lógica dos dados usados pelo sistema e os relacionamentos entre os dados. Índice Podem ser incluídos diversos índices para o documento. Assim como um índice alfabético normal, pode haver um índice dos diagramas, índices de funções etc. 1. Introdução Escopo e propósito do documento Objetivos do projeto Objetivos Funções principais Questões de desempenho Restrições técnicas e administrativas 2. Estimativas de projeto Dados históricos usados nas estimativas Técnicas de estimativa Estimativas (Pressman) 6

7 (Pressman) (Pressman) 3. Riscos do projeto Análise dos riscos Identificação Estimativa dos riscos Avaliação Administração dos riscos Opções para evitar os riscos Procedimentos de monitoração dos riscos 4. Cronograma Work breakdown divisão do trabalho no projeto Rede de tarefas Gráficos de timeline Tabela de recursos 5. Recursos do projeto Pessoal Hardware e Software Recursos especiais 6. Organização do pessoal Estrutura de equipe (se for o caso) Relatórios administrativos 7. Mecanismos de tracking (rastreamento) e controle. 8. Apêndices 7