Engenharia de Software - Analise de Requisitos

Prévia do material em texto

Conclusões sobre 
Especificação de Requisitos
• O Documento de Especificação de Requisitos é uma
declaração acordada dos requisitos do sistema. Deve ser
usado tanto pelos clientes do sistema e os
desenvolvedores do software
• O processo de engenharia de requisitos inclui estudo de
viabilidade, elicitação e análise de requisitos, especificação
de requisitos, validação e gerenciamento de requisitos
Conclusões sobre 
Especificação de Requisitos
• O Documento de Especificação de Requisitos é uma
declaração acordada dos requisitos do sistema. Deve ser
usado tanto pelos clientes do sistema e os
desenvolvedores do software
• O processo de engenharia de requisitos inclui estudo de
viabilidade, elicitação e análise de requisitos, especificação
de requisitos, validação e gerenciamento de requisitos
AULA DE HOJE
Processo de Engenharia de Requisitos
JÁ FIZEMOS
VAMOS APRENDER 
A FAZER
Recapitulando...
Elicitação e Análise de Requisitos
• Categorizar e organizar os requisitos coletados em 
subconjuntos
• Relacionar os requisitos coletados
• Priorizar os requisitos coletados segundo a necessidade • Priorizar os requisitos coletados segundo a necessidade 
dos clientes / usuários
• Construir Construir modelos modelos que explicitem o entendimento 
colaborativo do sistema sob os diferentes pontos de vista 
envolvidos (clientes, usuários finais, arquitetos de sistema, 
etc.)
Modelo de Requisitos ou Modelos de 
Análise
Descrição do Descrição do 
Sistema Modelo de 
Análise
Modelo de 
Projeto
Fonte: [Pressman, 2011]
Modelos de Requisitos ou 
Modelos de Análise
• É a primeira representação técnica de um 
sistema
• A modelagem de requisitos usa combinação das 
formas textual e diagramática para representar os 
requisitos de maneira relativamente fácil de 
entender
Regras práticas para Análise
• Certifique-se de que os modelos gerados agregam valor a 
todos os interessados
• Cada participante tem um uso próprio para o modelo
• Interessados no negócio usam o modelo para validar os requisitos
• Projetistas usam o modelo como base para o projeto
• Pessoal de qualidade deve usar o modelo para ajudar no 
planejamento de testes
• Utilize uma linguagem de notação padrão, por exemplo: UML
UML – Unified Modeling Language
• Linguagem para elaboração da estrutura de projetos de 
software
• É uma linguagem bastante expressiva abrangendo todas 
visões necessárias ao desenvolvimento e implementação 
de sistemas de informação
• É de fácil entendimento e uso
• É apenas uma linguagem, portanto é independente do 
processo de desenvolvimento e pode ser utilizada em 
processos orientado a casos de uso, centrado na 
arquitetura, interativo, incremental, etc
Elementos do Modelo de Análise
Modelos de classes
(ex: diagramas de 
classes, diagramas de 
colaboração)
Modelos baseados 
em cenários
(ex: casos de uso, 
diagramas de 
atividades e de raias)
Requisitos
de software
Modelos 
comportamentais
(ex: diagramas de 
estado, diagramas de 
sequência)
Modelos de fluxos
(ex: DFDs, modelos 
de dados)
Elementos do Modelo de Análise
• Cada elemento do modelo de requisitos, ou modelo de análise, 
apresenta o problema segundo um ponto de vista
• Elementos baseados em cenários representam como o usuário interage 
com o sistema e a sequência das atividades
• Elementos baseados em classes modelam os objetos que o sistema irá • Elementos baseados em classes modelam os objetos que o sistema irá 
manipular, operações aplicadas aos objetos, relacionamento entre os 
objetos e colaborações entre as classes definidas
• Elementos comportamentais representam como eventos externos 
mudam o estado do sistema ou das classes do sistema
• Elementos orientados a fluxos representam o sistema como uma 
transformação de informações, indica como os objetos de dados são 
transformados pelas funções do sistema 
Elementos do Modelo de Análise
• Cada elemento do modelo de requisitos, ou modelo de análise, 
apresenta o problema segundo um ponto de vista
• Elementos baseados em cenários representam como o usuário interage 
com o sistema e a sequência das atividades
• Elementos baseados em classes modelam os objetos que o sistema irá 
AULA 
DE HOJE
• Elementos baseados em classes modelam os objetos que o sistema irá 
manipular, operações aplicadas aos objetos, relacionamento entre os 
objetos e colaborações entre as classes definidas
• Elementos comportamentais representam como eventos externos 
mudam o estado do sistema ou das classes do sistema
• Elementos orientados a fluxos representam o sistema como uma 
transformação de informações, indica como os objetos de dados são 
transformados pelas funções do sistema 
DE HOJE
Casos 
de Uso
Modelagem Baseada em Cenários
• A satisfação do usuário é o melhor indício de um sistema 
bem sucedido 
• Se você entender como os usuários finais (e outros 
atores) querem interagir com um sistema, a equipe de atores) querem interagir com um sistema, a equipe de 
software estará mais capacitada a produzir um software 
que condiz com a expectativa dos Stakeholders
• Para tanto, a modelagem de requisitos com UMLUML pode pode 
começar com a criação de cenários na forma de casos de 
uso, diagramas de atividades e diagramas de raias
• Caso de uso é um “contrato de comportamento” 
• Define a maneira que o ator vai utilizar o sistema para 
realizar uma tarefa
Modelos de Casos de Uso
realizar uma tarefa
• O caso de uso descreve um cenário de uso específico 
em uma linguagem simples sob o ponto de vista de um 
ator definido
• Como começar? 
• Enumere as funções realizadas por um ator (com 
base nos requisitos funcionais especificados)
Modelos de Casos de Uso
base nos requisitos funcionais especificados)
• Desenvolva o diagrama de casos de uso com os 
atores e funções identificados 
• Descreva o caso de uso detalhado para cada uma 
dessas funções
• Todo caso de uso deve ter um nome que o diferencie dos 
demais – normalmente descrito com verbo
• Ex: Incluir cliente, Imprimir relatório, Validar usuário...
Boas práticas para Casos de Uso
•
• O ator de caso de uso representa um papel que um ser 
humano, um dispositivo de hardware ou um sistema
desempenha com a função descrita no caso de uso
• Ex: Usuário, Administrador, Gerente de vendas, Instituição 
financeira, Rede de celular, etc
Notação de Casos de Uso
Diagrama de Casos de Uso
• Composição 
• Assunto
• Casos de uso
• Atores
 uc Use Case Model
Funcionário
Incluir 
funcionário
Editar dados de 
um funcionário
• Relacionamentos 
• Dependência
• Generalização
• Associação
Relatórios
Administrador
Excluir 
funcionário
Imprimir relatório de 
funcionários ativos
Diagrama de Casos de Uso
CRUD
• É o agrupamento dos casos de uso do tipo 
• Create – Criar (incluir)
• Retrieve – Recuperar (pesquisar)
• Update – Atualizar (editar) 
• Delete – Excluir • Delete – Excluir 
• Vantagem: agrupa casos de uso que podem triplicar o 
número de casos de uso para rastrear 
• Desvantagem: Cada um pode ser realizado por pessoas 
diferentes, com diferentes níveis de permissões
Diagrama de Casos de Uso
CRUD
 uc nivel detalhe 1
Funcionário
Gerente de RH
CRUD Gerenciar 
funcionário
Diagrama de Casos de Uso
Relacionamentos
• Os casos de uso podem ser organizados pela 
especificação de relacionamentos de generalização, 
inclusão e extensão existentes entre eles
• Include: um relacionamento include de um UC A para um • Include: um relacionamento include de um UC A para um 
UC B indica que B é essencial para o comportamento de A
• Extend: um relacionamento extend de um UC A para um UC B 
indica que o UC A pode ser acrescentado para descrever o 
comportamento de B (não é essencial)• Generalização ou Especialização (é_um): Pode ser 
entre casos de uso ou entre atores. Nesse caso “filho” herda 
todas as características de seu “pai”
Vamos praticar?
Sistema de gerenciamento de funcionários e folha de pagamento:
[RF1] O sistema deve permitir que o funcionário, o administrador do sistema e o gerente de 
RH façam login no sistema.
[RF2] O sistema deve permitir que o administrador inclua, edite, exclua e pesquise contas de 
usuários. 
[RF3] O sistema deve permitir que o gerente de RH imprima relatório de funcionários ativos
[RF4] O sistema deve permitir que o gerente de RH inclua novos funcionários. Sempre que 
for incluir um novo funcionário, é necessário pesquisar se o funcionário ainda não existe, 
para que não ocorra duplicação de cadastro. Toda vez que um funcionário for incluído, é 
necessário que a folha de pagamento seja atualizada com o novo funcionário. 
[RF5] O sistema deve permitir que o gerente de RH edite os dados de um funcionário. Para 
editar os dados de um funcionário, é necessário pesquisar na base de dados para encontrar 
o funcionário. Quando os dados de um funcionário, referentes a salário e cargo, forem 
atualizados, também é necessário que a folha de pagamento deste funcionário seja 
atualizada com os novos dados. 
[RF6] O sistema deve permitir que o gerente de RH exclua funcionários. Para excluir um 
funcionário, é necessário pesquisar na base de dados para encontrar o funcionário. 
[RF7] O sistema deve permitir que o gerente de RH realize as funcionalidades referentes a 
folha de pagamento, como efetuar pagamento de funcionário e atualizar folha de 
pagamento. 
 uc detalhes 2
Controle de Acesso
Relatório
Funcionário
Imprimir relatório de 
funcionários ativos
Excluir 
funcionário
Editar dados de 
um funcionário
Incluir 
funcionário
Gerente de RH
Pesquisar 
funcionário
Usuário
Efetuar login 
no sistema
«include»
Dependência
Usuário Folha de Pagamento
Gerente de RH
Administrador
Efetuar 
pagamento de 
funcionário
Atualizar folha de 
pagamento
CRUD Contas de 
Usuário
«extend» Associação
Vamos praticar?
–Fazer o Diagrama de Casos de Uso do 
sistema do trabalho em Grupo 
–Quinta-feira, dia 09/10 – aula prática –Quinta-feira, dia 09/10 – aula prática 
em sala para fazermos o diagrama de 
casos de uso dos sistemas
–Entregar o diagrama em PDF no 
Moodle até dia 10/10/2014 (sexta-
feira)
AVISO
–Alteração da data da próxima prova
–Do dia 23/10/14 para dia 30/10/14
–Conteúdo: tudo até projeto de interface –Conteúdo: tudo até projeto de interface 
Leitura Recomendada
– Capítulo 6 do livro texto: Pressman, Roger. 
Engenharia de Software, 7ed. McGrawHill, 
Porto Alegre, RS, 2011.
– Capítulo 5 do livro texto: Sommerville, Ian. – Capítulo 5 do livro texto: Sommerville, Ian. 
Engenharia de Software, 9ed. Prentice Hall, 
São Paulo, SP, 2011.
– Livro Booch, Grady, et al. UML Guia do 
Usuário, 2ed. Editora Campus, Rio de Janeiro, 
RJ, 2005.