MODELAGEM DE SOFTWARE

Especificação de Requisitos Tradicionais

Requisitos de um sistema são descrições do que o software deve fazer, os serviços

que devem ser fornecidos por esse sistema e as suas restrições operacionais. Os
requisitos descrevem o que o software deve fazer e o que não deve fazer sem dizer
como fazer (SOMMERVILLE, 2011).

Dentro da área de conhecimento "requisitos de software", obtemos diferentes

definições de requisitos, sendo os principais tipos: produto versus processo,
funcionais versus não funcionais, e propriedades.

Nessa área, também identifica-se a importância dos requisitos quantificáveis e

diferenciam-se sistemas e requisitos de software.

Requisito de software é classificado como uma AÇÃO que o software deve

executar que possui características e condições próprias para automatizar um
processo de negócio de cliente.

De acordo com o IEEE, definem-se requisitos de software como:

Uma condição ou uma capacidade de que o usuário necessita para

solucionar um problema ou alcançar um objetivo;
Uma condição ou uma capacidade que deve ser alcançada ou possuída
por um sistema ou componente do sistema, para satisfazer um contrato,
um padrão, uma especificação ou outros documentos impostos
formalmente;
Uma representação documentada de uma condição ou capacidade (on-
line).

Os requisitos de software existem em diversos níveis:

FIGURA 1 | REQUISITOS
 Ao final deste conteúdo, você será capaz de:
 Identificar o papel dos requisitos no processo de desenvolvimento de software.
 Elaborar diferentes tipos de requisitos.
 Descrever especificações de requisitos.
Vamos iniciar esta unidade com uma reflexão acerca do quadrinho apresentado a
seguir.

Quadrinho

Saiba mais
Para saber a respeito de certificações na área de engenharia de requisitos, acesse o
site do Instituto Brasileiro de Qualidade em Testes de Software por meio do link a
seguir.
[Link]

A leitura, indicada a seguir, traz uma visão detalhada de como descobrir e definir
requisitos de usuários e clientes no processo de desenvolvimento de software.

Estudo Guiado
Realize a leitura do capítulo 3 'Determinação dos requisitos'.
Clique no link e leia o livro
 DENNIS, Alan; WIXOM, Barbara H.; ROTH, Roberta M. Análise e Projeto de Sistemas.
[Digite o Local da Editora]: Grupo GEN, 2014. E-book. 978-85-216-2634-3. Disponível em:
[Link] Acesso em: 29 ago.
2022.

Requisitos funcionais

Os requisitos funcionais descrevem explicitamente as funcionalidades (funções que

o sistema deve realizar) e os serviços do sistema. Segundo Sommerville (2007), são
declarações de serviços que o sistema deve prover, descrevendo o que o sistema
deve fazer;

Pfleeger (2004) afirma que um requisito funcional descreve uma interação entre o
sistema e o seu ambiente. Para exemplificar, imagine um sistema de uma biblioteca,
que deve manter registro de todos os materiais que há nela (livros, CD's, séries,
jornais, revistas etc.), bem como deve permitir que o usuário busque um item por
seu título, autor ou outro.

Então, os requisitos funcionais abrangem os serviços que o sistema deve fornecer, e

assim como destaca Sommerville (2007), trata-se de como o sistema deve reagir a
entradas específicas, de como o sistema deve se comportar em situações específicas
e o que o sistema não deve fazer.

Para Pohl e Ruppy (2012), é um requisito relacionado ao resultado de algum

comportamento a ser fornecido por uma função do sistema.

Os requisitos funcionais estão relacionados às funções de negócios do dia a dia que

os usuários executam no sistema, como, por exemplo, o usuário deve ser capaz de
pesquisar em todo o conjunto inicial de um banco de dados.

Requisitos funcionais podem ser descritos por meio de diagramas de casos de uso e
de especificação de casos de uso, mas também podem ser descritos na forma
declarativa.

Exemplo

Acompanhe os exemplos:

 cadastrar clientes;

 fazer análise de crédito;

 fazer uma transação com banco de dados;

 cadastrar um registro de atendimento;

 imprimir relatório etc.

O sistema de compras on-line deverá informar, por e-mail, o número do pedido ao
comprador quando este finalizar a compra.
Exemplo

Exemplos detalhados:

 [RF01] O software deve permitir que o atendente efetue cadastro de clientes;

 [RF02] O software deve permitir que o caixa efetue o registro de itens vendidos;
 [RF03] O software deve permitir que o administrador gere um relatório de
vendas por mês.

Os requisitos funcionais definem as funcionalidades oferecidas pelo sistema a ser

desenvolvido, ou seja, dependem dos tipos de sistemas, do usuário e de onde eles
serão usados.

Esses requisitos podem ser divididos em: USUÁRIO e SISTEMA.

Requisitos funcionais do usuário:

são declarações de linguagem natural, que podem ser combinadas com diagramas
e que descrevem necessidades das partes interessadas em relação à solução
proposta pelo software. Eles podem ser usados para descrever como um conjunto
particular de usuários de uma solução irão interagir com ela e como um produto
irá atender às necessidades de diferentes grupos de clientes.
Requisitos funcionais de sistema:

descreve de forma detalhada quais funções um sistema deverá ter, tais como
entrada, saída e exceções, serviços e restrições. Um contrato envolvendo as
partes, desenvolvedor e clientes, poderá conter uma documentação de requisitos
de sistema que definirá o que, de fato, será implementado.

Requisitos não funcionais

Os requisitos chamados de não funcionais definem propriedades e restrições de um

sistema, isto é, a complexidade de um software é determinada, portanto, por sua
funcionalidade (o que o sistema faz) e por requisitos gerais que são parte do
desenvolvimento do software, como custo, desempenho, confiabilidade,
manutenibilidade, portabilidade, custos operacionais, entre outros.
Também conhecidos como RNF, suplementares ou de qualidade, os requisitos não
funcionais declaram as características que o sistema deve possuir e que estão
relacionadas às suas funcionalidades, ou seja, fixam restrições sobre como os
requisitos funcionais serão implementados, o que torna difícil, muitas vezes, u ma
distinção clara entre eles.

Como exemplo de características que o sistema deve possuir, temos: performance,

portabilidade, segurança, usabilidade, qualidade do serviço (QoS),
confidencialidade, confiabilidade, portabilidade, precisão, integridade, efici ência,
entre outras.

Os requisitos não funcionais podem ser mais severos e críticos que os requisitos
funcionais; isso quer dizer que, se eles não forem atendidos, então, o sistema não
serve: se não satisfaz, o sistema é inútil. Esses tipos de requisitos são as causas das
principais insatisfações dos usuários com relação ao software.

Também são classificados em três tipos, sendo eles: requisitos do produto final,
requisitos organizacionais e requisitos externos. Os requisitos do produto final
referem-se a como o produto deve se comportar, sua velocidade de execução,
confiabilidade, ente outros. Os requisitos organizacionais dizem respeito à
consequência de políticas e procedimentos organizacionais que devem ser seguidos.
Os requisitos externos são concernentes a fatores externos ao sistema e ao processo
de desenvolvimento.

Além desses três tipos, os requisitos não funcionais ainda se dividem em outros
diversos tipos, conforme a taxonomia dos requisitos não funcionais vista na figura a
seguir

FIGURA 1 | REQUISITOS NÃO FUNCIONAIS - TIPOS.

FIGURA 2 | TRATAMENTO DE REQUISITOS NÃO FUNCIONAIS
 Abordagens orientadas a produto: avaliam o grau em que o produto final atende
a determinados RNFs.
 O sistema é avaliado pelo grau em que ele atende a determinado requisito não
funcional.
 Propõe o uso de métricas para medir a qualidade do sistema.
 Existem várias propostas na literatura.
Abordagens orientadas a processo: integram o esforço de descrever e atender
RNFs durante o processo de desenvolvimento.
 Em vez de avaliar a qualidade do produto final, a ênfase é dada a orientar o
processo de desenvolvimento do sistema em relação aos NFRs que ele precisa
atender.
 As decisões tomadas durante o projeto podem afetar de forma positiva ou negativa
os RNFs.
 Essas interdependências servem para explicar o motivo pelo qual o sistema atende
ou não a determinado RNF.
Comparação entre as abordagens orientadas a processo e a produto: não existe
uma abordagem melhor que a outra; elas são complementares e devem ser usadas
para obter sistemas que, de fato, atendam aos requisitos não funcionais
dos stakeholders. Durante o estágio inicial de análise de requisitos, é recomendável
usar abordagens de processo. As abordagens orientadas a produto são indicadas
quando os requisitos estão bem definidos e podem ser especificados em termos de
funcionalidades e fatores qualitativos mensuráveis.

Requisitos não funcionais, normalmente, são escritos na forma declarativa.

Exemplo
O Sistema de Conta Corrente On-line deverá permitir que o usuário de internet
acesse a sua conta corrente em menos de cinco segundos.

Veja um exemplo detalhado de requisitos não funcionais, conforme figura a seguir.

QUADRO 1 | CARACTERÍSTICAS DOS REQUISITOS NÃO FUNCIONAIS

Os requisitos não funcionais têm origem nas necessidades dos usuários, em
restrições de orçamento, em políticas organizacionais, em necessidades de
interoperabilidade com outros sistemas de software ou hardware ou em fatores
externos como regulamentos e legislações (SOMMERVILLE, 2007).

Eles definem qualidades desejadas do sistema a ser desenvolvido e, muitas vezes,

influenciam a arquitetura do sistema mais do que os requisitos funcionais.
Determinam, ainda, desempenho, disponibilidade, confiabilidade, escalabilidade ou
portabilidade de um sistema (POHL; RUPP, 2012).

Saiba mais
Leia as páginas 113 a 119 do livro 'Engenharia de requisitos: software orientado ao
negócio', de Carlos Eduardo Vazquez e Guilherme Siqueira Simões, disponível
no link a seguir:
[Link]
 Principais características
Confiabilidade:

avalia quanto um programa executa as funções pretendidas com a precisão

exigida.
Eficiência:

verifica a quantidade de recursos computacionais exigida para que um programa

execute suas funções.
Flexibilidade:

esforço necessário para modificar um programa.

Integridade:

identifica o controle de acesso ao software ou aos dados por pessoas não

autorizadas.
Interoperabilidade:

envolve o quantitativo de esforço necessário para se acoplar um programa a um

outro.
Manutenibilidade:

relativa ao esforço necessário para localizar e eliminar erros em um programa.

Portabilidade:

esforço necessário para transferir um programa de uma plataforma

de hardware ou software para outra.
Reusabilidade:
identifica a reutilização de um programa (ou parte dele) em outros programas.
Testabilidade:

engloba o esforço necessário para testar um programa.

Usabilidade:

verifica o esforço necessário para aprender, inserir dados e interpretar a saída de

um programa.

Problemas comuns nos requisitos

 Nem sempre são óbvios.
 São originados de várias fontes (conflitos de interesse).
 Nem sempre retratam um problema que é possível de ser expresso por palavras.
 Sempre mudam.
 Os usuários nem sempre sabem o que desejam.
 Os usuários têm uma tendência de privilegiar a sua área ou o seu ponto de vista.
 Os analistas pensam que entendem os problemas melhor do que os próprios usuários.


Classes de requisitos
Segundo Sommerville (2007), os requisitos podem ser vistos em três classes
distintas: essenciais, importantes e desejáveis.

Essenciais:

são os requisitos sem os quais o sistema não entra em funcionamento. Requisitos

essenciais são requisitos imprescindíveis, que têm que ser implementados
impreterivelmente.
Importante:

é o requisito sem o qual o sistema entra em funcionamento, mas de forma não

satisfatória. Requisitos importantes devem ser implementados, mas, se não forem,
o sistema poderá ser implantado e usado mesmo assim.
Desejável:

é o requisito que não compromete as funcionalidades básicas do sistema, isto é, o

sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são
requisitos que podem ser deixados para versões posteriores do sistema caso não
haja tempo hábil para implementá-los na versão que está sendo especificada.

Em princípio, o sistema deve resolver todos os requisitos essenciais para requisitos

desejáveis.

RECORDANDO: A especificação de um requisito funcional deve determinar o

que o sistema deve fazer sem a preocupação de como fazer.

Atenção!
Há três fontes de requisitos:

 Stakeholders: conforme já dito anteriormente, são pessoas ou organizações que, direta

ou indiretamente, influenciam os requisitos de um sistema;

 Documentos: contém informações importantes que podem fornecer requisitos;

 Sistemas em operação: sistemas anteriores ou legados, bem como sistemas
concorrentes.

Requisitos de domínio
Também chamados de restrição, os requisitos de domínio são derivados do domínio
de aplicação e seus processos, podendo ser novos requisitos funcionais em si,
restringir os requisitos funcionais existentes, ou estabelecer como realizar cálculos
e processamentos específicos.

Os requisitos de domínio estão relacionados ao comportamento próprio do sistema

numa determinada aplicação ou no contexto "funcionando" para uma empresa.
Esses requisitos restringem o próprio sistema; por exemplo, o sistema deverá ser
implementado utilizando os serviços da web. Além disso, esses requisitos não são
implementados, mas são cumpridos, pois limitam o espaço da solução disponível
durante o processo de desenvolvimento.

Sem uma compreensão satisfatória desses requisitos, pode ser impossível fazer o
sistema operar de forma satisfatória (PRESSMAN, 2006), concluindo-se, então, que
se não forem satisfeitos, pode ser impossível fazer o sistema operar adequadamente.
Sommerville (2007) afirma que eles descrevem restrições sobre os serviços ou
funções oferecidas pelo sistema. Ainda, limitam as opções para criar uma solução
para o problema (PFLEEGER, 2004).

Exemplo
 [RN1]: os campos referentes ao orçamento do projeto vinculado só estarão ativos se o
tipo de projeto for vinculado;
 [RN2]: o campo valor total orçado para o projeto é calculado somando-se os valores
definidos para todas as rubricas incluídas no orçamento do projeto, seja ele vinculado
ou não vinculado;
 [RN3]: a soma dos percentuais a serem distribuídos entre os fundos incluídos no plano
de aplicação deve ser entre 0 e 100%.

Esses requisitos são expressos com o uso de uma linguagem específica do domínio
da aplicação e, geralmente, de difícil compreensão para os engenheiros de software.
Os especialistas do domínio podem, por julgarem óbvio, deixar de fornecer
informações importantes e, como resultado, o requisito pode não ser implementado
de forma satisfatória (SOMMERVILLE, 2008), ou seja, em um sistema de
Departamento de Pessoal, por exemplo, são utilizados termos e regras específicos
da área, e muitas vezes, o analista de requisitos não os conhece por não trabalhar
em tal área e não ter a mesma experiência que seu cliente tem no ramo.

Simplificando, trata-se de requisitos que são do conhecimento do processo, do

departamento e/ou da empresa cliente. Exemplificando: em um sistema de gestão
de operadora de plano de saúde, os requisitos de domínio são conhecimentos
 específicos desta área de atuação, os quais apenas as pessoas que estão na em presa
há anos possuem e podem detalhar de forma precisa ao analista de requisitos. Por
isso, é de extrema importância que o analista de requisitos faça as perguntas certas,
e que se atente aos mínimos detalhes.

Documentação de requisitos

Um documento de requisitos, segundo a norma IEEE, deverá conter declarações

não ambíguas, e ser verificável, consistente, modificável, rastreável e usável
durante todas as fases do ciclo de vida do requisito (IEEE; ANSI, 1996).

Todos os requisitos de um sistema devem ser capturados, modelados e

documentados.

Podemos modelar e documentar os requisitos em diversas formas, como, por

exemplo, casos de uso, diagramas DFD, diagrama SADT, rede de Petri etc.

Nesta etapa, interessa-nos modelar requisitos na forma de casos de uso e na forma

declarativa.

 Requisitos na forma de casos de uso são utilizados quando existe interação (diálogo)
entre os atores e o sistema. Eles descrevem o objetivo do ator ao interagir com o
sistema.

 Requisitos na forma declarativa são utilizados quando é necessário descrever o que o

sistema deve fazer em situações em que não existe iteração (ou em que a iteração é
mínima) do ator com os sistemas.

O documento de requisitos é o produto final do processo de descobrimento de

requisitos que reúne necessidades e propósitos demandados pelos stakeholders.
Trata-se de uma declaração formal de requisitos de clientes, usuários finais e
desenvolvedores de software (SOMMERVILLE; SAWYER, 1997; KOTONYA;
SOMMERVILLE, 1998). Ainda, é uma especificação do que é requerido a um
software fazer (não como) (MACAULAY, 1996).

Dependendo da organização, o documento de requisitos pode ter diferentes nomes e

ser de vários tipos ou níveis de detalhamento. Também, pode ter diferentes papéis e
diferentes formas e conteúdo.

A aplicação do documento de requisitos é feita para formalizar o registro das

necessidades dos stakeholders em um documento que descreve os produtos e
 serviços para especificação do software. Segundo Ryan (1998), o documento de
requisitos é o meio utilizado para descrever as restrições quanto às características
do produto e quanto ao processo de desenvolvimento, à interface com outras
aplicações, à informação acerca do domínio da aplicação e informações de suporte
ao conhecimento do problema, tais como modelos, termos especializados do
negócio, recuperação e gerenciamento de informações em mudança (RYAN, 1998).
De acordo com Kauppinen e Sulonen (1997), o documento de requisitos tem três
principais objetivos: ser um acordo entre cliente e fornecedor sobre o que o
software deverá fazer; prover a base de especificação de software e projeto; e servir
de subsídio para a verificação e validação do software. O documento de requisitos
também serve de subsídio para o gerenciamento do projeto. O esforço de estimativa
preliminar pode ser feito tão logo os requisitos tenham sido definidos. Outro
importante benefício é a redução do tempo total e de esforço requerido para o
desenvolvimento do software.

A seguir, a organização de um modelo de especificação de requisitos. E na

sequência, um arquivo contendo um exemplo real.

Exemplo
EXEMPLO DE ESPECIFICAÇÃO DE REQUISITOS

CAPA

EQUIPE

CLIENTE

Delinear o objetivo da especificação de requisitos e especificar os leitores desse

documento.

Introdução
Objetivo
Escopo
 Identificar pelo nome o produto de software a ser produzido
(por exemplo, Gerenciador Eletrônico de Documentos – GED);
 Explicar o que o produto vai e, se necessário, não vai
fazer;
 Descrever a aplicação de software que está sendo
especificada, incluindo seus benefícios, objetivos e metas;
 Ser consistente com outras especificações de alto nível do
sistema, se elas existirem.
Definições, acrônimos e abreviações
 Esta subseção deve conter todas as definições de termos,
acrônimos e abreviações necessárias para corretamente
entender a especificação. Essas informações podem ser
apresentadas em apêndice ou em referências a outros
documentos.

Referências

Esta subseção deve:

 conter uma lista completa de todos os documentos

referenciados na especificação;
 identificar cada documento adequadamente com título,
autores, data, editor etc.;
 especificar as fontes de onde as referências foram obtidas.
Visão geral

Esta subseção deve:

 descrever resumidamente o conteúdo do restante da

especificação;
 explicar como a especificação está organizada.
Descrição geral
Requisitos funcionais

Descrever as funcionalidades do software: produzir uma

lista de todos os requisitos funcionais e classificá-los
como obrigatórios, desejáveis ou opcionais.

Requisitos não funcionais

Descrever os requisitos não funcionais do software:

produzir uma lista de todos os requisitos não funcionais
e classificá-los segundo a taxonomia dos requisitos não
funcionais.

Requisitos de interface
Definir como o software interage com as pessoas, com
o hardware do sistema, com outros sistemas e com outros
produtos. Detalhar os aspectos das interfaces do produto
(normalmente, é feito um esboço das interfaces, levantado
através de um protótipo ou de estudos em papel; também
são detalhadas as interfaces com outros sistemas e
componentes de sistemas). É obrigatório o desenho das
telas referentes às principais funcionalidades do
produto.
Atributos de qualidade

Descrever os requisitos de desempenho (velocidade de

processamento, tempo de resposta etc.) e outros aspectos
considerados necessários para que o produto atinja a
qualidade desejada (por exemplo, portabilidade,
manutenibilidade, confiabilidade etc.). Finalmente,
classificar e rever os requisitos, estabelecendo
prioridades (obrigatório, desejável ou opcional).

Características dos usuários

Descrever as características gerais dos usuários do

produto, incluindo o nível educacional, a experiência e
os conhecimentos técnicos.

Restrições

Enumerar as restrições impostas pela aplicação, tais como

padrões, linguagem de implementação, ambientes
operacionais e limites de recursos.

Suposições e dependências

Listar todos os fatores que afetam os requisitos da

especificação. Esses fatores não são restrições ao
projeto do sistema, mas sim, mudanças que podem afetar os
requisitos. Por exemplo, uma suposição pode ser de que a
aplicação será instalada em um sistema operacional
específico; se esse sistema operacional não estiver
disponível, isso poderá afetar os requisitos.

Anexo

Citar todos os recursos e técnicas utilizadas para a

extração de requisitos, assim como as questões feitas, os
nomes das pessoas, as empresas, os telefones e as datas
de contato.

Confira a seguir, um template de documento de requisitos.

 Documento de Requisitos

Template

[Link]
[Link]

Chegamos ao fim deste conteúdo. Confira a seguir, uma breve síntese sobre o que
vimos até aqui.

Requisitos na Modelagem de Software:

“A atividade de modelagem de software é iniciada a partir da identificação e descrição dos

requisitos, considerando necessidades de usuários, ou seja, de quem opera o software, e de
clientes, isto é, quem vai patrocinar o desenvolvimento da solução. “

Definição de requisitos:

“Um requisito de sistema trata-se de uma descrição textual do que o software deve fazer para
fornecer as funcionalidades esperadas, respeitando restrições operacionais. É importante estar
atento ao fato de que um requisito descreve o que o sistema de software deve fazer e não
como fazer. “

Características de um requisito:

“Por se tratar de uma descrição base para todo o Processo de modelagem e desenvolvimento
de um software, devemos estar atentos ao definir um requisito para que ele esteja claro,
detalhado e livre de ambiguidade. “

Tipos de requisitos:

“Entre os tipos de requisitos, a diferença entre requisitos funcionais e não funcionais é a chave
para que o software construído atenda satisfatória os seus Stakeholders. “

Requisitos funcionais:

“Requisitos funcionais descrevem o que o software deve fazer. “

Requisitos não funcionais:

“Requisitos não funcionais, por sua vez, descrevem atributos de qualidade que o software
deve satisfazer, relacionados, por exemplo, à usabilidade, à segurança e ao desempenho. “

Documentação de requisitos:
“Para fins de comunicação, equipes de desenvolvimento de software costumam utilizar
documentos padronizados para apresentar e manter os requisitos. “

O uso dos requisitos:

“O documento de requisitos é utilizado como fonte para as demais atividades de modelagem

de software. Além disso, ele deve se manter atualizado a cada mudança realizada no software.
“

Referências Bibliográficas
KAUPPINEN, Maijo; SULONEN, Reijo. A Practical Framework for Requirements
Engineering. In: Third International Symposium on Requirements Engineering,
1ed, USA. 1997.
KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements engineering:
processes and techniques. Wiley Publishing, 1998.
MACAULAY, Linda. Requirements for requirements engineering techniques.
In: Proceedings of the Second International Conference on Requirements
Engineering. IEEE, 1996. p. 157-164.
PRESSMAN, R.; MAXIM, B. Engenharia de software. 8. ed. Porto Alegre:
AMGH, 2016.
RYAN, Linda. Software usage metrics for real-world software testing. IEEE
Spectrum, v. 35, n. 4, p. 64-68, 1998.
SERRA, A. P. G. Requisitos, análise e projeto orientado a objetos. São Paulo,
2019.
SOMMERVILLE, Ian; SAWYER, Pete. Viewpoints: principles, problems and a
practical approach to requirements engineering. Annals of software engineering,
v. 3, n. 1, p. 101-130, 1997.
VAZQUEZ, C. E.; SIMÕES, G. S. Engenharia de requisitos: software orientado
ao negócio. 1. ed. Rio de Janeiro: Brasport, 2016.