1. Engenharia de Software
Aula 3 – Engenharia de Requisitos
Profa. Dra. Judith Pavón
Universidade Salvador – UNIFACS
2012

2. Objetivo da aula
O objetivo desta aula é apresentar os
conceitos básicos de Engenharia de
Requisitos.
2

3. Conteúdo
1. Introdução
2. Importância dos requisitos
3. Processo de Engenharia de Requisitos
4. Classificação dos requisitos
3

4. Introdução
 Um processo de engenharia de
requisitos eficiente evita uma
compreensão incorreta dos requisitos.
4

5. Introdução
 Requisitos são importantes para projetos de
desenvolvimento de software, pois são a base
para :
­ Análise de contratos;
­ Elaboração / análise de propostas;
­ Planejamento;
­ Estimativas;
­ Análise de riscos;
­ Gestão e controle;
­ Modelagem do sistema;
­ Desenvolvimento;
­ Testes.
5

6. Introdução
 Problemas com requisitos levam a:
­ Clientes insatisfeitos;
­ Altos custos;
­ Perda de reputação;
­ Compreensão do “problema incorreto”;
­ Efeito cascata nas demais fases de
desenvolvimento de software.
6

7. Importância dos requisitos
 CMMI-SE/SW (Capability Maturity Model
Integration)
­ Modelo de melhoria de processo de desenvolvimento de
software.
­ Modelo seguindo 5 níveis de maturidade.
­ Capacidade de um processo de software:

faixa de resultados esperados dentro de uma margem de
probabilidade.
­ Maturidade do processo:

reflete em que medida ele pode ser definido, gerenciado,
medido, controlado e executado de maneira eficaz.
7

8. Importância dos requisitos
 CMMI-SE/SW (Capability Maturity Model
Integration)
5.
OTIMIZADO
4. GERENCIADO
5. Processo focado na
QUANTITATIVAMENTE melhoria contínua
3.
DEFINIDO 4. Processo medido e
controlado
2.
GERENCIADO 3. Processo orientado à
organização e proativo
1.
2. Processo orientado a
INICIAL
projetos e geralmente
reativo
1. Processo
imprevisível, pouco
controlado e reativo
8

9. Importância dos requisitos
Níveis de Maturidade - CMMI-SE/SW
9

10. Importância dos requisitos
Processo de Engenharia de Requisitos (PER) no modelo CMMI
nível 3. definido
PER baseado
em melhores práticas;
melhoria contínua
nível 2. repetível
PER obedecendo
a normas
nível 1. inicial
PER adhoc
10

11. Importância dos requisitos
Ciclo de Vida de Software (SWEBOK, 2004)
Levantamento
Projeto de Implementação Teste de Manutenção de
e Definição
Software de Software Software Software
de Requisitos
Elicitação de
Requisitos
Análise de
Requisitos
Especificação
de Requisitos ri co
e né
el o G
Validação d
de Requisitos Mo
Gerenciamento
de Requisitos
SWEBOK – Guide to the Software Engineering Body of Knowledge (IEEE)
11

12. Importância dos requisitos
 56% dos erros em um sistema associam-se a problemas na
fase de identificação dos requisitos (Fonte: “Extra time
saves money” Warren Kuffel).
 Erros mais comuns: uso de fatos incorretos, omissão,
inconsistência e ambigüidade.
Distribuição de Defeitos
56%
Requisitos
27%
Projeto
7% 10% Outros
Codificação

13. Importância dos requisitos
Clássicas falhas de sistemas por problemas de
requisitos
 Aeroporto de Denver: mais de US$ 50 milhões perdidos em
função de erros no sistema de controle de bagagens
(Flower).
 Sistema de Ambulâncias de Londres: o sistema foi
desativado um dia após o início de suas operações com
causa de seus erros e falhas de segurança, confiabilidade
e usabilidade (Flower).
 Foguete do Satélite Ariane 5: a trajetória do foguete era
controlada por um sistema de computador, que falhou junto
com seu sistema backup. Comandos de diagnóstico foram
enviados para os motores, fazendo com que o foguete
mudasse para uma trajetória instável (Nuseibeh).
13

14. Conceitos Básicos
Requisito
 Uma especificação do que deve ser implementado.
Descrição de como o sistema deve se comportar, ou uma
propriedade ou atributo do sistema. Pode ser uma
restrição no processo de desenvolvimento do sistema.
(Sommerville & Sawyer)
 Uma condição ou capacidade que o sistema deve
contemplar (Pressman)
 Uma necessidade do usuário ou característica, função ou
atributo de um sistema que pode ser percebido de uma
posição externa ao sistema. (Davis)
14

15. Conceitos Básicos
Engenharia de Requisitos
 A Engenharia de Requisitos é um processo que envolve
todas as atividades necessárias para criar e manter um
Documento de Especificação de Requisitos
(Sommerville).
 A Engenharia de Requisitos é uma sub-área da
Engenharia de Software que estuda o processo de
definição de requisitos que o software deverá atender
(Sampaio).
 A Engenharia de Requisitos tem como objetivo prover ao
profissional de métodos, técnicas e ferramentas que
auxiliem o processo de compreensão e registro dos
requisitos que o sistema deve atender (Sampaio).
15

16. Processo de Engenharia de Requisitos
Processo
 É um conjunto organizado de atividades que transforma entradas em
saídas (Pressman).
Atividades do Processo de Engenharia de Requisitos
(Sommerville &
Kontoya)
 Elicitação de Requisitos
­ Os requisitos são descobertos por meio das consultas com as partes
interessadas.
 Análise e Negociação de Requisitos
­ Requisitos são analisados e conflitos são resolvidos por meio da
negociação.
 Documentação de Requisitos
­ Um documento de requisitos é produzido.
 Validação de Requisitos
­ É checada a consistência, completude e outros atributos de qualidade do
documento de requisitos.
 Gerenciamento de Requisitos
­ Consiste no controle de mudanças dos requisitos dentro do ciclo de vida do
16
software.

17. Processo de Engenharia de Requisitos
Análise
Elicitação Documentaç Validação
ão
Gerenciamento de Requisitos
Fonte: Sommerville & Sawyer, 2000
17

18. Processo de Engenharia de Requisitos
Elicitar Requisitos Controlar Mudanças
Analisar Requisitos Rastreabilidade
Requisitos
Documentar Requisitos Gerenciar Configuração
Gerenciar Qualidade
Validar Requisitos
de Requisitos
Desenvolvimento de Requisitos Gerenciamento de Requisitos
18

19. Processo de Engenharia de Requisitos
sistemas Processo de Engenharia de Requisitos
existentes (Entradas e Saídas)
necessidades
dos
usuários
normas processo de requisitos
da engenharia de aprovados
organização requisitos
Documento
de
regulamentos Requisitos
informação
do Fonte: Kotonya & Sommerville, 1998
domínio
19

20. Processo de Engenharia de Requisitos
Características Principais da Engenharia de Requisitos
 O processo de engenharia de requisitos é estruturado como um
conjunto de atividades que leva a produção do documento de
requisitos.
 As entradas do processo de engenharia de requisitos são as
informações existentes dos sistemas, necessidade das pessoas
interessadas (stakeholders), padrões organizacionais,
regulamentações e informações do domínio.
 Os processos de engenharia de requisitos variam radicalmente entre
empresas. A maioria dos processos incluem a elicitação de requisitos,
análise e negociação, a documentação e a validação dos requisitos.
 A atividade de gerenciamento de requisitos é uma atividade
complementar que auxilia no controle das mudanças dos requisitos.
20

21. Stakeholders
Atores no Processo de Engenharia de Requisitos:
Stakeholders
 Quem são os “interessados no sistema”?
São as pessoas que serão afetadas pelo sistema e que
têm uma influência direta ou indireta na elaboração dos
requisitos:
­ usuários finais, gestores e outros envolvidos nos processos
organizacionais que o sistema influencia, responsáveis pelo
desenvolvimento e manutenção do sistema, clientes da
organização que possam vir a usar o sistema, organismos de
regulação e certificação, etc.
21

22. Stakeholders
Alguns exemplos de partes interessadas
(stakeholders):
 Gestor do sistema;
 Usuários finais;
 Gestores de sistemas impactados;
 Funcionários;
 Clientes do banco;
 Especialistas no negócio;
 Órgãos reguladores;
 Parceiros.
22

23. Conceito de
Rastreabilidade
 Técnica usada para prover relacionamento entre requisitos, projeto e
implementação final do sistema (Edwards).
 É uma técnica que permite que os requisitos sejam claramente
ligados às suas fontes e aos artefatos criados durante o ciclo
de vida de desenvolvimento do sistema (Ramesh).
 Habilidade de permitir que mudanças em qualquer artefato – requisitos,
especificação e implementação– sejam rastreadas através do sistema
(Greenspan).
Rastreabilidad
Domínio do
Problema Necessidades e
Macro-Requisitos
Domínio da Requisitos
Solução
Projeto e Documentações
23

24. Conceito de
Rastreabilidade
 Uma especificação de requisitos é rastreável se permite a fácil
determinação dos antecedentes e conseqüências de todos os
requisitos.
 Rastreabilidade para Trás:
­ Deve ser possível localizar a origem de cada requisito.
­ Deve-se saber por que existe cada requisito, e quem ou o que o originou.
Isso é importante para que se possa avaliar o impacto da mudança daquele
requisito, e dirimir dúvidas de interpretação.
 Rastreabilidade para Frente:
­ Deve ser possível localizar quais os resultados do desenvolvimento que serão afetados por
cada requisito.
Isso é importante para garantir que os itens de análise, modelagem, código e
teste abranjam todos os requisitos, e para localizar os itens que serão afetados
por uma mudança nos requisitos.
24

25. Conceito de
Rastreabilidade
 Os usuários comunicaram uma série de
mudanças nas regras de negócio do
Sistema de Contabilidade. Quanto você
acha que vamos levar para alterar o
sistema?
 Cara, vai dar um trabalhão. A lógica do
cálculo dos impostos está espalhado por
todo o sistema. Vamos gastar um tempão
só para localizar todos os lugares que
teremos de mexer.
25

26. Conceito de
Rastreabilidade
 A gestão de requisitos deve prover meios
para que seja possível fazer um
rastreamento entre os requisitos.
 Devem ser criados e mantidos entre
requisitos, desde os requisitos de negócio
até os requisitos de implementação, de
testes e de documentação.
 Deve ser possível seguir estes vínculos
nas duas direções.
26

27. Motivos para fazer
Rastreabilidade
 Certificação – demonstração de que todos os
requisitos foram implementados.
 Análise de impacto – cálculo do custo, tempo e risco
de uma mudança.
 Manutenção – Indicação dos lugares onde deverão
ser feitas as alterações solicitadas.
 Acompanhamento do projeto – aferição do progresso
de um projeto de desenvolvimento ou manutenção.
27

28. Motivos para fazer Rastreabilidade
 Reengenharia – vínculo entre as funções do velho
sistema e o local em que as mesmas estão
implementadas no novo sistema.
 Reutilização – identificação de pacotes reutilizáveis de
requisitos, design, código e testes.
 Redução de riscos – redução do impacto causado pela
perda de um membro da equipe que mantém
conhecimento essencial sobre o projeto.
 Testes – apoio na identificação dos locais onde pode
estar o defeito detectado.
28

29. Classificação de Requisitos
29

30. Classificação de Requisitos
 Níveis de Requisitos
 Nível de negócio
 Nível de sistema
 Tipos de Requisitos
­ Nível de negócio
­ Requisitos de usuário (negócio)
­ Regras de negócio
­ Nível de sistema
­ Requisitos Funcionais
­ Requisitos Não Funcionais;
­ Requisitos Inversos;
30

31. Níveis de Requisitos
 Existem basicamente dois níveis de
requisitos:
­ Nível de negócio:

Considera-se um nível macro, onde o foco principal é
o negócio, independente do sistema.
­ Nível de sistema:

Considera-se um nível mais micro, onde a
preocupação é identificar todos os requisitos
necessários para o negócio, que devem ser
contemplados no sistema.
31

32. Nível de Negócio
 Existem dois tipos de requisitos neste nível:
­ Requisitos de negócio:
 São as necessidades do negócio que são expressas pelos
usuários ou clientes do sistema.
 São declarações, em linguagem natural ou em diagramas
sobre o que o negócio exige que seja desenvolvido. Os
requisitos de negócio devem se concentrar no que o
sistema deve atender e não no como.
­ Regras de negócio:
 São restrições sobre dados ou processos de negócio.
32

33. Regras de Negócios
 Uma regra de negócio descrevem, restringem
ou controlam os dados ou atividades de um
processo de negócio.
 Um processo de negócio é um conjunto de um
ou mais procedimentos, os quais coletivamente
realizam um objetivo de negócio, normalmente
dentro do contexto de uma estrutura
organizacional.
33

34. Regras de Negócios
 Uma organização ou empresa opera de acordo com um conjunto
de regras de negócio, tais como, regras jurídicas, regras de
venda, regras de interação com o cliente, entre outras.
 As regras expressam aspectos estáticos e dinâmicos do negócio.
 A automatização dos processos de negócio exige a
automatização das regras que regem estes processos.
 As regras são representadas em uma linguagem processável,
com a finalidade de automatizá-las em um sistema.
34

35. Exemplo
Regra: O gerente designado para atender a um
cliente deve estar lotado em uma agência onde o cliente
possui conta corrente.
Está lotado
Gerente Agência
Atende Pertence
Possui Conta
Cliente
Corrente
35

36. Nível de Sistema
­ 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 é gerado neste nível. Ele pode servir como
um contrato entre o comprador do sistema e o
desenvolvedor de software.
36

37. Tipos de Requisitos de Sistema
 Requisitos Funcionais
­ Descrevem os serviços que se espera que o sistema
deve oferecer.
­ Especificam as funcionalidades do sistema.
 Requisitos Não Funcionais
­ Descrevem aspectos de qualidade que o software deverá
apresentar, ou as restrições a serem atendidas.
­ Os requisitos não funcionais referem-se às condições
nas quais deve funcionar o sistema.
­ Podem estar relacionados a propriedades do sistema, tais como,
confiabilidade, desempenho, etc.
 Requisitos Inversos
­ Referem-se ao que o sistema não fará. Descrevem as funções e
restrições que não serão consideradas na abrangência do sistema.
­ São declarações do que o sistema não deve fazer ou de
condições que nunca devem ocorrer durante o uso do
sistema.
37

38. Tipos de Requisitos de Sistema
 Exemplos de Requisitos Funcionais:
­ O sistema deve permitir o cálculo dos gastos diários,
semanais, mensais e anuais com o pessoal.
­ O sistema deve permitir consultar informações
gerenciais operacionais da empresa.
 Exemplos de Requisitos Não Funcionais:
­ O tempo de resposta do sistema não deve ultrapassar
30 segundos.
­ O software deve ser operacionalizado no sistema Linux..
­ O sistema deve ter uma disponibilidade 24x7.
 Exemplos de Requisitos Inversos:
­ A integração com o banco central, contabilidade e
recursos humanos não fazem parte deste sistema.
38

39. Requisitos Funcionais
Como especificar requisitos funcionais?
 Linguagem Natural
­ Os requisitos funcionais podem ser descritos em linguagem
natural em nível macro.
 Casos de uso
­ Um modelo de casos de uso é utilizado para representar as
funcionalidades do sistema de forma detalhada.
­ Um modelo de casos de uso identifica quem ou o que
interage com o sistema e o que sistema deve fazer.
­ Casos de uso são técnicas baseadas em cenários onde são
identificados atores e sua interação com o sistema.
39

40. Requisitos Não Funcionais
TIPOS DE REQUISITOS NÃO FUNCIONAIS (Sommerville)
 Requisitos de produtos
­ São os requisitos que especificam o comportamento do produto.
­ Exemplo: requisitos de desempenho, que especificam com que rapidez o
sistema deve operar.
 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 processos que devem ser utilizados, os
requisitos de implementação, como a linguagem de programação ou a
metodologia de processo de desenvolvimento.
 Requisitos externos
­ Abrange todos os requisitos procedentes de fatores externos ao sistema e ao
seu processo de desenvolvimento.
­ Exemplo: requisitos de interoperabilidade, requisitos legais, requisitos éticos.
40

41. Requisitos Não Funcionais
Requisitos
não-funcionais
Produto Organizacionais Externos
Interoperabilidade Éticos
Eficiência Confiabilidade Portabilidade
Legislativos
Facilidade
de uso Entrega Implementação Padrões
Privacidade Segurança
Desempenho Espaço
41

42. Requisitos Não Funcionais
 Usabilidade (facilidade de uso)
­ Definição: A facilidade de aprendizado e operação do software pelos potenciais
usuários.
­ Métrica: Tempo de treinamento
Habilidades do usuário / unidade de tempo
Recursos de ajuda on-line
­ Exemplo:

Um balconista treinado deve ser capaz de cadastrar um cliente em no
máximo 5 minutos.

Novos usuários do internet banking devem ser capazes de encontrar o
serviço de recarga de celulares no máximo em duas tentativas.
 Eficiência (performance)
­ Definição: medida de velocidade e eficiência do sistema em execução.
­ Métrica: Throughput (quantidade de transações/unidade de tempo)
Tempo de resposta ao usuário/evento
Capacidade (quantidade de usuários usando o sistema
simultaneamente)
­ Exemplo:

O tempo de resposta do serviço “saldo da conta” deve ser no máximo 4
segundos.
42

43. Requisitos Não Funcionais
43

44. Requisitos Não Funcionais
 Portabilidade
­ Definição: A habilidade do software de se adaptar a diferentes ambientes
pré-definidos.
­ Métrica: Número de sistemas-alvo
Porcentagem de declarações dependentes de sistemas-alvo
­ Exemplo:
 O sistema deverá ser capaz de operar em Windows e Linux.
 Confiabilidade
­ Definição: A habilidade do software de se comportar consistentemente de
forma aceitável pelo usuário.
­ Métrica: Taxa de ocorrências de falhas
Probabilidade de indisponibilidade (downtime)
Disponibilidade
­ Exemplo:
 O sistema deverá estar disponível 24x7.
44

45. Requisitos Não Funcionais
 Interoperabilidade
­ Definição: capacidade de interação com outros produtos especificados.
­ Métrica: Produtos com os quais o sistema deve se comunicar
­ Exemplo:

O sistema deverá permitir exportar os relatórios para Excel.
 Segurança
­ Definição: resistência ao acesso não-autorizado e à perda de
informações. Se preocupa pela privacidade dos dados.
­ Métrica: Restrições de acesso
 Definição de perfis de usuários

Procedimentos de segurança dos dados
­ Exemplo:

Duas cópias de segurança dos dados do sistema serão feitas
diariamente e pelo menos uma delas deve ser armazenada em
local externo.
45

46. Requisitos Não Funcionais
 Requisitos de entrega
­ Definição: indicam restrições de prazos e forma de entrega dos produtos a
serem elaborados.
­ Métrica: Data de Entrega
Formato de entrega de artefatos
­ Exemplo:
 O módulo referente a empréstimos deve ser entregue até dia 20 de
janeiro de 2008.
 Requisitos de implementação
­ Definição: indicam restrições quanto ao uso de ferramentas ou linguagens
de programação.
­ Métrica: Lista de ferramentas
Definição de padrões
­ Exemplo:
 O sistema será desenvolvido utilizando a linguagem de programação
Java e o SGBD PostgreSQL.
46

47. Requisitos Não Funcionais
 Requisitos relativos a padrões
­ Definição: indica a necessidade de obedecer métodos, normas e padrões
institucionais.
­ Métrica: Lista de padrões
Definição de métodos
­ Exemplo:
 O sistema será desenvolvido seguindo o modelo de processo de
desenvolvimento RUP.
 Requisitos éticos
­ Definição: abordam a prevenção da divulgação não autorizada de
informações pessoais e o respeito aos indivíduos como cidadãos.
­ Métrica: Regras éticas
Normas de comportamento do usuário
­ Exemplo:
 O sistema deverá possuir meios de impedir a cópia e divulgação de
listas de clientes para pessoas não autorizadas.
47

48. Requisitos Não Funcionais
 Requisitos legais
­ Definição: indica a necessidade de
conformidade com determinações legais e
regulatórias.
­ Métrica: Leis vigentes
Normas da empresa
­ Exemplo:
 O sistema deverá permitir o fornecimento dos dados
pessoais sobre os clientes quando a gerencia solicitar
os mesmos.
48

49. Importância dos Requisitos
Não Funcionais
 Todos os Requisitos Funcionais devem ser satisfeitos, mas
se os Requisitos Não-Funcionais forem negligenciados, o
sistema falhará.

50. Exercícios de Revisão
Identificação de Tipos de Requisitos
 Verifique se as sentenças abaixo são requisitos verificáveis.
 Caso não sejam verificáveis, há uma forma melhor de defini-los?
 Caso sejam requisitos verificáveis, indicar o tipo de requisito.
a) Todo funcionário deve possuir um cartão de identificação da empresa.
b) O downtime do sistema é 2 horas no período da madrugada de domingo.
c) O sistema deve permitir aos professores realizar uma reserva de
equipamentos por meio de uma aplicação web.
d) As janelas do sistema devem ter uma interface que permita aos usuários
utilizar o sistema de forma intuitiva.
e) O sistema deverá estar preparado para usuários com deficiências físicas.
f) O sistema deve permitir a criação de um menu de opções de equipamentos
que possam ser reservados.
g) O sistema deverá ser desenvolvido na linguagem de programação Java.
h) O sistema deve exportar dados de uma forma clara e precisa.
i) A reserva de um equipamento deve ser realizada no máximo 24 horas antes
do evento marcado.
j) O sistema deve ter a capacidade de suportar 2500 usuários simultaneamente.
k) O sistema deverá ser finalizado antes do final do ano.

51. Dúvidas
51