Engenharia de Software 3. Engenharia de Requisitos Nuno Miguel Gil Fonseca nuno.fonseca@estgoh.ipc.pt
Fases do desenvolvimento de software que mais erros originam (fonte: "Software Testing", Ron Patton) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 2
Custo da correcção de erros (fonte: "Software Project Survival Guide", Steve McConnell) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 3
Mas afinal o que são os requisitos? descrições de como o sistema se deve comportar descrições de propriedades do sistema descrições de restrições do sistema ou condicionantes no seu desenvolvimento descrições de capacidades que um sistema deve possuir para satisfazer uma determinada imposição descrição de capacidades que um sistema deve possuir para permitir um utilizador atingir um determinado objectivo (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 4
Mas afinal o que são os requisitos? Exemplos deverá existir sempre uma fotografia associada a cada docente o sistema deve respeitar as normas de acessibilidade da W3C o sistema deve ser compatível com o IE6 os dados dos clientes deverão ser guardados numa base de dados e as passwords deverão ser encriptadas o sistema deverá permitir editar a ficha pessoal do cliente (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 5
Mas afinal o que são os requisitos? Os requisitos devem incidir sobre o que é para fazer A forma como isso será feito será tratada posteriormente (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 6
Mas afinal o que são os requisitos? Requisitos funcionais Descrevem o que o sistema deve fazer Contexto do sistema Reacção a estímulos externos Estados do sistema Informação manipulada pelo sistema... Ex.: o sistema deve permitir adicionar utilizadores Requisitos funcionais podem ser descritos por Diagramas de Casos de Uso UML ou textualmente (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 7
Mas afinal o que são os requisitos? Requisitos não-funcionais Descrevem as restrições na implementação dos requisitos funcionais Usabilidade Desempenho Fiabilidade Disponibilidade Segurança Portabilidade Tecnologia de implementação Ambiente físico da instalação Ex.: "o sistema operativo a usar deve ser linux" Requisitos não funcionais são descritos textualmente. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 8
Mas afinal o que são os requisitos? Requisitos de desenvolvimento Descrevem restrições ao processo de desenvolvimento do sistema e não são perceptíveis pelos utilizadores Manutenção Evolução Documentação Processo Orçamento Recursos humanos Recursos computacionais Requisitos de desenvolvimento são descritos textualmente. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 9
Mas afinal o que são os requisitos? Documentos envolvidos Definição de Requisitos contém uma lista de tudo o que o cliente espera que o sistema faça. Define um entendimento entre o cliente e a equipa de desenvolvimento sobre o que é que o sistema deve fazer. É escrito pelos clientes e os analistas de requisitos. Especificação de Requisitos descrição do documento de definição de requisitos em termos técnicos mais apropriados à equipa de desenvolvimento e às actividades de desenho. É escrito pelos analistas de requisitos. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 10
Mas afinal o que são os requisitos? Principais atributos dos requisitos prioridade esforço risco Por vezes também é possível prever duração custo (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 11
Mas afinal o que são os requisitos? Níveis dos requisitos Alto nível Missões Objectivos Regras do negócio Baixo nível Necessidades dos utilizadores Funcionalidades Restrições (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 12
Engenharia de requisitos? Consiste do conjunto de actividades envolvidas no processo de criação de um documento de requisitos Fase 1: descobrir, obter, analisar Fase 2: especificar, documentar Fase 3: verificar, gerir, manter Implica a utilização de um conjunto de técnicas e modelos que tornam sistemática e repetitiva a execução destas tarefas (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 13
Pessoas envolvidas Engenheiros de requisitos Especialistas do domínio Engenharia de requisitos Engenheiros de software Utilizadores finais Responsável pelo projecto/ Cliente (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 14
Stakeholders (pessoas a quem o sistema interessa) são as pessoas que serão afectadas pelo sistema e que têm uma influência directa ou indirecta na elaboração dos requisitos os stakeholders têm diferentes "backgrounds" e diferentes objectivos individuais e organizacionais os interesses individuais e de grupo das pessoas envolvidas influenciam o processo de ER (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 15
Engenharia de requisitos? Normas da organização Necessidades dos utilizadores Sistemas legado Regulamentos Informação do domínio Processo de Engenharia de Requisistos Especificação do sistema Requisitos (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 16
Fases do processo de recolha de requisitos recolha necessidades dos utilizadores, sistemas legados, informação do domínio, normas organizacionais, etc. análise documentação validação manutenção documento de requisitos (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 17
Levantamento vs Desenvolvimento de requisitos Levantamento utilizadores finais gestores analistas clientes documento de requisitos fornecedores (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 18
Levantamento vs Desenvolvimento de requisitos Desenvolvimento utilizadores finais gestores negociação clientes analistas documento de requisitos fornecedores (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 19
Levantamento vs Desenvolvimento de requisitos Os requisitos não são algo que esteja à espera de ver levantado Um documento de requisitos deve resultar de um processo de negociação e aprendizagem envolvendo todas as partes No entanto nem sempre é assim! E por vezes os requisitos têm mesmo que ser pescados! (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 20
Em que momento deve terminar o processo de recolha de requisitos Quando ambas as partes assim o entenderem Nunca será possível prever à partida todas as situações possíveis, pelo que a negociação entre analistas e clientes deverá manter-se No documento de requisitos deverá estar sempre explicito quais os requisitos validados pelo cliente Não deverá nunca ser o programador a tomar decisões sobre o que deve ou não ser feito (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 21
Pode dizer-se que um documento de requisitos está fechado? Não! Porque vão sempre surgindo propostas de alterações O que não implica que todas essas propostas sejam aceites É necessário negociar em três frentes: âmbito, duração e custo Em algumas situações, a aceitação dessas alterações implica o pagamento de quantias adicionais (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 22
Um documento de requisitos aceite pelo cliente representa sem dúvidas as suas necessidades? Nem sempre! Por vezes o cliente não percebe o que é um documento de requisitos Outras vezes o cliente não sabe exactamente o que quer Por vezes ajuda utilizar maquetas, protótipos, storyboards, etc. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 23
Um documento de requisitos aceite pelo cliente representa sem dúvidas as suas necessidades? É fundamental manter diálogo constante com o cliente Não basta conduzir actividades de verificação garantir que o produto está conforme os requisitos documentados é necessário também conduzir actividades de validação garantir que o produto satisfaz as necessidades do cliente O objecto último deve ser satisfazer o cliente e não cumprir requisitos! (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 24
É certo que um cliente aceita um produto que cumpra com os requisitos? Pode não acontecer! Para que tal aconteça é importante: Evitar ambiguidades nos requisitos Quantificar e identificar requisitos não funcionais Acordar à partida os critérios e testes de aceitação Se os requisitos documentados e os testes de aceitação acordados não traduzirem realmente as necessidades do cliente, pouco há a fazer... (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 25
Gestão de requisitos Os requisitos mudam durante e depois do desenvolvimento Principais causas Novas necessidades de clientes e utilizadores Mudanças na tecnologia utilizada Mudanças em leis, normas ou padrões Etc As mudanças nos requisitos podem causar impacto nos requisitos relacionados As técnicas de gestão visam identificar e controlar estas mudanças (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 26
Métodos de recolha de requisitos Fase exploratória e de contacto com a realidade Análise documental Observação Fase incisiva de compreensão profunda das práticas correntes Entrevistas Questionários (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 27
Métodos de recolha de requisitos Análise documental Estudar a documentação da empresa de forma a descobrir os aspectos mais significativos formalizados, políticas, regras, directivas e indicações relevantes, assim como exemplos concretos da utilização dos dados e da informação na empresa. Desta forma o analista obtém a competência necessária para dialogar com os elementos da área em análise. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 28
Métodos de recolha de requisitos Observação Observar as pessoas no desempenho das sua funções, acompanhando a execução dos processos, determinando as interfaces entre processos, o manuseamento dos dados e levantando as necessidades de informação que estas tem para executar bem o seu trabalho. Desta forma o analista detalha a informação anteriormente obtida na análise documental. Tentar apanhar incongruências. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 29
Métodos de recolha de requisitos Entrevistas Entrevistar utilizadores chave com grandes conhecimentos e experiência sobre as operações e aspectos do sistema actual, assim como da necessidade de sistemas futuros com base em actividades organizacionais em desenvolvimento. Obter a visão de todos os interessados na empresa (operacionais, gestores intermédios, gestão topo, clientes do grupo e externos). (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 30
Métodos de recolha de requisitos Questionários Questionar as pessoas para obter a clarificação das opções correctas do sistema, assim como aspectos que exijam a quantificação, a ordenação por prioridades, a selecção de procedimentos, a decisão, etc. Essencial para obter a aprovação dos utilizadores. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 31
E quando uma empresa pretende desenvolver um produto para um mercado, e não um produto à medida para um cliente específico? Análise do domínio e de pontos de variabilidade no domínio é fundamental (engenharia do domínio) Normalmente começa-se com clientes concretos e depois generaliza-se para um mercado Pode-se desenvolver um produto genérico, altamente configurável, ou uma família de produtos, com base em componentes comuns (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 32
Qualidade dos requisitos Coerência não devem ser ambíguos ou incoerentes Completude todos os estados possíveis, alterações de estados, entradas, etc, devem ser descritos Realismo o que é pedido pelo cliente deve ser realizável Clareza a descrição dos requisitos deve ser simples e clara para os utilizadores (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 33
Qualidade dos requisitos Validade o requisito deve descrever algo que é de facto relativo ao problema Certificação deve ser possível escrever testes que demonstram que o requisito foi satisfeito Rastreabilidade deve ser possível relacionar o requisito com a solução e também saber qual é a origem do requisito (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 34
Documentação de requisitos Linguagem É uma das formas mais comuns de documentar os requisitos. Consiste basicamente de uma lista numerada dos requisitos [R1] - o sistema deve fazer isto, [R2] - o sistema deve fazer aquilo Caso de Uso É igualmente uma forma muito comum de representar os requisitos. Neste caso utiliza-se uma representação gráfica (linguagem UML). Faz isto Faz aquilo (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 35
Documentação de requisitos Protótipos Consiste na elaboração de protótipos visuais que representem exactamente o que o cliente quer. São geralmente utilizados como complemento de outros métodos Poderão ser feitos protótipos descartáveis (imagens, RAD, etc.) ou evolutivos User Stories Consiste na escrita de todos os passos que o utilizador faz para executar uma determinada operação. Para criar uma nova conta o utilizador pressiona o botão new, em seguida preenche os campos de formulário, nome, morada,., posteriormente o utilizador escolhe um ficheiro de fotografia, para tal pressiona o botão procurar e escolhe a localização do ficheiro. Finalmente pressiona o botão guardar. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 36
Documentação de requisitos Rich pictures Permitem fazer uma análise do negócio ao nível de abstracção dos clientes e utilizadores Ideal para fazer a ponte entre negócio e requisitos facilita a interacção e a comunicação entre os clientes e a equipa Devem-se captar as tensões entre os intervenientes (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 37