[inap] Requisitos

Levantamento de Requisitos
 Entrevistas
 Workshop de requisitos
 Brainstorm
 Storyboards
 Casos de uso
 Role playing
 Prototipagem
Levantamento de Requisitos (Entrevista)
 Técnica simples e direta
 Questões livres de contexto podem ajudar no alcance de entrevistas não-tendenciosas
 Quem são os usuários?
 Quem são os clientes?
 As necessidades deles são diferentes?
 Onde a solução desse problema pode ser encontrada?
 Resultado: repositório de requisitos
 Questionário não substitui uma entrevista.
 Gerente:
 Qual é sua visão do problema?
 Quais são as mudanças desejadas com a solução do problema?
 Em que ambiente essa solução deverá funcionar?
 Qual é a abrangência geográfica e número de usuários que estarão utilizando a solução?
 Como é o parque tecnológico existente (Servidores, Desktops, Topologia da Rede, Internet)?
 Gerente:
 Quais são os ambientes existentes na empresa (Desenvolvimento, Testes, Produção, etc...);
 Como serão as integrações entre os sistemas?
 Haverá migração de dados ? Em que estrutura estão esses dados?
 Existe alguma padronização a ser seguida e/ou algum artefato de sua metodologia que deverá ser gerado e entregue?
Como está estruturada a equipe de TI?
 Usuário:
 Qual é sua visão do problema?
 Quais são as mudanças desejadas com a solução do problema?
 Que facilidades você espera do sistema?
 Qual informação do negócio é a mais difícil de processar (trabalho braçal, formato do dado, baixa navegabilidade em sistemas existentes)?
 Quais são as macro funcionalidades necessárias para os sistema?
 Usuário:
 Quais são as pessoas que se relacionam com o sistema?
 Como são as telas imaginadas para o sistema (esboços de telas)?
 Quais são as importações e exportações de dados necessárias para o funcionamento do sistema (detalhar layout dos arquivos / fontes de dados)?
 Outros
 Manutenções:
 Quais são as dificuldades de manutenção do sistema?
 Qual é a qualidade das estruturas do banco de dados?
 Qual é a qualidade do código fonte do aplicativo?
 A documentação do sistema é suficiente e compreensível?
 Como é a demanda (freqüência) de manutenção (corretiva, melhorias, legal)?
 Quais são os pontos de “gargalo” do sistema atual
Levantamento de Requisitos (Brainstorm)
 É uma técnica em que as pessoas colocam tudo que vier na cabeça com relação ao projeto.
 Muito útil quando existem diversos interessados no projeto.
 É dividido em duas etapas.
 Na primeira, anota-se todas as idéias que surgirem, sem que sejam questionadas. Neste momento o que importa mais é a quantidade, não deixe de anotar nada.
 Na segunda etapa, debate-se com o grupo para ir refinando as idéias apresentadas anteriormente. Deixe as regras bem claras, e defina uma pessoa (facilitador) para “comandar” a reunião, para garantir que as regras sejam respeitadas.
 Pode ser efetiva no desenvolvimento de um novo projeto, na fase inicial, para identificar requisitos de alto nível, aqueles mais macros.
Levantamento de Requisitos (Storyboarding)
 Corresponde a qualquer técnica que expressa o comportamento do sistema, projeto ou intenção de implementação pela perspectiva do usuário. Esta técnica foi utilizada inicialmente no cinema e desenhos animados, representando um esboço dos personagens e da história.
Levantamento de Requisitos (Casos de Uso)
 Descreve a funcionalidade proposta para o novo sistema.
 Representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema.
 É uma unidade de um trabalho significante.
 Ex: o "login para o sistema", "registrar no sistema" e "criar pedidos".
 Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no sistema proposto.
 Um Caso de Uso pode "incluir" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento.
 Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho.
Levantamento de Requisitos (Role Playing)
 Esta técnica consiste em observar o usuário executando determinada tarefa, no dia-a-dia do seu trabalho, ou, até mesmo, você fazendo o trabalho deste usuário, para identificar suas dificuldades e necessidades, sentindo na pele como é realizar a tarefa.
 Muito útil quando o usuário não consegue identificar ou transmitir as informações necessárias para a identificação dos requisitos.
Levantamento de Requisitos (Prototipagem)
 Criação, apresentação e debate de modelos de interação não funcionais que ajudem a ilustrar como o sistema deverá se comportar, permitindo assim obter feedback mais detalhado dos stakeholders sobre o sistema.
 É a atividade de desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos, permitindo a descoberta de falhas difíceis de serem encontradas na comunicação verbal.
 Um processo que propõe a criação de um protótipo de software objetiva apoiar a fase levantamento de requisitos a fim de prevenir as possíveis falhas no sistema.
 Um protótipo simula a aparência e funcionalidade do software permitindo que os clientes, analistas, desenvolvedores e gerentes percebam os requisitos do sistema podendo interagir, avaliar, alterar e aprovar as características mais marcantes na interface e funções.
 Os protótipos podem ser evolutivos ou descartáveis.
Regras de Negócio
 Estabelecem requisitos gerais para o sistema, provenientes do próprio negócio como normas, políticas, legislações etc.
 São declarações que restringem, derivam e fornecem condições de existência, representando o conhecimento do negócio.
 Ex: Toda conta de telefone atrasada mais de n dias terá seu número bloqueado para receber chamadas.
Regras de Negócios
 São políticas, condições ou restrições que devem ser consideradas na execução dos processos existentes em uma organização.
 Descrevem a maneira pela qual a organização funciona.
 Estas regras são identificadas e documentadas no chamado modelo de regras do negócio.
 A descrição do modelo de regras do negócio pode ser feita utilizando-se texto informal, ou alguma forma de estruturação.
 Alguns exemplos de regras do negócio:
 O valor total de um pedido é igual à soma dos totais dos itens do pedido acrescido de 10% de taxa de entrega.
 Um professor só pode estar lecionando disciplinas para as quais esteja habilitado.
 Regras do negócio normalmente têm influência sobre uma ou mais funcionalidades.
Nome
Quantidade de inscrições possíveis Descrição
Um aluno não pode ser inscrever em mais de seis disciplinas por semestre letivo. Fonte
Coordenador da escola de informática Histórico
Data de identificação: 16/04/2006
Revisão - Passos de Requisitos
 Levantar os requisitos do sistema através de entrevistas com representantes do usuário gestor e usuários finais, e registrá-los no Documento de Requisitos do Sistema
 Atualizar o Glossário do projeto com novos termos identificados durante o levantamento de requisitos
 Priorizar os requisitos levantados, em conjunto com o responsável por sua definição, como: essencial, importante ou desejado.
 Classificar os requisitos levantados como: funcionais, não-funcionais ou regras de negócio.
 Identificar, com base nos requisitos funcionais levantados, os usuários do sistema
 Identificar os relacionamentos entre usuários e funcionalidades, representando-os através de um Diagrama de Casos de Uso inicial.
 Revisar, junto aos representantes do usuário gestor e de usuários finais, o Documento de Requisitos do Sistema.