UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

Transcrição

1 UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013.

2 Revisão aula anterior Documento de Requisitos Estrutura Padrões Template

3 Descoberta de Requisitos É o processo de reunir informações sobre o sistema requerido e os sistemas existentes e separar dessas informações os requisitos de usuário e de sistema Fontes de informações -> Stakeholders A iteração varia de usuário finais passando pelos gerentes do sistema até a órgão reguladores externos Normalmente existem uma variedade de stakeholders

4 Stakeholders no MHC-PMS Os pacientes cujas informações estão registradas no sistema Os médicos responsáveis pela avaliação e tratamento dos pacientes Os enfermeiros que, alinhados, com os médicos, coordenam as consultas e administram tratamentos As (os) recepcionistas dos médicos, que gerenciam as consultas dos pacientes A equipe de TI, responsável pela instalação e manutenção do sistema Um gerente de ética medica, que deve garantir que o sistema atenda às diretrizes éticas atuais no atendimento ao paciente Gerentes de saúde, que obtêm informações de gerenciamento a partir do sistema A equipe de registros médicos, responsável por garantir que as informações do sistema sejam mantidas e preservadas, e que os procedimentos de manutenção dos registros sejam devidamente implementados

5 Entrevista Entrevistas formais ou informais com os stakeholders do sistema são parte da maioria dos processos de engenharia de requisitos Tipos de Entrevistas Entrevistas fechadas Em que o stakeholder responde a conjunto predefinido de perguntas Entrevistas abertas Em que não existe uma agenda predefinida

6 Entrevistas na prática Na prática, as entrevistas costumam ser um mistura de ambos os tipos Entrevistas são boas para: Obter uma compreensão global sobre o que os stakeholders fazem Como eles podem interagir com o novo sistema Quais as dificuldades que eles enfrentam com os sistemas atuais Entrevistas não são boas para: Entender os requisitos de domínio da aplicação Engenheiros de requisitos não pode entender a terminologia de domínio específico Algum conhecimento de domínio é tão familiar que as pessoas acham difícil articular ou pensar que não vale a pena articular Conhecimento das restrições organizacionais

7 Entrevista eficazes Dicas para entrevistas eficazes Seja aberto a novas idéias Evite idéias preconcebidas sobre os requisitos Esteja disposto a ouvir os stakeholders Estimule a discussão Com uma questão chave, Uma proposta de requisitos ou Trabalhando em conjunto em um protótipo do sistema

8 Cenários Cenários são exemplos reais de como um sistema pode ser usado Eles podem incluir: Uma descrição do que o sistema e os usuários esperam quando o cenário se iniciar Uma descrição do fluxo normal de eventos no cenário Uma descrição do que pode dar errado e como isso será tratado Informações sobre outras atividades simultâneas Uma descrição do estado do sistema quando o cenário termina

9 Cenário para a coleta do histórico medico em MHC-PMS Situação Inicial O paciente é atendido em uma clinica medica por uma recepcionista; ela gera um registro no sistema e coleta suas informações pessoais (nome, endereço, idade, etc.). Uma enfermeira é conectada ao sistema e coleta o histórico medico do paciente. Normal A enfermeira busca o paciente pelo sobrenome. Se houver mais de um paciente com o mesmo sobrenome, o nome e a data de nascimento são usados para identificar o paciente A enfermeira escolhe a opção menu para adicionar o histórico medico A enfermeira segue, então, uma série de prompts do sistema para inserir informações sobre consultas em outros locais, os problemas de saúde mental (entrada de texto livre), condições medicas (enfermeira seleciona condições no menu), medição atual (selecionado no menu), alergias (texto livre) e informações da vida doméstica (formulário)

10 Cenário para a coleta do histórico medico em MHC-PMS O que pode ser errado O prontuário do paciente não existe ou não pode ser encontrado. A enfermeira deve criar um novo registro e registrar as informações pessoais As condições do paciente ou a medicação em uso não são inscritas no menu. A enfermeira deve escolher a opção outros e inserir texto livre com descrição da condição/medicação O paciente não pode/não fornecerá informações sobre seu histórico medico. A enfermeira deve inserir um texto livro registrando a incapacidade/relutância do paciente em fornecer as informações. O sistema deve imprimir o formulário padrão de exclusão afirmando que a falta de informações pode significar que o tratamento será limitado ou postergado. Este deverá ser assinado e entregue ao cliente Outras Atividades Enquanto a informação está sendo inserida, o registro pode ser consultado, mas não editado por outros agentes Estado do sistema na conclusão O usuário esta conectado. O prontuário do paciente, incluindo seu histórico medico, é inserido no banco de dados e um registro é adicionado ao log do sistema, mostrando o tempo de início e fim da sessão e a enfermeira envolvida

11 Casos de Uso São uma técnica de descoberta de requisitos baseada em cenários UML (Unified Modeling Language) Em sua forma mais simples, um caso de uso identifica os atores envolvidos em uma interação e dá nome ao tipo de interação O conjunto de casos de uso representam todas as possíveis interações que serão descritas no requisitos de sistema Os casos de uso são documentados por diagramas de caso de uso de alto nível Modelo gráfico complementada pela descrição mais detalhada Diagramas de seqüência podem ser usados para adicionar detalhes a casos de uso, mostrando a seqüência de processamento de eventos no sistema.

12 Casos de uso para o MHC-PMS

13 Etnografia Técnica onde o cientista social gasta um tempo considerável observando e analisando como as pessoas realmente trabalham As pessoas não têm de explicar ou articular o seu trabalho Podem ser observados fatores sociais e organizacionais de importância Estudos etnográficos têm mostrado que o trabalho é geralmente mais rico e complexo do que o sugerido por modelos de sistemas simples Pode ser aplicado na fase da descoberta de requisitos

14 Escopo da Etnografia Requisitos que são derivados da maneira que as pessoas realmente trabalham e não da forma como as definições dizem que devem trabalhar Requisitos que são derivados da cooperação e conscientização das atividades de outras pessoas Consciência de que outras pessoas estão fazendo leva a mudanças nas formas em que fazemos as coisas Etnografia é eficaz para o entendimento dos processos existentes, mas não pode identificar novos recursos que devem ser adicionados ao sistema

15 Etnografia focada A etnografia pode ser combinada com prototipação A etnografia informa o desenvolvimento do protótipo, para que menos ciclos de refinamento sejam necessários Questões e problemas identificados podem ser discutidos com etnógrafo Esse profissional deve procurar as respostas para essas perguntas durante a próxima fase do estudo do sistema Esse desenvolvimento com protótipo resulta em questões não respondidas com o foco na analisa da etnografia

16 Etnografia e prototipação para análise de requisitos

17 Problemas da Etnografia Estudos etnográficos podem revelar detalhes críticos de processos que, muitas vezes, são ignorados por outras técnicas de elicitação de requisitos Contudo, uma vez que o foco é no usuário final, essa abordagem não é apropriada para descobrir requisitos organizacionais ou de domínio A etnografia não é uma abordagem completa e deve ser usada apenas como complemento para outras abordagens

18 Validação de Requisitos É o processo pelo qual se verifica se os requisitos definem o sistema que o cliente realmente quer A validação de requisitos é importante porque erros em um documento de requisitos podem trazer diversos problemas O custo para consertar um problema por meio de uma mudança é geralmente muito maior que o custo de consertar erros de projeto ou de codificação

19 Verificação de Requisitos Validade O sistema fornece as funções que melhor suportam as necessidades do cliente? Consistência Há algum conflito requisitos? Integralidade São todas as funções exigidas pelo cliente incluído? Realismo Os requisitos podem ser implementados com o orçamento disponível e tecnologia? Verificabilidade Podem ser verificados os requisitos?

20 Técnicas de Verificação de Requisitos Revisão de requisitos Análise manual sistemática dos requisitos Prototipagem Usando um modelo executável do sistema para verificar os requisitos Geração de casos de teste Desenvolvimento de testes para verificar os requisitos

21 Revisão de Requisitos Revisões periódicas devem ser realizadas enquanto a definição de requisitos está sendo formulada Cliente e funcionários contratante deve estar envolvido em comentários Comentários podem ser formais (com documentos completos) ou informal Boa comunicação entre desenvolvedores, clientes e usuários podem resolver problemas em um estágio inicial

22 Verificações de Revisão Verificabilidade O requisito é realisticamente testável? Compreensibilidade O requisito é adequadamente compreendido? Rastreabilidade A origem do requisito é claramente declarada? Adaptabilidade O requisito pode ser alterado sem um grande impacto em outros requisitos?

23 Gerenciamento de Requisitos O gerenciamento de requisitos é o processo de gerenciamento de mudanças de requisitos durante o processo de engenharia de requisitos e desenvolvimento de sistemas Novos requisitos emergem quando o sistema está sendo desenvolvido e depois de ter entrado em uso Você precisa manter o controle das necessidades individuais e manter ligações entre os requisitos dependentes para que você possa avaliar o impacto das mudanças de requisitos. Você precisa estabelecer um processo formal de elaboração de propostas de mudança e ligando os requisitos de sistema para.

24 Mudança de Requisitos O ambiente empresarial e ambiente técnico do sistema sempre muda após a instalação Um novo hardware pode ser introduzido Pode ser necessário uma interface do sistema com outros sistemas As prioridades de negócios pode mudar (com conseqüentes alterações no sistema de apoio necessário) Uma nova legislação e os regulamentos podem ser As pessoas que pagam por um sistema e os usuários desse sistema raramente são as mesmas pessoas Os clientes do sistema impõem requisitos devido a restrições orçamentais e organizacionais Estes podem entrar em conflito com os requisitos do usuário final e, após a entrega, os novos recursos podem ter que ser adicionado para suporte ao usuário se o sistema está a cumprir os seus objetivos Sistemas de grande porte geralmente têm uma comunidade de usuários diversificada, com muitos usuários com diferentes necessidades e prioridades que podem ser conflitantes ou contraditórias Os requisitos finais do sistema são inevitavelmente um compromisso entre eles e, com a experiência, isto é muitas vezes descoberto que o equilíbrio de apoio dado a diferentes utilizadores tem que ser mudado.

25 Evolução dos requisitos

26 Planejamento de gerenciamento de requisitos Determina o nível de detalhamento requerido no gerenciamento de requisitos Decisões de gerenciamento de requisitos: Identificação de requisitos Cada requisitos requisito deve ser unicamente identificado para poder ser comparado com outros requisitos e usados em avaliações de rastreabilidade Processo de gerenciamento de mudança É o conjunto de atividades que avaliam o impacto e o custo das mudanças. Políticas de rastreabilidade Definem os relacionamentos entre cada requisito e entre os requisitos e o projeto de sistema que devem ser registrados Ferramenta de apoio Gerenciamento de requisitos envolve o processamento de grandes quantidades de informações sobre os requisitos por isso se usa alguma ferramenta de apoio Essa ferramenta varia de um sistema especializado em gerenciamento de requisitos até planilhas eletrônicas e sistemas de banco de dados simples

27 Gerenciamento de mudança de requisitos Decide se uma mudança de requisitos devem ser aceita Existem três estágios principais em um processo de gerenciamento de mudanças: Análise do problema e especificação de mudanças Durante esta fase, o problema ou a proposta de mudança é analisado para verificar se ele é válido. Esta análise é transmitida a quem solicitou a mudança, que pode responder com uma proposta mais especifica de mudança de requisitos ou retirar a solicitação Análise de mudanças e custos O efeito da mudança proposta é avaliada através de informações de rastreabilidade e conhecimento geral dos requisitos do sistema. O custo dessa mudança é estimado e, uma vez que esta análise é concluída, é tomada uma decisão se deve ou não prosseguir com a mudança de requisitos Implementação de mudança O documento de requisitos e, se necessário, o projeto e implementação do sistema, são modificados. Idealmente, o documento deve ser organizado de modo que as mudanças podem ser facilmente implementadas.

28 Gerenciamento de mudança nos requisitos

29 Resumo Pode-se usar uma variedade de técnicas de elicitação de requisitos, incluindo entrevistas, cenários, casos de uso e etnografia A validação de requisitos é o processo de verificação dos requisitos de validade, consistência, integridade, realismo e verificabilidade Mudanças de negócios, ambiente técnico e organizacionais são inevitáveis, portanto, mudanças nos requisitos. O gerenciamento de requisitos é o processo de gestão e controle dessas mudanças

30 Referências Engenharia de Software 9º Edição. Sommerville, I. Editora Persson. Capítulo 4