Relatório de Especificação de Requisitos 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 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. 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, inter-conexõ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. 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 Os requisitos funcionais serão aqui descritos de diferentes formas complementares: sob a forma de User Stories, facilmente compreensíveis pela equipa técnica e pelo cliente; e sob a forma de casos de utilização, mais formal. Ambas as formas devem ter referências cruzadas para facilitar a rastreabilidade. 3.2.1 User Stories Enumeração das várias user stories do projecto em mãos, sucintamente descritas em 1-3 parágrafos que possam ser facilmente compreendidos por todos envolvidos no projecto. As user stories podem eventualmente ser organizadas em grupos para facilitar a sua apresentação. 3.2.2 Modelo de Casos de Utilização O objectivo é capturar requisitos funcionais, focando no valor para os utilizadores (actores). Os casos de utilização devem ser descritas nesta secção de forma sucinta, começando por uma visão geral, organização em módulos/sub-módulos (packages) e a descrição individual de cada caso de utilização.
3.2.2.1 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 com a sua divisão em módulos (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). 3.2.2.2 Actores Descrever sumariamente cada um dos actores. 3.2.2.3 Módulo 1 (pacote de casos de utilização) Descrever sumariamente as funcionalidades englobadas neste módulo e depois descrever cada um dos seus casos de utilização. 3.2.2.3.1 Caso de utilização 1 Cada caso de utilização descreve as funcionalidades pretendidas ou requisitos funcionais. Deve-se usar uma secção/página wiki para cada caso de utilização, com a sua descrição detalhada. 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 (essencial, desejável, opcional). 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.). 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): Listar as classes do modelo de domínio (ver adiante) relevantes para o caso de utilização ou, se a complexidade o justificar, apresentar um diagrama de classes parcial, com as classes, atributos e relações relevantes. 3.3 Requisitos de informação 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). Normalmente encontram-se 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). Esta secção deve ser estruturada da seguinte forma: 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 detalhada (pode ser o texto do Javadoc): o explicando o que é (ou não é) uma instância da classe o tabela com nome e descrição de cada atributo e o que significam, se tal não for evidente pelo seu nome e descrição o descrever eventuais restrições informalmente o Relações: explicar as relações, se tal não for evidente pelo seu nome e descrição o Operações: não é necessário definir nesta fase, mas pode-se já indicar aquelas que se consideram essenciais. Se forem definidas, devem corresponder às transacções (e consultas) fundamentais do negócio, e não a todas as operações elementares que se podem imaginar. o Ciclo de vida: diagrama de estados mostrando o ciclo de vida de um objecto da classe, acompanhado eventualmente de uma pequena descrição. Só
quando se justifica. Estados devem corresponder a condições nos valores de atributos e ligações. Nesta fase, eventos devem corresponder a casos de utilização, podendo ter parâmetros 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 Protótipo da Interface com o Utilizador Diz a norma IEEE 830-1998 que: 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. 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). A forma mais simples pode ser fazer esboços em papel/lápis ou quadro branco e digitalizar. Em alternativa, pode-se usar um programa de desenho com capacidade para desenho de GUIs (ex: Dia ou Microsoft Visio). No caso de interfaces Web, podem-se construir páginas HTML estáticas. Os protótipos podem incluir dados de exemplo (coerentes entre as várias imagens) As imagens de ecrãs podem ser organizadas em sequências como nas histórias aos quadradinhos (storyboards). Plano de Testes de Aceitação O plano de testes de aceitação define um conjunto de casos de teste de aceitação das funcionalidades descritas como user stories.
As principais vantagens são: 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 contrato 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 user stories ou casos de utilização, os teste de aceitação relativos aos requisitos funcionais devem ser baseados em cenários de utilização. As user stories definem funcionalidades que têm que poder ser avaliadas de forma objectiva, com dados reais fornecidos pelos futuros utilizadores. Os casos de utilização permitem também definir cenários (sequências específicas de funcionamento) que por sua vez permitem definir 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 Referências e leituras recomendadas 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