O documento aborda os requisitos de software, definindo requisitos do usuário e do sistema, e delineando características de um bom requisito, como ser necessário, verificável e conciso. Ele distingue entre requisitos funcionais, que definem o que o sistema deve fazer, e não funcionais, que especificam como esses requisitos devem ser atendidos. Além disso, destaca a importância de organizar e priorizar requisitos para o desenvolvimento eficiente de sistemas.

1. Requisitos
Profª.: Rosanete Grassiani dos Santos
rosaneteg@gmail.com

2. Breve revisão dos requisitos

3. O que são requisitos?
 Uma sentença identificando uma capacidade, uma
característica física ou um fator de qualidade que limita
um produto ou um processo (IEEE 1220-1994).

4. Requisitos do usuário
 É algum comportamento ou característica que o usuário deseja do
software ou o sistema como um todo.
 O que o usuário quer.
 São escritos pelo próprio usuário ou levantados por um analista de sistemas
que consulta o usuário.

5. Requisitos do sistema
 É algum comportamento ou característica exigido do sistema como um
todo, incluindo hardware e software.
 O comportamento desejado do sistema.
 São normalmente levantados por engenheiros ou analistas de sistemas,
refinando os requisitos dos usuários e os transformando em termos de
engenharia.

6. Características de um bom requisito
 Necessário: Se retirado, ele não atenderá plenamente as expectativas do
usuário.
 Não devem existir requisitos do tipo “seria interessante ter”.
 Deve ser levado em conta que cada requisito aumenta a complexidade e o
custo do projeto.
 Não-ambíguo: Possui uma e apenas uma interpretação.
 Verificável: Não ser vago ou geral e sendo quantificado de uma maneira
que permita a verificação de uma das seguintes formas: inspeção, análise,
demonstração ou teste.

7. Características de um bom requisito
 Conciso: Cada requisito define apenas um requisito que deve ser feito e
apenas o que deve ser feito, de maneira clara e simples.
 Não inclui explicações, motivações, definições ou descrições do seu uso.
 Alcançável: Realizável a um custo definido por uma ou mais partes do
sistema.
 Consistente: Não contradiz ou duplica outro requisito.
 Ordenável: Por estabilidade e/ou importância.
 Aceito: Pelos usuários e desenvolvedores.

8. Características de um bom requisito
 Requisito for funcional, deverá ser também Independente da
Implementação.
 O requisito define o que deve ser feito, mas não como!

9. Como fazer os requisitos?
 Devemos chegar ao problema:
 É necessário que todos concordem com a definição do problema.
 Entender as causas do problema:
 O problema por trás do problema pode ser mais importante, sendo que o problema
visto inicialmente é apenas um sintoma.
 Identificar todos os stakeholders e usuários.
 Definir a fronteira do sistema de solução.
 Identificar as restrições impostas à solução.

10. Requisitos funcionais e de informação
 Requisito funcional:
 Representa algo que o sistema deve fazer, ou seja, uma função esperada do
sistema que agregue algum valor a seus usuários.
 Requisito informação:
 Representa a informação que o cliente deseja obter do sistema.
 São as respostas fundamentais do sistema.

11. Requisitos não funcionais
 São a forma como os requisitos funcionais devem ser alcançados.
 Eles definem propriedades e restrições do sistema.
 Muitos requisitos não funcionais são também requisitos de qualidade,
como exigências de desempenho e robustez.
 Outros são restrições ou exigências de uso de tecnologia.

12. Requisitos não funcionais

13. Exemplo de Requisitos
 Em um sistema médico:
 O sistema deverá permitir que um paciente marque uma consulta.
 O sistema deverá confirmar que a consulta foi aceita pelo paciente.
 Em um sistema para condomínios:
 O sistema deverá permitir que um condômino solicite a segunda via de sua
conta condominial.
 O sistema deverá permitir um aviso ao condômino que não pagar sua no prazo
correto.
 Em um sistema para controle de produtos:
 O sistema deverá permitir que um fornecedor cadastre um produto no
catálogo.
 O sistema deverá informar ao sistema de estoques que um produto foi vendido

14. Dicas para formular os requisitos
 Use sentenças e parágrafos curtos.
 Use a voz ativa.
 Use verbos no futuro.
 Use os termos de forma consistente e mantenha um glossário.

15. Dicas para formular os requisitos
 Para cada requisito, avalie se a partir de sua definição é possível
determinar se ele está pronto ou não.
 Garanta que todos os requisitos são verificáveis imaginando (e
possivelmente documentando) uma forma de fazê-lo.
 Verifique requisitos agregados e divida-os.
 Mantenha um nível de detalhe único em todos os requisitos.

16. Requisitos suplementares

17. O que são requisitos suplementares?
 São requisitos não funcionais.
 Os requisitos suplementares são todo tipo de restrição tecnológica ou
lógica que se aplica ao sistema como um todo e não apenas a funções
individuais.
 Exemplo:
 Errado
 O sistema deve ser fácil de usar.
 Certo
 O sistema terá ajuda on-line em todas as telas e para todas as funções.

18. Requisitos Suplementares
18
Nome
Restrição
S1 Tipo de Interface
As interfaces do sistema devem ser
Interface
implementadas como formulários acessíveis em
um browser html.
A camada de persistência deve ser implementada Persistência
de forma que diferentes tecnologias de bancos de
dados possam vir a ser utilizadas no futuro
( )
( )
( )
(x)
S3 Perfis de usuário
Os perfis de usuário para acesso ao sistema são:
3. Administrador - pode efetuar todas as
operações.
2. Operador - pode efetuar as operações de
empréstimo, devolução, pagamento e
cadastramento.
1. Convidado - pode efetuar apenas consultas
nos próprios dados (cliente).
Segurança
( )
( )
...
...
...
...
...
S2 Armazenamento de
dados
Profª.: Rosanete Grassiani dos Santos
Categoria
Desejável
Permanente
18/10/2013

19. 19
Documento de Requisitos
Sistema Livir
Documento de Requisitos
Requisitos funcionais
1. Registrar novos títulos a partir do catálogo das editoras.
2. Registrar vendas de livros.
3. Realizar encomendas de livros.
4. Registrar e autorizar pagamentos com cartão de crédito.
5. Registrar e aplicar promoções.
6. Calcular custos de entrega.
7. Emitir relatório de livros mais vendidos.
8. Emitir relatório de compradores mais assíduos.
9. Emitir sugestões de compra para compradores baseadas em
compras anteriores.
Requisitos suplementares
1. O sistema deve operar via interface Web
2. Todos os controles de interface devem ter um campo de ajuda
associado.
Profª.: Rosanete Grassiani dos Santos
18/10/2013

20. 20
Documento de Requisitos
Alternativa 2
Profª.: Rosanete Grassiani dos Santos
18/10/2013

21. Desafios da Análise de Requisitos
21
 Como descobrir os requisitos.
 Como comunicar os requisitos para as outras fases ou equipes do projeto.
 Como lembrar dos requisitos durante o desenvolvimento e verificar se
foram todos atendidos.
 Como gerenciar a mudança.
Profª.: Rosanete Grassiani dos Santos
18/10/2013

22. 22
Organização dos Requisitos
 Casos de Uso
 Os principais processos
 “Manutenção” de Conceitos
 Implementação das operações de cadastro
 Consultas/Relatórios
 Acesso à informação que não altera a informação em si
Profª.: Rosanete Grassiani dos Santos
18/10/2013

23. 23
Organizando Requisitos em Casos de
Uso
 O objetivo de listar os casos de uso é levantar
informações sobre como o sistema interage
com possíveis usuários e quais consultas e
transformações são necessárias além daquelas
já identificadas na fase de levantamento de
requisitos.
Nome
Realizar
venda de
livros
Realizar
encomenda
de livros
Registrar e
aplicar
promoções
Atores
Cliente
Gerente
Gerente
Descrição
O cliente se identifica e identifica os livros que deseja
levar efetuando ao final o pagamento com cartão de
crédito.
O gerente autoriza a encomenda de livros faltantes e
lançamentos as editoras.
Referências Cruzadas
F1, F3, F5, F9, F10
O Gerente configura as promoções válidas em
determinado período.
F11, F12
Profª.: Rosanete Grassiani dos Santos
F2, F4, F6, F7, F8
18/10/2013

24. 24
Organizando Requisitos em Casos de
Uso
 Para descobrir os casos de uso, devem-se
identificar os atores envolvidos com o sistema.
Para tanto, o analista deve responder algumas
perguntas:
 Quem usa o sistema?
 Quem mantém e configura o sistema?
 Quais os outros sistemas de informação utilizam ou são
utilizados pelo sistema?
 Quem busca informações no sistema?
 Quem provê informações para o sistema?
Profª.: Rosanete Grassiani dos Santos
18/10/2013

25. 25
Diagrama de Casos de Uso UML
Profª.: Rosanete Grassiani dos Santos
18/10/2013

26. 26
Diagrama de Casos de Uso UML
Profª.: Rosanete Grassiani dos Santos
18/10/2013

27. 27
Diagrama de Casos de Uso UML
Profª.: Rosanete Grassiani dos Santos
18/10/2013

28. Granularidade de um Caso de Uso
28
 Um caso de uso deve ser monossessão, ou seja, executado em uma única
interação e não se estendendo ao longo de vários dias .
 Um caso de uso deve ser interativo, com informações fluindo para dentro
e para fora do sistema .
 Um caso de uso deve produzir uma alteração consistente na informação
armazenada.
Profª.: Rosanete Grassiani dos Santos
18/10/2013

29. 29
Organização de Requisitos em
Função de Conceitos
 Algumas
operações
relativamente
simples
e
elementares (de um único passo), como o registro de
uma fita, ou de um pagamento, não devem ser
consideradas como casos de uso por si só, pois não há
necessidade de se estudar seu processo interativo, que
é de um único passo.
Profª.: Rosanete Grassiani dos Santos
18/10/2013

30. 30
Organização de Requisitos em
Função de Conceitos
 Sugere-se a criação de um modelo conceitual preliminar para facilitar esta
tarefa.
 Indicar apenas os conceitos e associações que constituem informação a
ser armazenada pelo sistema.
Profª.: Rosanete Grassiani dos Santos
18/10/2013

31. 31
Como Encontrar Conceitos e Atributos
 Verificar o texto dos casos de uso expandidos.
 Selecionar termos que representam informação transmitida do e para o
sistema.
 Agrupar sinônimos
Profª.: Rosanete Grassiani dos Santos
18/10/2013

32. 32
Cada conceito normalmente tem
associadas operações de:
 inserção (I)
 alteração (A)
 exclusão (E)
 consulta (C)
 Também podem ser identificadas restrições ou regras de validação para
execução das operações
Profª.: Rosanete Grassiani dos Santos
18/10/2013

33. 33
Tabela para Representar Operações
de “Manutenção”
Conceito
Cliente
Reserva
Livro
Vendas
I
x
x
x
A
x
x
x
E
x
x
x
x
C
x
x
x
x
Profª.: Rosanete Grassiani dos Santos
Observação
Só é possível excluir se não houver vendas associadas
Ref. Cruzadas
F13
F15, F16
Só é possível excluir se não houver vendas associadas
F18
A inclusão das vendas só pode acontecer através do caso de F17, F19
uso “Registrar venda de livros”.
Não é possível alterar uma vendas, apenas excluir.
18/10/2013

34. 34
Modelo Conceitual Preliminar
Profª.: Rosanete Grassiani dos Santos
18/10/2013

35. 35
Modelo Conceitual Preliminar
Profª.: Rosanete Grassiani dos Santos
18/10/2013

36. 36
Organização de Requisitos em
Consultas
 A identificação das consultas/ relatórios desejados na fase de concepção
pode ajudar muito no levantamento dos requisitos e na elaboração do
sistema.
 Não precisam ser tratados como casos de uso.
 São listados para auxiliar a construção das etapas posteriores.
Profª.: Rosanete Grassiani dos Santos
18/10/2013

37. 37
Organização de Requisitos em
Consultas
Nome
Vendas Mensais
Clientes Suspensos
...
Profª.: Rosanete Grassiani dos Santos
Referências Cruzadas
F20, F21, F22
F13, F23, F1
...
18/10/2013

38. Planejamento do Desenvolvimento
38
 Alocar o desenvolvimento em ciclos iterativos de mesma duração.
 Estimativa de Esforço:
 Pontos de Função
 Pontos de Caso de Uso
Profª.: Rosanete Grassiani dos Santos
18/10/2013

39. 39
Estabelecendo Prioridades
 Casos de Uso Críticos
 Casos de Uso de Apoio
 Conceitos
 Consultas
Profª.: Rosanete Grassiani dos Santos
18/10/2013

40. Planejamento dos Ciclos Iterativos
40
Ciclo
1
2
3
4
Casos de
Uso
Vender Livros
(550)
Manutenção de
Informações
-
Consultas
Observações
-
Encomenda
Livros (300)
Reservar
Livros (270)
-
-
-
Livro (100), Cliente
(100) e Reserva (100)
Venda (100)
-
Neste ciclo ainda não será
implantado o mecanismo de
persistência
Implementar mecanismo de
persistência (300 horas)
-
todas (400)
-
Profª.: Rosanete Grassiani dos Santos
Esforço
estimado
550 horas
600 horas
570 horas
500 horas
18/10/2013

41. 41
Cronograma de Execução
 Considerar:
 Tempo total estimado para o projeto (em hora/pessoa).
 Tempo disponível (em semanas ou meses).
 Tamanho da equipe.
 Estruturação da equipe.
Profª.: Rosanete Grassiani dos Santos
18/10/2013

42. 42
Planejamento com 4 equipes
Dias:
1-10
11-20
Ciclo 1
análise projeto
Ciclo 2
análise
Ciclo 3
Ciclo 4
Implantação
21-30
implementação
projeto
análise
Profª.: Rosanete Grassiani dos Santos
31-40
testes
implementação
projeto
análise
41-50
51-60
61-70 70-90
testes
implementação testes
projeto
implementação testes
implantação
18/10/2013

43. 43
Planejamento com 2 equipes
Dias:
Ciclo 1
Ciclo 2
Ciclo 3
Ciclo 4
Implantação
1-20
análise
21-40
projeto
41-60
impl.
análise
Profª.: Rosanete Grassiani dos Santos
61-80
testes
projeto
81-100
101-120
impl.
análise
testes
projeto
121-140
141-160
161-180
181-200
impl.
análise
testes
projeto
impl.
201-220
testes
implant.
18/10/2013

44. Dúvidas?

45. Atividade
 Fazer uma pesquisa sobre diagrama de classes.
 O que é?
 Como funciona?
 Fazer um exemplo.
 Entregar em documento word ou escrito a mão.
 Para o diagrama de classe deste trabalho não deverá ser utilizada ferramenta
de diagramação.
 Entrega no e-mail: rosaneteg@gmail.com até 25/10/2013. Não serão aceitos
trabalhos após esta data!

46. Requisitos
Profª.: Rosanete Grassiani dos Santos
rosaneteg@gmail.com