Este documento apresenta uma aula sobre levantamento e análise de requisitos, cobrindo tópicos como:
- Definição de requisitos e seus objetivos
- Classificação de requisitos em funcionais, não funcionais, de domínio, do usuário e do sistema
- Exemplos de cada tipo de requisito
2. AULA 2
LEVANTAMENTO E ANÁLISE DE
REQUISITOS – PARTE 1
2
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
3. 3
Agenda
• O que é um requisito?
• Classificação dos requisitos
●
Funcionais
●
Não Funcionais
●
De produto
●
Organizacionais
●
Externos
●
De domínio
●
Do usuário
●
Do sistema
• Vocabulário
• Referências
3
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
4. 4
O que é um requisito?
"Uma condição ou capacidade que um usuário necessita para
resolver um problema ou alcançar um objetivo. Uma condição ou
capacidade que deve ser satisfeita por um sistema para satisfazer um
contrato ou um padrão" IEEE - Institute of Electrical and Electronics
Engineers
"Os requisitos para um sistema de software estabelecem o que o sistema
deve fazer e definem restrições sobre sua operação e implementação."
Sommerville
"Condição necessária para a obtenção de certo objetivo, ou para o
preenchimento de certo fim." Dicionário Aurélio
5. 5
O que é um requisito?
Para que o processo de
desenvolvimento de software
seja bem sucedido é
fundamental que haja uma
compreensão completa dos
requisitos de software.
Tanto o desenvolvedor como o
cliente desempenham um
papel ativo na análise e
especificação dos requisitos.
6. 6
O que é um requisito?
Tentativa de solução do problema
Desenvolvedor Cliente
Indagações
O que?
Tentativa de passar informações do
negócio
Um sistema sob encomenda
Pra que?
Como?
Por que?
Pra automatizar
o agendamento
de consultas e exames
Porque queremos
que o próprio paciente
escolha o melhor
horário, sem necessitar
ocupar nossa secretária
Através de uma
ferramenta online
7. 7
Objetivos dos requisitos
Estabelecer e manter concordância
com os clientes e outros envolvidos
sobre o que o sistema deve fazer;
Oferecer aos desenvolvedores uma
compreensão melhor do sistema a
ser desenvolvido;
Delimitar o sistema;
Planejar o desenvolvimento do
sistema;
Fornecer uma base para estimar o
custo e o tempo de desenvol-
vimento do sistema.
8. 8
Classificação
De acordo com Sommerville (2007), os requisitos são classificados como:
1)Funcionais
2)Não funcionais
3)De domínio
4)Do usuário
5)Do sistema
9. 9
Requisitos Funcionais(RF)
São requisitos que descrevem a funcionalidade (funções
que o sistema deve realizar) ou os serviços que se
espera que o sistema faça.
Exemplos:
cadastro de cliente
emissão de nota fiscal
consulta ao estoque
geração de pedido
emissão de relatório de vendas
lançamento de notas de aluno
12. 12
Requisitos Funcionais(RF)
Cada requisito deixa sua contribuição para a construção de uma parte do
sistema.
Cadastro de aluno Cadastro de avaliação
Cadastro de aluno
na turma
13. 13
Requisitos Funcionais(RF)
Cada requisito deixa sua contribuição para a construção de uma parte do
sistema.
Cadastro de aluno Cadastro de avaliação
Cadastro de aluno
na turma
Cadastro de nota de
uma avaliação do aluno
14. 14
Requisitos Não-Funcionais(RNF)
São requisitos que não dizem respeito diretamente à
funcionalidade do sistema, mas expressam propriedades
do sistema e/ou restrições sobre os serviços ou funções por
ele providas.
Se categorizam em 3 tipos:
Requisitos de produto
Requisitos Organizacionais
Requisitos Externos
15. 15
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:
Requisitos de Facilidade de Uso ou de Usabilidade:
referem-se ao esforço para utilizar ou aprender a utilizar
o produto. Estão relacionados com a interação do usuário
junto ao sistema.
16. 16
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:
Requisitos de Confiabilidade: referem-se à frequência de
ocorrência de falhas e recuperabilidade em caso de falha,
como:
●
tempo médio de falhas
●
probabilidade de indisponibilidade
●
taxa de ocorrência de falhas; tempo de reinício após falha
●
percentual de eventos causando falhas
●
probabilidade de corrupção de dados após falha
17. 17
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:
Requisitos de Eficiência: referem-se ao desempenho do
sistema e estão associados à eficiência, uso de recursos e
tempo de resposta da aplicação, como: transações
processadas/segundo; tempo de resposta do
usuário/evento, entre outros.
18. 18
Requisitos Não-Funcionais(RNF)
Requisitos de produto
São requisitos que especificam o comportamento do
produto, como por exemplo:
Requisitos de Portabilidade: são relativos à capacidade
de transferir o produto para outros ambientes
19. 19
Requisitos Não-Funcionais(RNF)
Requisitos Organizacionais
São requisitos derivados das políticas organizacionais do
cliente e do desenvolvedor, como por exemplo:
Requisitos de Implementação: ligados às regras de
codificação e restrições de software e hardware usados
para desenvolver ou executar o sistema
20. 20
Requisitos Não-Funcionais(RNF)
Requisitos Organizacionais
São requisitos derivados das políticas organizacionais do
cliente e do desenvolvedor, como por exemplo:
Requisitos de Padrões: referem-se à definição da
linguagem de programação e às normas que devem ser
seguidas pelo sistema ou no processo de desenvolvimento.
21. 21
Requisitos Não-Funcionais(RNF)
Requisitos Organizacionais
São requisitos derivados das políticas organizacionais do
cliente e do desenvolvedor, como por exemplo:
Requisitos de entrega: referem-se ao modo como será
implantada a solução como configurações necessárias e
ordem de instalação dos pacotes.
22. 22
Requisitos Não-Funcionais(RNF)
Requisitos Externos
São requisitos procedentes de fatores externos ao sistema e ao seu
processo de desenvolvimento, como por exemplo:
●
Requisitos Éticos
●
Requisitos Legais (como política de privacidade e direitos autorais)
●
Requisitos de Interoperabilidade
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 (legislação de privacidade); em razão das restrições
referentes aos direitos autorais, alguns documentos devem ser excluídos
imediatamente ao serem fornecidos.
24. 24
Requisitos de Domínio
São requisitos derivados do domínio da aplicação do
sistema. Ao invés de serem obtidos a partir das necessidades
específicas dos usuários do sistema, eles podem se
transformar em novos requisitos funcionais, ou serem regras
de negócios específica do domínio do problema. Por
exemplo:
Utilização de uma interface padrão utilizando a norma
Z39.50;
Disponibilização de arquivos somente para leitura devido
aos direitos autorais;
25. 25
Requisitos do Usuário
São os requisitos funcionais e
não funcionais do sistema sob o
ponto de vista do usuário. Em
geral apresentam problemas
como falta de clareza, confusão e
fusão, ou seja, requisitos
diferentes escritos como um
único requisito.
26. 26
Requisitos do Sistema
São descrições mais detalhadas
dos requisitos do usuário. São a
base para que os engenheiros de
software possam fazer o projeto
do sistema. Servem como base
para um contrato destinado à
implementação do sistema.
27. 27
Referência
LEITE, Jair C. Ciclo de vida de Software. 2007.
• Disponível em: http://engenhariadesoftware.blogspot.com/2007/02/ciclo-
de-vida-do-software-parte-1.html
• PINTAUD, Marcelo e OLIVEIRA, Elisamara. Engenharia de Software e
Engenharia de Requisitos. 2014.
• FIGUEIREDO, IRIA LUPPI. 2008.
http://www.oficinadanet.com.br/artigo/738/tipos_de_sistemas_de_informaca
o_na_empresa
27
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
28. 28
Extras
Algumas empresas que trabalham com desenvolvimento de software
no Brasil:
• http://www.totvs.com
• http://www.thoughtworks.com
• http://www.hbsis.com.br
• http://www.ciandt.com/br-pt
• http://www.bhsistemas.com.br
• http://www.lambda3.com.br
29. 29
Vocabulário
Stakeholders (Influenciadores / Envolvidos):
São as partes interessadas no projeto, ou seja,
são pessoas e organizações envolvidas no
projeto ou que possuem interesses que podem
ser afetados pelo projeto, podendo exercer
influência sobre os resultados do projeto.
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
30. 30
Vocabulário
DERS - Documento de Especificação de Requisitos de Software:
De acordo com o IEEE este documento deve ser completo e não
ambíguo, sendo responsável por auxiliar os clientes de software a
descrever com precisão o que eles desejam obter, e desenvolvedores
de software a entender exatamente o que o cliente deseja. Para os
clientes, desenvolvedores e outros indivíduos ligados ao projeto, um
bom DERS deve prover diversos benefícios, tais como:
●
Estabelecer a base de acordo entre os clientes e a empresa fornecedora
sobre o que o software irá fazer;
●
Reduzir o esforço de desenvolvimento;
●
Prover uma base para estimativas de custo e prazos;
●
Prover uma base para validação e verificação do produto;
●
Facilitar a manutenção do produto de software final.
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
31. 31
Praticando
Responda ao questionário:
1. Stakeholder é qualquer pessoa que vá comprar o software em
desenvolvimento.
(a)Verdadeiro
(b)Falso
2) É relativamente comum para diferentes usuários propor requisitos
conflitantes, cada qual argumentando que sua versão é a mais
adequada ou melhor.
(a) Verdadeiro
(b) Falso
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
32. 32
Praticando
Responda ao questionário:
3) Qual a definição de requisitos segundo o IEEE?
4) Defina Requisitos Funcionais e Requisitos Não-Funcionais.
5) Exemplifique requisitos :
●
Funcionais
●
Não funcionais
●
Do usuário
●
Do sistema
●
De domínio
Introdução ao Desenvolvimento de Software
Janynne L. S. Gomes
33. 33
Disciplina: Introdução ao Desenvolvimento de Sistemas
Professora: Janynne L. S. Gomes
Contato: janynne.gomes@outlook.com
www.eteit.univale.br