Requisitos de Software
Capítulo 5 Ian Sommerville
Tópicos

Requisitos funcionais e não funcionais
 Requisitos do usuário
 Requisitos do Sistema
 O Documento de requisitos do Software
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.
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ê
entendeu???
REQUISITOS ????
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."
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
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
Leitores dos Requisitos
User requirements
Client managers
System end-users
Client engineers
Contractor managers
System architects
System requirements
System end-users
Client engineers
System architects
Software developers
Software design
specification
Client engineers (perhaps)
System architects
Software developers
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.
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
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 (orderid), que o usuário poderá copiar para a área de
armazenagem permanente da conta.
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
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.
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.
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.
Non-functional requirement types
Non-functional
requir ements
Product
requir ements
Ef ficiency
requir ements
Reliability
requir ements
Usability
requirements
Performance
requirements
Or ganizational
requir ements
Portability
requirements
Delivery
requirements
Space
requir ements
External
requirements
Interoperability
requirements
Implementation
requir ements
Ethical
requirements
Standards
requirements
Legislative
requirements
Privacy
requirements
Safety
requirements
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.
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
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.
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.
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
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
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
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 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ção
Efeitos colaterais: Nenhum.
Especificação de Requisitos de
Software

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:
– 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:
–
–
–
–
–
–
–
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:

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 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;
