REQUISITOS FUNCIONAIS DE SOFTWARE: REFLEXÕES INICIAIS DA INFLUÊNCIA DO MÉTODO DE ESPECIFICAÇÃO EM CARACTERÍSTICAS DE GESTÃO DE PROJETOS

Transcrição

1 1 ÁREA-5 GESTÃO DE OPERAÇÕES, TECNOLOGIA DA INFORMAÇÃO E INOVAÇÃO REQUISITOS FUNCIONAIS DE SOFTWARE: REFLEXÕES INICIAIS DA INFLUÊNCIA DO MÉTODO DE ESPECIFICAÇÃO EM CARACTERÍSTICAS DE GESTÃO DE PROJETOS Carlos Eduardo Marquioni i RESUMO Este trabalho apresenta como o método utilizado para a especificação dos requisitos funcionais de software através de textos em linguagem natural pode ultrapassar as fronteiras evidentes de documentação de produto, e apoiar diretamente na execução de atividades relacionadas a pelo menos três aspectos que podem ser observados em projetos de software: a negociação para entregas parciais dos requisitos, as solicitações de mudança como potenciais fontes de aumento de escopo e a elaboração de casos de teste de aceite para o produto construído (Leffingwell, Widrig, Pressman). É utilizado o conceito de granularidade do requisito (Robertson & Robertson) para debater a relevância do nível de detalhamento na especificação do requisito. A partir deste conceito são realizadas análises comparativas, através de um mesmo requisito redigido de formas distintas, o que possibilita avaliar como eventuais dificuldades relacionadas aos três aspectos considerados podem ser minimizadas quando utilizada uma granularidade que permite compreensão uniforme tanto por técnicos quanto por usuários do nível de detalhamento que deve ser aplicado (Alexander, Stevens) na formalização de cada requisito funcional. Palavras-chave: Engenharia de Requisitos. Gestão de escopo de software. Entrega parcial de sof 1 INTRODUÇÃO i i Universidade Federal do Paraná (UFPR), marquioni@marquioni.com.br, A definição de requisito considerada no trabalho é aquela proposta pela norma do Institute of Electrical and Electronics Engineers (IEEE): (1) Uma condição ou capacidade que um usuário necessita para resolver um problema ou atingir um objetivo. (2) Uma condição ou capacidade que obrigatoriamente deve ser atendida ou possuída por um produto ou um componente de um produto para satisfazer um contrato, um padrão, uma especificação, ou outros documentos formalmente estabelecidos. (3) Uma representação documentada de uma condição ou capacidade conforme descrita em (1) ou (2) (ap. CHRISSIS; KONRAD; SHRUM, 2003, p. 627)

2 2 O método utilizado para redação dos requisitos ii funcionais iii influencia sua compreensão. Se, por um lado, as representações formais através de diagramas técnicos costumam enfrentar dificuldades na leitura rigorosa por usuários iv, quando os requisitos são especificados através de textos em linguagem natural tampouco é possível afirmar que haverá compreensão adequada: Esta abordagem de escrita [a linguagem natural] possui a vantagem de não apresentar barreiras adicionais entre as pessoas de disciplinas diferentes que estão envolvidas na fase [do ciclo de vida do projeto de software]. Por outro lado, a linguagem natural tem muitas propriedades que são indesejáveis em especificações (ambigüidade, imprecisão e inconsistência) (MAZZA et al., 1994, p. 25). Embora controladas pela gramática, as linguagens naturais são mais fáceis de escrever porque sua gramática não é especificada de forma tão rígida quanto aquela das linguagens formais. Por outro lado, é mais difícil ser específico e preciso, evitar ambigüidades na linguagem natural (NADIN, 1988, p. 299). No caso dos requisitos funcionais, o método de especificação possui uma importância evidente, relacionada ao fato de ser fundamental que a documentação gerada para o produto possibilite aos participantes do projeto de software a compreensão do conteúdo formalizado, de modo que seja possível entender o que o produto oferece (suas funcionalidades). Mas a compreensão dos requisitos especificados pode influenciar também em aspectos que ultrapassam a documentação do produto: como exemplos podem ser citados o momento do projeto no qual o requisito deve ser desenvolvido, a determinação se solicitações de mudança originadas durante o projeto caracterizam aumento das funcionalidades previstas, além de auxiliar a definir critérios para evidenciar que o produto apresenta o comportamento esperado. Em outros termos, os requisitos funcionais especificados tanto orientam o que deve ser desenvolvido em termos de software como também apóiam a execução de tarefas de caráter gerencial e técnico, pois podem influenciar a negociação para entregas parciais, a determinação de variações de escopo e a especificação de casos de teste. ii A definição de requisito considerada no trabalho é aquela proposta pela norma do Institute of Electrical and Electronics Engineers (IEEE): (1) Uma condição ou capacidade que um usuário necessita para resolver um problema ou atingir um objetivo. (2) Uma condição ou capacidade que obrigatoriamente deve ser atendida ou possuída por um produto ou um componente de um produto para satisfazer um contrato, um padrão, uma especificação, ou outros documentos formalmente estabelecidos. (3) Uma representação documentada de uma condição ou capacidade conforme descrita em (1) ou (2) (ap. CHRISSIS; KONRAD; SHRUM, 2003, p. 627). iii Um requisito funcional é uma ação que o produto deve executar para ser útil aos usuários. Requisitos funcionais surgem a partir do trabalho que seus stakeholders necessitam fazer. Quase toda ação calcular, inspecionar, publicar [...] pode ser um requisito funcional. [...] Este requisito é algo que o produto obrigatoriamente deve fazer para ser útil no contexto do negócio do cliente (ROBERTSON; ROBERTSON, 2007, p. 09). iv Há evidências que pessoas que não sejam engenheiros de sistemas leiam todos os diagramas [independente da notação utilizada] [...] como se eles fossem [apenas] fluxogramas, então não espere muito de diagramas formais (ALEXANDER; STEVENS, 2002, p. 37).

3 3 Visando minimizar as incompreensões em relação aos requisitos funcionais, pensadores têm apresentado características que merecem ser observadas durante sua formalização através de linguagem natural, destacando que é [...] importante utilizar boas práticas de escrita ao redigir requisitos [...] [como, por exemplo,] Escrita na voz ativa [...] Remoção de ambigüidades [...] Uso da linguagem do cliente [...] Organização em sentenças independentes, focadas e curtas: [...] Decomposição dos requisitos de modo que cada requisito tenha um foco claro e um propósito verdadeiro (JONASSON, 2008, p ). Este trabalho realiza análises comparativas no texto de um mesmo requisito funcional especificado de duas formas distintas, enfatizando a relevância da decomposição dos requisitos e tentando estabelecer o que pode significar um foco claro. Para estas análises, o artigo é dividido em quatro seções, além desta introdução e das considerações finais. A seção Contextualização geral introduz brevemente o conceito de granularidade do requisito funcional e apresenta o exemplo utilizado ao longo do trabalho. A seção Entregas parciais analisa como a forma de especificação utilizada pode influenciar nas negociações relacionadas à ordem de desenvolvimento e entrega de releases ao longo do projeto de software. A seção Variação de escopo apresenta como o método de especificação pode apoiar os profissionais de software a evidenciar situações em que uma solicitação de mudança caracteriza um aumento de escopo, enquanto a seção Especificação de testes analisa como a granularidade utilizada pode auxiliar na elaboração de casos de teste de aceite para demonstrar que o comportamento do produto foi implementado corretamente. Finalmente, as Considerações finais resumem o conteúdo debatido, indicando a necessidade de haver desdobramentos para este trabalho. 2 CONTEXTUALIZAÇÃO GERAL O método de especificação não exerce influência apenas quando considerados requisitos complexos em termos de negócio ou de implementação técnica. Visando demonstrar como inclusive requisitos simples merecem atenção em relação ao nível de refinamento durante sua especificação, as breves análises reflexivas realizadas neste artigo são elaboradas a partir de um exemplo de requisito funcional que sugere simplicidade, tanto sob perspectiva de negócio quanto para implementação em termos de software da funcionalidade requerida. A idéia é demonstrar que mesmo para os requisitos de implementação técnica simples, os aspectos considerados no trabalho são críticos e podem caracterizar risco caso sejam tratados apenas de maneira superficial.

4 4 Vale destacar que o exemplo utilizado assume como premissa que o conhecimento do negócio em questão foi equacionado (por exemplo, através do entendimento de causas raízes dos problemas v ), e o requisito resultante efetivamente corresponde à maneira adequada de atender às necessidades dos usuários: ou seja, o trabalho não avalia se o requisito exemplo deveria existir, por considerar que esta análise foi realizada anteriormente. Ainda, uma vez que a ênfase do trabalho é em relação ao método de especificação, não são realizadas análises reflexivas quanto a outros aspectos indubitavelmente relevantes, como restrições gerenciais (prazo, orçamento etc.), de equipe (conhecimento técnico, dedicação, motivação etc.) ou ambiente (tecnologia utilizada, dificuldade da linguagem de programação etc.). Em outros termos: o artigo se limita a apresentar qual é o impacto do método de formalização nos três aspectos considerados (negociação de entregas parciais, variação de escopo de produto e elaboração dos casos de teste). 2.1 GRANULARIDADE DO REQUISITO FUNCIONAL Todo requisito deveria nomear um único resultado desejado [grifo meu] (ALEXANDER; STEVENS, 2002, p. 99). A granularidade define a atomicidade do requisito funcional. O termo costuma ser utilizado para referenciar o quão detalhados estão os requisitos, referenciando o Nível de Detalhe ou Granularidade (ROBERTSON; ROBERTSON, 2007, p. 160): a partir da definição da granularidade do requisito funcional é possível estabelecer o que significa um requisito funcional (sua unidade). Uma analogia com a Engenharia Civil auxilia a entender em linhas gerais a relevância dessa definição: um indivíduo que conhece e compreende o conceito de área construída e a unidade metro quadrado compreende que uma casa que tem 100 metros quadrados construídos é menor do que uma outra com 200 metros quadrados de área construída. Por outro lado, no caso do desenvolvimento e manutenção de software, sem a definição da granularidade dos requisitos ainda que seja entendido o conceito de o que significa um software não é possível afirmar que um produto com 10 requisitos é menor que outro contendo 20 requisitos. Sem definir claramente o que significa um requisito funcional, a realização de análises comparativas de tamanho pode ser prejudicada. Em outros termos, a granularidade auxilia na definição de como o requisito funcional pode ter um foco claro. 2.2 REQUISITO BÁSICO DE REFERÊNCIA v Consulte (LEFFINGWELL; WIDRIG, 2006, p ).

5 5 Requisitos que contém conjunções palavras que unem sentenças são perigosos. Conjunções que podem trazer perigo incluem: e, ou, com, também [grifo no original] (ALEXANDER; STEVENS, 2002, p ). Conhecimentos do negócio e jargão relacionados à publicação de livros dão conta que obras editadas possuem um título, um autor (ou vários) e um número que o identifica, atribuído de acordo com um padrão mundial: o ISBN (International Standard Book Number). O exemplo utilizado no trabalho considera um requisito para disponibilizar consultas de livros já cadastrados. A primeira forma de especificação exemplo para as análises comparativas é apresentada na Tabela 1. Tabela 1 - Formato original exemplo para especificação de requisitos funcionais Requisito O sistema deverá permitir aos usuários a procura de um item por título, autor ou ISBN Fonte: (KOTONYA; SOMMERVILLE, 1998, p. 4) Apesar da aparente simplicidade e clareza, o trabalho considera que este requisito exemplo está especificado utilizando uma granularidade inadequada, pois parece fornecer três resultados possíveis (um resultado associado a cada consulta), devido ao uso da conjunção ou. Logo, considera-se que esta forma de especificação do requisito funcional não possui um foco claro. Para efeito de análises comparativas, é proposta uma forma de especificação alternativa através de três requisitos, ao invés de um único. Assim, a segunda forma de especificação para as análises comparativas é apresentada na Tabela 2. Tabela 2 - Formato alternativo exemplo para especificação de requisitos funcionais Requisito O sistema permite aos usuários a procura de um item por título O sistema permite aos usuários a procura de um item por autor O sistema permite aos usuários a procura de um item por ISBN Fonte: Sugestão do autor O leitor deve ter observado que inclusive o tempo verbal dos requisitos especificados segundo o formato alternativo sugerido na Tabela 2 é diferente daquele apresentado anteriormente: isto se deve ao fato que este trabalho considera que os requisitos são itens de

6 6 configuração vi, caracterizam documentação de produto e, como tal, devem ser especificados utilizando tempo verbal presente: com o produto construído, os requisitos continuam válidos e o tempo verbal futuro pode causar a sensação que mesmo requisitos entregues ainda não foram implementados. Contudo, o artigo não apresenta reflexões em relação aos requisitos funcionais como itens de configuração: a complexidade do tema parece justificar a elaboração de um trabalho específico para esta análise. As seções seguintes analisam comparativamente as duas formas de escrita, debatendo como a definição da granularidade influencia nos aspectos considerados. 3 ENTREGAS PARCIAIS 3.1 GRANULARIDADE E NEGOCIAÇÃO DO REQUISITO Entregas parciais podem ser observadas quando é utilizado um ciclo de vida iterativo vii para executar o projeto de software. O risco principal relacionado à negociação de entregas parciais nestes casos está associado ao usuário classificar a maioria (ou, em uma situação limite, a totalidade) dos requisitos funcionais como tendo necessidade de entrega urgente, dificultando a definição das iterações: os técnicos e gestores de software podem encontrar dificuldades para negociar quais funcionalidades necessitam ser entregues em cada release do sistema viii. O trabalho considera que a negociação para entregas parciais pode ser facilitada caso os requisitos sejam especificados detalhadamente (considerando como referência a granularidade proposta da Tabela 2). Complementando o detalhamento para as negociações, é recomendada também a utilização de uma classificação dos requisitos a partir de atributos que permitam pontuar características técnicas e de negócio a maior granularidade auxilia inclusive na pontuação destes atributos. Para efeito ilustrativo, o artigo utiliza como estratégia os atributos para negociação propostos por Leffingwell e Widrig (2006), que classificam os requisitos quanto à vi Um item de configuração (IC) é uma agregação de hardware, software ou ambos, que é designada para gestão de configuração e é tratada como uma entidade única no processo de gestão de configuração. Muitos fatores podem ser relevantes ao decidir onde definir as fronteiras de um item de configuração. Um item de configuração pode ser qualquer tipo de item de software, por exemplo: um módulo, um documento ou um conjunto de ICs (MAZZA et al., 1994, p. 64). Consulte ainda (LEON, 2005). vii Consulte (JACOBSON, BOOCH, RUMBAUGH, 2001). viii Uma release do sistema é um conjunto de itens que é entregue aos clientes. Cada release do sistema inclui novas funcionalidades ou features ou algumas correções para falhas encontradas por clientes, desenvolvedores ou testadores (LEON, 2005, p ).

7 7 prioridade, esforço ix e risco x. A estratégia sugerida pelos autores foi escolhida apesar de eles proporem um nível de granularidade para aplicação dos atributos distinto daquele recomendado por este trabalho (apresentada na Tabela 2): os autores defendem que a negociação deve ocorrer em relação às features xi (2006, p ) do produto que têm, por definição, menor granularidade (são menos refinadas). Esta variação, de certa forma, auxilia a demonstrar a relevância do maior refinamento no exemplo a seguir. O trabalho considera ainda que a estratégia de considerar uma menor granularidade para especificação dos requisitos funcionais nos estágios iniciais dos projetos de software, de modo que uma maior granularidade seja obtida à medida que o projeto avançasse no ciclo de vida (proposta por Leffingwell e Widrig) pode não ser interessante, pois essa variação supostamente prevista eventualmente caracteriza uma nova dificuldade, associada à definição de qual seria a variação esperada ou aceitável para o nível de detalhamento. Ao invés de supor níveis distintos de especificação, parece mais adequado que seja definido um método de especificação simples e que forneça já nas primeiras abstrações dos requisitos uma granularidade considerada adequada pelos profissionais envolvidos em projetos de software. Assim, este trabalho sugere o uso dos atributos propostos por Leffingwell e Widrig (2006), mas entende que a granularidade de features conforme proposta por esses autores pode dificultar a negociação: é apresentado em seguida um exemplo de como cada granularidade oferece possibilidades distintas de visibilidade e, conseqüentemente, de negociação. Vale destacar ainda que aparentemente a feature, conforme proposta por Leffingwell e Widrig (2006) possui um nível de detalhamento mais geral do que aquele apresentado na Tabela 1: talvez a feature correspondente ao exemplo que tenha fidelidade em relação à definição dos autores seja Possibilitar consultas. Contudo, por se tratar de uma hipótese (uma vez que o conceito de nível de detalhamento mais geral parece demasiado subjetivo), o trabalho considera que utilizar a especificação apresentada na Tabela 1 como feature não compromete as análises ou distorce de maneira significativa o conceito apresentado pelos autores. ix Os autores recomendam utilizar escalas considerando Prioridade: valores Crítico (Muito prioritário), Importante (Médio prioritário) e Útil (Pouco prioritário) e Esforço: Alto (Muito esforço), Médio (Médio esforço) e Baixo (Pouco esforço). x Os autores comentam que o risco a considerar deve ser aquele associado à probabilidade que uma implementação cause um impacto adverso no cronograma e/ou no orçamento. xi Features são expressões em alto nível do comportamento de um sistema desejado [...]. Features geralmente não estão bem definidas e podem inclusive estar em conflito entre si (LEFFINGWELL; WIDRIG, 2006, p. 96).

8 8 3.2 VARIAÇÃO DE VISIBILIDADE DE NEGOCIAÇÃO A premissa considerada é que quanto menor for a granularidade dos requisitos, maior deve ser a dificuldade de negociação, pois a granularidade pode sugerir ao usuário que o que está em negociação não é a entrega de parte dos requisitos, mas a entrega de parte de um requisito (no caso do exemplo apresentado na Tabela 1, caso houvesse necessidade de negociar para uma primeira release a entrega apenas da pesquisa por título, o usuário poderia entender a release como um terço do requisito funcional). Quando há menor granularidade, inclusive a avaliação dos atributos para classificação dos requisitos é dificultada, provocando eventuais omissões de análise por simplificação. Para as tabelas a seguir, os valores atribuídos para as prioridades, esforços e riscos são apenas ilustrativos; o que se deseja evidenciar é que o formato de especificação apresentado na Tabela 3 pode induzir o profissional que vai atribuir valores para os critérios de classificação a uma simplificação. Tabela 3 - Exemplo de priorização para o requisito no formato original Requisito Prioridade Esforço Risco O sistema deverá permitir aos usuários a procura de um item por título, autor ou ISBN Crítico Baixo Baixo Fonte: Sugestão do autor adaptação a partir de (KOTONYA; SOMMERVILLE, 1998, p. 4) e (LEFFINGWELL; WIDRIG, 2006, p. 215) Tabela 4 - Exemplo de priorização para o requisito utilizando maior granularidade Requisito Prioridade Esforço Risco O sistema permite aos usuários a procura de um item Crítico xii Médio xiii Baixo por título O sistema permite aos usuários a procura de um item Importante Médio xiv Médio por autor O sistema permite aos usuários a procura de um item por ISBN Útil xv Baixo Baixo Fonte: Sugestão do autor Os requisitos especificados nas Tabelas 3 e 4 procuram demonstrar que a maior granularidade possibilita uma avaliação mais rigorosa dos atributos considerados: requisitos xii A pesquisa por título poderia ser considerada prioritária pelo cliente por ser aquela através da qual normalmente as consultas são realizadas (trata-se da consulta mais usual). xiii O esforço poderia ser considerado médio neste caso devido à necessidade de utilizar mecanismos técnicos de busca de texto eficiente. xiv O esforço maior em comparação aos outros requisitos poderia ser justificado, por exemplo, devido a uma entidade de dados auxiliar para manter o catálogo de autores. xv A pesquisa por ISBN poderia ser considerada pelo cliente pouco prioritária por ser pouco usual.

9 9 com menor granularidade podem não fornecer visibilidade suficiente para negociações, chegando mesmo a ofuscar nuances relacionadas a cada critério utilizado, eventualmente provocando omissão de informações relevantes. 4 VARIAÇÃO DE ESCOPO A granularidade dos requisitos funcionais pode auxiliar também a evidenciar variações de escopo do produto. O escopo do produto é função das funcionalidades que devem ser obrigatoriamente entregues para atender às necessidades dos usuários (LEFFINGWELL; WIDRIG, 2006, p. 207), e apresenta em um projeto de software típico uma variação que oscila xvi entre 125% e 500% (p. 209). Para entender como a granularidade do requisito pode auxiliar a evidenciar que houve variação de escopo, considere que uma solicitação de mudança originou três novos critérios de procura para a consulta de livros do exemplo: a editora, o idioma e o ISBN-13 do item. Para não tornar as considerações demasiado extensas, o exemplo não vai entrar no mérito da especificação do requisito relacionado à adição dos atributos nas entidades de dados ou classes correspondentes, e vai se deter apenas nas consultas. As Tabelas 5 e 6 apresentam a nova versão para os requisitos funcionais, considerando as duas formas de especificação utilizadas. Tabela 5 - Requisito original atualizado com novos critérios de procura Requisito O sistema deverá permitir aos usuários a procura de um item por título, autor, ISBN, editora, idioma ou ISBN-13 Fonte: Sugestão do autor adaptação a partir de (KOTONYA; SOMMERVILLE, 1998, p. 4) Tabela 6 - Requisitos alternativos atualizados com novos critérios de procura Requisito O sistema permite aos usuários a procura de um item por título O sistema permite aos usuários a procura de um item por autor O sistema permite aos usuários a procura de um item por ISBN O sistema permite aos usuários a procura de um item por editora O sistema permite aos usuários a procura de um item por idioma O sistema permite aos usuários a procura de um item por ISBN-13 Fonte: Sugestão do autor xvi É relevante destacar que a variação típica informada pelos autores é relativa à granularidade de features, que consideram adequada. Assim, considerando a granularidade proposta no trabalho, o índice de variação tende a ser menor.

10 10 Como a Tabela 5 apresenta, quando utilizada uma menor granularidade através do uso da conjunção ou, para ser mantida a coerência em relação à forma de especificação, os novos critérios para pesquisa dos itens deveriam ser adicionados no final do texto do requisito anteriormente especificado. Com isso, a quantidade de requisitos não varia: antes da solicitação de mudança havia um único requisito, e na nova especificação (após a solicitação de mudança) ainda há um único requisito: a granularidade menor esconde a variação quantitativa dos requisitos funcionais em relação à solicitação de mudança. A Tabela 6 procura evidenciar que quando cada critério é listado como um requisito independente, um novo critério adicionado aumenta a quantidade dos requisitos. Parece ainda importante destacar que caso a alternativa de especificação para formalizar os requisitos relacionados à solicitação de mudança seja semelhante àquela apresentada na Tabela 7 (ou com pequenas variações), o usuário pode ter a sensação que a equipe do projeto faz a quantidade de requisitos variar de acordo com os próprios interesses, por eventualmente não entender a lógica aplicada para que os novos critérios não fossem adicionados no final do requisito original, utilizando também a conjunção ou. Em outros termos, se a granularidade não é aplicada de maneira uniforme na especificação dos requisitos, é difícil estabelecer claramente como ocorre a variação de escopo do produto, ou qual é o critério utilizado para fazer variar a quantidade de requisitos. Tabela 7 - Requisitos atualizados com novos critérios de pesquisa sem manter granularidade uniforme Requisito O sistema deverá permitir aos usuários a procura de um item por título, autor ou ISBN O sistema deverá permitir aos usuários a procura de um item por editora, idioma ou ISBN- 13 Fonte: Sugestão do autor É relevante destacar que este trabalho não propõe romper com técnicas de estimativas de tamanho de produto (Pontos de Função, por exemplo que poderia ser utilizada para demonstrar a variação de escopo). Contudo, o método de especificação pode apoiar nesta definição do tamanho do produto de software: no caso do exemplo desta seção, provavelmente xvii haveria também variação de tamanho se realizadas contagens de Pontos de Função antes e depois do aumento dos critérios de pesquisa, mas talvez seja mais clara ao xvii Neste caso, a variação dependeria da solução técnica utilizada.

11 11 usuário a variação de requisitos através da evidência de variação da quantidade numérica ao invés do uso de uma unidade mais complexa como Pontos de Função, que necessita de maior repertório técnico para compreensão. 5 ESPECIFICAÇÃO DE TESTES Para evidenciar que os requisitos funcionais desenvolvidos possuem o comportamento esperado existem os casos de teste, que devem ser especificados ainda nos estágios iniciais do projeto de software xviii. Os casos de teste estabelecem relação direta com os requisitos: Testar é o processo de exercitar ou avaliar um sistema ou um componente de sistema, utilizando meios manuais ou automatizados para: - confirmar que ele satisfaz os requisitos especificados (MAZZA et al., 1994, p ). A relação entre os requisitos funcionais e os casos de teste fica ainda mais evidente quando considerado que: Conhecendo a função especificada para a qual um produto foi projetado, podem ser conduzidos testes para demonstrar que cada função está completamente operacional, ao mesmo tempo em que são procurados erros em cada função (PRESSMAN, 2000, p. 432) as funções que um produto de software deve executar são seus requisitos funcionais. É relevante também prever situações de erro para avaliar o comportamento do produto no tratamento de exceções durante os testes. 1. Testar é um processo de executar um programa com o objetivo de encontrar um erro. 2. Um bom caso de teste é aquele que tem grande probabilidade de encontrar um erro não descoberto até o momento. 3. Um teste de sucesso é aquele que descobre um erro não descoberto até o momento (MYERS, 1979 ap. PRESSMAN, 2000, p. 428). Com isso, é necessário especificar, no mínimo, dois casos de teste para cada requisito: um caso para testar o comportamento conforme esperado, e outro para o tratamento da exceção. Evidentemente, quanto maior o número de exceções previsto, maior o número de casos de teste que deve ser elaborado para haver uma validação sistemática. Segundo esta instrução, os requisitos listados na Tabela 6 teriam ao menos doze casos de teste associados: dois para cada requisito (por exemplo, um caso de teste para pesquisar um título cadastrado, e outro para avaliar comportamento quando pesquisado um título não cadastrado; um caso de xviii Jacobson, Booch e Rumbaugh comentam que ainda na fase de concepção do produto de software, Paralelamente às atividades de análise, design e implementação, [...] os engenheiros de testes tomam conhecimento da natureza geral do sistema proposto, considerando quais testes serão requeridos (2001, p. 354).

12 12 teste para pesquisar um autor cadastrado, e outro para avaliar comportamento quando pesquisado um autor não cadastrado etc.). Os mesmos doze casos de teste mínimos deveriam ser identificados em relação à Tabela 5 contudo, neste caso parece mais difícil ao profissional responsável pela formalização dos testes identificar todas as possibilidades, inclusive determinar aquela quantidade mínima necessária, uma vez que há uma única sentença para especificar todo o comportamento. Em outros termos, há risco de ser subestimada a quantidade mínima de casos de teste, o que pode comprometer o aceite do produto: a especificação de cenários para tratar alternativas (na execução correta e em situações de erro) parece facilitada quando os requisitos possuem maior granularidade, ao invés de ter funcionalidades agrupadas. 6 CONSIDERAÇÕES FINAIS A especificação de requisitos não é uma tarefa trivial: enquanto as representações formais através diagramas técnicos não são validadas com o rigor técnico esperado, textos em linguagem natural enfrentam o problema da ambigüidade e podem ser prejudicados em função da quantidade de informações de cada requisito funcional. Pensadores de software têm divulgado que A essência da boa escrita [de requisitos] é a simplicidade, e a chave para isso é permitir que cada requisito diga apenas uma coisa. Os requisitos se tornam complicados quando tentam definir de uma única vez [todo] um comportamento, um desempenho, um ou dois casos especiais, além de um comportamento alternativo (ALEXANDER; STEVENS, 2002, p. 18), Associado aos fatores de escrita há o fato que mesmo requisitos com implementação tecnicamente simples podem caracterizar fontes potenciais de problemas quando a especificação não estiver em um nível de detalhamento adequado para compreensão uniforme entre os participantes do projeto de software. Contudo, são poucos os métodos definidos para redação de requisitos funcionais utilizando linguagem natural xix, e embora estes métodos apresentem boas práticas relacionadas à escrita de requisitos, ainda não é possível afirmar que exista uma definição clara de qual é a granularidade a utilizar para especificação dos requisitos funcionais de software. Um exemplo para esta afirmação pode ser obtido através do método Volere (ROBERTSON; ROBERTSON, 2007), que apresenta boas práticas de escrita para os xix Como exemplos de métodos de especificação textual podem ser citados Freedom (LUTOWSKI, 2005), Volere (ROBERTSON; ROBERTSON, 2007), o guia de especificação Software Requirement Patterns (WITHALL, 2007), as orientações de especificação apresentadas em (WIEGERS, 2003).

13 13 requisitos, aborda o problema da granularidade/atomicidade dos requisitos funcionais, fornece um modelo de artefato para proceder com a formalização, mas se limita, na instrução de preenchimento deste artefato, a indicar que a especificação do requisito corresponde a Um enunciado através de uma sentença acerca da finalidade do requisito (ROBERTSON; ROBERTSON, 2007, p. 15): indubitavelmente vago. Além disso, os exemplos de especificação apresentados pelos autores parecem não realizar reflexões aprofundadas acerca dos requisitos como documentação de produto (como itens de configuração), pois a formalização apresentada utiliza tempo verbal futuro para redação, sugerindo que os requisitos possam ser descartados uma vez com o produto construído. Os exemplos apresentados ao longo do artigo tampouco podem ser classificados como tendo a granularidade adequada apenas procuraram ilustrar que a definição de um nível de detalhamento que seja compreendido e aceito possibilita atuar em relação aos requisitos com aspectos que ultrapassam a documentação (por mais importante que seja a documentação). Assim, este trabalho não se considera conclusivo ao contrário, apresentou reflexões apenas iniciais da relevância de definir uma granularidade para os requisitos, não apenas para que os usuários tenham maior probabilidade de compreensão do conteúdo especificado, mas também para que os próprios profissionais (técnicos e gestores) que atuam em projetos possam extrair informações do conteúdo especificado dos requisitos que minimizem dificuldades durante o desenvolvimento e a manutenção de produtos de software.

14 14 FUNCTIONAL SOFTWARE REQUIREMENTS: INITIAL REFLECTIONS RELATED TO THE INFLUENCE OF THE SPECIFICATION METHOD IN PROJECT MANAGEMENT CHARACTERISTICS ABSTRACT This paper presents a relation between the method used to specify functional requirements (using natural language) and three aspects that can characterize difficulties in software projects: the negotiation to realize incremental deliveries of the product, the change requests as a potential source to increase product scope and acceptance test cases elaboration (Leffingwell, Widrig, Pressman). Using the requirement granularity concept (Robertson & Robertson), this work proposes some analytical reflection considering the specification of the same requirement in different ways, which allow an evaluation of how some difficulties related to these three aspects can be minimized when using a requirement s specification granularity that reduces misunderstandings (Alexander, Stevens) between technicians and users. Keywords: Requirements Engineering. Software scope management. Software partial delivery. Software test cases.

15 15 REFERÊNCIAS ALEXANDER, Ian F.; STEVENS Richard. Writing Better Requirements. Londres: Addison-Wesley, CHRISSIS, Mary B.; KONRAD, M.; SHRUM, S. CMMI Guidelines for process integration and product improvement. Boston: Addison-Wesley, JACOBSON, I.; BOOCH, G.; RUMBAUGH, J. The unified software development process. Boston: Addison-Wesley, JACOBSON, I.; NG, Pan-Wei. Aspect-Oriented software development with use cases. Boston: Addison-Wesley, JONASSON, H. Determining project requirements. Boca Raton: Auerbach Publications, KOTONYA, G.; SOMMERVILLE, I. Requirements Engineering Processes and Techniques. New York: John Wiley & Sons Inc, LEFFINGWELL, D.; WIDRIG, D. Managing Software Requirements Second Edition A use case approach. Boston: Addison-Wesley, LEON, A. Software configuration management handbook. Boston: Artech House, LUTOWSKI, R. Software Requirements: encapsulation, quality and reuse. Boca Raton: Auerbach Publications, MAZZA, C. et al. Software Engineering Standards. Londres: Prentice-Hall, NADIN, M. Interface design: a semiotic paradigm. In: Semiotica 69-3/4. Amsterdam: Mouton-de Gruyter, 1988, p Disponível em: < Acesso em: 03 fev PRESSMAN, R., Software Engineering: A Practitioner s Approach: European Adaptation. Londres: McGraw-Hill International, ROBERTSON, S.; ROBERTSON, J. Mastering the requirements process: Second Edition. Boston: Addison Wesley, WIEGERS, Karl E. Software requirements. Redmond: Microsoft Press, WITHALL, S. Software requirement patterns. Redmond: Microsoft Press, 2007.