Requisitos de Software Capítulo 5 Ian Sommerville

Apresentação em tema: "Requisitos de Software Capítulo 5 Ian Sommerville"— Transcrição da apresentação:

1 Requisitos de Software Capítulo 5 Ian Sommerville

2 Tópicos Requisitos funcionais e não funcionais Requisitos do usuário
Requisitos do Sistema O Documento de requisitos do Software

3 Engenharia de requisitos
Engenharia de requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições que o usuário requer para o sistema. Os requisitos são a descrição do sistema, funções e restrições que são gerados durante o processo de engenharia de requisitos.

4 O que é um requisito? Um requisito pode ser visto como uma declaração abstrata de alto-nível, uma função que o sistema deve fornecer ou uma restrição do sistema. No outro extremo ele pode ser visto como uma especificação detalhada, matematicamente formal de uma função do sistema..

5 REQUISITOS: Você entendeu???

6 REQUISITOS ????

7 Abstração de Requisitos (Davis, 1993)
"Se uma empresa deseja estabelecer um contrato para desenvolvimento de um grande projeto de software, ela tem de definir suas necessidades de maneira suficientemente abstrata para que uma solução não seja pré-definida. Os requisitos devem ser redigidos de modo que os diversos fornecedores possam apresentar propostas, oferecendo, talvez, diferentes maneiras de atender às necessidades organizacionais do cliente. Uma vez estabelecido um contrato, o fornecedor precisa preparar uma definição do sistema para o cliente, com mais detalhes, de modo que o cliente compreenda e possa validar o que o software fará. Estes dois documentos podem ser chamados de documentos de requisitos do sistema."

8 Tipos de Requisitos Requisitos do usuário
São declarações em linguagem natural e também em diagramas, sobre as funções que o sistema deve fornecer e as restrições sobre as quais deve operar. Requisitos de Sistema Estabelecem detalhadamente as funções e as restrições de sistema. O documento de requisitos de sistema, algumas vezes chamado de especificação funcional, deve ser preciso. Ele pode servir como um contrato entre o comprador do sistema e o desenvolvedor do software. Especificação de Projeto de Software É uma descrição abstrata do projeto de software, que é uma base para o projeto e a implementação mais detalhados.acrescenta mais detalhes à especificação de requisitos do sistema

9 Definição e Especificação (exemplo)
Definição dos requisitos do usuário 1. O Software deve oferecer um meio de representar e acessar arquivos externos criados por outras ferramentas. Especificação dos requisitos do sistema 1.1 O usuário deve dispor de recursos para definir o tipo de arquivos externos. 1.2 Cada tipo de arquivo externo pode ter uma ferramenta associada que pode ser aplicada a ele. 1.3 Cada tipo de arquivo externo pode ser representado como um ícone específico na tela do usuário. 1.4 Devem ser fornecidos recursos para o ícone que representa um arquivo externo, a ser definido pelo usuário

10 Leitores dos Requisitos

11 Requisitos Funcionais e Não-Funcionais
Os requisitos de sistema de software podem ser vistos como: Requisitos Funcionais São declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem também explicitamente declarar o que o sistema não deve fazer. Requisitos não-Funcionais São restrições sobre os serviços ou as funções oferecidas pelo sistema. Entre eles destacam-se restrições de tempo, restrições sobre o processo de desenvolvimento,padrões, entre outros. Requisitos de domínio São requisitos que se originam do domínio de aplicação do sistema e que refletem características desse domínio. Podem ser requisitos funcionais e não funcionais.

12 Requisitos funcionais
Descrevem a funcionalidade ou os serviços que se espera que o sistema forneça. Dependem do tipo de software que está sendo desenvolvido, dos usuários de software e do tipo de sistema. Quando expressos como requisitos de usuário eles são descritos de um modo geral Quando expressos como requisitos do sistema descrevem a função de sistema detalhadamente, suas entradas, saídas, exceções etc

13 Exemplos de requisitos funcionais para um sistema de biblioteca de universidade
1. O usuário deve ser capaz de buscar todo o conjunto inicial de banco de dados ou selecionar um subconjunto a partir dele. 2. O sistema fornecerá telas apropriadas para o usuário ler documentos no repositório de documentos 3. Cada pedido será alocado a um único identificador (order- id), que o usuário poderá copiar para a área de armazenagem permanente da conta.

14 Imprecisão de requisitos
Problemas podem se originar da imprecisão na especificação de requisitos. Requisitos ambíguos podem ser interpretados de diferentes maneiras por desenvolvedores e usuários. Considere o termo ‘telas apropriadas’ Intenção do usuário - Telas especiais para cada tipo de documento (texto, imagens, mapas, etc). Interpretação do desenvolvedor - Fornecer uma tela de texto que mostra o conteúdo de um documento. => ambiguidade

15 Completeza e Consistência
Em princípio, os requisitos devem ser completos e consistentes. Completo Todas as funções requeridas pelo usuário devem estar definidas. Consistente Não devem existir conflitos ou contradições nas definições dos requisitos. ==> na prática, para sistemas grandes e complexos é quase impossível atingir a completeza e consistência requeridos.

16 Requisitos Não-Funcionais
São aqueles que não dizem respeito, diretamente às funções específicas fornecidas pelo sistema. Eles estão relacionados a propriedades como confiabilidade, tempo de resposta e espaço em disco. Requisitos não funcionais de processo podem solicitar o uso de uma determinada ferramenta CASE, linguagem de programação ou método de desenvolvimento. Requisitos não funcionais podem ser mais importantes que requisitos funcionais individuais pois a falha em não cumprir um requisito não funcional pode tornar o sistema inútil.

17 Classificação dos Requisitos Não-Funcionais
Requisitos de Produto São os requisitos que especificam o comportamento do produto. entre os exemplos estão os requisitos de desempenho sobre com que rapidez o sistema deve operar e quanta memória ele requer, os requisitos de confiabilidade, que estabelecem a taxa aceitável de falhas, os requisitos de portabilidade e os reuisitos de facilidade de uso. Requisitos Organizacionais São procedentes de políticas e procedimentos nas organizações do cliente e do desenvolvedor. Entre os exemplos estão os padrões de processo que devem ser utilizados, os requisitos de implementação, como a linguagem de programação ou o método de projeto utilizado, e os requisitos de fornecimento(quando o produto e seus documentos devem ser entregues. Requisitos Externos requisitos procedentes de fatores externos tais como interoperabilidade, requisitos legais e éticos.

18 Non-functional requirement types

19 Requisitos Não-Funcionais - exemplos
Requisitos de Produto Toda entrada de dados deve ser padrão TXT Requisitos Organizacionais O processo de desenvolvimento e a documentação de todo o sistema devem ser entregues conforme norma padrão xxx.yyyy. Requisitos Externos O sistema não deve revelar aos operadores nenhuma informação pessoal sobre os clientes além do nome e número de referência.

20 Requisitos de domínio São derivados do domínio da aplicação do sistema, em vez de serem obtidos a partir das necessidades específicas dos usuários do sistema Eles podem ser novos requisitos funcionais em si, podem restringir os requisitos funcionais existentes Podem também estabelecer como devem ser realizados cálculos específicos

21 Exemplos – Requisitos de Domínio
1. Deve haver uma interface-padrão como usuário para todos os banco de dados, que terá como base o padrão Z39.50. 2. Em razão das restrições referentes a direitos autorais, alguns documentos devem ser excluídos imediatamente ao serem fornecidos. Dependendo dos requisitos dos usuários, esses documentos serão impressos localmente no servidor do sistema para serem encaminhados manualmente ao usuário ou direcionados para uma impressora de rede.

22 Exemplos – Requisitos de Domínio
A desacerelação do trem será computada como: Dtrem = Dcontrole + Dgradiente Onde Dgradiente é 9,81 ms2 * gradiente compensado/alfa e onde os valores de 9,81 ms²/alfa são conhecidos para diferentes tipos de trens.

23 Requisitos de Usuário Descrevem os requisitos funcionais e não funcionais de modo compreensível pelos usuários do sistema que não têm conhecimentos técnicos detalhados Devem especificar somente o comportamento externo do sistema Deve-se evitar as características do projeto do sistema Podem ser escritos com o uso de linguagem natural, formulários e diagramas intuitivos simples

24 Exemplos – Requisitos de usuário
2.6 Recursos de grade. 2.7 O editor deverá fornecer um recurso de grade, em que uma matriz de linhas horizontais e verticais constitua um fundo da janela do editor. Essa grade deverá ser uma tela passiva em que o alinhamento de entidades é de responsabilidade do usuário. Lógica: uma grade ajuda o usuário a criar um diagrama ‘limpo’, com entidades bem espaçadas. Embora uma grade ativa, em que 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/ Ferramentas/DE/FS. Seção 5.6

25 Diretrizes para redação dos requisitos do usuário
Invente um formato padrão e certifique-se de que todas as definições de requisitos estejam conforme este formato Utilize a linguagem de modo consistente Faça distinção entre o requisitos obrigatórios e os desejáveis Utilize destaque no texto(negrito ou itálico) para ressaltar partes importants Evite o uso de jargões de informática

26 3.5.1 Adicionando nós a um desenho
O editor deve fornecer um recurso aos usuários para adicionar nós de um tipo especificado a seu desenho. A seqüência de ações para acrescentar um nó deve ser como se segue: 1. O usuário deve selecionar o tipo de nó a ser acrescentado. 2. O usuário deve mover o cursor para a posição aproximada do nó no diagrama e indicar que o símbolo do nó deve ser adicionado naquele ponto. 3. O usuário deve então arrastar o símbolo do nó para sua posição final. Lógica: o usuário é a melhor pessoa para decidir onde posicionar um nó no diagrama. Essa abordagem dá ao usuário o controle direto sobre a seleção do tipo de nó e seu posicionamento.

27 Requisitos de sistema São descrições mais detalhadas dos requisitos de usuário. Serve como base para projetar o sistema. Pode ser usado como base para o contrato. Pode ser expresso usando um modelo de dados, funcional ou de objetos

28 Função: Adicionar nós. Descrição: Adiciona um nó em um desenho existente. O usuário seleciona o tipo de nó e seu posicionamento. Quando adicionado ao desenho, o nó se torna a seleção atual. O usuário escolhe a posição do nó movimentando o cursor para a área em que o nó será adicionado. Entradas: Tipo de nó, Posição do nó, Identificador do desenho. Origem: Tipo de nó e Posição do nó são entradas fornecidas pelo usuário; Identificador de desenho se origina na base de dados. Saídas: Identificador do desenho. Destino: O banco de dados do desenho. O desenho é designado para a base de dados, no término da operação. Requer: Gráfico do desenho associado ao identificador de desenho de entrada. Pré-condição: O desenho é aberto e exibido na tabela do usuário. Pós-condição: O desenho é imutável, a não ser pela adição de um nó do tipo especificado em dada posição Efeitos colaterais: Nenhum.

29 Especificação de Requisitos de Software
A ERS é descrita no Padrão IEEE e é descrita na seqüência: Índice Analítico; Introdução: Propósito do documento de requisito; Escopo; Definições, acrônimos, abreviações; Referências; Visão Geral do restante do documento;

30 Na introdução: Comentários sobre o objetivo da ERS;
Objetivo, público-alvo da ERS; Especificar produto, função, benefícios, objetivos; Termos necessários para interpretar a ERS; Documentos mencionados na ERS; O que a ERS contém, sua organização;

31 Descrição Geral: Perspectiva do produto; Funções do produto;
Características do usuário; Restrições; Suposições e dependências;

32 Na Descrição geral: Descrever os fatores que afetam o produto;
Contexto (produtos relacionados) do produto; Funções principais que o software desempenha; Usuários-alvo do produto; Itens que limitam as opções de desenvolvimento; Alterações que afetam os requisitos; Itens adiados até versões futuras do software;

33 Requisitos Específicos:
Requisitos de interface; Requisitos funcionais; Requisitos de desempenho; Requisitos do banco de dados lógico; Restrições de projeto; Atributos do sistema de software; Organização dos requisitos específicos; Características de qualidade

34 Nos Requisitos Específicos:
Forneça detalhes suficientes para permitir que os projetistas projetem um sistema que satisfaça os requisitos; Usuários, hardware, software, comunicação; Identificar ações de processamento básicas do sistema; Requisitos estáticos, requisitos numéricos; Especificar qualquer informação incluída no banco de dados; Restrições impostas por padrões; Atributos do software que servem como requisitos; Como organizar os requisitos específicos;

35 Informações de Suporte:
Índice analítico e remissivo; Apêndices;

36 Nas Informações de Suporte
Fornecer instruções detalhadas para os leitores da ERS; Identificar as localizações de itens da ERS; Fornecer amostras de formatos de E/S, descrição de estudos de análise de custos, resultados de pesquisas dos usuários, dados de suporte ou background para ajudar os leitores a compreenderem a ERS, instruções de empacotamento do código para atender à segurança, exportação, carta inicial e outros requisitos;

37