ULBRA – Universidade Luteranado Brasil

Curso de Sistemas de Informação

Engenharia de Requisitos
n A Engenharia de Requisitos estabelece o processo de
Engenharia de definição de Requisitos no qual o que deve ser
produzido é elicitado, modelado e analisado. Este

Software processo acontece num contexto previamente definido a

que chamamos de Universo de Informação (UdeI).
Aula 03: Engenharia de Requisitos n Universo de Informação: ambiente geral no qual o
software será desenvolvido. Inclui todas as fontes de
informação e as pessoas relacionadas ao software, às
Prof. MSc Fernando Prass quais denominamos de agentes desse universo.
fprass@gmail.com
www.fp2.com.br/fernando Prof. MSc. Fernando Prass 2

Requisito x Especificação Que é um requisito?

Requisito: condição necessária para a obtenção n Um requisito tanto pode ser uma
de certo objetivo, ou para o preenchimento de
declaração abstrata de alto nível de um
certo objetivo.
Especificação: descrição detalhada/minuciosa das servi ço, como uma restrição do sistema
características que um material, obra, ou um ou ainda uma especificação funcional
serviço deverão apresentar.
detalhada de alguma rotina.
Portanto, Especificação é diferente de Requisitos

Prof. MSc. Fernando Prass 3 Prof. MSc. Fernando Prass 4

Tipos de Requisitos O Processo

n Explícitos: aqueles descritos em um documento que Estudo de Elicitaç ão e
Aná lise de
lista os requisitos de um produto (especificação de viabilidade
requisitos
Especifica çã o
requisitos) de requisitos
Validaç ão
n Normativos: aqueles que decorrem de leis, Relat ório de de requisitos

regulamentos, padrões e outros tipos de normas a viabilidade

que o tipo de produto deve obedecer Requisitos do

usu ário e do
n Implícitos: expectativas dos clientes e usuários, que sistema
são cobradas por esses, embora não-documentadas
Modelos do Documento de
sistema requisitos

Prof. MSc. Fernando Prass 5 Prof. MSc. Fernando Prass 6

1
Estudo de Viabilidade
n Estudo que indica se o esforço em desenvolver
a idéia vale a pena
¨ Visa tanto a tomada de decisão como a sugestão de
possíveis alternativas de solução
n Oferece informações para ajudar na decisão
¨ Se o projeto pode ou não ser feito
¨ Se o produto final irá ou não beneficiar os usuários
interessados
¨ Há uma melhor alternativa?
Prof. MSc. Fernando Prass
Visão dos Requisitos
n Requisitos do Usuário: declarações em
linguagem natural com diagramas de serviços
que o sistema deve oferecer e suas restrições
operacionais. Escrito para os clientes.
n Requisitos do Sistema: documento estruturado
com descrições detalhadas sobre os serviços do
sistema. Contrato entre cliente e fornecedor.
Prof. MSc. Fernando Prass
Requisitos Funcionais (RF)
n Descreve funcionalidade e servi ços do
sistema
n Depende do
¨ Tipo do software
¨ Usuários esperados
¨ Tipo do sistema onde o software é usado
Prof. MSc. Fernando Prass
Elicitação e Análise de requisitos
n Elicitação: processo de descoberta, objetiva
descobrir o domínio de aplicação, serviços que
devem ser fornecidos e restrições
¨ Deve envolver usuáriosfinais, gerentes, pessoal
envolvido na manutenção, especialistas no domínio,
etc. (Stakeholders).
n Análise: é o processo de entendimento e
avaliação do que foi levantado
7 Prof. MSc. Fernando Prass 8
Tipos de Requisitos
n Requisitos Funcionais
n Requisitos Não-Funcionais
n Requisitos de Domínio
9 Prof. MSc. Fernando Prass 10
Exemplos de RF
n [RF001] Usuário pode pesquisar todo ou um
sub-conjunto do banco de dados
n [RF002] Sistema deve oferecer visualizadores
apropriados para o usuário ler documentos
armazenados
n [RF003] Todos os documentos devem ser
passíveis de impressão
11 Prof. MSc. Fernando Prass 12
2
Requisitos Não-Funcionais (RNF)
n Definem propriedades e restrições do sistema
(tempo, espaço, etc)
n Requisitos de processo também podem
Classificação de RNF
n Requisitos do Produto: o produto deve comportar -se de forma
particular (velocidade de execuç ão, confiabilidade, etc.)
¨ [RNF001] Consultas baseadas em código de barras devem ser
concluída em até 5 segundos

especificar o uso de determinadas linguagens n Requisitos Organizacionais: conseq üência de procedimentos e

de programação, método de desenvolvimento
n Requisitos não-funcionais podem ser mais
críticos que requisitos funcionais. Não satisfaz,
sistema inútil.
políticas da organização (padrões de processo, diretrizes, etc.)
¨ [RNF002] Todos os documentos entregues devem seguir o padrão de
relatórios XYZ-00
n Requisitos Externos: conseq üência de fatores externos ao sistema
e ao processo de desenvolvimento (legislação, cotações, etc.)
¨ [RNF003] Informações pessoais do usuário não devem ser vistas pelos
operadores do sistema

Prof. MSc. Fernando Prass 13 Prof. MSc. Fernando Prass 14

Exercício Requisitos de Domínio

n Dê alguns exemplos de RNFs para: n São derivados do domínio da aplicação e

¨ Sistema da padaria de pequeno porte; descrevem características do sistema e
¨ Site de e-commerce; qualidades que refletem o domínio
¨ Sistema de alocação docente.
n Podem ser requisitos funcionais novos,
restrições sobre requisitos existentes ou
computações espec íficas

Prof. MSc. Fernando Prass 15 Prof. MSc. Fernando Prass 16

Requisitos de Domínio
Requisitos
(Problemas)
Requisitos
n Entendimento
¨ Requisitos são descritos na linguagem do domínio
Usuário = Sistema
¨ Não é entendido pelos engenheiros de software que
vão desenvolver a aplicação
n Implicitude: especialistas no domínio entendem Funcionais Não-funcionais Domínio
a área tão bem que não tornam todos os
requisitos de domínio explícitos
Produto Organização Externo
Prof. MSc. Fernando Prass 17 Prof. MSc. Fernando Prass 18

3
Técnicas de Elicitação Entrevistas
n Técnica direta
n Entrevistas ¨ Pode ser usada na análise do problema e na
elicitação de requisitos
n Questionários n Objetivo
n Casos de Uso ¨ Entender os problemas reais e soluções
potenciais das perspectivas dos usuários,
n Brainstorming clientes, e outros stakeholders

n Workshop de Requisitos

Prof. MSc. Fernando Prass 19 Prof. MSc. Fernando Prass 20

Entrevistas Entrevistas

n Quem são os clientes e o usuários? n Qual é o problema?

n Possuem necessidades diferentes? n Como é resolvido atualmente?
n Quais são suas necessidades: n Qual a razão para resolvê-lo?
¨ Capacidades
n Qual o valor de uma solução bem-sucedida?
¨ Backgrounds

¨ Ambientes, etc.
n Onde mais uma solução pode ser encontrada?

Prof. MSc. Fernando Prass 21 Prof. MSc. Fernando Prass 22

Questionários Casos de Uso

n Aplicabilidade a mercados espec íficos n Discuta com o cliente o que o sistema fará e
¨ Onde perguntas são bem definidas identique quem interage com o mesmo .
n Hipóteses Modele um protótipo de interface, apresente
¨ Perguntas relevantespodem ser decididas
antecipadamente ao usuário e tente identificar se há requisitos
¨ Leitor ouve da maneira desejada faltando
¨ Suprime o que é bom sobre análise n Vantagem é ter apelo visual dos requisitos
n Úteis após uma entrevista inicial mais relevantes do cliente

Prof. MSc. Fernando Prass 23 Prof. MSc. Fernando Prass 24

4
 Brainstorming Workshop de Requisitos
n Põe todos os stakeholders
n Numa tradução literal: “tempestade de idéia”. As
juntos por um período intensivo
regras são variadas, mas não fogem das (focado)
apresentadas a seguir: n Facilitador conduz a reunião
¨ Estabeleça o objetivo da sessão n Todos têm sua vez de falar
¨ Gere quantasidéias for possível n Resultados são disponíveis
imediatamente
¨ Deixe a os usuários imaginação livre
n Provê um ambiente para
¨ Num primeiro momento não admita críticas ou debates
aplicar outras técnicas de
¨ Num segundo momento ajuste e combine as idéias elicitação

Prof. MSc. Fernando Prass 25 Prof. MSc. Fernando Prass 26

Análise de Requisitos Entendimento do Domínio

Defini ção e Documento
especificaçã o
de requisitos
de requisitos
n Desenvolver sistemas envolve domínios
7 8
além de software e hardware
Validaç ão
dos requisitos
n Podemos ter que entender sobre
Entendimento 6 Atribuiç ão de ¨ Contabilidade
do domí nio Prioridade
Entrada do 1
processo 5 ¨ Saúde

2 4 ¨ Supermercados
Coleta de Resoluç ão
requisitos de conflito ¨ Etc.
3

Classifica çã o

Prof. MSc. Fernando Prass 27 Prof. MSc. Fernando Prass 28

Coleta de Requisitos Classificação dos Requisitos

n Como vimos anteriormente, a coleta de n Esta etapa consiste basicamente em

requisitos é feita através de técnicas agrupar os diversos requisitos coletados
n Nesta etapa, os requisitos são em categorias (clusters) bem-definidos
simplesmente documentados à medida n Por exemplo
que são coletados ¨ Deve ser possível consultar o preço de uma
n Resulta em documento preliminar (draft) mercadoria
n A consulta deve retornar uma resposta em no
máximo 5 segundos

Prof. MSc. Fernando Prass 29 Prof. MSc. Fernando Prass 30

5
Problemas Resolução de Conflitos
n Stakeholders em geral não sabem o que querem, n É normal que ocorram requisitos
expressam requisitos em sua terminologia conflitantes
n Stakeholders diferentes podem gerar requisitos
conflitantes n Por exemplo
n Requisitos mudam durante o processo de análise ¨ R-23: O sistema deve ...
n Stakeholders novos podem surgir e o ambiente de ¨ R-45: O sistema não deve ...
trabalho muda n Cliente/usuário deve ser consultado para
n Fatores políticos e organizacionais podem influenciar os resolver conflitos (ambigüidades)
requisitos do sistema

Prof. MSc. Fernando Prass 31 Prof. MSc. Fernando Prass 32

Atribuição de Prioridade Prioridade

n Alguns requisitos são mais urgentes que n Requisitos podem ser vistos em três
outros classes distintas
¨ Essenciais
n É essencial determinar a prioridade dos
¨ Importantes
requisitos junto ao cliente
¨ Desejáveis
n Requisitos de maior prioridade são
n Em princípio, sistema deve resolver todos
considerados em primeiro lugar os requisitos de essenciais para
desejáveis

Prof. MSc. Fernando Prass 33 Prof. MSc. Fernando Prass 34

Exemplo de Prioridade Validação dos Requisitos

n [RF001] Consulta X ao B.D. deve retornar dados n Será que realmente entendi o que o cliente deseja?
A, B, C n Devo me certificar de que não houve falha em nossa
¨ Prioridade: Essencial
intera ção (comunicação)
n [RNF001] Consulta X ao B.D. deve visualizar
n Demonstrar que os requisitos definem o sistema que o
dados segundo padrão Y
¨ Prioridade: Importante cliente realmente deseja
n [RNF010] Consulta X ao B.D. deve usar cores n Custos com erros de requisitos são altos
azuis nos resultados ¨ Consertar um erro de requisitos ap ós entrega do sistema pode
¨ Prioridade: Desejável custar mais de 100 vezes o custo de um erro de implementa ção

Prof. MSc. Fernando Prass 35 Prof. MSc. Fernando Prass 36

6
Rastreamento Rastreamento
1.Rastrear requisitos do
n Rastreamento de Requisitos Requisitos usuário nos do sistema
¨ Associação entre requisitos dependentes Produto Req A
(Caracter.) 2.Rastrear requisitos no
projeto
n Rastreamento de Projeto 1 3.Rastrear requisitos nos
¨ Associação dos requisitos com o projeto procedimentos de teste
Requisitos
n Usar hipertexto ou referência cruzada Detalhados Req B 4.Rastrear requisitos do
(Casos de Uso ) usuário no plano
¨ Ou matriz de rastreamento 2 3 4

Projeto Teste Doc. Usuário

Prof. MSc. Fernando Prass 37 Modelos Suítes Teste Plano

Prof. MSc. Fernando Prass 38

Documento de Requisitos Documento de Requisitos

n Fonte: IEEE/ANSI (830-1998) n 2. Descrição geral
n 1. Introdução ¨ 2.1 Perspectiva do produto
¨ 1.1 Propósito do documento
¨ 2.2 Funções do produto
¨ 1.2 Escopo do sistema
¨ 2.3 Características dos usuários
¨ 1.3 Definições, acrônimos e abreviaturas
¨ 1.4 Referências ¨ 2.4 Restrições gerais
¨ 1.5 Descrição do resto do documento ¨ 2.5 Assertivas e dependências

Prof. MSc. Fernando Prass 39 Prof. MSc. Fernando Prass 40

Documento de Requisitos Bibliografia

n 3. Requisitos espec íficos n BOOCH, G.. UML: guia do usuário. Rio

¨ requisitos
funcionais, não-funcionais, GUI
de Janeiro: Elsevier, 2005.
com o usuário: n PRESSMAN, Roger S.. Engenharia de
Software. São Paulo: Pearson, 2006.
n funcionalidade,interfaces externas,
n SOMMERVILLE, Ian. Engenharia de
desempenho, restrições, atributos do
sistema, caract. qualidade, ...
Software. São Paulo: Pearson, 2004.

Prof. MSc. Fernando Prass 41 Prof. MSc. Fernando Prass 42