Campus Graças

Introdução a Engenharia de Software e

Gestão ágil de Projetos

PROFESSOR:

Adilson da Silva
CURSO ( 202 4 . 1)

Apresentação baseada em
apresentação dos professores Mauricio
Braga e Ricardo Baudel
 Campus Graças

Requisitos de
Software
Requisito de software
Campus Graças
 Descrição dos serviços fornecidos pelo sistema e as suas restrições
operacionais.
 Pode ser redigido de forma abstrata, descrevendo em alto nível um
serviço ou restrição de um sistema ou de uma maneira formal e
detalhada, especificando de forma clara uma determinada
funcionalidade da aplicação;
 Essa variação se explica pela função a ser cumprida pelo requisito, que
pode ser utilizado:
 Em uma especificação inicial, visando o recebimento de propostas de
fornecedores que tenham interesse em desenvolver o sistema;
 Em um contrato de desenvolvimento, devendo portanto definir de forma não
ambígua o que deve ser realizado.
Tipos de requisito
Campus Graças

 Requisitos de usuário:
 São declarações, redigidas em linguagem natural ou fazendo uso de diagramas,
dos serviços esperados do sistema e das restrições sob as quais ele deve
operar;
 Requisitos de sistema:
 Definem em detalhes as funções, os serviços e as restrições operacionais do
sistema a ser implementado. É utilizado como parte do contrato entre o fornecedor
e o comprador do software.

 Um requisito de usuário pode gerar um ou mais requisitos de

sistema.
Classificação dos requisitos
Campus Graças

 Podemos classificar os requisitos em:

 Requisitos funcionais;
 Requisitos não funcionais;
 Requisitos de domínio.
Requisitos funcionais
Campus Graças
 Descrevem as funcionalidades e serviços
que devem ser oferecidos pelo sistema;

 Dependem do tipo de software, dos

usuários a que o software se destina e do
sistema onde o software será utilizado;

 Podem ser redigidos em alto nível

(requisitos de usuário funcionais) ou
especificar detalhadamente o que deve ser
feito (requisitos de sistema funcionais).
Exemplo
Campus Graças

 O sistema LIBSYS:
 Um sistema de biblioteca para faculdades que
disponibiliza uma interface única conectando o usuário a
várias bases de dados que residem em diferentes
bibliotecas.
 Disponibiliza a seus usuários serviços de pesquisa e
download de artigos científicos.

7/53
Exemplos de requisitos funcionais
Campus Graças

 Requisitos funcionais de usuário do sistema LIBSYS:

 “O usuário deverá ter a opção de fazer a busca considerando todo o conjunto
de bases de dados ou apenas uma fração delas”;
 “O sistema deverá oferecer recursos para visualização dos artigos
disponibilizados nas bases de dados”
 “Cada pedido receberá um único identificador, o qual o usuário deve ser capaz
de copiar para a área de armazenamento permanente da sua conta”
Problemas nos requisitos
Campus Graças
 A imprecisão na especificação de requisitos pode causar muitos
problemas no desenvolvimento do sistema;

 Um requisito ambíguo pode ser interpretado de diferentes

maneiras pelos usuários e pelos desenvolvedores, levando os
primeiros a pedirem mudanças no produto;

 Ex: Considere o termo: “recursos para visualização”:

 Intenção do usuário: Um visualizador específico para cada formato de artigo.
 Interpretação do programador: Um visualizador genérico com funções básicas
de manipulação do arquivo.
Especificação de requisitos de um sistema
Campus Graças
 O documento de especificação de um sistema deve ser:
 Completo: Todos os serviços exigidos pelos usuários devem ser
definidos.
 Consistente: Requisitos não devem ter definições contraditórias.

 Na prática, com sistemas grandes e complexos, é

praticamente impossível atingir a completeza e consistência
dos requisitos.
Requisitos não funcionais
Campus Graças

 Definem propriedades do sistema como um todo bem como

restrições sobre a operação do mesmo. Ex: usabilidade, memória
máxima a ser usada, etc.

 Surgem em decorrência de necessidades dos usuários, restrições de

orçamento, necessidade de interoperabilidade com outros sistemas,
políticas organizacionais, regulamentos de segurança, legislação, etc.

 Podem ser críticos para a utilização do sistema por parte do usuário. Ex:
Confiabilidade de uma aeronave ou performance de um software de
tempo real;
Requisitos não funcionais
Campus Graças

 Podem restringir também o processo de construção do sistema,

exigindo o uso de certas ferramentas CASE ou a utilização de um
processo de desenvolvimento específico.

 Uma vez que podem ser expressos como metas vagas a serem
atingidas, podem ser difíceis de implementar bem como verificar
se foram cumpridos.
 Ex: “O sistema deve ser fácil de ser usado pelos controladores experientes
e ser organizado de forma a minimizar o número de erros cometido pelo
usuário”
Requisitos não funcionais
Campus Graças

 Uma forma de minimizar o problema da verificação dos requisitos não

funcionais é, sempre que possível, definir uma métrica passível de
verificação.
 Ex: Para o requisito de usabilidade anterior, definir um número máximo de erros
que pode ser cometido pelos usuários experientes.

 Infelizmente nem todos os requisitos não funcionais podem ser

transformados em requisitos quantificáveis.
 Ex: Como medir a manutenabilidade de um sistema?
 Outro problema é que pode ser difícil definir uma métrica que convença
os usuários de que o requisito foi atingido.
Métricas de requisitos não funcionais
Campus Graças
Propriedade Medida
Velocidade Transações processadas por segundo; Tempo de
resposta de usuário/evento; Tempo de atualização da
tela.
Tamanho Número de kbytes.
Facilidade de uso Tempo necessário para treinamento; Número de
telas de ajuda.
Confiabilidade Taxa de ocorrência de falhas; Probabilidade de
indisponibilidade;
Robustez Porcentagem de eventos que causam falhas; Probabilidade de
corrupção de dados devido a falhas.
Portabilidade Número de sistemas alvo.
Classificação dos requisitos não funcionais
Campus Graças
 Requisitos de produto
 Especificam o comportamento do produto. Ex: desempenho,
confiabilidade, portabilidade, etc.

 Requisitos organizacionais
 São derivados de políticas e procedimentos da organização cliente e
do desenvolvedor. Ex: Formato da documentação, processo a ser
utilizado, etc.

 Requisitos externos
 Abrange todos os requisitos derivados de fatores externos ao sistema.
Ex: Legislação, requisitos de interoperabilidade com outros sistemas,
etc.
Tipos de requisitos não funcionais
Campus Graças
Exemplos
Campus Graças
 Requisito de produto
 “A interface de usuário para o LIBSYS deve ser implementada usando HTML, sem
applets ou frames” (compatibilidade)

 Requisito organizacional
 “O processo de desenvolvimento do sistema e os documentos a serem entregues
devem estar em conformidade com a norma: XYZ-ABC-2005”.

 Requisito externo
 “O sistema LIBSYS não deve revelar quaisquer informações pessoais sobre os
usuários aos funcionários da biblioteca, a não ser o nome e o número de registro no
sistema.” (privacidade)
Requisitos de domínio
Campus Graças

 São derivados do domínio de aplicação do sistema, em vez de

necessidades específicas do usuário.

 Podem se apresentar como requisitos funcionais ou como restrições

ao produto ou processo.

 São importantes porque descrevem características do domínio, tais como

fórmulas para realização de cálculos. Se não forem atendidos corretamente,
o sistema pode se tornar inútil para a organização cliente.
Problemas dos requisitos de domínio
Campus Graças

 Como podem ser especificados usando termos ligados ao domínio, a

equipe de desenvolvimento pode ter dificuldade em compreendê-los.

 Especialistas no domínio podem se esquecer de fornecer detalhes

importantes por achar que são óbvios demais.

19/53
Exemplo
Campus Graças

 Exemplos de requisitos de domínio:

 “A interface com o usuário deve ser a mesma para todos os
bases de dados ser baseada na norma técnica BR-Z39.50”
 “Devido a restrição de direitos autorais, o usuário só poderá
visualizar, antes de realizar o pagamento, no máximo 20% do
conteúdo do documento.”
 “A desaceleração do trem deve ser calculada através da
fórmula:
 Dtrem=Dcontrole + Dgradiente ”
Requisitos de usuário
Campus Graças

 Descrevem os requisitos funcionais e não funcionais de forma que

eles sejam compreensíveis pelos usuários do sistema que não
possuem conhecimento técnico detalhado.

 Devem especificar apenas o comportamento externo da aplicação,

evitando fazer referências a características de projeto do sistema;

 São definidos usando linguagem natural, tabelas e diagramas para

que possam ser entendidos por todos os usuários.
Problemas dos requisitos de usuário
Campus Graças

• Pelo fato de serem redigidos em linguagem natural, podem

apresentar os seguintes problemas:
• Falta de clareza: A linguagem natural é ambígua. Tentar contornar isso pode deixar o documento
prolixo e difícil de ler.
•  Confusão de requisitos: Requisitos funcionais e não funcionais tendem a se misturar no
documento.
•  Fusão de requisitos: Diversos requisitos diferentes podem ser expressos juntos como um único
requisito.

22/53
Dicas para redação de requisitos de usuário
Campus Graças

 Ao redigir requisitos de usuário, é importante lembrar que descrições

detalhadas devem ser deixadas para os requisitos de sistema.
 Ao incluir muitas informações, o requisito de usuário pode restringir o conjunto de
soluções que pode ser oferecido pelo desenvolvedor, além de dificultar a sua
compreensão.
 Foco deve se restringir aos recursos principais a serem oferecidos.

 Sempre que possível, tente definir uma justificativa lógica para a

inclusão do requisito.
Exemplo
Campus Graças
Requisitos de sistema
Campus Graças
 Descrevem em detalhes os requisitos de usuário, sendo utilizados pelos
engenheiros de software como ponto de partida para o projeto do sistema;

 Fornecem uma especificação completa da aplicação, podendo ser

usado como parte do contrato para a implementação do sistema.

 Idealmente, devem descrever apenas o comportamento externo e as

restrições operacionais da aplicação, sem impor restrições a forma de
projeto ou implementação do sistema.

25/53
Descrição dos requisitos
Campus Graças

 Embora a linguagem natural seja freqüentemente utilizada na

redação dos requisitos, seu uso pode tornar os requisitos confusos
e difíceis de serem entendidos;

 Mal entendidos causados por uma especificação inadequada dos

requisitos podem aparecer apenas na fase final do projeto,
tornando caro eventuais correções;

 Em função disso, costuma-se utilizar notações mais

especializadas para redação dos requisitos, como as listadas
no quadro a seguir.
Notações para especificação de requisitos
Campus Graças
Notação Descrição
Linguagem natural Utiliza formulários ou modelos padronizados para a
estruturada especificação de requisitos.
Linguagens de Utiliza uma linguagem semelhante a linguagem de
descrição de programação para especificação dos requisitos do sistema.
projeto
Notações gráficas Utiliza gráficos e anotações de texto para definir os requisitos
funcionais. Ex: Os diagramas de caso de uso e de sequência
da UML.
Especificações Notações baseadas em conceitos matemáticos, são
matemáticas utilizadas para eliminar a ambigüidade dos requisitos.
Especificações em linguagem estruturada
Campus Graças

 Restringe a liberdade do elaborador dos requisitos através do uso de

modelos (templates) para a definição dos requisitos e de limites impostos a
terminologia a ser utilizada em sua redação;

 O uso de um modelo garante que os requisitos serão todos descritos de forma

padronizada, mantendo a maior parte da facilidade de expressão e
compreensão da linguagem natural.

 O uso de modelos com campos pré-definidos ajuda a evitar que informações

essenciais sejam esquecidas no momento em que o documento de
requisitos é redigido.
Modelo padronizado para redação de
requisitos funcionais Campus Graças

 Idealmente, defina um formato com informações extra

sobre o requisito. Esse novo formato pode incluir
informações tais como:
 Identificação do requisito.
 Nome do requisito.
 Descrição geral do requisito.
 Prioridade do requisito.
 Fonte do requisito;
 Usuários;
Modelo padronizado para redação de
requisitos funcionais Campus Graças

 (continuação):
 Pré-condições;
 Pós-condições;
 Fluxo de eventos;
 Requisitos relacionados;
 Informação adicional.

30/53
Modelo padronizado de requisitos
funcionais Campus Graças

 Identificação do requisito
 Deve ser definido um código que facilite a identificação e o
relacionamento do requisito com outros requisitos. Ex: RF-001,
NFR-002, etc.
 Nome do requisito
 Deve ser associado um nome curto (2 ou 3 palavras apenas)
que permita identificar rapidamente a função do requisito. Ex:
Efetuar Login, Pesquisar produto, inserir pedido, etc.
 Descrição
 Descreve a função realizada pelo requisito.
Modelo padronizado de requisitos funcionais
Campus Graças
 Prioridade do requisito
 Deve ser definida a prioridade desse requisito em relação aos
demais. Ex: Essencial, Importante ou desejável.
 Fonte do requisito
 Deve ser identificado o stakeholder (nome do usuário, membro
da equipe de desenvolvimento, etc) que solicitou o requisito.
 Usuários
 Informa quem irá fazer uso do requisito. Deve ser descrito os
usuários principais, seguidos dos usuários secundários.
Modelo padronizado de requisitos funcionais
Campus Graças

 Pré-condições
 O que deve ser verdadeiro antes que a função relacionada a
esse requisito seja executada. Ex: Para o requisito relacionado
a cadastro de usuário, o usuário não deve ter ainda sido
cadastrado no sistema.
 Pós-condições.
 O que é verdadeiro após a execução da função relacionada a
esse requisito. Ex: Para o requisito relacionado a cadastro de
usuário, o usuário estará cadastrado no sistema.
Modelo padronizado de requisitos funcionais
Campus Graças

 Fluxo de eventos.
 Conjunto ordenado de ações (algoritmo) que serão realizadas
quando o serviço associado ao requisito for executado.
 Requisitos relacionados
 Identifica os requisitos que estão de alguma forma relacionados
(ou são afetados) pelo requisito em questão.
 Informação adicional
 Lista material de apoio (sites, documentos, etc) que possam
fornecer informações adicionais sobre o requisito em questão.
Exemplo
Campus Graças

 Considere a especificação de um sistema para

venda de cd’s, livros e dvds pela internet.
Exemplo requisito funcional
Campus Graças
Exemplo requisito funcional
Campus Graças
Exemplo requisito funcional
Campus Graças
Exemplo requisito funcional
Campus Graças
Exemplo requisito funcional
Campus Graças
Exemplo requisito funcional
Campus Graças
Modelo padronizado para redação de
requisitos não funcionais Campus Graças

 Um modelo para requisitos não funcionais requer bem menos

informações que um requisito funcional. Esse novo formato pode
incluir informações tais como:
 Identificação do requisito.
 tipo do requisito (usabilidade, desempenho, etc).
 Descrição geral do requisito.
 Prioridade do requisito.
 Fonte do requisito.

42/53
Modelos gráficos
Campus Graças

 Pode-se fornecer detalhes adicionais sobre os requisitos funcionais

através do uso de símbolos gráficos;

 Modelos gráficos são úteis para descrever a seqüência de ações

necessária para cumprir o objetivo do requisito ou o funcionamento de
um algoritmo;

 A linguagem UML possui os diagramas de seqüência e o diagrama de

atividades, que podem ser utilizados para complementar a informação do
documento de requisitos.
Especificação de interface
Campus Graças
 A maioria das aplicações precisa trocar dados com sistemas pré-
existentes.
 Interfaces dos sistemas com as quais a nova aplicação precisa
interagir devem ser incluídas no documento de requisitos (em um
apêndice).
 Três tipos de interfaces podem ser definidas:
 Interfaces de procedimentos (API’s): Listam os serviços que podem ser
acessados em um sistema.
 Estruturas de dados: formato utilizado para representar as informações a
serem trocadas;
 Representação dos dados: conjunto de bits utilizado para troca de dados e o
significado de cada um.
Exemplo
Campus Graças
Documento de requisitos
Campus Graças

 Reúne as informações necessárias para o

entendimento do sistema a ser construído.

 Padrão do IEEE pode ser utilizado como guia

para o documento de requisitos.
Documento de requisitos (IEEE)
Campus Graças

 1. Introdução.
 1. Propósito do documento.
 Defina aqui o propósito do documento (Porque você está
escrevendo o documento (quais são os objetivos)? Qual é o
público alvo?).
 2. Escopo do produto.
 Defina aqui o propósito do produto que vai ser construído. Deixe
claro os seus limites (o que ele vai e (se necessário) não vai
fazer).
Documento de requisitos (IEEE)
Campus Graças

 3. Convenções, termos e abreviações.

•  Defina aqui os termos e abreviações utilizados no produto e neste documento cujo
conhecimento irá facilitar o entendimento do documento de requisitos.
 4. Referências.
•  Liste aqui quaisquer referências que tenham sido utilizadas na redação deste documento.
 5. Visão geral do restante do documento
•  Descreva o conteúdo de cada seção na qual o documento foi dividido.
Documento de requisitos (IEEE)
Campus Graças

 2. Descrição geral
 1. Perspectiva do produto
 Coloque o produto em perspectiva, comparando-o com outros
produtos e projetos.
 Se o produto é independente, isso deve ser registrado.
 Se o produto é parte de um sistema maior, relacione as
necessidades do sistema maior com as funcionalidades do
software descrito neste documento. Identifique também a
responsabilidade do mesmo no contexto do sistema como um
todo e as interfaces existentes entre o produto e o sistema.
Documento de requisitos (IEEE)
Campus Graças

 2. Funções do produto.
 Liste aqui as principais funcionalidades que estarão disponíveis
no produto, com uma rápida descrição de seu propósito e sua
importância (prioridade) em relação as outras funcionalidades.
 3. Características dos usuários.
 Descrição de cada usuário do sistema, com informações sobre a
sua função na organização, freqüência de uso do sistema e que
partes do sistema irá operar.
 4. Restrições gerais
 Descreva qualquer restrição que possa afetar o desenvolvimento
do produto, tais como padrões e processos, linguagem de
programação, interfaces com produtos existentes, legislação,
segurança, etc.
Documento de requisitos (IEEE)
Campus Graças
 2.5 Suposições e dependências.
 Liste aqui todos os fatores que foram levados em consideração ao redigir o
documento de requisitos, tais como ferramentas e software que serão utilizados no
desenvolvimento do produto.
 3. Requisitos.
 Liste aqui todos os requisitos funcionais e não funcionais da aplicação. Requisitos
funcionais devem utilizar o modelo com campos pré-definidos descrito
anteriormente.
 4. Apêndices
 Descreva aqui quaisquer informações relevantes que não se encaixam nas outras
seções, tais como a metodologia de levantamento dos requisitos.
 Obrigado
E - mail:adilson.silva@sereducacional.com

@prof.Adilson.silva