Engenharia de Software

Natália Chaves Lessa

Aula 9
 Agenda
• Engenharia de Requisitos
– Motivação
– Requisitos de software
– Tipos de requisitos

• Definição da Etapa 2 do Trabalho

2
Motivação

3
 O que é sucesso em software?
• Um projeto bem sucedido é aquele para o
qual se aplicam os seguintes aspectos:
– Cliente/usuário satisfeito
– Auxiliou positivamente na obtenção da meta do
negócio
– Executou o escopo exatamente como previsto e o
software está sendo utilizado como previsto
– Atendeu às especificações técnicas de qualidade e
desempenho
– Atendeu às restrições de prazo e custo
[Ajax, 2011] 4
 Relatório do CAOS (1/2)
• Estudo feito pelo Standish Group em 2015
– 50.000 projetos de software
– Resultados:
[InfoQ, 2015]

• Successful: projetos finalizados com sucesso, ou seja, cobre todas as funcionalidades em tempo e
dentro do custo previsto;
• Challenged: projetos considerados problemáticos, ou seja, não cobre todas as funcionalidades
exigidas, custo aumentado e/ou está atrasado;
• Failed: projetos que fracassam, ou seja, o projeto é cancelado durante o desenvolvimento. 5
 Relatório do CAOS (2/2)
Fatores de Projetos Críticos % Resp.

1. Requisitos Incompletos 13.1%

2. Falta de Envolvimento do Usuário 12.4%

3. Falta de Recursos 10,6%

4. Expectativas Irreais 9,9%

5. Falta de Apoio Executivo 9,3%

6. Mudança de Requisitos e Especificações 8,7%

7. Falta de Planejamento 8,1%

8. Sistema não mais necessário 7,5%

Requisitos estão envolvidos na maioria das causas!

6
 Outros estudos (1/2)
• Segundo o IDC, mais de 80% das falhas em
desenvolvimento de software resultam
diretamente de problemas no levantamento,
na gerência ou na análise dos requisitos

• Segundo o IAG Consulting, mais de 40% do

orçamento de TI será consumido por
especificações pobres de requisitos

[Coelho, 2009] 7
 Outros estudos (2/2)
• Segundo Brooks (1987), a Engenharia de
Requisitos é a parte mais difícil da construção
de um software
– Nenhuma outra parte do desenvolvimento causa
tantos danos se feita de forma errada
– Nenhuma outra parte é tão difícil de ser corrigida

8
 Custo
• O custo relativo para a correção de um
problema de requisitos em cada fase de
desenvolvimento de sistema é:
– $1 na fase de análise de requisitos
– $5 na fase de projeto do sistema
– $10 na fase de codificação
– $20 na fase de teste de unidade
– $200 após a entrega do sistema

9
 Importância do entendimento do
problema
• Einstein afirmou que se ele tivesse 1 hora para
salvar o mundo, ele gastaria ”55 minutos
definindo o problema e apenas 5 minutos
buscando a solução”

• Um problema bem definido (bem entendido)

é um problema 50% resolvido

10
 Por que é tão difícil? (1/2)
• É típica da natureza humana a ansiedade por
buscar a solução rapidamente para algo que lhe
foi demandado
• Não é confortável para analistas e engenheiros
de sistemas navegar em áreas de conhecimento
muitas vezes desconhecidas como os processos
de negócio e conhecimentos da indústria
– Preferem tratar de tabelas, relatórios, funções e
dados...
[Coelho, 2009] 11
 Por que é tão difícil? (2/2)
• Falta de preparação dos profissionais de TI pela
maioria das faculdades e universidades nos
cursos relacionados à áreas
– Não existe foco em termos de ciências humanas ou
psicologia para aprendermos a nos comunicar com
pessoas que não tem conhecimento técnico
• O baixo envolvimento do usuário durante o
projeto

[Coelho, 2009] 12
Importância da comunicação

13
Requisitos de Software

14
 O que é requisito? (1/3)
• Para Pfleeger (2004), um requisito é uma
característica do sistema ou a descrição de algo
que o sistema é capaz de realizar, para atingir
os seus objetivos

• No SWEBOK (2004), um requisito é descrito

como uma propriedade que o software deve
exibir para resolver algum problema no mundo
real
15
 O que é requisito? (2/3)
• Em resumo, é um conjunto de necessidades
do cliente que deverão ser atendidas para
solucionar um determinado problema do
negócio no qual o cliente faz parte

• Problema:
– Nem sempre o cliente sabe o que quer
– Nem sempre a equipe consegue entender o que o
cliente precisa

16
 O que é requisito? (3/3)

• Fundamental para o sucesso do projeto

• Grande impacto sobre o desenvolvimento
• Maior ainda sobre a manutenção
• Pode ocasionar o cancelamento do projeto
• Os requisitos são o grande “vilão” da
Engenharia de Software

17
[Rocha, 2013]
 Por que definir os requisitos?
• Estabelecer uma base de concordância entre o
cliente e outros envolvidos sobre o que o sistema
deve fazer
• Oferecer aos desenvolvedores uma melhor
compreensão do sistema a ser desenvolvido
• Delimitar o sistema
• Planejar o desenvolvimento do sistema
• Fornecer uma referência para a validação do
produto final

18
Tipos de Requisitos

19
Classificação dos requisitos (1/2)

Requisito do
usuário

20
[Ventura, 2013]
Classificação dos requisitos (2/2)

21
[Ventura, 2013]
 Requisitos Funcionais (1/3)
• Diretamente ligados a funcionalidade do
software e descrevem as funções que o software
deve executar

• Exemplos:
– O software deve permitir o cadastro de clientes
– O software deve permitir a geração de relatórios
sobre o desempenho de vendas no semestre
– O software deve permitir o pagamento das compras
através de cartão de crédito
22
[Schots, 2012]
 Requisitos Funcionais (2/3)
• Cada requisito contribui para a construção de uma parte
do sistema

23
[Gomes, 2015]
 Requisitos Funcionais (3/3)
• Funcionalidade x requisito funcional
– Uma funcionalidade pode ser uma tela, uma rotina... de um
sistema
– Uma funcionalidade pode realizar um ou mais requisitos
funcionais
– Exemplo: Uma tela “Manutenção de clientes” equivale a uma
funcionalidade que atende a quantos requisitos funcionais?
• RF01 – Incluir cliente
• RF02 – Alterar cliente
• RF03 – Excluir cliente
• RF04 – Consultar cliente

24
 Requisitos Não-Funcionais (1/5)
• Expressam condições que o software deve
atender ou qualidades específicas que o
software deve ter
– Não dizem respeito diretamente à funcionalidade
– Em vez de informar o que o sistema fará, os requisitos
não funcionais colocam restrições no sistema

• Podem ser categorizados em 3 tipos:

– Requisitos não-funcionais do produto
– Requisitos não-funcionais organizacionais
– Requisitos não-funcionais externos
25
 Requisitos Não-Funcionais (2/5)
• Requisitos não-funcionais do produto
– São os requisitos que especificam o comportamento do
sistema
– São as características de qualidade do software
• Norma ISO/IEC 25000 (antiga ISO/IEC 9126)

26
Exemplos:
-Tempo médio entre falhas
- probabilidade de
indisponibilidade

Exemplos:
-Transações executadas
por segundo
- Tempo de resposta

27
 Requisitos Não-Funcionais (3/5)
• Requisitos não-funcionais do produto
– Exemplos:
• Disponibilidade • Integridade
– DS-1: O sistema deve ficar disponível – IN-1: Transações históricas dos
por 99,5% do tempo nos dias úteis, consumidores só poderão ser vistas
das 6h às 22h, e 99,95% do tempo por usuários com privilégios de
nos dias úteis, das 16h às 18h “auditor”
• Eficiência • Interoperabilidade
– EF-1: Em condições de pico de uso, – IT-1: O sistema deve ser capaz de
deve ter uma reserva de 25% de importar dados tanto do MS Office
capacidade de processamento e (versão 2003 ou maior) quanto do
memória OpenOffice(versão 2.4 ou maior)
– EF-2: O cálculo de interferência deve • Confiabilidade
ser finalizado com sucesso em menos – CF-1: Em cada 1000 execuções, não
de 5 minutos mais do que 2 podem apresentar
falhas de software

28
 Requisitos Não-Funcionais (4/5)
• Requisitos não-funcionais organizacionais
– Derivados das políticas organizacionais do cliente e do
desenvolvedor
• Requisitos de implementação: regras de codificação, e
restrições de software e hardware
• Requisitos de padrões: definição das normas que devem ser
seguidas pelo sistema e no processo de desenvolvimento
• Requisitos de entrega: como será implantada a solução; ex.:
configurações necessárias, ordem de instalação dos pacotes etc.

– Exemplo:
• O software deve ser compatível com os browsers IE (versão 7.0 ou
superior) e Firefox (2.0 ou superior)
29
 Requisitos Não-Funcionais (5/5)
• Requisitos não-funcionais externos
– São fatores externos ao sistema e ao seu processo de
desenvolvimento, éticos e legais (como política de
privacidade e direitos autorais)

– Exemplos:
• O sistema não deverá revelar aos operadores nenhuma informação
pessoal sobre os clientes, além de seus nomes e o número de
referência
• O sistema deve excluir os documentos imediatamente ao serem
fornecidos (devido aos direitos autorais)

30
 Requisitos de Negócio (1/3)
• Também denominados requisitos de domínio ou
regras de negócio
• Derivados do domínio da aplicação
• Descrevem premissas ou restrições de negócio
que o sistema deverá atender
– Norma, condição ou padrão para execução das
funcionalidades
• Podem ou não estar associadas a um requisito
funcional, mas que sempre serão realizadas por
uma ou mais funcionalidades do sistema
31
 Requisitos de Negócio (2/3)
• Requisitos de negócio x Requisitos funcionais
– Requisitos funcionais definem quais são as
necessidades/exigências da empresa em termos
funcionais (que funcionarão através de um
sistema)
• O QUE o sistema deverá fazer
– Requisitos de negócio definem como o sistema
fará o atendimento às necessidades/exigências
definidas
• COMO um requisito funcional se realizará
[Ventura, 2013]
32
 Requisitos de Negócio (3/3)

• Exemplos:
– O cálculo da média final de cada aluno é dado pela
fórmula: (Nota1 * 2 + Nota2 * 3)/5
– Um aluno pode se matricular em uma disciplina desde
que tenha sido aprovado nas disciplinas consideradas
pré-requisitos

[Schots, 2012] 33
 Exercício (1/4)
• Em grupos, para o sistema descrito a seguir
(Compras NET) definir:
– Requisitos funcionais
– Requisitos não-funcionais
– Requisitos/regras de negócio

[Ajax, 2011]
 Exercício (2/4)
• Minimundo:
– O cliente navega pelo site e adiciona itens desejados ao
carrinho de compras. Se não encontrar o produto
desejado, pode usar a opção de busca
– Durante sua navegação no site, o cliente pode ver o
conteúdo de seu carrinho de compras, alterando
quantidades ou excluindo itens
– Quando o cliente finalizar a compra, ele deve se
identificar com seu login/senha. Caso não seja ainda
cadastrado, deverá fazê-lo antes de prosseguir.
[Ajax, 2011]
 Exercício (3/4)
• Minimundo (cont.):
– Em seguida, o cliente informa o endereço de entrega
daquela compra e detalha a opção de pagamentos
(dados do cartão de crédito ou para pagamento por
boleto bancário).
– Confirmada a compra, o sistema fecha a venda e envia
um e-mail informando ao cliente o status da compra
(aguardando confirmação do cartão de credito ou do
pagamento do boleto).

[Ajax, 2011]
Exercício (4/4)

[Ajax, 2011]
 Possíveis respostas (1/5)
• Requisitos Funcionais
– Sub-Processo “Selecionar Produto”
• RF1 – O sistema deve buscar produto
• RF2 – O sistema deve adicionar produto (itens do
carrinho)
• RF3 – O sistema deve visualizar produtos (itens do
carrinho) (RN1) (RN2)
• RF4 – O sistema deve excluir produto (itens do
carrinho)
• RF5 – O sistema deve alterar quantidade produto (itens
do carrinho)
• RF6 – O sistema deve finalizar pedido (fechar carrinho)
[Ajax, 2011]
 Possíveis respostas (2/5)
• Requisitos Funcionais (cont.)
– Sub-Processo “Realizar Compra”
• RF7 – O sistema deve identificar cliente
• RF8 – O sistema deve cadastrar cliente (RN 3, RN 4)
• RF9 – O sistema deve cadastrar endereço de entrega
(RN 5)
• RF10 – O sistema deve permitir ao cliente selecionar
opção de pagamento (RN 6)
• RF11 – O sistema deve confirmar a compra
• RF12 – O sistema deve enviar e-mail de status

[Ajax, 2011]
 Possíveis respostas (3/5)
• Regras de negócio
– RN 1: Ao listar os produtos no carrinho de compras, deve-
se apresentar uma miniatura da imagem de cada produto
(RF 3)
– RN 2: A listagem de produtos no carrinho de compras deve
ser limitada a 5 produtos por página (RF 3)
– RN 3: Todos os campos do cadastro do cliente são de
preenchimento obrigatório (RF 8)
– RN 4: A senha do cliente deve possuir, no mínimo, 6
caracteres (RF 8)
– RN 5: O frete deve ser calculado a partir do endereço de
entrega informado pelo cliente (RF 9)
– RN 6: Possíveis formas de pagamento: cartão de crédito ou
boleto bancário
 Possíveis respostas (4/5)
• Requisitos não-funcionais
1. Confiabilidade
• O sistema deve garantir que a atualização de dados será feita
de forma atômica e imediata, sempre com registro histórico
• O sistema deve realizar backups diariamente após a 00:00 hrs

2. Eficiência
• O sistema deve responder a qualquer pesquisa, inclusão,
alteração e exclusão em tempo inferior a 3 (três) segundos
• O sistema deve garantir que as atualizações dinâmicas de
informação única não devem exceder 1 (um) segundo
[Ajax, 2011]
 Possíveis respostas (5/5)
• Requisitos não-funcionais (cont.)
3. Portabilidade
• O sistema deve ser compatível com os navegadores Google
Chrome v.69 e Internet Explorer v.11

4. Usabilidade
• O sistema deve focar em eficiência, fornecendo teclas de
atalho para todas as ações mais importantes
• O sistema deve seguir as diretrizes do Design Material do
Google
 Exercício para casa
• Considere o extrato fornecido de uma ata de
reunião sobre o desenvolvimento de um sistema
de informação para uma locadora de automóveis
– Disponibilizado no SIGAA: “Minimundo Locadora
Automóveis”

• Identifique e descreva os requisitos funcionais,

regras de negócio e requisitos não-funcionais.
– Entrega pelo SIGAA, no recurso “Exercício da aula 9
(requisitos)”, até às 10h do dia 11/out (4ª f)
43
Trabalho – Etapa 2

44
 Identificação dos requisitos
• Escolham a(s) técnica(s) de elicitação de
requisitos que será(ão) utilizada(s) de acordo
com o contexto e tipo de sistema (mesmo da
etapa anterior) e justifiquem seu uso
• Os requisitos devem ser derivados a partir de
pesquisas realizadas pelo grupo sobre o tipo de
sistema, e a partir do contato com o cliente
– Eu assumirei o papel de cliente. Portanto, cada
grupo deve entrar em contato comigo, se necessário,
de acordo com a técnica de elicitação escolhida
45
 Documento de requisitos
• Os requisitos devem ser documentados de
acordo com o template disponibilizado no
SIGAA
• O documento de requisitos deve conter, pelo
menos:
– 5 requisitos funcionais
– 2 requisitos (ou regras) de negócio
– 2 requisitos não-funcionais
• Fiquem atentos às recomendações de escrita,
conforme apresentado nas aulas passadas 46
 Entregáveis
• Documentos a serem entregues:
– Documento de requisitos
– Se for pertinente, questões da entrevista,
questionários etc.

• Prazo: enviar documentos em PDF no SIGAA até

às 10h do dia 25/out (4ªf)

47
 Apresentação (1/2)
• Na aula do dia 25/out (4ª f)
– Slides devem ser enviados no SIGAA, em PDF, até
às 10h

• Cada grupo deverá apresentar em 20min

– Depois haverá 5min para comentários e perguntas

48
 Apresentação (2/2)
• A ordem das apresentações dos grupos foi
definida a partir de sorteio

Etapa - Data Ordem de apresentação

Etapa 2 – 25/out 1) Grupo 2
2) Grupo 4
3) Grupo 5
4) Grupo 1

49
Bom Trabalho!
 Referências
– Pressman, R.S., Engenharia de Software, 6ª edição, Ed. McGraw-Hill, 2006
– Sommerville I., Engenharia de software, 9ª edição, São Paulo: Pearson Prentice Hall 2011
– Koscianski, A; Soares, M. S., Qualidade de Software, Novatec Editora
– Slides da Profa. Ana Regina Rocha, “Gerência de Requisitos”
– Slides do Prof. Ricardo Ajax, “Engenharia de Requisitos”
– Slides do Prof. Marcelo Schots, “Engenharia de Requisitos de Software”
– Coelho, M., 2009, “Precisamos ser mais psicólogos que engenheiros para ter sucesso com
engenharia de software”, disponível em:
[Link]
– DevMedia, Técnicas para levantamento de Requisitos, disponível
em: [Link]
requisitos/
– Pohl, K., Rupp, C., 2012, Fundamentos da Engenharia de Requisitos – Um Guia de Estudo para o
Exame Certified Professional for Requirements Engineering-Foundation Level, IREB
– Ventura, P., 2013, “O que é Requisito Funcional”, disponível em:
[Link]
– Santos, R., 2010, “Escrevendo Estórias do Usuário Eficazes”, disponível em:
[Link]
– Gomes, J. L. S., 2015, “Definição e classificação dos requisitos”, disponível em:
[Link]
– Roberti, W., 2014, “Requisitos”, disponível em: [Link] 51
requisitos