requisitos de software capítulo 5 ian sommerville
TRANSCRIPT
Requisitos de SoftwareCapítulo 5 Ian Sommerville
TópicosTópicosRequisitos funcionais e não funcionaisRequisitos do usuárioRequisitos do SistemaO Documento de requisitos do Software
Engenharia de requisitosEngenharia de requisitosEngenharia 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.
O que é um requisito? 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..
REQUISITOS: Você REQUISITOS: Você entendeu???entendeu???
REQUISITOS ????REQUISITOS ????
Abstração de Requisitos Abstração de Requisitos (Davis, 1993)(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."
Tipos de RequisitosTipos 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
Definição e Especificação Definição e Especificação (exemplo)(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
Leitores dos RequisitosLeitores dos RequisitosClient managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
User requirements
System requirements
Software designspecification
Requisitos Funcionais e Não-FuncionaisRequisitos 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.
Requisitos funcionaisRequisitos funcionaisDescrevem 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
Exemplos de requisitos funcionais para um Exemplos de requisitos funcionais para um sistema de biblioteca de universidadesistema 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.
Imprecisão de requisitosImprecisã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
Completeza e ConsistênciaCompleteza 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.
Requisitos Não-FuncionaisRequisitos 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.
Classificação Classificação dos Requisitos Não-Funcionaisdos 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.
Non-functional requirement Non-functional requirement typestypes
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
RRequisitos Não-Funcionais - exemplosequisitos 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.
Requisitos de domínioRequisitos 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
Exemplos – Exemplos – Requisitos de DomínioRequisitos 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.
Exemplos – Exemplos – Requisitos de DomínioRequisitos 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.
Requisitos de UsuárioRequisitos 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
Exemplos – Exemplos – Requisitos de usuárioRequisitos de usuário2.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
Diretrizes para redação dos requisitos Diretrizes para redação dos requisitos do usuáriodo 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 consistenteFaça distinção entre o requisitos obrigatórios e
os desejáveisUtilize destaque no texto(negrito ou itálico)
para ressaltar partes importantsEvite o uso de jargões de informática
3.5.1 Adicionando nós a um desenho
3.5.1.1 O editor deve fornecer um recurso aos usuários para adicionar nós de um tipo especificado a seu desenho.
3.5.1.2 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.
Requisitos de sistemaRequisitos 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
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çãoEfeitos colaterais: Nenhum.
Especificação de Requisitos de Especificação de Requisitos de SoftwareSoftware
A ERS é descrita no Padrão IEEE 830-1993 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;
Na introdução: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;
Descrição Geral:– Perspectiva do produto;– Funções do produto;– Características do usuário;– Restrições;– Suposições e dependências;
Na Descrição geral: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;
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
Nos Requisitos Específicos: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;
Informações de Suporte:– Índice analítico e remissivo;– Apêndices;
Nas Informações de SuporteNas 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;