Engenharia de Software

Requisitos de Sistema

O que Engenharia de Requisitos?

a engenharia (Arte de aplicar os conhecimentos cientficos inveno, aperfeioamento ou utilizao da tcnica industrial em todas as suas determinaes Dicionrio Michaelis) aplicada a obteno metdica de requisitos (Requisitos: Condio necessria para a obteno de certo objetivo, ou para o preenchimento de certo objetivo. - Leite 94) do sistema, sejam estes Funcionais ou No-Funcionais, tratando-os de maneira sistemtica e padronizada com o fim de se ter um reaproveitamento da anlise de requisitos feita, para qualquer outro projeto semelhante ou mesmo para manuteno do mesmo.

Levantamento de Requisitos
O que : a definio das caractersticas e propriedades desejadas para o sistema que ser elaborado; Objetivos: Definir claramente o que se deseja do sistema a ser implementado; Quem participa: Contratantes do sistema, futuros usurios do sistema e analistas de requisitos; Tcnicas utilizadas: Entrevistas e questionrios, workshops de requisitos, interpretao de papis, prototipao e outras.

Importncia
Requirements elicitation is perhaps the most difficult, most critical, most error-prone, and most communication-intensive aspect of software development. Karl Wiegers, 2003 A obteno das exigncias talvez a mais difcil, a mais crtica, de aspecto o mais sujeito a erros, e a mais intensiva em comunicao da programao de software.

Ciclo-de-vida dos REQUISITOS

Necessidade Definio

Gesto

Utilizao

Avaliao

Processo de Engenharia de Requisitos

Informaes

Necessidades

Elicitao

Modelagem

Validao
Especificao dos Requisitos
Rocco, 2004

Anlise
Especificao

Aquisio
Representaes

Requisitos de Software
A Norma ISO/IEC 9126 define seis caractersticas de qualidade de software que devem ser avaliados: Funcionalidade (finalidade do produto) Usabilidade (esforo para utilizar, aprender o produto) Confiabilidade (freqncia de falhas, recuperabilidade) Eficincia (desempenho) Manutenibilidade (esforo necessrio para modificar) Portabilidade (capacidade de transferir o produto para outros ambientes)

Nveis de Requisitos
Requisitos de negcio
objetivos de alto nvel requeridos pelos clientes

Requisitos de usurio
tarefas que os usurios so habilitados a realizar

Requisitos funcionais
funcionalidade que o software deve prover
(comportamento e propriedade: como o sistema deve se comportar quando recebe um estimulo)

Requisitos no funcionais
Restritivos: Impem restries ao sistema, o que limita as
opes de soluo a serem adotadas. No expressam nenhuma funcionalidade a ser realizada pelo software

Como os Projetos Podem Ter Sucesso?

Anlise do Problema
Entenda o problema Obtenha concordncia dos envolvidos

Levantamento dos Requisitos

Identifique quem usar o sistema (atores) Descubra como o sistema ser usado (casos de uso)

Gerncia de Requisitos
Especifique os requisitos completamente Gerencie expectativas, mudanas e erros Controle o aumento do escopo Defina a equipe e a mantenha informada

Gerncia de Requisitos
Atividades de: - acompanhar o desenvolvimento - controlar as mudanas dos requisitos Aes: - planejamento desenvolvimento - rastreabilidade com componentes de software - definio do estado e avaliao da qualidade - Anlise de impacto e controle de verses de mudanas

Rocco, 2004

Principais Atividades da Eng de Requisitos

Documento de Requisitos do Sistema

ELICITAR

ANALISAR Decises da Anlise Mtodos, Tcnicas e Ferramentas Modelo de Anlise do Sistema

MODELAR

Elicitao dos requisitos

Nesta fase o engenheiro de requisitos procura captar os requisitos do software, buscando obter conhecimento do domnio do problema. ELICITAR: descobrir, tornar explcito, obter o mximo de informaes para o conhecimento do objeto em questo.

Cabe elicitao a tarefa de identificar os fatos relacionados aos requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que demandado do software.
Para alcanar tal objetivo, esta fase utiliza trs atividades principais: identificao das fontes de informao; coleta de fatos e comunicao, alm de ferramentas, pessoal e mtodos.

Elicitao dos requisitos

Obter informao sobre domnio do problema e sistema atual (Antes de manter as reunies com os clientes e usurios e identificar os requisitos, fundamental conhecer o domnio do problema e os contextos organizacional e operacional (situao atual). A equipe responsvel pelo levantamento deve se familiarizar com o vocabulrio prprio do domnio a ser considerado. Preparar e realizar reunies de levantamento /negociaes (Utilizar tcnicas especficas para o levantamento de requisitos e tcnicas de negociao).

Elicitao dos Requisitos

Identificar e revisar os objetivos do sistema (Identificar e revisar quais informaes relevantes para o cliente que o sistema dever gerir e armazenar.)
Identificar e revisar os requisitos funcionais

Identificar e revisar os requisitos no funcionais

Necessidades da Elicitao

Faz
Faz Faz

Coleta de Fatos
Identificao de Fontes de Informao Comunicao

Faz/Usa Ferramentas Usa

Pessoal

Usa

Mtodos

Depende de Pontos de Vista

Identificao das Fontes de Informao

O que so Stakeholders do sistema?

Qualquer pessoa afetada de alguma forma pelo sistema (atores, cliente, usurio final, desenvolvedor)

A anlise dos Stakeholders ajuda a

determinar o impacto que um novo sistema de informao ter.

Identificao das Fontes de Informao

Outras fontes de Informao:
Documentao do macrosistema Polticas Manuais Memos, atas, contratos... Livros sobre tema relacionado Outros sistemas da empresa, sistemas externos.

Identificao das Fontes de Informao

Importante:
Priorizar as Fontes de Informao. Descubra:
Atores mais importantes Documentos mais mencionados Rede de comunicaes entre os componentes do macro-sistema ...

Comunicao
(...entre clientes/agentes e os eng. soft.)

Apresentao: A forma como a informao apresentada Entendimento: Estabelecimento de contextos comuns.

Ex. Planta; Ordem de 5,10,2,9,8,4,6...

Linguagem
Nvel de Abstrao

Retro-alimentao

Apresentao
Diferentes formas de apresentao ajudam ou dificultam o entendimento.

Distribuio de Vendas
45% 40% 35% 30% 25% 20% 15% 10% 5% 0% Produto A Produto B Produto C Produto D

Distribuio de Vendas
Produto A Produto B Produto C Produto D 15% 40% 20% 25%

Percentual

Entendimento
A comunicao pode ser ruidosa se os indivduos estiverem dialogando em diferentes nveis de abstrao. Conflito presente entre generalistas e especialistas.
Exemplo Devemos conquistar mercados (Diretoria) X Distribuir os vendedores (Gerncia de Vendas)

Linguagem
A linguagem reflexo da cultura de uma sociedade. Para entendermos algo de importante para uma sociedade temos que entender sua linguagem. Deve-se compreender a linguagem antes de elicitar as necessidades.
Exemplos Conta-me, Dzero, Fecha a mesa, Passagem de Resultados, Zipar, FTP, TCP/IP

Retroalimentao
Obrigar ao receptor da informao a recolocar a comunicao at que o emissor responda positivamente a recolocao. Resumir, parafrasear, confirmar.
a ?

Tcnicas de Levantamento
- Entrevistas - Questionrios -Observao / Visitas instalaes (prprias ou outras) - Demonstraes - Pesquisa externa - Anlise da Documentao - Joint Application Design (JAD) - IBM - Brain Storm - Brain Writing

JAD - Joint Application Development

Processo
INTRODUZ TEMA

Usurios e desenvolvedores trabalham juntos em uma reunio com o objetivo de:

identificar o problema propor elementos de soluo negociar diferentes abordagens especificar um conjunto preliminar de requisitos de soluo preparao para reunio a partir de uma requisio geral do produto reunio

MOSTRAR EXEMPLOS

DISCUSSO Responsvel PENDNCIA IMPASSE Gerncia CONSENSO

Envolve:

DOCUMENTAO O

Anlise de Requisitos
O tratamento da informao um requisito que fundamenta o processo de desenvolvimento de software antes da soluo de tecnologia a ser aplicada. Cada projeto deve ter suas fases de desenvolvimento adequadas s necessidades de tratamento da informao.

Classificao de Requisitos no funcionais

Usabilidade: requisitos que selecionam ou afetam a usabilidade do sistema. Exemplos incluem a facilidade de uso e a necessidade ou no de treinamento dos usurios.

Confiabilidade: Tratamento de falhas, possibilidade de previso, no erros de programao;

Desempenho: Velocidade, eficincia, preciso, tempo de recuperao, tempo de resposta, uso de recurso, etc;

Configurabilidade: O que pode ser configurado pelos usurios do sistema;

Portabilidade: restries sobre a plataforma de hardware e de software nas quais o sistema ser implantado e sobre o grau de facilidade para transportar o sistema para outras plataformas. Segurana: Permisses de usurios do sistema;

Requisitos
Requisitos funcionais evidentes so efetuados com conhecimento do usurio; Requisitos funcionais ocultos so efetuados pelo sistema sem o conhecimento explcito do usurio; Descrever requisitos funcionais e requisitos nofuncionais requer tratar dois aspectos: primeiro, "Produzir"; segundo, "com Qualidade", as duas faces da moeda aplicveis Engenharia de Software.

 O processo de produo de software depende da definio clara de qual produto construir. Esta definio fundamenta-se no conhecimento do problema e na viabilizao de oportunidade de negcio com o uso de tecnologia da informao.

Requisitos

 A estratgia o tratamento multidisciplinar da informao de requisitos obtida do ponto de vista dos stakeholder (fonte de informao) para o entendimento e atendimento s necessidades.

Requisitos

Tabela de Requisitos Funcionais

Cdigo do requisito funcional (Ex.: F1, F2, F3, ...). Nome do requisito funcional (especificao curta). Descrio (especificao longa e detalhamento do requisito). Categoria funcional: evidente ou oculto. Cdigo do requisito no funcional (Ex.: NF1.1, NF1.2, ... NF2.1, NF2.2, ...).

Tabela de Requisitos No Funcionais

Nome do requisito no funcional (especificao curta). Restrio: especificao do requisito no funcional. Categoria: tipo de restrio: segurana, performance, compatibilidade, etc. Obrigatoriedade: se o requisito desejvel ou obrigatrio.

Desafios da Anlise de Requisitos

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 mudana

Organizao dos Requisitos

Casos de Uso
Cada caso de uso tem uma descrio o qual descreve a funcionalidade que ir ser construda no sistema proposto.

Manuteno de Conceitos Consultas/Relatrios

Requisitos Funcionais e No Funcionais Associados

F1 Registrar emprstimos Oculto ( ) Descrio: O sistema deve registrar emprstimos de fitas, indicando o cliente e as fitas que foram emprestadas, bem como a data do emprstimo e valor previsto para pagamento na devoluo. Requisitos No Funcionais Nome Restrio Categoria Desejvel Permanente NF1.1 Controle de A funo s pode ser acessada por usurio com Segurana ( ) (x) Acesso perfil de operador ou superior. NF1.2 Identificao de As fitas devem ser identificadas por um cdigo de Interface ( ) (x) Fitas barras NF1.3 Identificao O cliente dever ser identificado a partir de seu Interface ( ) ( ) do cliente nome NF1.4 Tempo de O tempo para registro de cada fita deve ser inferior Performance (x) ( ) registro a um segundo. NF1.5 Janela nica Todas as funes relacionadas a emprstimos Interface (x) (x) devem ser efetuadas em uma nica janela ... ... ... ... ...

F2 Calcular descontos Oculto ( x ) Descrio: O sistema deve calcular descontos nos emprstimos em funo da poltica da empresa. Requisitos No Funcionais Nome Restrio Categoria Desejvel NF2.1 Desconto de Nos fins de semana, usurios que levam 4 fitas Especificao ( ) fim de semana pagam apenas 3. ... ... ... ...

Permanente ( ) ...

Requisitos Suplementares
Nome S1 Tipo de Interface Restrio As interfaces do sistema devem ser implementadas como formulrios acessveis em um browser html. A camada de persistncia deve ser implementada de forma que diferentes tecnologias de bancos de dados possam vir a ser utilizadas no futuro Os perfis de usurio para acesso ao sistema so: 3. Administrador - pode efetuar todas as operaes. 2. Operador - pode efetuar as operaes de emprstimo, devoluo, pagamento e cadastramento. 1. Convidado - pode efetuar apenas consultas nos prprios dados (cliente). ... Categoria Interface Desejvel ( ) Permanente ( ) S2 Armazenamento de dados Persistncia ( ) (x)

S3 Perfis de usurio

Segurana

( )

( )

...

...

...

...

Organizando Requisitos em Casos de Uso

Nome Atores Descrio Emprestar Cliente, O cliente se identifica e identifica as fitas que Fitas Funcionrio deseja levar. O funcionrio faz o registro e libera as fitas para emprstimo. Devolver Cliente, O cliente entrega ao funcionrio as fitas. O Fitas Funcionrio funcionrio faz o registro da devoluo e o cliente efetua o pagamento devido. Reservar Cliente, O cliente solicita a reserva de um ou mais filmes. O Fitas Funcionrio funcionrio registra a reserva. Referncias Cruzadas F1, F3, F5, F9, F10

F2, F4, F6, F7, F8

F11, F12

Tabela para Representar Operaes de Manuteno

Conceito Cliente Reserva Fita Emprstimo

I x x x

A x x x

E x x x x

C x x x x

Observao S possvel excluir se no houver emprstimos associados S possvel excluir se no houver emprstimos associados A incluso de emprstimo s pode acontecer atravs do caso de uso emprestar fitas. No possvel alterar um emprstimo, apenas excluir.

Ref. Cruzadas F13 F15, F16 F18 F17, F19

Organizao de Requisitos em Consultas

Nome Vendas Mensais Clientes Suspensos ... Referncias Cruzadas F20, F21, F22 F13, F23, F1 ...

Amostragem
o processo de seleo sistemtica de elementos representativos de uma populao. Quando os elementos selecionados em uma amostragem so analisados, pode-se assumir que esta anlise revelar informaes teis acerca da populao como um todo. Por que usar amostragem? diminuir custos; acelerar o processo de levantamento de informaes; eficincia: a informao tende a ser mais apurada, j que menos elementos podem ser analisados, mas estes podem ser analisados com mais detalhes; reduzir tendncias.

Investigao
Muitas vezes, algumas informaes so difceis de serem obtidas atravs de entrevistas ou observao. Tais informaes revelam, tipicamente, um histrico da organizao e sua direo. Nestes casos, devemos utilizar investigao, isto , anlise de documentos. Atravs de investigao, podemos obter mais facilmente informaes, tais como tipos de documentos e problemas associados, informao financeira e contextos da organizao. Tais informaes so difceis de serem obtidas atravs de outras tcnicas de levantamento de requisitos, tais como entrevistas ou observao.

Entrevistas
Uma entrevista de levantamento de informaes uma conversa direcionada com um propsito especfico, que utiliza um formato pergunta-resposta. Os objetivos de uma entrevista incluem: obter as opinies do entrevistado, o que ajuda na descoberta dos problemas-chave a serem tratados; conhecer os sentimentos do entrevistado sobre o estado corrente do sistema; obter metas organizacionais e pessoais; e levantar procedimentos informais.

Questionrios
O uso de questionrios constitui uma tcnica de levantamento de informaes que permite ao engenheiro de software obter de vrias pessoas afetadas pelo sistema (corrente ou proposto) informaes, tais como: Posturas: o que as pessoas na organizao dizem querer; Crenas: o que as pessoas pensam ser realmente verdade; Comportamento: o que as pessoas fazem; Caractersticas: propriedades de pessoas ou coisas.

Observao
Observar o comportamento e o ambiente do indivduo que toma decises pode ser uma forma bastante eficaz de levantar informaes que, tipicamente, passam desapercebidas usando outras tcnicas. Tomadas de deciso ocorrem em diversos nveis da organizao: operacional, gerencial e estratgico e, portanto, importante observ-las em todos os nveis que tenham interao com o sistema. Atravs da observao possvel capturar: o que realmente feito e no apenas o que documentado ou explicado. o relacionamento entre o tomador de deciso e outros membros da organizao. A observao usada para: obter informaes sobre o tomador de deciso e seu ambiente, que no so capturadas por outras tcnicas. confirmar ou negar informaes de entrevistas e/ou questionrios. Alguns pontos importantes devem ser realados: o analista deve saber o que observar, quem observar, quando, onde, porque e como.

Prototipao
A prototipao uma tcnica valiosa para se obter rapidamente informaes especficas sobre requisitos de informao do usurio. Tipicamente, a prototipao permite capturar os seguintes tipos de informao: Reaes iniciais do usurio: Como o usurio se sente em relao ao sistema em desenvolvimento? Reaes ao prottipo podem ser obtidas atravs da observao, entrevistas, questionrio ou relatrio de avaliao. Sugestes do usurio para refinar ou alterar o prottipo: guiam o engenheiro de software na direo de melhor atender as necessidades dos usurios. Inovaes: novas capacidades, no imaginadas antes da interao com o prottipo. Informaes para reviso de planos: estabelecer prioridades e redirecionar planos.

JAD: Joint Application Development

Tcnica que envolve: Atividades de preparao Sesses de workshop
Estruturadas Foco especfico Pouco freqentes Todos os interessados participam, se manifestam e so ouvidos

Agenda Facilitador / condutor Documentador Facilidades visuais

Sesso JAD Viso Geral

Para que o JAD seja bem sucedido:

Interao entre pessoas que necessitam tomar decises que afetem mltiplas reas de uma organizao com: Reunies estruturadas Objetivos que envolvem mais de um departamento Projetos de sistemas de computao Planejamento de Projetos Tomada de decises nos negcios

Fases do JAD

Primeira fase do JAD

Entrevistas Gerenciais Seleo dos participantes Programao da sesso JAD Preparao do Guia de Definies Gerenciais

Segunda fase do JAD

Familiarizao com as reas de negcio e com sistemas Documentao dos requisitos e processos de negcio Recolhimento de informaes preliminares Preparao da agenda da sesso JAD

Terceira fase do JAD

Elaborao do documento de trabalho Treinamento do documentador e estabelecimento do protocolo de comunicao Preparao das facilidades visuais Preparao da sala da reunio

Quarta fase do JAD

1. Abertura da sesso Apresentao pessoal, itens administrativos Apresentao dos objetivos da sesso, agenda e documento de trabalho Apresentao das regras da sesso Apenas uma pessoa fala de cada vez Quem cala, consente Seja pontual (incio das sesses, intervalos) 2. Palavras do patrocinador 3. Viso geral do negcio

Quarta fase do JAD (continuao)

4. Discutir as premissas coletadas 5. Identificar e discutir os tpicos do documento de trabalho, procurando um consenso nas decises Para cada tpico a ser validado de cada rodada, o facilitador apresenta o tpico, transfere a palavra a cada um dos participantes da sesso, solicitando que se manifeste sobre o tpico 6. Avaliao da sesso JAD 7. Fechamento da sesso JAD

Quinta fase do JAD

Elaborao do documento final Reviso do documento final Realizao da reunio de reviso Aprovao do documento final Distribuio do documento final

Vantagens
Ganho de produtividade Mais de 75% dos erros de um sistema resultam de especificaes de baixa qualidade Custo e tempo para alterar o projeto de um sistema depois de pronto so 50 a 100 vezes maiores que alter-lo durante a elaborao do projeto Preveno de erros mais econmica do que deteco e correo A soluo no est apenas em processos, mtodos e ferramentas adequados...

Modelagem de requisitos
O que : Detalhamento dos requisitos funcionais definidos na especificao de requisitos; A criao de modelos grficos representativos do que se deseja do sistema de informao a ser implementado Objetivos: Permitir uma estruturao preliminar do sistema de informao que se quer desenvolver, do ponto de vista de quem utilizar o sistema; Quem participa: Contratantes do sistema, futuros usurios do sistema e analistas de requisitos; Caracterstica:Abstrao quanto a detalhes internos do sistema de informao, dando mais importncia ao ponto de vista externo do sistema. Tcnica utilizada: Use Cases

Espao do problema

Espao da soluo Espao para construir o produto

Modelagem Organizacional com Casos de Uso

Perguntas
1. Para que serve o Levantamento de Requisitos? 2. Quais so as barreiras comuns no levantamento de casos? 3. Por que usar o JAD? 4. Qual o primeiro passo do Levantamento de Requisitos?

Requisitos funcionais usando Casos de Uso Conceitos Chaves

60

Conceito Chave - Caso de Uso

Um caso de uso uma forma especfica de uso do sistema composta por uma seqncia de aes que produz um resultado de valor para algum agente externo. Mostram apenas o que o sistema faz, no como. Capturam o comportamento pretendido para um sistema, sem a necessidade de especificar como esse comportamento ser implementado.

61

Conceito Chave - Caso de Uso (2)

Casos de uso servem como guia para:
Criao e validao da arquitetura do sistema. Definio de casos e procedimentos de testes. Planejamento da iteraes, elaborao de cronograma, organizao do time. Criao da documentao do usurio.

NomeDoCasoDeUso

Representao em UML

62

Conceito Chave - Ator

Qualquer coisa que possui interface com o sistema a ser desenvolvido Definem um papel particular So sempre externos ao sistema O sistema ser descrito atravs de vrios casos de uso que so executados por vrios atores.

Ator
Representao em UML

63

Atores e usurios do sistema

Uma mesma pessoa pode desempenhar diferentes papis:

Joana

Joana como professora

Professora

Joana como diretora

Diretora

64

Conceito Chave Diagrama de casos de uso

Diagrama com casos de uso do sistema e atores relacionados Facilitam o entendimento do sistema mostrando a sua viso externa A coleo de casos de uso deve especificar todas as formas existentes de uso do sistema.

CasoDeUso1

Representao em UML de um diagrama de casos de uso

Ator 1

CasoDeUso3

Ator 2

CasoDeUso2

65

Diagrama de casos de uso Exemplos

Sacar dinheiro

Cliente

Realizar depsito

Transferir entre contas

66

Diagrama de casos de uso Exemplos (2)

Realizar pedido

Comprador Entregar pedido Empresa de Entrega

Receber fatura a cobrar

Sistema de cobrana

67

Conceito Chave Cenrios

Em UML significa um caminho atravs de um caso de uso. Exemplo (Sacar dinheiro):
Saque com sucesso Tentativa de saque MAS senha incorreta Tentativa de saque MAS saldo insuficiente

Cada caso de uso contm uma coleo de cenrios, tanto de sucesso como de falha.

68

Conceito Chave pacotes

Servem para agrupar casos de uso relacionados Critrios para agrupamento:
Ator Funcionalidades correlatas Processos Um por todos e todos por um

Sacar dinheiro

Cliente

Transferir entre contas Realizar depsito

69

Conceito Chave modelo de casos de uso

Modelo que descreve os casos de uso do sistema e atores relacionados.
Atores Casos de Uso

Especificaes de casos de uso

70

Requisitos funcionais usando Casos de Uso II Casos de uso

71

Objetivos deste mdulo

Discutir como encontrar atores e casos de uso

Discutir como especificar os casos de uso

72

Como encontrar atores e casos de uso?

73

Como encontrar atores?

Quem usa o sistema? Quem instala/mantm o sistema? Quem inicia/desliga o sistema? Que outros sistemas usam o sistema? Quem recebe informao do sistema? Quem prov informao ao sistema?

74

Como encontrar casos de uso?

Atores so fundamentais para a descoberta dos casos de uso Pergunte:
Que funes o ator vai querer do sistema? O sistema armazena informaes? Que informaes atores iro criar, ler, atualizar ou apagar? O sistema precisa notificar o ator sobre mudanas no seu estado interno? Existe algum evento externo que o sistema precisa saber? Que ator informa o sistema desses eventos?

75

Escopo do sistema
preciso delimitar as fronteiras do sistema

Sistema Bancrio

Sistema de Caixa Automtico

Cliente
Caixa

Qual a fronteira do sistema?

76

Tcnicas para levantar casos de uso

Use-Case Workshop
No pode ter muita gente Pessoas com diferentes perfis Presena de um facilitador Aceitar todo tipo de sugesto, filtrar depois! Evitar pensar em detalhes Os casos de uso levantados devem estar claros para todos! Principalmente o valor que cada um agrega ao usurio Consulte todos!

Reunies
Conversas com usurios.

77

Especificao detalhada dos casos de uso

78

Quando e por que realiz-las?

Quando?
Aps fazer levantamento dos principais casos de uso do sistema.

Por que?
Descrever detalhes dos casos de uso Descrever fluxos de eventos e outras propriedades Uniformizar entendimento entre clientes, usurios e equipe de desenvolvimento.

79

Especificando casos de uso

Casos de uso no precisam ser especificados todos de uma vez Casos de uso devem ser priorizados por iterao
Prioridade tcnica Prioridade do usurio

80

Especificao de um caso de uso

Identificador Nome e breve descrio Ator Prioridade Requisitos no funcionais associados Pr-condies Ps-condies Fluxo de eventos principal Fluxos secundrios: alternativos e de exceo

81

Identificao do caso de uso

Deve ser nica No deve mudar nunca Pois casos de uso podem ser referenciados por seu identificador.
82

Breve descrio do caso de uso

Dar uma idia do propsito do caso de uso, do seu objetivo Deve ser feita ao se identificar o caso de uso, para evitar mal-entendidos 2 ou 3 linhas!

83

Prioridades de casos de uso

Essencial para gerenciar requisitos E para montar iteraes Definir prioridade de todos os casos de uso Exemplo de classificao da prioridade:
Essencial Importante Desejvel

84

Pr e ps condies
O que deve ser verdade antes e depois da realizao do caso de uso!

85

Pr e ps condies: exemplos
Caso de uso Entregar pedido
Pr-condio: Os itens do pedido devem existir em estoque Ps-condio: Os itens enviados devem ser abatidos do estoque.

Caso de uso Recadastramento de CPF

Pr-condio: o usurio deve possuir um CPF Ps-condio: a situao do contribuinte atualizada.
86

Fluxo de eventos bsico ou principal

Funcionalidade bsica ou central do caso de uso Representa o caminho que seguido na maioria das vezes que o caso de uso executado. Descreve a situao mais simples do caso de uso, na qual o objetivo atingido. Pense nos fluxos secundrios depois!

87

Exemplo de um fluxo bsico

Caso de uso Sacar dinheiro
1. O cliente passa o carto 2. O sistema solicita senha e valor do saque 3. O cliente digita os valores solicitados 4. O sistema verifica se h saldo suficiente 5. O sistema debita da conta do cliente o valor do saque. 6. O dinheiro entregue ao cliente.
88

Exemplo de um fluxo bsico

Caso de uso Sacar dinheiro
MAS...
E se a senha no conferir? E se no houver saldo? E se no houver dinheiro suficiente na mquina?

Calma, vamos deixar esses detalhes para depois!

89

Exemplos de especificaes
Observe a especificao dos casos de uso XX, YY e ZZ.
Pequena descrio Pr e ps-condies Fluxo de eventos bsico ou principal

90

Subfluxos
Observe a especificao dos casos de uso XX, YY e ZZ.
Pequena descrio Pr e ps-condies Fluxo de eventos bsico ou principal

91

Subfluxos
As vezes, o fluxo principal possui vrias alternativas igualmente provveis de ocorrer Nestes casos, pode-se usar o conceito de subfluxos Cada subfluxo representa um dos possveis caminhos do fluxo principal
92

Subfluxos - Exemplo
Caso de uso Cadastrar Produtos
Fluxo bsico
1. O funcionrio seleciona a opo de cadastro, iniciando o caso de uso. 2. O sistema solicita que o funcionrio indique a operao que deseja efetuar: incluso, atualizao ou remoo de produtos. 3. De acordo com a opo fornecida pelo funcionrio, um dos subfluxos abaixo executado.

93

Subfluxos Exemplo (2)

Subfluxo Incluir produto
1. O sistema solicita o nome, descrio e preo do novo produto. 2. O funcionrio fornece os dados 3. O sistema gera um identificador nico para o produto e o armazena as informaes fornecidas.

Subfluxo Alterar informaes do produto

1. O sistema solicita o nome ou identificador do produto a ser alterado. 2. O funcionrio fornece o identificador do produto. 3. Os sistema apresenta os dados do produto para alterao (os mesmos dados solicitados no subfluxo Incluir produto) 4. O funcionrio atualiza os dados do produto e o sistema armazena os novos dados.

Subfluxo Remover produto

...
94

Fluxos secundrios
S devem ser analisados e descritos aps a descrio dos fluxos bsicos. Fluxos alternativos
Situaes especiais (desconto para um cliente)

Fluxos de erro
Situaes de erro

95

Reuso de fluxos secundrios

Fluxos secundrios, principalmente de erros, podem ser referenciados por diferentes casos de uso Evitar duplicao de informao!

96

Resumo Fluxos de eventos

Fluxo normal ou bsico (Happy Path)
Pode conter subfluxos

Fluxos alternativos
Variaes regulares Casos incomuns

Fluxos de exceo
Tratam situaes de erro do fluxo bsico.

97

Exemplo de fluxos secundrios

Observe os fluxos secundrios dos casos de uso XX, YY, ZZ

98

Caso de uso no a NICA ferramenta...

Especificao de interface Requisitos de performance Caso de uso Dicionrio de dados Regras de negcio Restries

Itens em aberto

Fonte: Patterns for Effective Use Cases

99

Exemplo de seo adicional

Observe duas verses de parte de uma especificao de caso de uso para mudana de assento em um avio:
Uma das verses incorpora a regra de negcio no fluxo de eventos A outra, separa a regra em uma seo adicional.

Fonte: Patterns for Effective Use Cases

100

Requisitos - Exerccio
Baseado no plano de projeto elaborado anteriormente e na descrio do projeto entregue, descreva os requisitos funcionais usando casos de uso.

101

Requisitos no funcionais

102

Objetivos deste mdulo

Discutir as diferenas entre requisitos funcionais e no funcionais e a relao destes com casos de uso Apresentar uma classificao para requisitos no funcionais Discutir como especificar requisitos no funcionais

103

Requisitos funcionais X Requisitos no funcionais

Atributos ou qualidades do sistema Podem estar associados a um caso de uso apenas, ou ainda a um grupo de casos de uso especfico

104

Tipos de requisitos no-funcionais

Facilidade de uso (usabilidade) Confiabilidade Desempenho (performance) Segurana Distribuio Adequao a padres Restries de Hardware e Software
105

Facilidade de uso (usabilidade)

Relacionados com:
Interface com o usurio, material de treinamento e documentao do sistema.

Exemplos:
Help Instalao automtica
106

Confiabilidade
Relacionados com:
Freqncia e severidade de falhas Habilidade de recuperao das falhas Corretude do sistema

Exemplos:
Disponibilidade 24/7 Prazo de tolerncia mxima para volta do sistema
107

Desempenho
Relacionados com:
Eficincia Tempo de resposta Uso de recursos

108

Segurana
Relacionados com:
Privacidade Integridade Autenticidade dos dados do sistema

109

Distribuio
Relacionados com a distribuio da verso executvel do sistema. Crtico para sistemas com grande volume de usurios.

110

Adequao a padres
Relacionados com padres ou normas que devem ser seguidos no sistema ou no seu desenvolvimento:
Interface grfica Desenvolvimento de componentes Modelo especfico de arquitetura

Deve-se referenciar o documento que define o padro adotado.

111

Restries de hardware e software

Relacionados com o hardware e software utilizados para desenvolvimento do sistema:
Plataforma cliente
Windows Web

Plataforma servidor
Linux Banco de Dados

Protocolo de comunicao Etc

112

Requisitos no funcionais
Devem ser testveis, para isso devem ser mensurveis! Ou, deve-se especificar qual o seu critrio de aceitao! Precisam estar definidos com nmero e nomes:
O sistema precisa ser rpido. Quo rpido? O sistema deve ser implementado numa plataforma madura. Que plataforma?

113

Requisitos no funcionais
Redefinindo os requisitos...
O sistema deve responder em menos de 10 segundos

Ou
80% dos usurios que participarem da etapa de beta-testes devem avaliar o tempo de resposta do sistema no mnimo como satisfatrio.

114

Requisitos no funcionais X casos de uso

Requisitos no funcionais podem estar:
Associados a um caso de uso especfico Associados a todo o sistema

Para serem atendidos podem gerar novos casos de uso

115

Requisitos no funcionais X casos de uso (exemplos)

Requisitos no funcional genrico:
O sistema deve ser implementado na plataforma XXXX.

Requisito no funcional associado a um caso de uso:

No caso de uso Sacar dinheiro, o tempo de resposta para o cliente no pode ser maior que 1 minuto.
116