Um Guia para Especifi cação de Requisitos em Manutenção

Estou concluindo meu mestrado em ciência da computação na PUC-RS. Escrevi alguns textos no decorrer do curso que não foram inteiramente aproveitados na dissertação. Apresento aqui um desses textos onde eu faço uma relação entre grau de formalidade do processo de software e a necessidade de especificação com objetivo de se chegar a um balanceamento mais adequado entre os dois fatores.

Resumidamente o meu ponto é o seguinte: dependendo do contexto podemos ter um grau maior ou menor de formalismo em relação à especificação de requisitos. Baseado em minha experiência, acredito que a especificação de requisitos é necessária para QUALQUER PROJETO INDEPENDENTE DO TAMANHO. Para isso devemos adequá-la às exigências contratuais ou características do projeto tais como tamanho, lifespan do sistema, importância e risco do negócio. ISTO NÃO SIGNIFICA ESCREVER REQUISITOS EM PAPEL DE PÃO.

O problema é que a insegurança leva as pessoas à busca de subterfúgios como a incontinência verbal. Este é o ponto em que nascem documentos extensos e ilegíveis, portanto, inúteis. Cockburn fala muito bem ao dizer que o que dá valor a uma especificação não é sua extensão e sim sua acurácia. Isto exige um bom trabalho cognitivo que pode ser otimizado com uma certa dose de experiência. Por isso gosto desta citação do Pascal:

"I have made this letter longer than usual, only because I have not had the time to make it shorter." - Blaise Pascal

O texto é bem "academiquês" mas acho que a leitura pode ser proveitosa. Segue.



Um Guia para Especificação de Requisitos em Manutenção

Souza et al. [Souza:2005] reafirma o problema histórico de documentação de requisitos e software regidos tanto pelo modelo da Análise Estruturada como pelo modelo de Análise e Projeto Orientados a Objetos. Nesta seção será abordada a forma de especificação do Processo Unificado. O objetivo das próximas seções é descrever uma estrutura lógica fundamental de especificação de requisitos para reconstrução e na seqüência expor alguns critérios para seleção e balanceamento entre a abordagem do Processo Unificado e alguns métodos tradicionais.

A Especificação de Requisitos de Software no Processo Unificado RUP

Em sistemas legados, onde a documentação de projeto, requisitos e design possa estar comprometida, pode ser difícil a especificação de um ponto de partida para a redocumentação de um sistema. O estabelecimento de uma estrutura básica pode ser de grande valia para a dimuição da ansiedade da equipe durante a adoção de um processo novo[Kroll:2006] e, consequentemente, do tempo necessário para o início do projeto.

Neste sentido o RUP pode prover uma estrutura principal, orientada a casos de uso, que pode servir como base não somente para os esforços de restauração de requisitos como eventuais esforços na redocumentação de elementos de design e processamento. Para tanto o RUP provê um formato moderno de SRS [Leffingwell:1999, Kroll:2006].

Ao invés de se valer de um formato convencional de documento SRS, essa abordagem provê uma estrutura lógica de especificação no formato de um pacote de artefatos construídos a partir da visão do produto, conforme mostrado na figura a seguir.



O ponto de partida é o documento de visão contendo:

• necessidades;
• metas;
• objetivos;
• mercados alvo;
• características do sistema.

Com a visão formada pode-se prosseguir com a especificação o pacote SRS. Este é formado através do balanço adequado entre modelagem orientada a casos de uso e técnicas tradicionais de especificação de requisitos. Apesar do foco do PU em casos de uso, há o espaço para abordagens tradicionais de especificação contempladas pelo artefato de Requisitos Suplementares[Kroll:2006].

Os Requisitos Suplementares são identificados seguindo-se o esquema FURPS+ de classificação de requisitos. O nome do esquema é um acrônimo para:

• Functionality (Funcionalidade): requisitos funcionais;
• Usability (Usabilidade): fatores humanos como facilidade de uso do sistema;
• Reliability (Confiabilidade): a habilidade de conservação das funções do sistema sob condições normais de operação;
• Performance (Desempenho): quantidade de trabalho realizado pelo sistema em relação ao tempo e recursos consumidos;
• Supportability (Sustentabilidade): habilidade da equipe técnica em instalar, configurar e monitorar produtos de software;
• + (símbolo “mais"): demais requisitos não funcionais como restrições de design, restrições de implementação, restrições de interface e restrições físicas.

A orientação a casos de uso do RUP faz parte de um conceito maior de especificação de arquitetura de software[Kruchten:1995, Kruchten:2001, Kruchten:2003]. Dadas as necessidades de diferentes perfis de stakeholders que o projeto de software deve atender, usa uma abordagem de pontos de vista para separar aspectos do software de acordo com o interesse do stakeholder. Esse é o modelo 4+1 de arquitetura de software, visto na figura a seguir.



As visões do modelo 4+1 são a lógica, processos, implementação e implantação, cada qual com objetivo e público específicos. No entanto a visão que une as demais perspectivas é a visão de caso de uso, cujo objetvo é capturar os requisitos mais significativos na forma de casos de uso ou partes de casos de uso que têm grande impacto na arquitetura do software, bem como os demais requisitos não funcionais.

Equilíbrio entre abordagens orientadas a caso de uso e abordagens tradicionais de requisitos

Há divergências na comunidade de requisitos a respeito da abrangencia da modelagem de requisitos em casos de uso. Segundo autores como Wiegers e Davis [Davis:2005, Wiegers:2003, Wiegers:2006], casos de uso não substituem requisitos funcionais especificados em um modelo de SRS convencional. Wiegers ainda aponta que há uma impedância na acomodação de requisitos não funcionais entre casos de uso do PU e na documentação de Requisitos Suplementares.

Neste sentido estes autores afirmam preferir o uso de casos de uso como um meio para se chegar a especificação de requisitos baseada em listas semi-estruturadas.

No entanto há esforços para a adoção de abordagens híbridas de especificação e modelagem[Kroll:2006, Ambler:Primer:2004]. Wiegers afirma ainda que casos de uso sofrem limitações quanto a natureza do projeto, principalmente quando a complexidade do sistema não se estabelece nas interações entre sistema e usuário e sim em camadas mais profundas de sistemas tais como:

• data warehouses;
• processamento em lote (batch);
• hardware com software de controle embarcado;
• aplicações de computação intensiva.

Leffingwell propõe a adoção de casos de uso ou especificações tradicionais seguindo critérios baseados nas características da equipe e do projeto. Estes critérios são mostrados na tabela abaixo (clique para expandir).




Cerimônia de um Processo de Software

Cada processo de software como o PU e derivações bem como processos ágeis como Extremme Programing (XP) e Scrum podem ser comparados em um mapa de processos [Kroll:2006, Kruchten:2003, Larman:2003]. Este mapa é um plano composto das dimensões:

• Pouca Cerimônia (Low Cerimony)/Muita Cerimônia (High Cerimony): no eixo horizontal. A Pouca Cerimônia produz documentação mínima e possui pouco formalismo; Muita Cerimônia produz documentação abrangente e alta rastreabilidade entre artefatos, também conhecido como peso do método.
• Cascata (Waterfal)/Iterativo(Iterative): no eixo vertical. Cascata é uma abordagem linear do Processo de Software com integração e testes tardios; Iterativo é uma abordagem orientada a riscos com adoção de uma arquitetura e testes antecipados.

A Figura acima mostra três possíveis configurações do RUP no mapa de processos de Kroll, onde a iteratividade é o fator pervasivo. O grau de formalismo de cada processo é evidenciado pelo deslocamento lateral de cada configuração. O OpenUP/Basic pode ser considerado uma configuração análoga à Light RUP Configuration da figura. A localização de uma configuração no mapa pode ajudar na sua adequação do PS frente às características e necessidades de um SI ou organização. Na próxima seção serão abordados alguns aspectos para a o balanceamento adequado da especificação de requisitos.

Abordagens "Suficientemente Boas" para Especificação e Modelagem de Requisitos e a Redocumentação

Frente aos problemas de domínios dinâmicos e requisitos voláteis, movimentos baseados em metodologias ágeis têm-se firmado nos últimos anos. De movimentos mais contundentes, como o Extreme Programming, onde o peso do processo foi preterido em favor da informalidade veio a necessidade de se estabelecer um maior balanço entre o peso do processo, a carga de produção dos subprodutos de um software (como documentação, de requisitos ou técnica) e a entrega do sistema em si [Rosenberg:2003, Kroll:2006].

Neste sentido um tema recorrente a literatura é o balanceamento entre a agilidade e a disciplina de um determinado método. Estas abordagens podem ser referidas como “suficientemente boas" (good enough) e têm como valor a adequação e dimensionamento das práticas do processo de software frente às características específicas do software em desenvolvimento.

Neste sentido, Davis[Davis:2005] afirma que o cronograma do projeto deve ser considerado um fator importante para a definição do tempo gasto em requisitos. Um fator que pode servir como contrapeso em relação ao cronograma é o risco, mudando assim o nível de formalismo necessário para o desenvolvimento do produto.

Ambler [Ambler:Primer:2004] propõe a metodologia Modelagem Ágil (Agile Modeling) com o objetivo de oferecer um guia para viabilização da modelagem de um sistema guiada por valores, princípios e práticas que susbsidiem o uso de modelos com pouco grau de cerimônia. Estas práticas contemplam a modelagem e especificação de requisitos na forma de modelagem de utilização, prototipação de interface do usuário e especificação de requisitos suplementares. Ambler compara sua abordagem sobre documentação a “viajar com pouco peso" (traveling light), onde modelos e documentos são criados de forma “suficientemente boa" para prosseguir o desenvolvimento.

O trabalho de Ambler é corroborado por [Rüping:2003], que afirma que pouca documentação, mas "suficiente", é mais acessível e portanto mais útil para uma equipe do que muita documentação. Rüping preconiza que o valor da documentação está associado à concisão e sua acessibilidade frente aos leitores e propõe que a utilidade da documentação, a partir de certa quantidade, tende a diminuir, como mostrado na figura abaixo. Um fator importante para manter a documentação útil é seu nível de abstração (princípio adotado tanto pelo OpenUP [Kroll:2006] como pelo método de gerência de [Bittner:2006]): detalhes tendem a mudar mais rapidamente que a documentação portanto são melhor comunicados informalmente.



Um fator que serve de “contrapeso" para a decisão sobre a forma de documentação em relação ao princípio traveling light são as informações necessárias para os esforços de manutenção do sistema[Larman:2003, Highsmith:2002]. Larman recomenda que a necessidade seja utilizada como critério para balanço ao invés de especular-se a respeito da documentação, assim uma equipe mantenedora pode tornar-se fonte de informações valiosas a respeito das necessidades de documentação.

O esforço despendido no balanço da documentação torna-se especialmente relevante no contexto de redocumentação[Yang:2003] de um produto de software num processo de Engenharia Reversa. Deve-se levar em conta que à medida do avanço na recuperação de artefatos de requisitos, o sistema legado está sendo submetido à mesma carga de requisições de mudanças característica do domínio dinâmico. Neste sentido a acurácia da documentação [Cockburn:2001] é um quesito imperativo.

Casos de Uso como Ponto de Partida para Modelagem e Especificação de Requisitos

O ponto de partida para o balanço dos requisitos tomado neste trabalho são os Casos de Uso. Apesar das críticas às limitaçõesde Casos de Uso como modelos efetivos para documentação dos requisitos de um sistema [Fortuna:2005, Wiegers:2006, Davis:2005], no contexto de sistemas legados onde a documentação, sobretudo a de requisitos, é precária.

A estratégia para início da reconstrução dos requisitos de um sistema nestas condições é valer-se do comportamento externo do sistema para a descrição do sistema. Assim, a perspectiva do usuário torna-se mais valiosa para a formação de um referencial comum entre a equipe mantenedora e o usuário formando a estrutura de ligação do projeto [Cockburn:2001]. A abordagem de cenários e a modelagem da utilização do sistema[Ambler:Primer:2004, Kroll:2006] têm sua importância aumentada uma vez que a documentação pertinente aos demais aspectos do software como design e requisitos funcionais pode encontrar-se completamente perdida[Souza:2005].

Apesar dos debates entre defensores de abordagens orientadas a objetivos e cenários[Fortuna:2005], alternativas para composição de objetivos, cenários e casos de uso podem ser encontrada com o emprego de abordagens de Cockburn e Ambler. Cockburn propões a estratificação do conjunto de casos de uso em níveis: sumário, objetivos e subfunções em um esquema de padrão de caso de uso chamado EverUnfoldingStory, ou desdobramento contínuo da história[Cockburn:2002]. Ambler utiliza a abordagem de Casos de Usos Essenciais onde estes têm por função capturar os objetivos do usuário e declará-los de forma mais suscinta que um caso de uso convencional, ou como Ambler chama “de Sistema"[Ambler:Primer:2004]. Em ambas a orientação para a estruturação dos cenários em torno de um objetivo de negócio maior é continuamente enfatizada.

Enriquecimento de Requisitos no Contexto de Redocumentação

A questão de balanço entre utilidade e tamanho da documentação recuperado pode ser atingida através da adoção dos Casos de Uso como estrutura de ligação do projeto [Cockburn:2001]. Para o posterior enriquecimento dinâmico dos requisitos recuperados via Casos de Uso mantendo a qualidade e utilidade da documentação pode-se observar do princípio “Múltiplos Modelos" da Modelagem Ágil[Ambler:Primer:2004] e o emprego do Padrão de Caso de Uso “Adornos" (Adornments) [Cockburn:2002].

Casos de Uso, a medida de sua evolução podem se tornar pesados, portanto menos úteis, caso sejam complementados com requisitos não-funcionais, assim o uso de requisitos suplementares torna-se relevante para manter o valor do Caso de Uso quanto a concisão e acesso. Um esquema do padrão Adornos de Cockburn pode ser visto na figura abaixo, onde pode-se observar a ligação entre especificações de interfaces de usuário, requisitos de performance, dicionário de dados, regras de negócio e restrições e o Caso de Uso.




Sistemas legados podem encontrar-se desenvolvidos em tecnologias ou paradigmas que são anteriores as propostas de métodos como a família do PU ou Modelagem Ágil. Neste cenário determinados modelos, como os propostos pela UML, podem não ser adequados para o esforço de documentação do sistema. Ambler faz um discernimento entre os conceitos de modelagem e modelagem visual, considerando importante também o emprego de modelos textuais e afirma que cada modelo tem um propósito específico daí a necessidade do princípio "Múltiplos Modelos": utilizar uma técnica adequada a cada situação. Sendo assim a estruturação dos modelos de requisitos para um projeto de manutenção torna-se uma atividade importante para adequação da estrutura de artefatos utilizada para recuperação dos requisitos.

Afora a importância da se utilização do modelo correto, ressalta-se a importância do uso de artefatos (podendo estes ser decorrentes de modelos) como registro do trabalho da equipe e como veículo de transmissão de conhecimento sobre o projeto[Bittner:2006]. Artefatos devem ser produzidos para mitigar riscos do projeto ou para satisfazer alguma abordagem de desenvolvimento, bem como o grau de formalismo demandado, de um quadro branco, como na Modelagem Ágil, como pelo uso de ferramentas de software específicas. Deve-se observar os riscos da produção de artefatos sem o devido entendimento do porquê este está sendo trabalhado. O uso de um artefato apenas por este ser definido no processo sem o entendimento de seu propósito pode levar a uma explosão de artefatos. O autor sugere o emprego de uma Matriz de Artefatos contendo os artefatos produzidos pelo projeto e seu uso em fases e iterações no PU.

Referências


[Ambler:Primer:2004] Scott Ambler. The Object Primer. Cambridge University Press, 3rd edition, 2004.

[Bittner:2006] Kurt Bittner and Ian Spence. Managing Iterative Software Development
Projects. Addison Wesley Professional, 2006.

[Cockburn:2001] Alistair Cockburn. Writing Effective Use Cases. Addison-Wesley, 2001.

[Cockburn:2002] Steve Adolph, Paul Bramble, Alistair Cockburn, and Andy Pols. Patterns for
Effective Use Cases. Addison-Wesley, 2002.

[Davis:2005] Alan M. Davis. Just Enough Requirements Management. Dorset House, 2005.

[Fortuna:2005] Michel Heluey Fortuna and Marcos R. S. Borges. Modelagem informacional
de requisitos. In WER, pages 269280, 2005.

[Highsmith:2002] Jim Highsmith. Agile software development ecosystems. Addison-Wesley
Longman Publishing Co., Inc., Boston, MA, USA, 2002.

[Kroll:2006] Per Kroll and Bruce MacIsaac. Agility and Discipline Made Easy: Practices
from OpenUP and RUP. Addison Wesley, 2006.

[Kruchen:1995] Philippe Kruchten. The 4+1 view model of architecture. IEEE Software,
12(6):42-50, 1995.

[Kruchten:2001] Philippe Kruchten. The Rational Unied Process An Introduction. Addison
Wesley, second edition edition, 2001.

[Kruchen:2003] Per Kroll and Philippe Kruchten. The Rational Unied Process Made Easy:
A Practitioner's Guide to the RUP. Addison Wesley, 2003.

[Larman:2003] Craig Larman. Agile and Iterative Development: A Manager's Guide. Addison
Wesley, 2003.

[Leffingwell:1999] Dean Lefingwell and Don Widrig. Managing Software Requirements - An
Unied Approach. Addison Wesley, 1999.

[Rosenberg:2003] Matt Stephens and Doug Rosenberg. Extreme Programming Refactored: The
Case Against XP. Apress, 2003.

[Rüping:2003] Andreas Rüping. Agile documentation : a pattern guide to producing
lightweight documents for software projects. John Wiley & Sons, 2003.

[Souza:2005] Souza, Nicolas Anquetil, and Kathia M. de Oliveira. A study of the
documentation essential to software maintenance. In SIGDOC '05: Proceedings
of the 23rd annual international conference on Design of communication ,
pages 68-75, New York, NY, USA, 2005. ACM Press.

[Wiegers:2003] Karl E. Wiegers. Software Requirements. Microsoft Press, 2nd edition, 2003.

[Wiegers:2006] Karl E. Wiegers. More About Software Requirements: Thorny Issues and

[Yang:2003] Hongji Yang and Martin Ward. Successful Evolution of Software Systems.