Requisitos funcionais e não-funcionais, as duas faces da moeda aplicáveis à engenharia de software

Autores: Edna Pacheco Zanlorenci - GPT Robert Carlisle Burnett - PUC-PR

RESUMO

A idéia do artigo é focar o tratamento da informação requisitos, o ciclo de vida dos produtos de um projeto e as fases de projeto, com a aplicação em software. As fases de projeto[21] são aqui definidas como: entendimento da demanda, estudos de viabilidade do projeto, modelo lógico, modelo físico, construção da solução e implantação. Os processos de Engenharia de Requisitos[19,20] aplicáveis a requisitos são definidos como: descobrimento, análise, validação, documentação e gerência de requisitos[7]. Os processos de Gerência de Projeto[16] aplicáveis à gestão do projeto são: iniciação, planejamento, execução, controle e finalização.

1 INTRODUÇÃO

O tratamento da informação é um requisito que fundamenta o processo de desenvolvimento de software antes da solução de tecnologia a ser aplicada. Cada projeto deve ter suas fases de desenvolvimento adequadas às necessidades de tratamento da informação, voltadas para o resultado do produto contratado. É necessário o conhecimento das exigências e condições que são essenciais à organização para, de maneira seletiva, priorizar a implementação da solução [10,17] em atendimento a estas necessidades.

Fala-se muito sobre requisitos; propagam-se necessidades de gestão de mudanças, de atendimento ao cliente; diz-se muito de métodos, técnicas e ferramentas para descrevê-los e representá-los, mas muito pouco da aplicação prática deste conhecimento.

O requisito é uma condição cuja exigência deve ser satisfeita. Se a condição é produzir algo, diz-se que o requisito é funcional. Se a condição é caracterizar algo (atributo, propriedade, comportamento, restrição, etc,...), diz-se que o requisito é não-funcional. A descrição destes requisitos é uma atividade indutiva e continuada. Descrever requisitos funcionais e requisitos não-funcionais requer uma abordagem holística, tratando os dois aspectos: primeiro, "Produzir"; segundo, "com Qualidade", as duas faces da moeda aplicáveis à Engenharia de Software.

O processo de produção de software depende da definição clara de qual produto construir. Esta definição fundamenta-se no conhecimento do problema e na viabilização de oportunidade de negócio com o uso de tecnologia da informação. A estratégia é o tratamento multidisciplinar da informação de requisitos obtida do ponto de vista dos stakeholder (fonte de informação) para o entendimento e atendimento às necessidades.

O entendimento sobre o que é o projeto, é um fator determinante para definir o ciclo de vida de um produto a ser construído e, por conseguinte, a identificação e descrição dos requisitos. Portanto, descrever o quê (what), sob qual o papel desempenhado e a responsabilidade de quem (who), no momento oportuno (when), no contexto em estudo e com o domínio da aplicação (where), de que forma implementá-lo (how) e, principalmente, por quê (why) identificá-los, torna-se a causa do sucesso de um projeto, independente de sua complexidade.

A complexidade de um projeto de software, segundo Chung [6], é determinada parcialmente por suas funcionalidades (requisitos funcionais), isto é, "o quê" o sistema faz e, parcialmente, pelos requisitos globais dos custos de desenvolvimento e de custos operacionais, abrangendo as características de qualidade [1,2,11,12] (requisitos não-funcionais) "do que é" e "do que faz", em relação a: precisão, desempenho, segurança, confiabilidade, manutenibilidade, portabilidade, robustez, resposta ao usuário, restrições, premissas, entre outros.

O artigo propõe o tratamento dos processos e técnicas de Engenharia de Requisitos (descobrimento, análise, validação, documentação e gerência de requisitos) nas fases do ciclo de vida de um projeto de software (demanda, estudo preliminar, modelo lógico, modelo físico, construção e implantação). A aplicação prática relata as fases de entendimento da demanda e a de estudos de projeto (viabilidade) de um sistema de informações de negócio[13,15]. Inclui o tratamento de requisitos funcionais e não-funcionais ou de qualidade, estes, representados inicialmente por restrições, premissas e expectativas do cliente, compondo o documento inicial de requisitos.

2 MOTIVAÇÃO

A motivação para a realização deste trabalho concentra o esforço de consolidar a idéia de inserir o tratamento da informação requisitos aplicada a um contexto de desenvolvimento de projeto de software, com o apoio dos processos, técnicas e ferramentas de gerência de projeto (gerenciar processos de projeto e processos voltados a produto).

O assunto é oportuno porque trata de métodos de desenvolvimento e de processos da Engenharia de Requisitos para adequar às exigências de qualidade a descrição mais precisa do objeto de contratação para o desenvolvimento de software com o uso apropriado de tecnologia da informação.

A abordagem de tratamento das fases de um projeto depende do fator gerência de produto (ciclo de vida do produto) por quem é responsável pelo resultado do objeto contratado. Este objeto, entenda-se como produto, tem sua contratação e desenvolvimento fundamentado em um ciclo de vida. Quanto menos se conhece do objeto ou o domínio da aplicação, tanto mais fracionado deverá ser o planejamento do ciclo de vida do produto. Da mesma forma, quanto mais se conhece do que vai ser construído, mais previsível torna-se o planejamento e, portanto, com mais chance de sucesso.

O conhecimento exigido é sobre as funcionalidades e as características de qualidade do produto a construir. As restrições de prazo, de recursos financeiros e a imposição de tecnologia a serem aplicados ao processo de desenvolvimento, forçam a adoção de ciclos de vida adequados para a construção do produto. As fases de um projeto, dependendo da complexidade da informação a ser tratada, tornam-se subprojetos de um projeto maior e devem ser gerenciados como projetos e gerar produtos específicos.

A negociação de entrega de resultados intermediários é que dirigirá a continuidade do projeto, ou seja, a passagem para a fase seguinte do projeto ou de um novo projeto.

3 ABORDAGEM: FASES DE PROJETO X PROCESSOS DE ENGENHARIA DE REQUISITOS

A negociação para o desenvolvimento de um novo trabalho sempre envolve o interesse, por parte dos participantes, na metodologia a ser aplicada. Quando se trata de descrição de requisitos, não é diferente. É necessário, primeiramente, o entendimento comum do escopo do trabalho. Em seguida, o planejamento das atividades em função dos objetivos adequados ao produto que se quer construir. E, na seqüência, a negociação com o patrocinador contratante, sobre a convocação do grupo de trabalho e a forma de aplicação das técnicas, ferramentas e métodos para o entendimento comum na realização das atividades, com eficiência e eficácia. Quem define o escopo são os requisitos declarados pelo cliente.

O escopo do projeto não pode ser definido na ausência de algum entendimento básico de como criar o produto. É necessária a descrição do produto, ter acesso à informação histórica, identificar restrições ambientais e premissas.

A abordagem proposta para o trabalho descrito neste artigo, envolve a aplicação de uma metodologia centrada no tratamento da informação. O foco é entender a demanda do cliente para fundamentar o desenvolvimento do produto encomendado. Esta demanda é melhor entendida e esclarecida à medida que se avança no processo descritivo de requisitos, nas fases de projeto, cujo limite é a construção da solução.

Do ponto de vista genérico, o ciclo de vida de um projeto como exposto na figura 1, abrange todas as fases previsíveis de um projeto. Mas, o sucesso de desenvolvimento de um projeto depende do conhecimento e acordo de ambas as partes, contratante e contratado, sobre o resultado entendido e construído em todas as fases.

Figura 1: Fases de um Projeto de Software

As fases de entendimento da demanda, estudo preliminar e modelo lógico [5,8] devem ter concentrados os esforços de captura das funcionalidades requeridas para o software em atenção às questões de negócio do cliente, centradas no produto a construir para compor a solução. Não exclui a captura de informações sobre qualidade, restrições e premissas do ambiente e infra-estrutura.

A fase de modelo físico deve agregar aos requisitos funcionais, os requisitos não-funcionais obtidos nas várias oportunidades de captura de informações, tratá-los em termos de prioridade, precedência e relacionamentos entre si, com ênfase em como o software deve funcionar. Inclui a solução de tecnologia da informação a ser aplicada no software.

A fase de construção deve apresentar o produto construído adequado aos requisitos declarados. A fase de implantação deve especificar o ambiente e procedimentos para o funcionamento do software.

A informação capturada em qualquer fase de projeto é um produto que envolve opinião e ponto de vista[14] de pessoas, com interesses e prioridades diversos. Assim, a capacidade do interlocutor em interpretar o que é declarado pela fonte de informação e adequar à veracidade do que foi pretendido dizer, vai orientar e definir a técnica de comunicação na aplicação da metodologia.

A tabela 1 apresenta de forma resumida a idéia do tratamento da informação requisito nas fases de um projeto de software. Os requisitos funcionais e não-funcionais têm tratamento diferenciado em cada fase de projeto. Primeiro, é necessário definir o que é para fazer, qual produto gerar (requisito funcional); segundo, qual forma, conteúdo, comportamento, atributos deve conter o produto (requisito não-funcional). Isto quer dizer que somente se consegue definir atributos ou características de qualidade à medida que se tenha a definição do produto. E, conseqüentemente, medir a qualidade deste produto, após a definição dos requisitos não-funcionais. O processo culmina com a complementação das informações no modelo físico de implementação da solução. Isto se explica pelo fato que a alternativa de implementação física define o ambiente e a distribuição das funcionalidades operacionais do software.

Fases de PROJETO

Processos ER

1-enten.de- manda

2-estudo prelimi

3-modelo lógico

4-modelo físico

5-construção

6-implantação

REQUISITOS

NFR

descobrimento

análise

validação

documentação

gerência

legenda: x = ocorrência de processos de requisitos

requisitos:

FR = funcionais (o que faz)

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

Tabela1: Processos de Engenharia de Requisitos nas Fases de Projeto

O mapeamento das informações apresentado na figura 2 como roteiro metodológico da abordagem, representa o tratamento dos requisitos nas fases de projeto, compatibilizados com as fases propostas na figura 1.

Os elementos apresentam-se relacionados em forma de diagrama, numa seqüência encadeada de informações. As fases descritivas, apesar de apresentadas em grupos separados de 1 a 6, na figura 2, são sempre acumulativas e iterativas, ou seja, à medida que se avança no processo descritivo, novas informações surgem e complementam as já registradas nas fases anteriores até que se conclua o processo descritivo, antes da construção efetiva do software ou parte dele.

Na fase de entendimento da demanda, os esforços são direcionados para a clarificação do escopo do projeto. O contexto apresenta o foco da informação; o domínio da aplicação define a abrangência ou fronteira da informação no contexto; o cenário representa o ambiente de ocorrência da informação; os stakeholder são as pessoas ou organizações que atuam no cenário e exercem papéis específicos, utilizando uma linguagem comum[9] ao contexto em foco.

Figura 2: Informações de Descrição de Requisitos, nas fases de Projeto

Na fase de estudo preliminar ou estudos de projeto, fazem parte dois grupos de atividades distintos. O objetivo é captar informações para análise de viabilidade do projeto. Primeiro, os esforços são direcionados para a caracterização do problema e identificação dos requisitos do cenário específico e, segundo, na validação dos requisitos descritos para a proposta de alternativas de solução. A caracterização do problema apresenta os fatos e fenômenos e os respectivos requisitos funcionais e não-funcionais do ponto de vista dos stakeholder, onde são expandidas e clarificadas as informações de linguagem comum que irão compor o dicionário e a base de dados inicial para o projeto. A validação dos requisitos depende do processo de qualificação das informações de origem, funcionalidade e relacionamento de dependências dos requisitos e, do processo de qualificação de exigências pelos stakeholder. Na seqüência, são apurados os riscos de implementação e a definição de prioridade de implementação dos requisitos funcionais, os requisitos não-funcionais são documentados, mas ainda não priorizados, pois o serão na fase de modelo físico.

Na fase de modelo lógico, são detalhados os eventos e visões dos processos, identificados os papéis e responsabilidades dos stakeholder, capturadas as informações de características de qualidade e linguagem comum e detalhadas as alternativas de solução que fundamentarão a negociação de desenvolvimento do software.

Na fase de modelo físico, são detalhados os requisitos das funções de solução e dos processos de negócio, formalizados e analisados os requisitos não-funcionais relacionados às funcionalidades, definida a tecnologia da informação aplicável, consolidados o dicionário e base de dados para um modelo físico de banco de dados e definidas as métricas para avaliação de qualidade do produto.

Na fase de construção, são documentados os requisitos da arquitetura de funções e dos produtos e revisados o dicionário e a base de dados e as métricas de qualidade.

Na fase de implantação, são especificados os requisitos de infra-estrutura de uso do software. Destacam-se as políticas de uso da tecnologia, as normas e padrões aplicados, as funcionalidades do novo produto, a infra-estrutura de hardware e de comunicação necessários, relatos técnicos, base de treinamentos e cursos e casos de sucesso no cliente.

O enfoque na informação é fundamentado em quatro fatores da comunicação: o conteúdo da mensagem, quem a produz, a quem se destina e qual o entendimento da mesma pelo destinatário.

O objetivo da aplicação da abordagem metodológica é identificar os conflitos [3,4] das mensagens recebidas da variedade de fonte de informação, verificar a relação de dependência existente entre as informações obtidas e, principalmente, a precedência dos fatos, o que irá orientar a definição de prioridade no encaminhamento da solução de implementação.

A aplicação do roteiro é adequada ao planejamento das atividades nas fases de projeto. Sendo assim, depende do uso de um modelo[18] que, associado à atividade de captura de requisitos, identifique e qualifique o requisito e a fonte de informação e proceda a aplicação de critérios para identificação do risco de implementação do requisito em relação à participação da fonte de informação nas decisões.

A aplicação do roteiro direciona a constituição do produto referenciado pelos requisitos, considerando-se as fases de projeto da proposta. No entanto, o sucesso da gestão dos processos do projeto é que influenciará os resultados e o produto final. A figura 3 fundamenta o tratamento das fases de projeto com atividades que prevêm a contratação de um produto observando o conjunto de processos: iniciação (definição do escopo), planejamento de atividades e recursos, execução das atividades, controle de processos e de produto e encerramento das atividades.

Figura 3: Grupos de Processos em Fase de Projeto

A aplicação dos grupos de processos em um projeto ou em fases intermediárias de um projeto vai depender dos fatores determinantes da demanda do cliente. Estes fatores estão associados à disponibilidade de recursos, limite de prazo de entrega do produto, exigências de qualidade, domínio da tecnologia da informação a ser utilizada, restrições, etc...

A gerência dos processos de projeto garante a entrega do produto desde que o escopo seja claro e o produto entendido. Da mesma forma, que pressionada pelos fatores externos, a adoção do ciclo de vida para a construção de um produto é que determinará as fases do projeto.

4 APLICAÇÃO PRÁTICA

A aplicação prática relata o estudo de uma organização que foi constituída para a gestão de fundo capitalizado de previdência, de regime próprio, com capitalização e foco atuarial. A organização com pouco tempo de existência, juntou atribuições de um órgão que tratava pensões com as atribuições de outro órgão que tratava de aposentadorias e contribuições para a futura aposentadoria. Com isto, herdou toda a base de dados e sistemas dos referidos órgãos na forma em que funcionavam e teve alocados recursos humanos das mais diversas áreas de atuação do negócio.

A abordagem de estudo do sistema de informações para este novo ambiente foi mapear a situação existente e congregar esforços em andamento para a manutenção do legado e criar funcionalidades adequadas ao novo contexto de negócio. A figura 4 apresenta a proposta de trabalho para as fases de projeto, contendo as atividades (retângulo) e respectivos produtos intermediários gerados (documento).

Figura 4: Fase de Projeto e Produtos a serem Gerados

4.1 Fase de Entendimento da Demanda

As informações preliminares do ambiente da organização que serviram de balizador para a iniciação do trabalho foram:

Contexto - Tratamento de Informações de Negócio da Organização
Domínio - Ambiente interno em um primeiro momento, atividades fim da organização
Cenários:
- Gestão de Aposentadorias
- Gestão de Pensões
- Gestão de Contribuintes/Contribuições
- Gestão de Dependentes
- Gestão Atuarial
- Compensação previdenciária com outros sistemas
Stakeholder - Presidência e 4 Diretorias Executivas: Previdência, Jurídica, Administrativa e Financeira.
- Assessorias Técnicas da Presidência e de Diretorias Executivas e as Gerências das Diretorias Executivas.
- Corpo operacional e os órgãos estaduais e federal de previdência.
Linguagem:
- Herdada do legado administrativo anterior: legislação, base de dados e sistemas
- Externa oriunda de grupo técnico previdenciário nacional
- Externa oriunda de grupo técnico previdenciário estadual
- Externa oriunda de formação jurídica especializada
- Externa de corpo gerencial
- Interna do legado operacional anterior
Papéis e Responsabilidades:
- Com fronteiras não formalizadas, em definição
Problemas
- Herança de cultura de folha de pagamento e não de gestão previdenciária
- Base de dados não adequada para os propósitos gerenciais e operacionais atuais
- Base de dados agregados inexistente para gestão
- Base de dados detalhada não especialista para provisão atuária
- Linguagem comum inexistente, conceitos variados
Requisitos:
- Propriedade e domínio exclusivo das informações e bases de dados
- Padronização de conceitos e de linguagem comum (léxico)
- Novas funcionalidades em atendimento à missão da organização
Eventos/Processos Produtivos:
- a definir
- a documentar
- a regulamentar
Base de Dados (ou objetos)/Dicionário:
- Ambiente centralizado em mainframe (maior volume)
- Ambiente descentralizado em vários órgãos

Foram realizadas várias reuniões para negociar a contratação do trabalho. O resultado desta fase foi uma proposta de execução de descrição de requisitos que orientasse o tratamento da informação.

4.2 Fase de Estudo Preliminar (viabilidade)

Após várias reuniões de negociação sobre a necessidade de comprometimento das pessoas responsáveis pela tomada decisão, ficou contratado que o trabalho pelo tamanho, volume e esforço a serem despendidos, necessitaria ser dividido em fases. Isto permitiria apresentar produtos intermediários para avaliação de resultados e negociação de continuidade.

A fase de trabalho, denominada de estudos de projeto (figura 4), formalizou um planejamento de atividades, conforme tabela 2, aplicando técnica de reunião com os representantes individuais das áreas diretiva, assessoria técnica e gerências da organização que possuiam afinidade e domínio do conhecimento com o tema abordado. Para isso foi apresentando um cronograma, cujo objetivo era criar um produto (documento preliminar de requisitos) gerado com a participação do corpo decisório da organização.

A necessidade de informação era conhecer o ambiente e a pretensão das pessoas quanto a "o quê" fazer para adequar à realidade da nova organização, sem deixar de atender aos processos operacionais em andamento. Para contextualizar o trabalho a ser desenvolvido, foi adotado o diagrama (conforme apresentado na figura 4), sintetizando as atividades que dependiam do esforço interno da organização.

A documentação gerada nesta fase, faz parte do conhecimento das Informações de Negócio do Sistema sob quatro aspectos: a) restrições de negócio, b) premissas visualizadas, c) problemas e necessidades de negócio e oportunidade de aplicação de tecnologia da informação e, d) os requisitos do ponto de vista diretivo e gerencial, eventualmente, algumas declarações de requisitos operacionais. O enfoque é para o conhecimento dos requisitos de negócio, priorizados.

A pauta da reunião foi orientada por um roteiro que serviu de check-list para a checagem das informações. Neste momento não se tratava de informática e sim da Informação

Agenda de reuniões de trabalho
etapa	pess
estudo do material histórico e proposta de abordagem	3
negociação de contratação do processo de entendimento da demanda e da metodologia	3
levantamento de informações com o corpo diretivo e assessorias técnicas	12
validação das informações documentadas do corpo diretivo e assessorias técnicas: presidência, jurídica, financeira, previdência, administrativa, gerência benefícios, assessorias atuária e benefícios	10
geração da 1.versão do documento de requisitos	1
validação dos requisitos: prioridade e relacionamentos	1
geração da 2.versão do documento de requisitos	1
negociação de continuidade do trabalho	3

Tabela 2: Agenda de Reuniões de Trabalho

O documento originado na fase de estudo preliminar resultou num total de 185 requisitos genéricos. Foi necessária uma classificação prévia pela similaridade de tratamento do tema, antes da qualificação dos requisitos para avaliação de relacionamento de dependência e respectiva prioridade definida. Para a priorização foi utilizado um modelo de qualificação específico[18,19].

Completado o cronograma de atividades da proposta de trabalho, os contextos identificados nos requisitos que foram referência de trabalho no tratamento da informação, representando a atividade fim de negócio, estão apresentados a seguir (figura 5):

A - Atendimento ao Cliente

B - Base de informações de Negócio (Regras de Negócio)

C - Cadastro da Base de Dados de Informações do Cliente

D - Definição de Papéis e Responsabilidades nos Processos

F - Fundo Previdenciário (Gestão Atuarial)

G - Base de Dados Gerenciais (Gestão da Informação Histórica)

I - Infra-estrutura e Sistemas Internos (Administrativos e Financeiros)

K - Definição de Conceitos do Negócio e Parametrização de Regras (Léxico)

L - Lei de Responsabilidade Fiscal (Gestão do Negócio)

P - Processos de Negócio (Operacionalização do Negócio)

X - Processamento de Requisitos do Negócio (Precisão, Segurança, Desempenho)

A figura 5 apresenta a forma de relacionamento e dependência das informações como priorizadas pelos participantes do processo. Apesar de as informações não coincidirem com a visão inicial da demanda, o gráfico é resultado do confronto de informações e qualificação das exigências do grupo.

As áreas C e P dependem respectivamente de K e D e ambas, dependem de B.

Para a geração da base de informações de negócio (B), é necessário, de um lado, fundamentar os conceitos do negócio (K) e gerar a base de dados de clientes (C) e, de outro lado, identificar papéis e responsabilidades (D) que consolidam os processos do negócio (P).

O tratamento dos demais contextos seguirá a ordem de alternativas de solução que será identificada no momento da construção do modelo lógico.

Concluindo, no processo de qualificação foi gerado um documento com requisitos priorizados para fundamentar a negociação da continuidade do trabalho.

Figura 5: Informação e Prioridade de Tratamento

4.3 Proposta de Continuidade do Trabalho - Modelo Lógico

Uma característica particular apareceu na negociação da fase de modelo lógico (figura 4). Pela complexidade e esforço a ser despendido nas atividades de modelagem da informações, principalmente pelo recurso tempo e participação das mesmas pessoas de linha de produção em repetidos processos de definição, optou-se pelo resultado de definição de alternativas intermediárias para implementação imediata. Alocando esforços nas atividades que inicialmente agregariam maior valor. Para isso, deveria ser referência a hierarquia de requisitos definida na fase de estudo preliminar.

A contratação da fase de modelo lógico foi condicionada às seguintes restrições e premissas:

apresentar proposta de alternativa de produção de resultados imediatos:
adaptação dos sistemas existentes (inovação e melhoria);
construção de base gerencial técnica: dataware house;
atendimento da fila de solicitações em andamento;
apresentar alternativas de implementação de novas funções prioritárias.

5 CONCLUSÃO

A aplicação prática do conhecimento no tratamento da informação tendo como foco a descrição dos requisitos, leva à reflexão de alguns fatores relevantes. Cabe aqui referenciar a tabela 1, Relacionamento dos Processos de ER com as Fases de Projeto, como um referencial de análise.

1. Quanto à avaliação da aplicação dos processos da Engenharia de Requisitos:

1.1 na fase de entendimento da demanda:

a) descobrimento:

os requisitos são informações genéricas, não declaradas, serão baseadas no entendimento do contexto, domínio da aplicação, identificados cenários, os stakeholder envolvidos e a identificação da linguagem comum;

b) análise: (não aplicável)

c) validação: (não aplicável)

d) documentação: descrição em linguagem natural

e) gerência: (não aplicável)

1.2 na fase de estudo de viabilidade:

a) descobrimento:

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;
a participação das pessoas está condicionada à disponibilidade de tempo;
a utilização de técnicas não deve exigir tempo adicional de aprendizagem pela fonte de informação;
o engenheiro de requisitos deve valorizar o tempo do cliente, captando o mais que possível das idéias;
o processo deve ser estimulado na linguagem em que a fonte de informação está acostumada;
deve existir negociação prévia do método a ser aplicado e o compromisso a ser assumido;
a metodologia aplicada deve ser flexível e adequada ao público-alvo;
deve-se ter o cuidado com palavras rejeitadas no contexto, por exemplo, problema;
o resultado da caracterização do requisito depende da interpretação do engenheiro de requisitos, pois a metodologia a ser aplicada no processo deve ser menos formal, por exemplo, distinção entre requisito funcional e não-funcional;

b) análise:

deve ser feita para os requisitos funcionais para avaliar conflitos, ambigüidades, repetição;

c) validação:

deve ser feita para os requisitos funcionais para verificar a relação de dependência, precedência e prioridade de atendimento;

d) documentação:

deve ser registrada e representada toda a informação coletada;

e) gerência: (não aplicável)

1.3 na fase de modelo lógico: (proposta de continuidade)

a) descobrimento:

o esforço de entendimento e conceituação de uma linguagem comum;
a definição clara de papéis e de responsabilidades pelos processos;
a visão preliminar dos processos de negócio, restrições e premissas;
a aplicação de formalismo na presença de informações obrigatórias;
(*) esta proposição deve-se ao fato do projeto específico, pelas restrições de participação das pessoas, sendo necessária a adequação de técnicas de captura e de representação das informações;

b) análise:

deve ser feita para os requisitos funcionais e não-funcionais para avaliar conflitos, ambigüidades, repetição;

c) validação:

deve ser feita para os requisitos funcionais e não-funcionais para verificar a relação de dependência, precedência e prioridade de atendimento;

d) documentação:

deve ser registrada e representada toda a informação coletada;

e) gerência: (não aplicável)

2. Quanto à avaliação da aplicação dos processos de gerência de projeto:

utilização dos grupos de processos: iniciação, planejamento, execução, controle e conclusão de um documento de requisitos em cada fase;
divisão do projeto em subprojetos, com controle como se fosse projeto;

3. Quanto à avaliação da aplicação de tratamento do ciclo de vida do produto:

em relação ao projeto, o desenvolvimento do produto depende de: restrições de prazo, restrições de qualidade, restrições de tecnologia, restrições de recursos financeiros,... necessitando a adequação de aplicação dos processos de ER de forma mais apropriada à necessidade.

Concluindo, a definição de requisitos, além de estar circunscrita a um contexto de negócio, deve observar as restrições de projeto e do ciclo de vida do produto.

O projeto deve ter suas fases de desenvolvimento adequadas às necessidades de tratamento da informação, voltadas para o resultado do produto contratado, e conseqüentemente, o refinamento de requisitos funcionais e não-funcionais até a versão final para construção.

A negociação de entrega de resultados intermediários é que [1] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 13596: tecnologia [2] ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 12207: tecnologia [3] BOEHM, B. Identifying quality requirement conflicts. IEEE Software, [4] BOEHM, B. Software model conflicts and how to avoid them. In: SIMPÓSIO [5] CASTRO, J. et al. From early requirements modeled by the 1st technique [6] CHUNG, L. et al. Non-functional requirements in software engineering. [7] CMMI PROJECT. CMM Integrated Systems/ Software Engineering. [8] CYSNEIROS, L. Non-functional requirements for object-oriented modeling. [9] DOORN, J. Inspección del lexico extendido del lenguaje. In: WORKSHOP [10] FOCAL POINT. Prioritizing requirements: what we want always [11] INTERNATIONAL ORGANIZATION FOR STANDARTIZATION. ISO/IEC 9126: [12] INTERNATIONAL ORGANIZATION FOR STANDARTIZATION. ISO/IEC 15504: [13] KILOV, H. Business specifications: the key of successful [14] LEITE, J. Viewpoints on viewpoints. In: INTERNATIONAL WORKSHOP ON [15] LEONARDI, M. et al. Hear, una herramienta de adquisición de requisitos. [16] A GUIDE to the project management body of knowledge. Newton Square: [17] RYAN, K. Requirements engineering: getting value for money. In: SIMPÓSIO [18] ZANLORENCI, E. et al. Modelo para qualificação da fonte de informação [19] ZANLORENCI, E.; BURNETT, R. Descrição e qualificação de [20] ZANLORENCI, E.; BURNETT, R. Modelo para descrição, análise, e validação [21] ZANLORENCI, E.; BURNETT, R. Ferramenta de apoio aos processos de dirigirá a continuidade do projeto, ou seja, a passagem para a fase seguinte do projeto ou de um novo projeto.

REFERÊNCIAS

da informação - avaliação de produto de software - características de qualidade e diretrizes para seu uso. Rio de Janeiro: ABNT, 1998. 10 p.

da informação - processos do ciclo de vida do software. Rio de Janeiro: ABNT, 2000.

Los Angeles, v. 13, n. 2, p. 25-35, March 1996.

BRASILEIRO DE ENGENHARIA DE SOFTWARE, 12., 1998, Maringá. Anais ... Maringá: UEM, 1998. 80 p.

to later requirements modeled in precise UML. In: WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro: WER 2000, 2000. p. 92-108.

Boston: Kluwer Academic, 2000. 439 p.

[s.l]: Continuous Representation, 1999.

In: WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro: WER 2000, 2000. p. 109-125.

DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro: WER 2000, 2000. p. 70-91.

exceeds what we can afford. Disponível em: http://www.focalpoint.se/Metod/e_index.htmlll. Acesso em fev. 2001.

information technology - software product evaluation - quality characteristics and guidelines for their use. Geneva : ISO, 1991. p. 10

software process assessment - concepts and introductory guide - reference model for process capability. Geneva : ISO, 1998.

software engineering. New Jersey: Prentice Hall, 1999. 301 p.

MULTIPLE PERSPECTIVES IN SOFTWARE DEVELOPMENT, 2., 1996, San Francisco. Joint Proceeding... San Francisco: SIGSOFT'96, 1996. p. 285-288.

In: WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro: WER 2000, 2000. p. 38-53

PMI, 2000. p. 216.

BRASILEIRO DE ENGENHARIA DE SOFTWARE, 12., 1998, Maringá. Anais... Maringá: UEM, 1998. 80 p.

cliente e de requisito funcional. In: SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 12., 1998, Maringá. Anais... Maringá: UEM, 1998. p. 39-48

requisitos: um modelo aplicável à análise e validação da informação.1999. 229 f. Dissertação (Mestrado em Engenharia de Software) - Pontifícia Universidade Católica do Paraná. Curitiba. 1999.

de requisito. In: WORKSHOP IBEROAMERICANO DE ENGENHARIA DE REQUISITOS E AMBIENTES DE SOFTWARE, 2000, Cidade do México Anais... Cidade do México: IDEAS2000, 2000, p. 61-71

ER, nas fases de projeto. In: WORKSHOP DE ENGENHARIA DE REQUISITOS, 3., 2000, Rio de Janeiro. Anais... Rio de Janeiro: WER 2000, 2000. p.38-53