Laboratório de Desenvolvimento de Software FEUP/MIEIC, 2010/11 Nuno Flores nuno.flores at fe.up.pt Rosaldo Rossetti rossetti at fe.up.pt Filipe Correia filipe.correia at fe.up.pt http://paginas.fe.up.pt/~nflores/dokuwiki/doku.php?id=teaching:1011:ldso
Fase de Especificação de Requisitos Actividades Estudo do domínio do problema Levantamento de requisitos (requirements elicitation) Análise e negociação de requisitos Especificação de casos de utilização e classes de domínio Elaboração do protótipo da interface com o utilizador Definição de testes de aceitação Resultados Relatório de especificação de requisitos (conjunto de páginas Wiki) Protótipo da interface com o utilizador Plano de testes de aceitação Deadline: 24 de Outubro de 2010 (4 semanas) Discussão e validação com o cliente (docente): semana seguinte Peso de 15%
Processo de Engenharia de Requisitos (fonte: Kotonya e Sommerville, 1998)
Algumas Leis Relevantes Lei nº 1 - Lei fundamental da Engenharia de Requisitos: Os requisitos terminam onde começa a liberdade do implementador Lei nº 2 Lei dos 3 éfes da Gestão de Prioridades 1º) Funcionalidade 2º) Fiabilidade 3º) Eficiência Lei nº 11 Princípio da incerteza no Planeamento de Projectos Não é possível fixar simultaneamente o resultado (âmbito e qualidade), custo e duração de um projecto de software.
Norma IEEE 830-1998 (IEEE Recommended Practice for Software Requirements Specifications)
Relatório de Especificação de Requisitos (1) 1. Introdução 1.1 Objectivo - Indicar o objectivo e destinatários do RER 1.2 Âmbito - Identificar o produto de software a desenvolver pelo respectivo nome - Explicar brevemente o que o produto vai fazer e, se necessário, não vai fazer - Descrever como e onde vai ser aplicado o produto, indicando benefícios relevantes e objectivos - Explicar se faz parte de um sistema mais vasto 1.3 Definições, acrónimos e abreviaturas - Definir termos, acrónimos e abreviaturas requeridos para interpretar adequadamente o RER 1.4 Referências - Listar todos os documentos referenciados no RER, indicando o seu título, identificador (se aplicável), data, organização que o publicou e fonte onde o mesmo pode ser obtido (e.g., URL) 1.5 Visão geral - Descrever sumariamente o conteúdo do resto do RER e explicar a forma como está organizado
Relatório de Especificação de Requisitos (2) 2. Descrição geral Apresentar informação de background importante para ajudar a perceber os requisitos a especificar posteriormente: 2.1 Contexto do produto - Indicar se o produto é auto-contido ou se é um componente de um sistema maior e, nesse caso, apresentar a arquitectura geral (com principais componentes, interconexões e interfaces externos) e requisitos gerais desse sistema - Indicar as várias interfaces do produto: interfaces com o utilizador, interfaces de hardware, interfaces de software (interfaces com outros produtos), interfaces de comunicação, etc. - Caracterizar o ambiente de operação do produto e eventuais restrições associadas a esse ambiente 2.2 Funções do produto - Sumariar as funções principais que o sistema vai realizar 2.3 Características dos utilizadores - Descrever as características dos utilizadores a que se destina o produto, incluindo nível de educação, experiência e conhecimentos técnicos. 2.4 Restrições - Descrição geral de quaisquer outros itens que possam limitar as opções dos developpers 2.5 Pressupostos e dependências - Por exemplo sobre o ambiente de operação do sistema
Relatório de Especificação de Requisitos (3) 3. Requisitos específicos 3.1 Requisitos de interfaces externos - Incluir as seguintes secções, se aplicáveis: - 3.1.1 Interfaces com utilizadores - 3.1.2 Interfaces de hardware - 3.1.3 Interfaces de software - 3.1.4 Interfaces de comunicação 3.2 Requisitos funcionais - User Stories e Modelo de casos de utilização 3.3 Requisitos de informação -> Modelo de domínio 3.4 Requisitos suplementares - Listar e descrever sumariamente requisitos transversais aos vários módulos do sistema ou aos vários casos de utilização deste módulo - Para cada requisitar indicar - Identificador - Descrição sumária - Prioridade (exemplo: essencial, desejável, opcional) - Referências/fontes (como se faz nos casos de utilização) - Incluem-se aqui tipicamente requisitos de qualidade do produto (usabilidade, eficiência, segurança, etc.) Apêndices Glossário definindo termos do vocabulário do domínio
Modelo de casos de utilização Objectivo: capturar requisitos funcionais, focando no valor para os utilizadores (actores) Estrutura: Visão geral - Com um ou mais diagramas de casos de utilização e uma descrição genérica que passa superficialmente pelos casos de utilização e actores mais importantes - Se existirem muitos casos de utilização, apresentar um primeiro diagrama de pacotes de casos de utilização e depois um diagrama de casos de utilização para cada pacote - Em alguns casos, pode-se mostrar o encadeamento de casos de utilização através de um ou mais diagramas de actividades (descrevendo processos de negócio em que surgem os casos de utilização) Actores - Descrever sumariamente cada um dos actores Caso de utilização - Descrevem as funcionalidades pretendidas ou requisitos funcionais - Uma secção/página para cada caso de utilização, com a sua descrição detalhada (ver adiante)
Documentação de Casos de Utilização (1) Identificador wiki name, nome curto Nome Nome longo Descrição sumária Uma ou duas frases curtas, que ficaria bem numa tabela de resumo dos casos de utilização, tornando evidente o objectivo/utilidade Actores Indicar os vários actores intervenientes e o seu papel, tornando evidente quem inicia a interacção Prioridade Indicar a prioridade do caso de utilização Exemplo: essencial, desejável, opcional
Documentação de Casos de Utilização (2) Sequência de funcionamento / Fluxo de eventos Por definição, um caso de utilização é "uma sequência de acções que...". Descrever as sequências de funcionamento normais e alternativas ou excepcionais Indicar as acções realizados pelos actores e pelo sistema Tornar evidentes os dados de entrada (introduzidos pelos actores) e de saída (fornecidos pelo sistema) Tornar evidente como é que se inicia o caso de utilização (exemplo: o caso de utilização inicia-se quando o utilizador pretende... e já fez... ) Pode-se acompanhar a descrição textual por diagramas dinâmicos (diagramas de sequência ou diagramas de actividades) para facilitar a comunicação e remover ambiguidades Interface com o utilizador Apresentar esboços ou imagens do protótipo da interface com o utilizador (ver adiante) Se se justificar (no caso de não ser óbvio), pode-se descrever o significado de cada elemento que aparece na interface (campo, botão, etc.)
Documentação de Casos de Utilização (3) Pré-condições e restrições (Preconditions) Uma pré-condição é uma restrição nos dados de entrada e estado inicial do sistema. Exemplo, no levantamento em ATM: a conta tem saldo suficiente; a máquina ATM tem stock suficiente Pós-condições (Posconditions) Uma pós-condição é uma condição que relaciona os dados de saída e estado final do sistema com os dados de entrada e o estado inicial do sistema Traduz o efeito/resultado do caso de utilização Exemplo, no levantamento em ATM: o cliente recebeu o dinheiro; o saldo da conta foi actualizado Pressupostos (Assumptions) Referências/fontes (References) Fontes de informação consideradas (entrevistas, sites, etc.). Se forem iguais para todos os casos de utilização, basta indicar no fim do documento Classes participantes (Participating classes) Apresentar um diagrama de classes parcial, com as classes, atributos e relações relevantes entre os principais conceitos de domínio relevantes no caso de utilização.
Modelo de Domínio Organizar o vocabulário do domínio do problema (utilizado na descrição dos casos de utilização) Organizar e relacionar termos que estão definidos num glossário ou num dicionário de dados Capturar os requisitos de informação Que informação é mantida no sistema e trocada com o ambiente Opcionalmente, especificar as transacções do negócio (por operações) Três tipos de classes: Classes que modelam o estado interno persistente e partilhado do sistema, como atributos e ligações de entidades do negócio são as classes mais importantes (também chamadas entidades informacionais) Classes que modelam a estrutura de documentos trocados entre o sistema e o seu ambiente Classes que modelam tipos de dados (usados nos atributos e operações das classes anteriores) Estrutura Uma secção de visão geral, com diagrama de classes e descrição textual que passa superficialmente pelas várias classes Uma secção/página para cada classe, com a sua descrição breve.
Protótipo da Interface com o Utilizador (1) Diz a norma IEEE 830-1998: Prototypes are useful for the following reasons: a) The customer may be more likely to view the prototype and react to it than to read the SRS (Software Requirements Specification) and react to it. Thus, the prototype provides quick feedback. b) The prototype displays unanticipated aspects of the systems behavior. Thus, it produces not only answers but also new questions. This helps reach closure on the SRS. c) An SRS based on a prototype tends to undergo less change during development, thus shortening development time.
Protótipo da Interface com o Utilizador (2) Nesta fase, interessa um protótipo da interface com o utilizador, também chamado protótipo horizontal, cobrindo as interfaces mais importantes Muitos autores recomendam a elaboração de protótipos de deitar fora (em vez de evolutivos), para garantir o foco nos requisitos (em vez de questões de implementação) O Microsoft Visio pode ser usado para elaborar protótipos de interfaces gráficas com o utilizador (GUIs) em Windows No caso de interfaces Web, podem-se construir páginas HTML estáticas Protótipos podem incluir dados de exemplo (coerentes entre as várias imagens) Imagens de ecrãs podem ser organizadas em sequências como nas histórias aos quadradinhos (storyboards)
Plano de Testes de Aceitação (1) O plano de testes de aceitação define um conjunto de casos de teste de aceitação Vantagens: Garantir que os requisitos especificados são verificáveis se não for possível definir casos de teste concretos correspondentes a um requisito, é porque este não está bem definido Clarificar a especificação de requisitos os casos de teste são exemplos do comportamento pretendido do sistema; escrever casos de teste concretos obriga a interpretar os requisitos, podendo nesse processo ser descobertas ambiguidades ou omissões Servir como contracto concreto entre o fornecedor e o cliente Os mesmos dados de exemplo usados nos protótipos podem ser usados nos testes de aceitação Numa abordagem baseada em casos de utilização, os teste de aceitação relativos aos requisitos funcionais devem ser baseados em cenários de utilização
Plano de Testes de Aceitação (2) Caso de utilização -> cenários (sequências específicas de funcionamento) -> casos de teste Estrutura da definição de um caso de teste Identificador Item ou itens que são objecto do teste: caso de utilização, cenário, requisito (para rastreabilidade em relação aos requisitos) Condição específica a testar Dados de entrada e condições iniciais Dados de saída e condições finais Procedimento de teste (se necessário) - Como estabelecer as condições iniciais - Passos a seguir na execução do teste (normalmente é seguir o cenário) - Como verificar as condições finais Precedências - Para organizar casos de teste em sequências, por exemplo, fazer testar uma inserção e depois uma consulta
Ferramentas Ferramenta de documentação colaborativa Wikis, google docs,... Ferramentas de modelação UML Enterprise Architect, Visio, ConceptDraw,... Ferramentas de prototipagem de interfaces Balsamiq Mockups, Visio,...
Bibliografia Recomendada Kurt Bittner, Ian Spence; Use Case Modelling, Addison- Wesley. 2003 IEEE recommended practice for software requirements specifications (IEEE Std 830-1998) Disponível em http://ieeexplore.ieee.org/ Gerald Kotonya and Ian Sommerville, Requirements Engineering: Processes and Tecnhiques, 1998 www.uml.org tem a definição da linguagem OCL Materiais das disciplinas de ES, ERSS, IPC e TQS