3 Requisitos de alto nível

•Atores de sistema

•Casos de uso de sistema

•Como encontrar casos de uso de sistema no modelo de negócio

•Requisitos

•Modelo conceitual preliminar

3.1 Introdução aos requisitos de alto nível

• Casos de uso de sistema em alto nível ou resumido

= requisitos funcionais de alto nível.

• Anotações nos casos de uso

= requisitos não funcionais.

• Especificações suplementares

= requisitos suplementares

Utilidade dos casos de uso de sistema

• Definição e validação da arquitetura do sistema

• Criação de casos de teste

• Planejamento de iterações

• Base para documentação do usuário

3.2 Atores de sistema

• Entidade do mundo real que interage com o sistema por meio de um caso de uso.

• Tipos:

– Humano

– Sistema

Sistemas atores

• São sistemas de informação completos.

• Não são módulos ou partes do sistema sendo desenvolvido.

3.3 Casos de uso de sistemaCaso de uso de negócio Caso de uso de sistema

Processos da organização Processos de uso de um sistemaa ser informatizado

Duram dias ou semanas Duram segundos ou minutos

Pode ser interrompido e reiniciado

Deve ser executado como uma transação ininterrupta

Vários atores humanos primários Usualmente um ator humano primário e eventualmente alguns secundários

Exemplo

Características de casos de uso de sistema como requisitos de alto nível...

• Sessão indivisível

• Interativo

• Resultado consistente

• Essencial

• Alto nível

• Fronteira de sistema definida

3.3.1 Sessão indivisível• Deve iniciar e terminar sem sofrer

interrupção.

• EBP (Elementary Business Process – Processo Elementar de Negócio.

Porém, isso está correto

3.3.2 Interativo

• Deve existir um ator para interagir com o sistema.

• Processos internos do sistema não são casos de uso, não importa quão complexos sejam.

3.3.3 Resultado consistente

• Produz uma alteração de estado consistente e completa na informação.

• Apresenta uma informação completa que tenha significado como objetivo de negócio para algum ator.

Por isso

3.3.4 Essencial

• Essencial: seu detalhamento independe da tecnologia usada.

• Real ou concreto: é pensado para uma tecnologia específica de interfaceamento.

Modelos essenciais

• São mais flexíveis, deixando mais opções em aberto.

• São mais capazes de acomodar mudanças na tecnologia.

• São mais robustos do que as representações concretas porque mais provavelmente permanecerão validos caso haja alguma mudança na tecnologia de implementação.

3.3.5 Alto nível

• Sua descrição se dá apenas pelo seu nome.

3.3.6 Fronteira do sistema

• Representa os limites do sistema computacional.

3.4 Como encontrar casos de uso de sistema no modelo de negócio

• Candidatos a atores de sistema no modelo de negócio:

Diagramas de atividades podem indicar casos de uso de sistema

Pontos a serem observados

• Atividades que necessariamente são executadas em sequencia pertencem ao mesmo caso de uso de sistema.

• Se uma atividade não precisa iniciar imediatamente após outra então elas pertencem a casos de uso de sistema diferentes.

• Se o papel do ator vai ser automatizado, então suas atividades passam a ser processos internos do sistema.

Transições de estado em diagramas de máquina de estado são casos de uso de sistema potenciais

Resultado

Atividade 4

• Identifique atores e casos de uso de sistema a partir do modelo de casos de uso de negócio, diagrama de atividades e diagrama de máquina de estados.

3.5 Requisitos

• Identificar casos de uso de sistema é a principal atividade da disciplina de “requisitos” do UP.

3.5.1 Eliciação de requisitos

• Casos de uso = requisitos funcionais

• Anotações = requisitos não funcionais

– Regras de negócio

– Requisitos de qualidade

Anotações no diagrama

Anotações no caso de uso (só com ferramenta CASE)

3.5.2 Eliciar requisitos não é design!

• Princípio da psicanálise

3.5.3 Desafio dos requisitos

• Descobrir

• Comunicar

• Lembrar

• Gerenciar mudança

3.5.4 Requisitos funcionais evidentes e ocultos

• Evidente: usuário está ciente da ação.

• Oculto: interno ao sistema.

3.5.5 Requisitos não funcionais

• Restrições lógicas:

– Regras de negócio – restrições sobre as funções.

• Restrições tecnológicas:

– Questões de qualidade – eficiência, usabilidade, acessibilidade, segurança, etc.

• Um requisito não especifica como a restrição vai ser implementada, ele apenas a exige.

3.5.6 Requisitos não funcionais permanentes e transitórios

• É uma decisão sobre a qualidade da adaptabilidade.

• Permanente:

– Mais barato implementar, mais caro manter.

• Transitório:

– Mais caro implementar, mais barato manter.

3.5.7 Requisitos obrigatórios e desejáveis

• No caso dos funcionais, define prioridade

• No caso dos não funcionais, flexibiliza restrições.

• Escala MoSCoW:

– Must

– Should

– Could

– Would

3.5.8 Requisitos suplementares

• São qualidades gerais do sistema

• Modelos:

– FURPS+

• Funcionalidade, usabilidade, confiabilidade, performance, suportabilidade.

– ISO 25010

• 13 características subdivididas em 42 subcaracterísticas.

Exemplo 25010

Aplicação do exemplo a Livir

3.6 Modelo conceitual preliminar

• Apoio ao levantamento de requisitos.

• Modelo de classes simplificado (apenas nomes das classes e associações simples).

• Extraído a partir dos nomes dos casos de uso de sistema.

Para ajudar a saber se CRUDs devem ser definidos:

• Para cada conceito do modelo preliminar verifique se existem operações que criam (alteram e deletam, se for o caso) e consultam os dados representados pelo conceito.

• Se faltar alguma é sinal de que pode ser necessário um novo caso de uso.

• Se o conceito for simples (independente) pode ser o caso de criar um caso de uso CRUD.

Resultado

Por fim, verificar se existem relatórios necessários mas não cobertos por nenhum caso de uso

3.7 O processo visto aqui

Atividade 5 (se o tempo permitir)

• Elabore um modelo conceitual preliminar baseado no diagrama de casos de uso de sistema.

• Identifique novos casos de uso (possivelmente CRUD) para conceitos que não são suficientemente tratados pelos casos de uso existentes no modelo atual.