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;