ES Aula03

(1)

Engenharia de

Requisitos

C L E Y TO N R O D R I G U ES , P H D C A N D I D AT E U P E – C A M P U S G A R A N H U N S A U L A 0 3 sites.google.com/site/upeguslces cleyton.rodrigues@upe.br

(2)

“... Um Cliente entra no seu escritório, senta-se,

olha você direto nos olhos e diz: “Eu sei que você

pensa que entende o que eu disse, mas o que você

não entende é que, o que eu disse, não é o que eu

queria dizer”...”

Pressman, R.

(3)

Agenda

Engenharia de Requisitos;

Modelo de Documento de Elicitação de Requisitos; Diagramas UML – Casos de Uso.

(4)

CLEYTON RODRIGUES, M.SC

Requisitos do sistema

Definem o que é solicitado (escopo do produto) ao sistema fazer e

com quais limitações ele é requisitado a operar;

Exemplos:

◦ O sistema deve manter registro de todos os materiais da biblioteca incluindo livros, séries, jornais e revistas, fitas de vídeo e áudio, relatórios, coleções de transparências, discos de computadores e CD-ROMs;

◦ O sistema deve permitir os usuários pesquisarem um item através do título, autor ou ISBN;

◦ A interface de usuário do sistema deve ser implementada usando um browser de WWW (World-Wide-Web);

◦ O sistema deve suportar pelo menos 20 transações por segundo;

◦ As facilidades do sistema que estão disponíveis para o público devem ser demonstradas em 10 minutos ou menos.

(5)

Tipos de requisitos

De modo geral:

◦ Requisitos Funcionais que definem parte da funcionalidade do sistema;

◦ Requisitos Não Funcionais

◦ Requisitos de Produtos que dizem respeito a restrições, aspectos de desempenho, interfaces com o usuário, confiabilidade, segurança, manutenabilidade, portabilidade;

◦ Requisitos Organizacionais que dizem respeito às metas da empresa, suas políticas estratégicas adotadas, os empregados da empresa com seus respectivos objetivos; enfim toda a estrutura da organização.

◦ Requisitos Externosque dizem respeito aos requisitos éticos e legais; ◦ Funcionais + Não Funcionais: FURPS

(6)

FAQ: Perguntas frequentes sobre

requisitos

Requisitos

Engenharia de Requisitos Custo

Processo de Engenharia de Requisitos Requisitos Errados

Engenharia de Requisitos Ideal Stakeholders

(7)

FAQ: Perguntas frequentes sobre

requisitos

Requisitos

Engenharia de Requisitos Custo

Processo de Engenharia de Requisitos Requisitos Errados

Engenharia de Requisitos Ideal

Stakeholders

Gerenciamento de Requisitos

Funções / Limitações Processo

15 % do Desenvolvimento

Projeto atraso/ sem qualidade Processo se adapta à empresa Todos interessados Manutenção Sistematização de Atividades

(8)

Fases da Engenharia de

Requisitos (ER)

(9)

7 fases

Concepção; Levantamento; Elaboração; Negociação; Especificação; Validação; Gestão.

(10)

Concepção

Em alguns casos, uma conversa (informal) é o primeiro passo;

Geralmente, começa quando uma necessidade de negócio e identificada ou um mercado ou serviço potencialmente novo é descoberto.

Há uma definição básica geral do sistema: negócios, funcionalidade, aplicabilidade...

- Problema;

- Interessados na solução; - Natureza da Solução; - Conflitos e Prioridades.

(11)

Concepção - Técnicas

Q&A – Perguntas e Respostas:

Você é a pessoa correta para responder estas perguntas? Suas respostas são oficiais?

Minhas perguntas são importantes para o problema que você tem? Estarei eu fazendo perguntas demais?

Alguma outra pessoa poderia me fornecer informações adicionais? Deveria eu perguntar-lhe algo a mais?

(12)

Levantamento

Pergunte ao Cliente, aos Usuários, os objetivos do produto;

Participação do Engenheiro de SW;

Tarefa Difícil:

◦ Problemas de Escopo; ◦ Problemas de Entendimento; ◦ Problemas de Volatilidade; - Brainstorming; - Documentação existente; - Ambiente operacional;

(13)

Levantamento - Técnicas

Coleta colaborativa de requisitos;

Reunião formal para entender os pontos-chaves, informal para

valorização de ideias;

Reunião Engenheiro de Software e demais interessados, regras,

facilitador, mecanismo de definições (flipchart + adesivos);

◦ Lista de objetos, serviços, restrições e desempenho.

Desempenho Restrições

Serviços Objetos

(14)

Elaboração

Expansão e Refinamento dos Requisitos;

São identificados cenários do usuário no sistema:

◦ Atores, e suas funções;

Marco: Diversos Diagramas UML de Análise como Casos de Uso,

Diagrama de Atividade.

(15)

Negociação

Problemas:

◦ Solicitação superior ao que pode ser feito;

◦ Necessidades de Clientes distintos conflitantes;

Reunião de Negócios;

Priorização de Requisitos;

(16)

Especificação

Documento Formal

◦

Modelo de Especificação de Requisitos de Software;

◦

Linguagem Natural + Modelos Gráficos.

Serve como base para as atividades subsequentes (desenvolvimento,

testes, ...);

Descreve as funções e restrições que governarão o desenvolvimento

do sistema;

(17)

Validação

Revisão Técnica Formal feita por:

◦ Clientes, Gerentes, Analistas, Usuários, ...

Para detectar:

◦ Requisitos conflitantes, ambíguos, irrealísticos, omissos.

(18)

Gestão de Requisitos

Adaptabilidade às mudanças;

Cada Requisito é atribuído um identificador;

São construídas (mantida em bancos de dados) tabelas de

rastreamento:

(19)

(20)

Documento de

Requisitos

(21)

Desenvolvimento dos

Casos de Uso - UML

(22)

Contexto Histórico

Década de 90: Desenvolvimento Orientado a Objetos (O.O.) dominou o mercado e a indústria.

Especialistas introduziram diversos métodos para análise e projeto de sistemas O.O., mas nenhum teve muito sucesso;

James Rumbaugh, Grady Booch, Ivar Jacobson

◦ Método unificado com o melhor do que existia na época, além de características adicionais; ◦ UML: Unified Modeling Language

(23)

UML

Totalmente adotada no Mercado; Linguagem Gráfica;

Objetivos: Especificação, Documentação, Simulação, comunicação,...., e até

programação! O que se modela: ◦ Requisitos; ◦ Estrutura; ◦ Comportamento; ◦ Pacotes; ◦ ...

(24)

Casos de Uso

DI AG RA MAS UML

(25)

Modelo de Casos de Uso

É um modelo das funções pretendidas do sistema e seu ambiente;

Serve como um contrato estabelecido entre o cliente e os desenvolvedores;

É usado como fonte de informações essencial para atividades de análise, design e teste.

(26)

Elementos do caso de uso

1. Ator:

◦ Representa um Papel, algo que interage com o software; ◦ Pode ser uma pessoa, um outro software ou hardware. ◦ Ex.:

(27)

Elementos do caso de uso

2. Generalização:

◦ Define herança entre os elementos de software.

Ex. 1:

Tanto mamífero quanto ave são animais, pois possuem característica em comum; Animal é uma generalização de mamíferos e aves;

Entretanto mamífero é uma generalização de homem e também de leão, os quais não são aves.

CLEYTON RODRIGUES, M.SC 27 Animal Leão Homem Mamífero Ave

(28)

Elementos do caso de uso

◦ Ex. 2: Clientes bancários podem ser pessoas físicas ou pessoas jurídicas

(29)

Elementos do caso de uso

◦ Ex 3.: Alunos de uma Universidade podem ser de Graduação ou Pós Graduação

(30)

Elementos do caso de uso

3. Caso de Uso

◦ Descreve uma sequência de ações - incluindo suas variantes -que o sistema deve executar com o objetivo de produzir como resultado algo de valor para o atendimento das necessidades de um ator.

Um caso de uso:

◦ Deve ser iniciado por um ator, embora haja exceções;

◦ Descreve uma funcionalidade completa do sistema conforme percebida por um ator; ◦ Gera como resultado algo de valor tangível para um ator (usuário);

◦ Expressam os requisitos do sistema.

(31)

Elementos do caso de uso

◦ Ex.: Um caso de uso deve ter como nome uma frase representando uma ação

(comportamento) significativa para o vocabulário do sistema em processo de modelagem.

(32)

Elementos do caso de uso

4. Comunicação

◦ Quando um ator inicializa um caso de uso, isso deve ser feito através de uma comunicação.

32

Este é o tipo de

comunicação mais comum, porém existem outros tipos

(33)

Elementos do caso de uso

◦

Entre atores e casos de uso

◦ Unidirecional

◦ Bidirecional

(34)

Elementos do caso de uso

◦

Entre dois casos de uso

◦ Neste caso, não representam uma comunicação;

◦ São relacionamentos ditos estruturais.

◦ Pode ser de três tipos:

◦ Inclusão (include) ◦ Extensão (extend) ◦ Generalização

(35)

Elementos do caso de uso

◦

Include

◦ Em alguns casos, o relacionamento include pode ser utilizado para colocar em evidência partes comuns a outros casos de uso.

◦ Ex.:

(36)

Elementos do caso de uso

◦

Extend

◦ O caso de uso que estende inclui serviços especiais, nem sempre obrigatórios, do caso de uso maior.

◦ Ex.:

(37)

Elementos do caso de uso

◦

Generalização

◦ Nesta situação, um caso de uso mais específico pode ser alguma situação particular do caso de uso geral;

◦ Ex.:

(38)

Atividade

Entrega do Modelo de Casos de Uso + Documento de Requisitos em; Data: 31/03/2015;

(39)