Roteiro para a escrita do documento de Especificao de Requisitos de Software (ERS) Disciplina de Compiladores Prof.

. Jorge Bidarra (UNIOESTE) Definio Geral: A especificao de requisitos tem como objetivo obter produtos de software de melhor qualidade que satisfaam s reais necessidades dos clientes dentro de prazo e oramento adequados. Podemos entender requisito como uma funo, restrio ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer s necessidades do usurio do sistema. (Descreve um servio ou uma limitao) Embora no exista um modelo padro consagrado para gerenciar requisitos, podemos definir alguns passos para um processo de especificao de requisitos. No geral, especificar um requisito implica em compreender exatamente o que deve ser feito e que se espera receber como resultado. Os requisitos podem ser classificados em : Funcionais - descrevem as funcionalidades do sistema desejadas pelos clientes ou seja O QUE se espera que o software faa; No-funcionais - So as qualidades e restries globais do sistema relacionados com manuteno, uso, desempenho, custo , interface, etc... Alguns exemplos de requisitos funcionais: O sistema deve possibilitar o cadastramento dos dados pessoais dos clientes; O sistema deve emitir relatrios gerenciais; O sistema deve permitir a baixa automtica do estoque quando da venda de um produto; A Norma ISO/IEC 9126 define seis caractersticas de qualidade de software que devem ser avaliadas: Funcionalidade (finalidade do produto);

 Usabilidade (esforo para utilizar/aprender o produto); Confiabilidade (freqncia de falhas, recuperabilidade); Eficincia (caracterstica relacionada ao desempenho); Manutenibilidade (esforo necessrio para modificar o sistema); Portabilidade (capacidade de transferir o produto para outros ambientes). Alguns exemplos de requisitos no-funcionais: tempo de resposta do sistema no deve ultrapassar 10 segundos; software deve ser operacionalizado no sistema Windows; O banco de dados usado dever ser o Oracle. (fonte de consulta: http://www.macoratti.net/07/12/net_fer.htm. Acesso em: 26/03/2011. Contedo adaptado) A seguir, apresenta-se uma sugesto de estrutura organizacional de um documento de Especificao de Requisitos de Software ou ERS. Proposta de Estrutura de uma ERS (fonte de consulta: http://www.wthreex.com/rup/webtmpl/templates/req/rup_srs.htm. Acesso em: 26/03/2011. Contedo adaptado) 1. Introduo Fornece-se aqui uma viso geral do software a ser desenvolvido; por exemplo, a finalidade, o escopo, as definies, os acrnimos, as abreviaes, as referncias. A Especificao de Requisitos de Software (ERS) deve ser capaz de mostrar todos os requisitos de software do sistema ou de uma parte do sistema. possvel organizar uma ERS de vrias maneiras diferentes. Para maiores detalhes, consultar o padro [IEEE830-1998]. 1.1 Finalidade

Uma ERS dever descrever o comportamento externo do aplicativo ou do subsistema identificado. Ela tambm dever descrever requisitos no funcionais, restries de projeto e outros fatores necessrios para fornecer uma viso completa e abrangente dos requisitos do software. 1.2 Escopo Apresenta-se nessa seo uma breve descrio do aplicativo de software; o recurso ou outro agrupamento de subsistemas; modelo(s) de Caso de Uso associados; e tudo o mais que seja afetado ou influenciado por este documento. 1.3 Definies, Acrnimos e Abreviaes Aqui devem ser fornecidas as definies de todos os termos, acrnimos e abreviaes necessrias adequada interpretao da ERS. muito comum nesse tipo de documento o uso de glossrios. 1.4 Referncias Relao completa de todos os documentos mencionados em qualquer outra parte desse documento. Cada documento dever ser identificado por ttulo, nmero do relatrio (se aplicvel), data e organizao de publicao. No se deve esquecer de especificar as fontes a partir das quais as referncias podem ser obtidas. Essas informaes podem ser fornecidas por um anexo ou atravs de outro documento. 2. Descrio Geral Descrever os fatores gerais que afetam o produto e seus requisitos. Evitar a especificao de requisitos especficos. Em vez disso, fornecer uma base para esses requisitos, cujos detalhes devero ser mostrados na Seo 3. Para facilitar a compreenso do leitor, incluir nessa seo os seguintes itens: perspectiva do produto funes do produto caractersticas do usurio restries suposies e dependncias subconjuntos de requisitos

3. Requisitos Especficos Descrevem-se aqui todos os requisitos de software em um nvel de detalhamento suficiente para possibilitar que os designers projetem um sistema que satisfaa esses requisitos e que os testadores verifiquem se o sistema satisfaz esses requisitos. Quando for utilizada a modelagem de casos de uso, esses requisitos sero capturados nos Casos de Uso e nas especificaes suplementares aplicveis. Se a modelagem de casos de uso no for utilizada, o esquema das especificaes suplementares poder ser inserido diretamente nesta seo, conforme mostrado a seguir. 3.1 Funcionalidade Esta seo descreve os requisitos funcionais do sistema. Para muitos aplicativos, este poder ser o volume do Pacote da ERS. Dentre os requisitos funcionais esto o conjunto de recursos existentes no software, suas capacidades e segurana. 3.2 Usabilidade Essa seo deve incluir todos os requisitos que afetam a usabilidade. Por exemplo, especificar o tempo de treinamento necessrio para que usurios normais e usurios com conhecimentos avanados se tornem produtivos em operaes especficas especificar perodos de tempo mensurveis para tarefas tpicas ou baseie os requisitos de usabilidade do novo sistema em outros sistemas que os usurios conheam e gostem especificar requisitos de forma que estejam em conformidade com padres comuns de usabilidade como, por exemplo, os padres CUA da IBM ou os padres GUI da Microsoft. 3.3 Confiabilidade Alguns tpicos que podem/devem ser considerados nessa descrio: Disponibilidade - especifique a porcentagem de tempo disponvel ( xx.xx%), as horas de uso, o acesso manuteno, as operaes de modo degradado, etc. Tempo Mdio entre Falhas (MTBF) - normalmente especificado em horas, mas tambm poder ser especificado em termos de dias, meses ou anos.

 Tempo Mdio para Reparo (MTTR) - quanto tempo o sistema poder ficar sem funcionar aps uma falha? Exatido - especifique a preciso (resoluo) e a exatido (atravs de algum padro conhecido) necessrias na sada do sistema. Taxa Mxima de Erros ou Defeitos - geralmente expressa em termos de erros por milhares de linhas de cdigo (erros/KLOC) ou de erros por ponto de funo (erros/ponto de funo). Taxa de Erros ou Defeitos - categorizados em termos de erros pouco importantes, importantes e crticos: o(s) requisito(s) devem definir o que se entende por um erro "crtico"; por exemplo, a perda total de dados ou uma total incapacidade de usar determinadas partes da funcionalidade do sistema.] 3.4 Desempenho tempo de resposta de uma transao (mdio, mximo); taxa de transferncia como, por exemplo, transaes por segundo; capacidade como, por exemplo, o nmero de clientes ou de transaes que o sistema pode acomodar; modos de degradao (o modo aceitvel de operao quando o sistema tiver sido degradado de alguma maneira); a utilizao de recursos como, por exemplo, memria, disco, comunicaes, etc. 3.5 Manutenibilidade Indicar nessa seo todos os requisitos que aprimoraro o sistema que est sendo criado, nos quais se incluem padres de codificao, convenes de nomeao, bibliotecas de classes, acesso manuteno e utilitrios de manuteno. 3.6 Restries de Projeto Indicar e descrever todas as restries de projeto referentes ao sistema que est sendo criado. As restries de projeto compreendem as decises de projeto que foram impostas e que devem ser respeitadas. Entre os exemplos desse tipo de restrio esto linguagens de software, requisitos de processo de software, uso prescrito de ferramentas de desenvolvimento, restries de design e de arquitetura, componentes comprados, bibliotecas de classes, etc.

3.7 Requisitos de Sistema de Ajuda Descrever aqui os requisitos de auxlio, tais como: documentao de usurio, sistemas de ajuda, observaes sobre ajuda, etc. 3.8 Interfaces Essa seo define as interfaces que devem ser suportadas pelo aplicativo. Ela deve conter as especificidades, os protocolos, a porta e os endereos lgicos adequados, entre outros, para que o software possa ser desenvolvido e verificado em relao aos requisitos de interface. Sua descrio deve contemplar os seguintes tipos de interface: 3.8.1 Interfaces de Usurio Descreva as interfaces de usurio que devero ser implementadas pelo software. 3.8.2 Interfaces de Hardware Esta seo define todas as interfaces de hardware que devem ser suportadas pelo software, incluindo a estrutura lgica, os endereos fsicos, o comportamento esperado, etc. 3.8.3 Interfaces de Software Esta seo descreve as interfaces de software com outros componentes do sistema de software, se houver. Podero ser componentes comprados, componentes reutilizados de outro aplicativo ou componentes que estejam sendo desenvolvidos para subsistemas fora do escopo desta SRS, mas com os quais esse aplicativo de software deve interagir. 3.8.4 Interfaces de Comunicao Descrever aqui todas as interfaces de comunicao com outros sistemas ou dispositivos como, por exemplo, redes locais, dispositivos seriais remotos, etc. 3.9 Padres Aplicveis Esta seo descreve, por meio de referncias, todos os padres aplicveis e as sees especficas desses padres que se aplicam ao sistema que est sendo descrito. Entre esses padres esto includos, por exemplo, padres reguladores, de qualidade e legais, padres de indstria referentes usabilidade, interoperabilidade, internacionalizao, compatibilidade com o sistema operacional, etc.

4. Informaes de Suporte As informaes de suporte facilitam o uso da ERS. Essas informaes incluem: ndice analtico ndice Apndices Podero estar includos roteiros de caso de uso ou prottipos da interface do usurio. Quando forem includos apndices, a ERS dever especificar explicitamente se os apndices devero ou no ser considerados parte integrante dos requisitos.