Autores: Edna Pacheco Zanlorenci e Robert Carlisle Burnett

Apresentação

O primeiro Simpósio Brasileiro de Qualidade de Software (I SBQS), realizado em Gramado, em outubro de 2002, com o Simpósio Brasileiro de Engenharia de Software (SBES), evidenciou a importância da abordagem da qualidade aplicada à Engenharia de Software. Em anos anteriores o evento era organizado como workshop em paralelo ao SBES.

O rol de trabalhos apresentados reuniu pesquisadores, acadêmicos e profissionais da área de software do Brasil e do exterior.

O texto apresenta um resumo do artigo apresentado no I SBQS, com o objetivo de abordar os processos e técnicas da Engenharia de Requisitos, nas fases do ciclo de vida de projeto, com o foco no conhecimento exigido das funcionalidades e das características de qualidade do produto a construir, apoiadas por um roteiro (script) de descrição de requisitos e um guia (checklist) para avaliação da qualidade (processo e produto) em cada fase de projeto. Apresenta também o enfoque de uma abordagem alternativa para a descoberta de requisitos em software em operação.

1 Fundamento da Abordagem

Cabe à Engenharia de Requisitos, como sub-área da Engenharia de Software, aperfeiçoar os processos para o gerenciamento do ciclo de vida dos requisitos. O sucesso do processo de desenvolvimento implica em praticar o uso de padrões de qualidade estabelecidos nas normas ISO/IEC: 9000 (gestão da qualidade) 12207 (ciclo de vida processos) 9126-x / 14598-série 25000 SQUARE (qualidade do produto), de referência aos modelos de maturidade dos processos CMMI, de métodos e técnicas de gestão PDCA (Planning, Do, Control, Action) e técnicas de gerência de projeto PMBOK.

A abordagem propõe a idéia representada na figura.1, sob três aspectos: processos da Engenharia de Requisitos, fases de projeto e produtos nas fases de projeto.

Para visualiar a figura clique aqui.

Figura.1 - Processos de RE e Fases de Projeto

A figura.1 foca a aplicação dos processos da Engenharia de Requisitos nas fases de projeto. Na parte inicial, apresenta o ciclo dos processos da Engenharia de Requisitos (descobrimento, análise, validação, documentação e gerência de requisitos), relacionados às fases de projeto. Na parte intermediária, apresenta o tratamento do requisito em cada fase de projeto (identificação da demanda, estudo de viabilidade, modelo lógico, modelo físico, construção e implantação), independente do ciclo de vida a ser adotado para o projeto (cascata, incremental, iterativo,...). Na parte final, apresenta os produtos gerados em cada fase do projeto.

Do ponto de vista de obtenção da informação, os processos de tratamento de requisitos, têm seus produtos esperados com detalhamento progressivo à medida que evolui o trabalho de desenvolvimento nas fases de projeto. A tabela.1 tem o objetivo de apresentar a ocorrência dos processos de Engenharia de Requisitos, visualizados nas fases de projeto.

Tabela.1 - Relacionamento entre Processos RE e Fases de Projeto

Para visualiar a figura clique aqui.

legenda: x = ocorrência de processos de requisitos (1, 2, 3, 4, grau de detalhamento, do geral para específico) requisitos:

FR = requisitos funcionais (o que é e o que faz)
NFR = requisitos não-funcionais (qualidade do que é e do que faz)

O tratamento da informação, requisitos no ciclo de vida do produto, conforme a visão anteriormente disposta, parte da idéia de que em cada fase de projeto tem-se uma versão de descrição de requisitos, tanto os funcionais (FR) como os não-funcionais (NFR), que se constituem em um produto intermediário do projeto, para cada fase de projeto.

Figura.2 - Roteiro de Descrição de Requisitos, nas Fases de Projeto

A execução sistemática dos processos depende da aplicação de um roteiro (script), que conforme apresentado na figura.2, direciona a constituição do produto referenciado pelos requisitos, considerando-se as fases de projeto da proposta. O roteiro constitui-se de duas etapas fundamentais: a primeira, abrange as fases 1 e 2 de projeto: demanda e estudo de viabilidade para conhecimento e priorização dos requisitos; a segunda, abrange as fases de modelo lógico, físico, construção e implantação do projeto, o detalhamento dos modelos e a implementação para o refinamento dos requisitos.

2 Modelo para Qualidade

O uso da Engenharia de Requisitos varia em cada organização. Este assunto é apresentado por Sommerville, em seu livro Engineering Requirements, referindo-se a três tipos de guia de referência aplicáveis (básico, intermediário, avançado) e a uma lista das dez mais atitudes para o sucesso do processo, indicando a restrição quanto a considerar o nível de maturidade da organização e o tipo de software a desenvolver. O modelo é uma adaptação do guia de referência de Sommerville, ao roteiro do processo de descrição de requisitos (figura.2), revisada após a aplicação prática em projetos com escopos diferentes.

O guia de referência, em cada fase de projeto, é apresentado em quatro partes: lista de atividades, processos da Engenharia de Requisitos, técnicas de captura e de representação dos requisitos e operacionalização da avaliação do resultado.

2.1 Fase de Entendimento da Demanda

Na fase de entendimento da demanda inicial (tabela.2), obtém-se os requisitos como informações genéricas, não declaradas, serão baseadas no entendimento do contexto do negócio, do ponto de vista dos stakeholder envolvidos com a encomenda do produto.

Tabela.2 - Guia de Referência da Fase de Entendimento de Demanda

Para visualiar a figura clique aqui.

(*) processo: des - descobrimento, ana - análise, val - validação, doc - documentação, ger - gerência
(#) operacionalização
uso: p - padrão, c- convencional
ckl: o - obrigatório, x - opcional

As atividades devem seguir o roteiro para contextualização do assunto. Os processos desta fase abrangem o descobrimento e a documentação do que é para ser feito.As técnicas utilizadas para captura devem ser as adequadas ao ambiente do negócio, observando a disponibilidade de tempo da fonte de informação. A representação da informação é documental, podendo ser em linguagem natural.

O produto é um documento inicial de demanda, cujo conteúdo orienta-se pelos elementos constitutivos do roteiro (figura.2, #1): contexto, domínio da aplicação, cenários, linguagem comum ao contexto, stakeholder, papéis e responsabilidades dos stakeholder, cuja finalidade é orientar o planejamento das atividades da fase seguinte, o estudo de viabilidade.

A abordagem da qualidade desta fase é o entendimento do contexto do negócio e identificar o universo dos stakeholder.

2.2 Fase de Estudo de Viabilidade (estudo preliminar)

Na fase de estudo de viabilidade (tabela.3), o conhecimento depende da participação de pessoas do cliente e com a habilidade para tal, necessitando de representação dos níveis decisórios da organização.

Tabela.3 - Guia de Referência da Fase de Estudo de Viabilidade

Para visualiar a figura clique aqui.

(*) processo: des - descobrimento, ana - análise, val - validação, doc - documentação, ger - gerência
(#) operacionalização
uso: p - padrão, c - convencional
ckl: o - obrigatório, x - opcional

As atividades desta fase são as mais extensas, abrangem quatro processos para requisitos e são fundamentais para o conhecimento da informação. Os processos são iterativos: descobrimento, análise, validação e documentação. As técnicas na captura das informações deverão ser aplicadas a pessoas com pontos de vista variados, segundo Leite, dentro de um contexto definido.

Os produtos são: documento da linguagem comum ao contexto, documento descritivo dos requisitos funcionais qualificados e priorizados e a visão inicial de requisitos não-funcionais ou de qualidade; documento preliminar de riscos de implantação de requisitos; documento que visualiza o rastreamento de requisitos, condições preliminares para teste e características genéricas de qualidade. Os conteúdos dos documentos orientam-se pelos elementos constitutivos do roteiro (figura.2, #2): fundamentados a partir do ponto de vista do problema e do requisito. A finalidade é orientar o planejamento das atividades da fase seguinte, a representação do modelo lógico de solução com a definição de alternativas.

A abordagem da qualidade é a obtenção da descrição dos requisitos representativos do contexto, devidamente qualificados, relacionados e priorizados, envolvendo uma amostra representativa do universo dos stakeholder.

2.3 Fase de Modelo Lógico

Na fase de modelo lógico (tabela.4), o processo de descobrimento (tabela.1) apresenta o esforço na definição clara de papéis e de responsabilidades dos stakeholder pelos eventos, a visão preliminar dos processos de negócio, restrições e premissas.

Tabela.4 - Guia de Referência da Fase de Modelo Lógico

Para visualiar a figura clique aqui.

(*) processo: des - descobrimento, ana - análise, val - validação, doc - documentação, ger - gerência
(#) operacionalização
uso: p - padrão, c - convencional
ckl: o - obrigatório, x - opcional

As atividades desta fase são específicas de detalhamento dos eventos do negócio e, conseqüentemente, contribuem para o refinamento dos requisitos já identificados. Os processos são iterativos, constituem-se de descobrimento, análise, validação e de documentação dos eventos associados aos requisitos priorizados. As técnicas utilizadas para captura e representação devem ser adequadas a uma linguagem acessível ao público-alvo, observando a essência do processo que é a comunicação entre os participantes. A representação da informação é documental, utilizando-se modelos.

Os produtos são: documento do modelo de representação dos eventos associados aos requisitos com papéis e responsabilidades dos stakeholder, documento descritivo da base de dados, documento preliminar de riscos e de teste de projeto, métricas de qualidade e do documento que propõe alternativas de solução. Os conteúdos dos documentos orientam-se pelos elementos constitutivos do roteiro (figura.2, #3): detalhando os eventos a partir dos requisitos funcionais, gerando opções de alternativas de solução, cuja finalidade é orientar o planejamento das atividades da fase seguinte, a representação do modelo físico da alternativa selecionada para a especificação técnica de processos e produtos do negócio.

A abordagem da qualidade desta fase é a obtenção dos modelos de representação dos eventos, especificando alternativas de solução com o uso de tecnologia da informação.

2.4 Fase de Modelo Físico

A fase de modelo físico (tabela.5), representa na especificação da solução, os processos de negócio e os produtos.

Tabela.5 - Guia de Referência da Fase de Modelo Físico

Para visualiar a figura clique aqui.

(*) processo: des - descobrimento, ana - análise, val - validação, doc - documentação, ger - gerência
(#) operacionalização
uso: p - padrão, c - convencional
ckl: o - obrigatório, x - opcional

As atividades desta fase são específicas de detalhamento das funções de solução. É essencial completar a descrição e o refinamento dos requisitos não-funcionais, as características de qualidade e as métricas, principalmente, a definição de prioridade de atendimento dos mesmos em relação às necessidades de negócio e à solução de software adotada. Os processos são iterativos, constituem-se de descobrimento, análise, validação e documentação da especificação de solução em como atender aos requisitos estabelecidos. As técnicas utilizadas para captura e representação são de domínio da equipe de projeto e voltadas para o público-alvo que construirá o projeto.

Os produtos são: documento do modelo de representação dos processos e produtos de negócio, documento descritivo da base de dados, documento de riscos de projeto, documento de testes, documento que propõe métricas para avaliação de qualidade do produto de software. Os conteúdos dos documentos orientam-se pelos elementos constitutivos do roteiro (figura.2, #4): detalhando os processos e produtos a partir da especificação da solução, orientando a arquitetura e comunicação entre as funções, cuja finalidade é orientar o planejamento das atividades da fase seguinte, a construção do software e, especialmente, fundamentar os processos de gerência de requisitos, gerência de testes, gerência de riscos e gerência de qualidade do software.

A abordagem da qualidade desta fase é a obtenção das informações dos processos e dos produtos e subsídios para os processos de gestão.

2.5 Fase de Construção

A fase de construção (tabela.6) além de representar a arquitetura das funções de software, é o marco inicial dos processos de gestão de requisitos, de riscos, de testes e de qualidade, pois é nesta fase que se tem a descrição completa da arquitetura da função que implementará a funcionalidade e as características de qualidade dos requisitos estabelecidos. Um fato particular é o registro das solicitações de mudanças que ocorrerem após o projeto da solução ter sido concluído.

Tabela.6 - Guia de Referência da Fase de Construção

Para visualiar a figura clique aqui.

(*) processo: des - descobrimento, ana - análise, val - validação, doc - documentação, ger - gerência
(#) operacionalização
uso: p - padrão, c- convencional
ckl: o - obrigatório, x - opcional

As atividades desta fase correspondem ao registro das ocorrências de construção do software. Os processos são iterativos, constituem-se de descobrimento, análise, validação e de documentação da arquitetura e comunicação entre funções em como atender aos requisitos. As técnicas utilizadas para captura e representação são de domínio da equipe que desenvolve o projeto. A representação da informação é documental.

Os produtos são: documento do modelo de representação da arquitetura e comunicação entre funções, documento descritivo da base de dados, documento de riscos de projeto, documento de validação de testes, documento que valida métricas para avaliação de qualidade do software. Os conteúdos dos documentos orientam-se pelos elementos constitutivos do roteiro (figura.2, #5): detalhando as funções, cuja finalidade é orientar o planejamento das atividades da fase seguinte, a implantação do software e, especialmente, fundamentar os processos de transferência de tecnologia, políticas, normas e padrões e resultados da aplicação.

A abordagem da qualidade desta fase é o relato de avaliação dos processos de gerência de requisitos quanto às mudanças, de gerência de riscos do projeto, de gerência de casos de testes, de gerência de qualidade e das métricas de qualidade dos processos e dos produtos.

2.6 Fase de Implantação

A fase de implantação (tabela.7) é o marco inicial da divulgação da tecnologia construída, pois é nesta fase que se tem a visão completa da funcionalidade e das características de qualidade do software.

Tabela.7 - Guia de Referência da Fase de Implantação

Para visualiar a figura clique aqui.

(*) processo: des - descobrimento, ana - análise, val - validação, doc - documentação, ger - gerência
(#) operacionalização
uso: p - padrão, c - convencional
ckl: o - obrigatório, x - opcional

O processo é essencialmente documental. As técnicas utilizadas para captura e representação dos resultados são voltadas para o usuário. A representação da informação é a formalização de procedimentos e de uso dos produtos.

Os produtos são: documento do modelo de uso da tecnologia, normas e padrões e resultados aplicativos. Os conteúdos dos documentos orientam-se pelos elementos constitutivos do roteiro (figura.2, #6): detalhando os procedimentos, cuja finalidade é orientar o planejamento das atividades de implantação.

A abordagem da qualidade desta fase é o preparo do ambiente e as condições e políticas para implantação do software.

3 Aplicação Alternativa do Modelo

A aplicação do modelo prescinde de algumas considerações quanto ao resultado que se queira obter, quer para um projeto iniciante, seguindo a seqüência anteriormente apresentada ou para descobrir requisitos em software existente, cuja documentação não esteja adequada. A seguir apresenta-se a alternativa de uso do modelo para descobrir requisitos em software existente.

3.1 Objetivo

O objetivo desta alternativa é identificar em software pré-existente, quais os requisitos (funcionais e não-funcionais) que estão implementados no produto de software e como são operacionalizados nos diversos contextos de uso, tomando como referência, métricas de qualidade do produto software contidas na norma ISO/IEC 9126 e na série Square 25000.

3.2 Fatores a Considerar

O produto software não é um produto acabado, está sempre em mutação, esta originária de mudanças das regras do negócio, da necessidade de melhoria do processo e/ou adequação do produto ou do serviço disponível na organização.

O volume de software existente e considerado como legado nas organizações é relativamente maior que o desenvolvimento de novos projetos. Existe um patrimônio de produto software nas organizações que tem de ser mantido em funcionamento e, em sua maioria, contém as funções essenciais do negócio.

A maioria do software legado não possui documentação atualizada que se possa utilizar para o gerenciamento da mudança dos requisitos implementados ou saber da existência dos mesmos, sem a pesquisa no código implementado.

A manutenção do legado, na maioria das vezes, é feita de forma continuada, sem controle de versões, dada a urgência requerida pelo negócio. Conseqüentemente, as alterações são realizadas e o registro das mudanças nem sempre o são, realimentando o caos na gestão dos requisitos.

Um dos fatores primordiais para se obter um produto software adequado ao contexto de uso é o entendimento e a definição clara da política de negócio. Da mesma forma que a definição de requisitos, a definição clara da política de negócio constitui-se numa tarefa difícil a de registrar as informações de segurança da informação, precisão de resultado e do desempenho do produto software, no início do estudo do projeto. A demanda será entendida e construída de forma iterativa em função do conhecimento adquirido do negócio durante o processo de desenvolvimento. Ao final da construção do software, muita coisa é implementada sem se perceber que se refere, especificamente, à política da organização em relação as suas regras de negócio. Em decorrência disto, pode existir muita coisa implementada que não se encontra documentada adequadamente para se proceder a gerência de futuras mudanças.

3.3 Motivação

A literatura tem referência extensa na definição de requisitos para a construção de um novo produto de software, mas pouco ou quase nada em relação a descobrir os requisitos implementados no produto software implantado.

Os fatores relacionados anteriormente motivaram a abordagem alternativa de documentação dos requisitos a partir do produto software construído, analisado em seu contexto de uso, recompondo informações básicas para o processo de gerência de requisitos.

3.4 Metodologia

A metodologia a ser adotada é documentar informações de todas as fases de desenvolvimento de um projeto, a partir do detalhamento do produto software em operação, de maneira reversa (do produto final para a demanda inicial), incluindo os processos de gerência de testes, de riscos, de qualidade do produto software e qualidade do processo construtivo do software, para chegar ao detalhamento do que o software propõe-se a executar, ou seja, em atendimento à demanda inicial do negócio.

3.5 Heurística

A seqüência dos passos a serem seguidos corresponde às fases de desenvolvimento de um projeto, recompondo a descrição dos produtos intermediários gerados a cada fase, considerando-se do final para o início do projeto, na seguinte ordem:

3.6 Resultados Esperados

Os resultados esperados referem-se à obtenção da descrição final do produto software, quanto a suas funções e características de qualidade e pelas métricas aplicáveis aos produtos intermediários nas respectivas fases de projeto.

Como a abordagem sempre vai ser orientada pelo produto, aqueles que estão em desuso ou inadequados ao uso, farão parte de análise para serem descartados (processos da ISO/IEC 15288).

O benefício é ter-se a possibilidade de rastrear a definição dos requisitos estabelecidos, para o gerenciamento de mudança futura em base de dados específica.

Documentar a política de qualidade implementada no produto software para o contexto de uso correspondente.

4 Conclusão

O fator mais importante na aplicação da abordagem da qualidade é a evidência de que a partir do modelo teórico de utilização dos processos da Engenharia de Requisitos em um projeto, deve-se sempre aproveitar o momento e as circunstâncias em obter-se o conhecimento efetivo do que é para fazer.

Cabe aqui relembrar a tabela.1, Relacionamento dos Processos de ER com as Fases de Projeto, como um referencial para esta análise. O processo de descrição de requisitos é uma atividade indutiva e continuada. Tem conteúdo mais genérico na fase de entendimento da demanda. À medida que se avança nas demais fases de projeto, exige-se detalhamento e mais formalismo. As descrições de funcionalidade tornam-se mais específicas e completas e as de não-funcionalidade (qualidade) também o são.

A capacitação e o nível de maturidade da organização devem estar voltados para a geração de produtos intermediários e/ou finais a cada fase de projeto utilizando um roteiro formal para o conhecimento, análise, validação, documentação e gerência da informação. Da mesma forma, a utilização de checklist para avaliação dos processos e produtos resultantes a cada fase de projeto. Concluindo, a abordagem da qualidade em Engenharia de Requisitos, compreende a somatória de fatores: a organização estar apta para aplicação dos processos e da avaliação sistemática de resultados. É um processo complexo, cujo objeto é a definição clara de requisitos e sua aplicabilidade ao ciclo de vida de um projeto que permita a gestão de mudanças.

Referências

1. BOEHM, B.; IN, H. Identifying quality-requirement conflicts. USA: IEEE Software, mar. 1996. p. 25-35.

2. BOEHM, B. Software model conflicts and how to avoid them. In: SBES´98 XII SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 12., 1998, Maringá. Tutorial... Maringá: SBC, 1998. 80 p. Disponível em: <http://www.sunset.usc.edu>.

3. CASTRO, J.; ALENCAR, F.; CYSNEIROS, G.; MYLOPOULOS, J. From early requirements modeled by the I* Technique to later requirements modeled in precise UML. In: WER'00, WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro, 2000. p. 92-108.

4. CHUNG, L.; NIXON, B. A.; YU, E.; MYLOPOULOS, J. Non-functional requirements in software engineering. USA: Kluwer Academic Publishers, 2000. 439 p.

5. CMM PROJECT. CMM integratedsystems/software engineering. Pensylvania: Carnegie Mellon University, 1999. v. 1. (Public Release DRAFT - version 0.2b.)

6. CYSNEIROS, L. M.; LEITE, J. C. S. P; SÁBAT NETO, J. M. Non-functional requirements for object-oriented modeling. In: WER'00 III WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro, 2000. p. 109-125.

7. DOORN, J.; LEITE, J. C. S. P; KAPLAN, G. N; HADAD, G. D. S. Inspección del lexico extendido del lenguaje. In: WER'00 III WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro, 2000. p. 70-91.

8. FOCALPOINT. Prioritizing requirements: "What we want always exceeds what we can afford". Disponível em: <http://www.focalpoint.se/Metod/e_index.html>.

9. INTERNATIONAL STANDARD ORGANIZATION. ISO 9000 - quality management system. Geneve: ISO, 2000.

10. INTERNATIONAL STANDARD ORGANIZATION/IEC. Joint Technical Committee. Information technology - software engineering - product quality ISO/IEC 9126-x. part 1 Quality model; part 2 External metrics; part 3 Internal metrics; part 4 Quality in use. Geneve: ISO/IEC, 1996.

11. INTERNATIONAL STANDARD ORGANIZATION/IEC. Joint Technical Committee. Information technology - software engineering - product quality ISO/IEC 14598 (1-6). Geneve: ISO/IEC, 1998.

12. INTERNATIONAL STANDARD ORGANIZATION/IEC. Joint Technical Committee. Information technology - software engineering - life cycle process ISO/IEC 12207. Geneve: ISO/IEC, 1995.

13. KILOV, H. Business specifications, the key of successful software engineering. New Jersey: Prentice Hall, 1999. 301 p.

14. LEITE, J. C .S. P. Viewpoints on viewpoints. In: ISAW INTERNATIONA WORKSHOP ON MULTIPLE PERSPECTIVES IN SOFTWARE DEVELOPMENT, 2. San Francisco, 1996. Joint Proceedings ... San Francisco: ACM, 1996. p. 285-288.

15. PINHEIRO, F. A. C. Formal and informal aspects of requirements tracing. In: WER'00 WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro, 2000. p. 38-53.

16. PROJECT MANAGEMENT INSTITUTE. PMBOK: a guide to the project management body of knowledge. Pennsylvania: PMI, 2000, 216 p.

17. RYAN, K. Requirements engineering - getting value for money. In: SBES´98 SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 12., 1998, Maringá, Tutorial... Maringá: Sociedade Brasileira de Computação, 1998. p. 55 .

18. SOMMERVILLE, I.; SAWYER, P. Requirements engineering: a good practice guide. Chichester: John Wiley & Sons, 1997. 391 p.

19. ZANLORENCI, E. P; BURNETT, R. C. Modelo para qualificação da fonte de informação cliente e de requisito funcional. In: WER'98 WORKSHOP DE ENGENHARIA DE REQUISITOS, 1998. Anais... Brasil: SBC, 1998. p 39-48.

20. ZANLORENCI, E. P; BURNETT, R. C. Descrição e qualificação de requisitos: um modelo aplicável à análise e validação da informação. 1999. 229 p. Dissertação (Mestrado) - Pontifícia Universidade Católica do Paraná - PUCPR, Curitiba, 1999.

21. ZANLORENCI, E. P; BURNETT, R. C. Ferramenta de apoio aos processos de ER, nas fases de projeto. In: WER'00 WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., Rio de Janeiro, 2000. Anais... Rio de Janeiro: SBC, 2000. p. 181-193.

22. ZANLORENCI, E. P; BURNETT, R. C. O ciclo de vida de requisitos, nas fases de projeto. In: WORKSHOP DE ENGENHARIA DE SOFTWARE, 1., Punta Arenas, 2001. Anais... Punta Arenas: JCC, 2001. Em CD-ROM.

23. ZANLORENCI, E. P; BURNETT, R. C. O tratamento da informação (requisitos no ciclo de vida do produto) - caso prático: sistema de informações de previdência. In: WER'01 WORKSHOP DE ENGENHARIA DE REQUISITOS, 4., Buenos Aires, 2001. Anais... Buenos Aires: WER, 2001. p. 55-73.

24. ZANLORENCI, E. P; BURNETT, R. C. Certificação de qualidade em engenharia de requisitos. In: SBQS 2002 SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE,1., 2002. Anais... Brasil: SBC, 2002. p. 71-83.

Link para o artigo do I Simpósio Brasileiro de Qualidade de Software (SBQS)