Prática 2:

Identificação de Requisitos Funcionais e

Não Funcionais

4 Roteiro da Prática.
4.1 – Introdução Conceitual.
A palavra requisito na área de desenvolvimento de software pode ser sinônimo de
solicitação, desejo ou necessidade do cliente ou usuário.

Os requisitos de um sistema são serviços, ou seja, capacidades, que o sistema deve

executar para atender as necessidades de negócios do cliente, e, portanto, resolvendo um
ou vários problemas de negócios do cliente.

De acordo com Ian Sommerville, “Os requisitos de um sistema são descrições dos
serviços fornecidos pelo sistema e as suas restrições operacionais, refletem as
necessidades dos clientes e ajudam a resolver algum problema. A engenharia de
requisitos é processo de descobrir, analisar, documentar e verificar as necessidades dos
clientes (serviços e restrições). O termo requisito não é utilizado de maneira consistente
na indústria, em alguns casos é simplesmente uma declaração abstrata em alto nível, no
outro extremo é uma definição formal e detalhada de uma função do sistema”.

É uma prática corrente em projetos de desenvolvimento de software separar os

requisitos, ou seja, as capacidades e serviços que o sistema deverá prover, em duas
categorias distintas. São elas os chamados requisitos funcionais e os requisitos não
funcionais.
Os requisitos funcionais são requisitos que expressam funcionalidades de negócios, as
quais devem ser atendidas pelo sistema. Estas funcionalidades (serviços), na maioria das
vezes:
● Envolvem interação entre o usuário e o sistema.

● Expressam como o sistema irá agir mediante a um estímulo ou evento gerado no

ambiente de negócios. Isto envolve entrada de dados, ações do usuário etc.

Uma importante observação sobre os requisitos funcionais é que eles podem ser
expressos muitas vezes sob a visão do que o usuário deverá fazer ou sobre o que o
sistema deverá fazer. A seguir são apresentados alguns exemplos de requisitos
funcionais. Também são apresentados requisitos funcionais sobre a visão do
comportamento do usuário e sobre o comportamento do sistema. O analista de
requisitos deve capturar e documentar ambos.

Exemplos de requisitos funcionais:

● O sistema deve fornecer um formulário para a entrada dos resultados dos testes
clínicos do paciente.
● O paciente deverá informar qual é o exame que deseja visualizar.

● O paciente deverá fazer o login no sistema antes de poder utilizá-lo.

● O sistema deverá apresentar o status dos exames realizados pelo paciente. Os
status são: “liberado” e “em análise”.

Os requisitos não funcionais são requisitos que expressam qualidades específicas que o
software deve atender. São qualidades, características ou dimensões não funcionais do
sistema. Tais como: usabilidade (facilidade de uso), manutenibilidade (facilidade de
manutenção no código do sistema) etc. Alguns exemplos de requisitos não-funcionais
são apresentados na Figura 1. Em geral, podem ser aplicados a qualquer sistema.
Requisitos não funcionais também podem estabelecer restrições sobre os serviços ou as
funções oferecidas pelo sistema, incluem restrições de tempo de execução, restrições
sobre o processo de desenvolvimento, uso de padrões, frequentemente aplicam-se ao
sistema como um todo.

Um ponto importante é que muitas vezes um requisito funcional e não funcional pode
fazer parte de uma mesma solicitação do usuário/cliente. Veja o exemplo: o sistema
deve emitir um recibo para o cliente (requisito funcional), com o tempo máximo de 8
segundos após a transação (requisito não funcional de desempenho).

Abaixo é apresentada uma organização possível dos requisitos não funcionais.

 Figura1. Requisitos Não Funcionais (Sommerville, 2007).

Requisitos não funcionais de produto:

● Usabilidade/Facilidade de Uso (esforço para utilizar, aprender a usar o produto).

● Confiabilidade (frequência de falhas, recuperabilidade).

● Eficiência (desempenho).
● Portabilidade (capacidade de transferir o produto para outros ambientes).

Requisitos não funcionais, derivados das políticas organizacionais do cliente e do

desenvolvedor, como por exemplo:
● Implementações (regras de codificação).

● Padrões (linguagem de programação).

Requisitos não funcionais externos, procedentes de fatores externos ao sistema e ao seu

processo de desenvolvimento. Com por exemplo:
● Requisitos éticos.

● Legais (política de privacidade, direitos autorais).

● Interoperabilidade.

A diferença entre Requisitos Funcionais e Requisitos Não Funcionais é muito simples.

Tudo o que diz respeito ao comportamento de um sistema, que atenderá o processo do
negócio do cliente são REQUISITOS FUNCIONAIS. E tudo o que diz respeito às
características gerais de um sistema e que apoiam o funcionamento com qualidade dos
requisitos funcionais, como: confiabilidade, desempenho, usabilidade, segurança,
disponibilidade, manutenção e tecnologias envolvidas, são REQUISITOS NÃO
FUNCIONAIS.

4.2 – Estudo de Caso “Automação de Vendas na Empresa Sua Casa”.

A empresa “Sua Casa” foi criada na região nordeste do Brasil em 2005 por João Abreu,
que é um empreendedor, que começou a sua vida profissional trabalhando como
vendedor em uma loja de material de construção no interior do seu estado. João Abreu
não teve a chance estudar, mas reconhece a importância do estudo como um fator de
crescimento profissional, e importante no ambiente de negócios.

Aos 80 anos de idade João Abreu agora deseja descansar. Ele reuniu os 2 filhos e
passou a eles o comando da rede varejista de material de construção “Sua Casa”. Pedro,
o primeiro filho, é formado em administração de empresas e está responsável pela
administração direta pela operação de negócios da empresa. Tomás, o segundo filho, é
formado em Sistemas de Informação é esta responsável pela área de TI da empresa.

Aproveitando o bom momento da área de construção civil decidiram abrir o capital da

empresa para poder obter dinheiro para investir em abertura de novas lojas aumentando
a sua presença de mercado e o seu faturamento e rentabilidade.

Um dos elementos chave na abertura das novas lojas são os novos TPV (Terminal de
Ponto de Venda), os quais irão operar sem a tradicional figura do operador de caixa, que
passa os produtos na leitora de código de barras, e faz o fechamento da compra do
cliente.

O TPV é um sistema computadorizado usado para registrar vendas e cuidar de

pagamentos. Tipicamente usado em vendas a varejo. Inclui componentes de software e
de hardware, tais como um computador e um leitor de código de barras.

Os novos TPV permitirão ao cliente fazer a leitura dos preços nas leitoras de código de
barras, e pagar com o próprio cartão de débito ou de crédito. Com isso, a empresa “Sua
Casa” pretende automatizar o processo de compras para permitir serviços e processos
comerciais mais rápidos, melhores e mais baratos. Tipicamente, isso inclui:
● Check out (passagem pelo caixa) mais rápido para o cliente.

● Análise rápida e precisa do crédito.

● Controle automático do estoque.

Com isto, a empresa “Sua Casa” pretende o reduzir o tempo de atendimento e as filas
nos caixas, e reduzir os custos fixos relacionados ao pagamento dos salários dos
operadores de caixa na operação dos TPVs.

A empresa XPTO foi convidada para desenvolver esses TPVs. A “Sua Casa” deseja que
os TPVs possam:
● Registrar a venda em andamento (corrente), isto é, os itens comprados. Cada
item deve ser registrado com o tempo máximo de 2 seg.
● Calcular o total da venda corrente, incluindo os cálculos de impostos e de
cupons de desconto com tempo máximo de 2 segundos após a finalização da
compra.
● Capturar a informação de um item adquirido, usando o código, obtido por um
leitor de código de barra, ou pela entrada manual do código do produto, usando
o código universal de produto (CUP ou UPC).
● Abater do estoque o item comparado, quando a venda for finalizada. Não mais
do que 5 min para atualização de estoque.
 ● Registrar as vendas completadas.
● Fornecer um mecanismo de armazenamento permanente dados.
● Fornecer mecanismos de comunicação inter processos e inter sistemas.
● Exibir a descrição e o preço do item registrado.
● Tratar o pagamento com cartão de crédito ou débito: capturar a informação do
cartão por um leitor de cartões, e autorizar o pagamento ou não da compra
segundo informações da operadora de cartão de crédito ou do banco.
● Registrar os pagamentos por crédito no sistema de contas a receber da loja, uma
vez que o serviço de autorização de crédito deve à loja a quantia oferecida como
pagamento.
● Manter a disponibilidade, ou seja, o sistema deverá ter uma taxa de
disponibilidade (quanto tempo ele ficará disponível para uso durante 24hrs X 7
dias) de 99,9%.
● Ter segurança, ou seja, a segurança da operação dos novos TPVs deverão
obedecer ao standard da IEEE 65369665.

1. Bibliografia
ALEXANDER, Ian & STEVENS, Richard. Writing Better Requirements. Addison-
Wesley, 2002.
ALEXANDER, Ian & BEUS-DUKIC, Ljerka. Discovering Requirements: How to
Specify Products and Services. Addison-Wesley, 2009.
SCHACH, Stephen. Object-Oriented Software Engineering. 7 Edition. McGraw Hill,
th

2008.
SOMMERVILLE, Ian. Engenharia de Software. 8ª. edição. Pearson Addison Wesley,
2007.