Especificação de requisitos

Prévia do material em texto

ESPECIFICAÇÃO DE REQUISITOS
Descrição do fluxo e estrutura da informação
Refinamento detalhado de todas as funções
Estabelecimento das características das interfaces.
Foco em “o que” o sistema deverá contemplar, não em “como”.
Detalhamento das restrições.(funcionais ou não funcionais)
Especificação dos critérios de validação.
Validação dos requisitos com o cliente.
Levantamento de requisitos
Conhecer o problema e alternativas para solução.
Exemplo de como não deve acontecer...
“Eu vou subir e ver o que eles querem o resto de vocês comecem a codificar.”
Habilidades de um analista:
Compreende conceitos abstratos.
Capacidade de sintetizar “soluções”.
Visualizar fatos em fontes conflitantes ou confusas.
Entender o ambiente do usuário.
Boa comunicação verbal e escrita.
Levantamento de dados:
Elaborar uma lista de desejos dos usuários,
Priorizar os requisitos coletados.
Conhecer detalhadamente as regras de negócios
Escolher os envolvidos de acordo com escopo do projeto
Sintetizar o problema.
Revisar e validar requisitos.
Certificar-se de que está executando o levantamento com a pessoa certa (é oficial?).
Conhecer restrições que impedem soluções do problema (performance, escalabilidades, portabilidade, etc).
Conhecimento e não de invenção.
Stakeholders
O termo stakeholder é utilizado para se referir a qualquer pessoa que terá alguma influência direta ou indireta sobre os requisitos do sistema. (SOMMERVILLE, 2003)
Os stakeholders frequentemente não sabem na realidade o que querem do sistema computacional, a não ser em termos muito gerais; eles podem achar difícil articular o que desejam do sistema; eles podem fazer pedidos não realistas, por não terem noção do custo de suas solicitações.
Os stakeholders em um sistema expressam naturalmente os requisitos em seus próprios termos e como o conhecimento implícito de sua área de atuação. Os engenheiros de requisitos (analistas) que não tem experiência no domínio do cliente devem compreender esses requisitos.
Diferentes stakeholders tem em mente diferentes requisitos e podem expressá-los de maneiras distintas. Os engenheiros de requisitos (analistas) precisam descobrir todas as possíveis fontes de requisitos e encontrar os pontos comuns e os conflitos.
Fatores políticos podem influenciar os requisitos do sistema. Eles podem provir de gerentes que definem requisitos específicos de sistema para aumentar sua influência na organização.
O ambiente econômico e de negócio, no qual a analise de requisitos ocorre, é dinâmico. Inevitavelmente, ele se modifica durante o processo de análise. Como consequência, a importância dos requisitos pode mudar. Novos requisitos podem surgir por parte dos novos stakeholders, que não haviam sido consultados inicialmente.
Métodos para levantamento de requisitos
Reunião Rápida
Facilitaded Application Specification Techniques.
Conhecida como JAD (Joint Application Development).
Reunião em local neutro.
Participação dos Analistas de sistemas e do Cliente.
Deve ser elaborada uma agenda dos pontos mais importantes.
Um moderador é designado para controlar a reunião.
Um mecanismo é definido (planilha, flip-chart, data show, etc).
Relacionar as possíveis soluções para o problema.
Workshop
Preparação do workshop.
Conduzir a sessão.
Encontros nos quais o analista expõe uma tecnologia ou cenário.
Os participantes devem conhecer e dar sugestões.
Consolidar resultados.
Brainstorming
Definir o objetivo do encontro.
Gerar o maior número de ideias para o assunto.
Não permitir críticas ou debates.
Reunir e combinar as ideias.
Todos devem expressar seu voto.
Priorizar cada ideia por categoria.
CASO DE USO
Exemplo de caso de uso básico: (PRESSMAN, )
Iniciar monitoração:
O proprietário observa o painel de controle do CasaSegura (Sistema de segurança) para determinar se o sistema está disponível para a entrada. Se o Sistema não estiver disponível, uma mensagem “não disponível” será exibida no mostrador LCD e o proprietário deverá fechar fisicamente as janelas/portas para que a mensagem “não disponível” desapareça. (Uma mensagem “não disponível” implica que um sensor está aberto, isto é, que uma porta ou janela está aberta.)
O proprietário usa o teclado para teclar uma senha de quatro dígitos. A senha é comparada com a senha válida armazenada no sitema. Se a senha não for correta, o painel de controle emitirá um bip e preparar-se-á para uma entrada adicional. Se a senha estiver correta, o painel de controle esperará a ação subsequente.
O proprietário seleciona e tecla dentro ou fora para ativar o sistema. Dentro ativa somente os sensores periféricos (os sensores internos de detecção de movimento são desativados). Fora ativa todos os sensores.
Quando a ativação ocorre, uma luz de alarme vermelha pode ser observada pelo proprietário.
O caso de uso básico apresenta uma história de alto nível que descreve a interação entre o ator e o sistema.
Em muitas instâncias, os casos de uso são elaborados para fornecer consideravelmente mais detalhes sobre a interação. (PRESSMAN, )
Exemplo para descrição detalhada de casos de uso:
Caso de uso:	IniciarMonitoraçaõ
Ator principal:	Proprietário.
Meta no contexto: Iniciar o sistema para monitorar os sensores quando o proprietário sair de casa ou permanecer dentro dela.
Precondições:	o proprietário decide “iniciar” o sistema, isto é, ligar as funções de alarme.
Cenário:
Proprietário: observa o painel de controle.
Proprietário: introduz a senha.
Proprietário: seleciona “dentro” ou “fora”.
Proprietário: observa luz vermelha do alarme indicando que o CasaSegura foi ligado.
Exceções:
O painel de controle indica não disponível: o proprietário verifica todos os sensores para determinar quais estão abertos, fechando-os.
Senha incorreta (painel de controle soa uma vez): proprietário introduz novamente a senha correta.
Senha não reconhecida: o sistema de monitoração e resposta deve ser contatado para reprogramar a senha.
Dentro é selecionado: o painel de controle soa duas vezes e a luz dentro acende; os sensores periféricos são ativados.
Fora é selecionado: o painel de controle soa três vezes e a luz fora acende; todos os sensores são ativados.
Prioridade:	Essencial, deve ser implementada.
Quando disponível: Primeiro incremento.
Frequencia de uso: Muitas vezes por dia.
Canal para o ator: Via interface do painel de controle.
Atores secundários: Técnico de apoio, sensores.
Canais para atores secundários:
Técnico de apoio: linha telefônica.
Sensores: interfaces em hardware e sem fio.
Tópicos em aberto:
Deve haver um modo de ativar o sistema sem o uso de uma senha ou com uma senha abreviada?
O painel de controle deveria mostrar mensagens de texto adicionais?
Quanto tempo o proprietário tem para introduzir a senha a partir do momento que pressionou a primeira tecla?
Há um modo de desativar o sistema antes que ele seja realmente ativado?
Casos de uso para outras interações do proprietário seriam desenvolvidos de maneira similar. É importante notar que cada caso de uso deve ser revisado com cuidado. Se algum elemento da interação for ambíguo, é muito provável que uma revisão do caso de uso descubra o problema. (PRESSMAN,)
ORGANIZAÇÃO DOS CASOS DE USO
O diagrama de contexto fornece a principal referência para visualização dos casos de uso.
Os casos de uso geralmente possuem um fluxo principal e vários subfluxos alternativos. notações especiais são utilizadas para facilitar a descrição de funcionalidade mais complexa. Entre estas notações, destacam-se os casos de usos secundários, que simplificam o comportamento dos casos de uso primários através dos mecanismos de inclusão e extensão.
O caso de uso B estende o caso de uso A quando B representa uma situação opcional ou de exceção, que normalmente não ocorre durante a execução de A. Esta notação pode ser usada para representar fluxos alternativos ou anormais complexos. O caso de uso “estendido” é referenciado nas precondições do caso de uso “extensor”.
O relacionamento “estende”é usado para representar:
comportamento opcional;
comportamento que só ocorre sob certas condições (por exemplo, alarmes);
fluxos alternativos cuja realização depende de escolha de um ator.
O caso de uso A inclui o caso de uso B quando B representa uma atividade complexa, comum a vários casos de uso. Esta notação pode ser usada para representar subfluxos complexos e comuns a vários casos de uso. O caso de uso “incluído” é referenciado no fluxo do caso de uso “incluidor”.