Modelo para Qualificação da Fonte de Informação do Cliente e de Requisito Funcional

Edna Pacheco Zanlorenci (*)

Robert Carlisle Burnett (**)


 


Resumo

O modelo proposto visa incrementar ao conteúdo do requisito parâmetros para qualificação e validação das informações. O foco de observação é sobre dois elementos: fonte de informação e características do requisito. Quanto à fonte de informação, o modelo propõe, primeiro, identificar a pessoa responsável pela declaração do requisito sob o ponto de vista de produtor e/ou consumidor da informação; segundo, visualizar claramente o papel que esta pessoa ocupa na organização (operacional, tático, estratégico) como formadora de opinião e, terceiro, qualificar o nível de exigência (essencial, expectativa, excedente) para a satisfação do requisito. Quanto ao requisito, o modelo propõe, primeiro, identificar a área de aplicação (operacional, tático, estratégico); segundo, identificar a área de origem do requisito (interno, externo, ordem legal) e terceiro, identificar a relação de dependência do requisito no contexto em estudo (individual, secundário, grupo).

O procedimento seguinte será a validação de requisitos pelo confronto das informações do requisito com as dos variados pontos de vista das pessoas, através da ponderação (valor) do grau de exigência e conformidade com a necessidade e/ou desejo do cliente expresso no processo de extração de requisito, em relação ao produto ou serviço.

Como resultado, obtém-se um índice médio de qualificação do requisito, que permitirá avaliar o grau de risco (alto, médio e baixo) para a implementação do requisito.

Palavras-chave: contexto, domínio aplicação, negócio, ponto de vista, problema, requisito

Abstract

The proposed model seeks to increase to the content of the requirement, parameters for qualification and validation of the information. The observation focus is about the two elements: source of information and characteristics of the requirement. With relationship to the source of information proposes: first, to identify the responsible person for the declaration of the requirement under the point of view of producing consuming and/or of the information; second, to visualize the role that this person occupies in the organization clearly (operational, tactical, strategic) as opinion form and, third, to qualify the demand level (essential, expectation, surplus) for the satisfaction of the requirement. With relationship to the requirement proposes: first, to identify the application area (operational, tactical, strategic); second, to identify the area of origin of the requirement (intern, external, legal order) and third, to identify the relationship of dependence of the requirement in the context in study (individual, secondary, group).

The following procedure will be the requirements validation for the confront of the requirement information with the people's varied point of view, through the assign (value) to its demand degree and conformity with the expressed customer's need e/ou desire in the requirement elicitation process, in relation to the product or service.

As result, is obtained a medium index of qualification of the source of information in relation to the requirement, that will allow to evaluate the degree risk (high, medium and low) for implementation.

Key-words: application domain, business, context, point-of-view, problem, requirement

__________________________________________________________________________________________

(*) Mestranda em Informática Aplicada na Pontifícia Universidade Católica do Paraná, PUC-PR

Analista de Sistemas na Companhia de Informática do Paraná, CELEPAR

e-mail: ednapz@pr.gov.br fone coml: [011-55] (0)41-350-5452 Curitiba-Pr

(**) Professor no Mestrado em Informática Aplicada na Pontifícia Universidade Católica do Paraná, PUC-PR

e-mail: robert@lambda.pucpr.br fone coml: [011-55] (0)41-330-1654 Curitiba-Pr

1. Introdução

O interesse por uma abordagem sistemática de conhecimento do problema levou à busca de apoio de uma nova área de pesquisa, a Engenharia de Requisitos.

A Engenharia de Requisitos, segundo Macaulay[9], pode ser definida como o processo sistemático de desenvolvimento de requisitos através de processos iterativos de análise do problema, de documentação das observações resultantes em uma variedade de formatos de representação e de checagem da precisão do entendimento obtido.

O processo de engenharia de requisitos, Sommerville[08,10] é um conjunto estruturado de atividades para extrair requisitos, validá-los e mantê-los.

Requisito, para Macaulay[9], simplesmente pode ser definido como "algo que um cliente necessita". Entretanto, do ponto de vista do engenheiro de software, requisito pode também ser definido como "algo que necessita ser projetado".

O produto do processo de engenharia de requisitos é o documento de requisitos. Agregar qualificação à fonte de informação e quantificação ao requisito no processo de extração, é fundamental para permitir a validação do requisito, que é o enfoque do modelo proposto.

A parte 2 deste artigo apresenta aspectos contextuais do processo de extração de requisitos. A parte 3 apresenta uma proposta de modelo para qualificação da fonte da informação do cliente e das características do requisito, individualmente e relacionado a outros requisitos integrantes do problema. A parte 4 apresenta um parecer sobre a contribuição para a pesquisa e a prática, no tratamento da fonte de informação do requisito para obtenção de requisitos completos, consistentes, não ambíguos e válidos. A parte 5 apresenta vantagens e limitações do modelo. A parte 6 finaliza com um resumo de considerações finais sobre o processo de extração de requisitos e os resultados esperados com a aplicação do modelo.

2. O Processo de Extração de Requisitos

O processo de extração de requisitos requer uma análise criteriosa da organização, compreendendo: a definição do alvo e da abrangência do domínio da aplicação, o entendimento do foco no problema a resolver (o quê, para quê e para quem), a identificação de processos do negócio e, principalmente o conhecimento da informação do cliente relativa as suas necessidades ou desejos e exigências.

Extração de requisitos[8] é o nome usual dado às atividades envolvidas em descobrimento de requisitos, representadas na fig.1.

 
 
fig1- componentes de extração de requisitos - Fonte [8]

 


2.1. Domínio da Aplicação ou Ambiente

O primeiro passo em análise de problemas, segundo Jackson[5], é estruturar e analisar o domínio da aplicação. O princípio de relevância do domínio declara que "Tudo o que é relevante para os requisitos, deve aparecer em alguma parte do domínio da aplicação". Existe uma importante conseqüência deste princípio. O domínio da aplicação não é limitado a partes do mundo que estão diretamente ligadas ao domínio da máquina. É mais abrangente, pois refere-se ao negócio.

O domínio da aplicação é onde os requisitos particulares dos clientes são encontrados. Se o domínio da aplicação não for identificado corretamente, não se está apto para focalizar os requisitos dos clientes. Zave [12] apresenta que todas as descrições envolvidas em engenharia de requisitos poderão ser descrições de ambiente.

A identificação do ambiente ou domínio da aplicação onde está inserido o problema que se quer tratar é o passo inicial para o planejamento das atividades de descobrimento dos requisitos inerentes ao contexto do negócio. Pode-se pensar o domínio da aplicação como o que é dado e o domínio da máquina como o que será construído[5].

 
 
fig.2 - o domínio da aplicação no contexto do conhecimento (fonte[5])

 


2.2. Problema a ser Resolvido

Um problema ao ser tratado por pessoas agrega sempre características inerentes ao fator humano do querer, do saber, do poder e, principalmente, da comunicação e do entendimento do requisito. Gause em [3] e [4] apresenta várias abordagens de enfoque sobre problema.

Ainda persiste na área de engenharia de software a tentativa de visualizar a tecnologia como solução de problema, sem antes focar intensivamente o esforço em definição e entendimento do problema e na negociação de eventuais conflitos de interesses pela solução.

A falta de habilidade para discutir problemas tem sido uma das mais flagrantes deficiências da teoria e da prática em software. Muitos escritores sobre métodos de desenvolvimento afirmam oferecer uma análise de problema, quando de fato oferecem somente um contorno de solução, deixando o problema inexplorado e inexplicável[5].

O problema no contexto de extração de requisitos é a razão principal para o entendimento, a especialização e o domínio do conhecimento. Identificar a designação do que é problema, qual é a definição do problema, quem tem o problema e qual a essência do problema sob o ponto de vista de quem o tem, caracterizam a complexidade do processo. Fatos como determinar o que está errado e o que pode ser feito acerca do erro ou como identificar o problema em função da diferença entre o que é desejado pelo cliente e o que é percebido pelo engenheiro de software agrega um esforço considerável ao processo de descobrimento.

Enfim, é necessário distinguir claramente um processo de definição do problema (conhecimento dos requisitos) de um processo de solução do problema (aplicação de ferramentas de software como solução). Como a fonte de problemas vem de dentro das pessoas, o importante é identificar qual a necessidade de ter resolvido o problema e se existe realmente o desejo de uma solução[5].

2.3. Contexto do Negócio

Assuntos organizacionais [11] e fatores políticos podem influenciar nos requisitos. Nas organizações, a luta pelo poder e relações de influência entre diferentes pessoas dificultam um denominador comum quanto à propriedade da informação e à definição da melhor forma de administrá-la. Cabe aí uma negociação cuidadosa e a delimitação de fronteiras, com o estabelecimento de objetivos, o entendimento do histórico e da estrutura organizacional e da própria organização do conhecimento.

Um fator expressivo de conflito também ocorre em ambientes descentralizados geograficamente, em relação ao desenvolvimento dos processos organizacionais. O desconhecimento das peculiaridades regionais pelo poder centralizado, as dificuldades de comunicação e a falta de padronização no tratamento da informação tornam mais complexo o processo de validação de requisitos, quando estes tendem a ser necessidades comuns ou até mesmo particulares.

2.4. Informação do Cliente

A fonte de informação cliente é composta por uma variedade de requisitos, expressa de acordo com a posição que a pessoa ocupa na organização e o seu nível de interesse e de comprometimento na identificação de problemas e na procura de solução.

O posicionamento do cliente como consumidor e/ou produtor como formador de opinião para definição do problema em estudo é o passo inicial do processo, especialmente no esclarecimento do nível de exigência do requisito sob o enfoque de grandeza do que é essencial para a organização, acima dos interesses particulares. É claro que o ponto de vista particular do cliente é importante, mas no contexto organizacional este pensamento pode ser diluído em confronto com os demais posicionamentos sobre o requisito, considerando-se a necessidade de se obter a melhor representatividade de opiniões para a definição do problema.

Portanto, a aplicação de um critério de qualificação da fonte de informação cliente contribui para as etapas seguintes de análise e validação do requisito.

3. Modelo para Qualificação da Fonte de Informação e de Requisitos

O que é?

O modelo é uma proposta aplicável ao processo de extração de requisitos dentro de um âmbito organizacional. A fig.3 representa o modelo de objetos no contexto da informação, caminho para o descobrimento de requisitos. O foco de estudo concentra-se especificamente na parte escurecida do modelo, compreendendo a fonte de informação cliente (ponto de vista, qualificação ocupacional e nível de exigência) e o requisito funcional (qualificação funcional, área de origem e relação de dependência).

 
 
fig.3 - modelo de objetos do contexto da informação

 


Objetivos?

3.1. Estratégia para Aplicação do Modelo

O procedimento de validação de requisitos deve confrontar as variadas declarações das pessoas comprometidas com o processo de definição do problema, sob os mais diversos pontos de vista e de cenários de ocorrência do fato. Para isso, a cada requisito, a pessoa segundo seu nível de expectativa declarado, irá definir seu grau de exigência e conformidade com a necessidade e/ou desejo em relação ao produto ou serviço. Nesta declaração, a pessoa estará se posicionando em função de seu papel principal de produtor ou consumidor da informação e, especialmente, em observância ao nível administrativo (operacional, gerencial ou estratégico) ocupado na organização e, como formador de opinião. A fig.4 apresenta todas as possibilidades possíveis de informação, nos três níveis de atributos.

 
 
fig.4 - possibilidades de caminhos de representação da fonte informação e requisito

 


3.2. Determinando a Qualificação da Fonte de Informação

Para a qualificação da fonte de informação cliente, definem-se três aspectos que caracterizam e personalizam o agente da informação, conforme representado na tab.1:

Fonte Informação Cliente atributo.1  atributo.2 atributo.3
1.Ponto Vista do Cliente  1.1.Produtor 1.2.Consumidor 1.3.Não P/C
2.Qualificação Ocupacional do Cliente 2.1.Operacional 2.2.Tático 2.3.Estratégico
3.Nível de Exigência Informação 3.1.Essencial  3.2.Expectativa 3.3.Excedente

tab.1- Relação entre Fonte de Informação e Requisitos


 


Analisando-se todas as possibilidades de resposta procedentes de todos os tipos de clientes envolvidos no processo de extração de requisitos, a tab.2, apresenta um quadro completo das situações possíveis, conforme os níveis de decisão da fig.4 anterior.
 
Quadro Demonstrativo da Qualificação da Fonte de Informação Cliente e do Nível de Exigência Informação 
Qualificação - Fonte Informação Possibilidades de Contribuição como Agente Fonte de Informação Cliente
ponto vista Produtor
1
1
1
1
1
1
1
1
1
  Consumidor                  
2
2
2
2
2
2
2
2
2
                  
  neutro não P/C                                    
3
3
3
3
3
3
3
3
3
qualif.ocupação Operacional
1
1
1
            
1
1
1
            
1
1
1
            
  Tático      
2
2
2
            
2
2
2
            
2
2
2
      
  Estratégico            
3
3
3
            
3
3
3
            
3
3
3
exg.informação Essencial
1
    
1
    
1
    
1
    
1
    
1
    
1
    
1
    
1
    
  Expectativa  
2
    
2
    
2
    
2
    
2
    
2
    
2
    
2
    
2
  
  Excedente    
3
    
3
    
3
    
3
    
3
    
3
    
3
    
3
    
3
Valor Atribuído
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2

A cada condição atendida atribui-se um valor pelo grau de importância no contexto (8=alto,4=médio,2=baixo)
 


tab.2- Possibilidades de Qualificação de Cliente e Exigência de Requisitos


 


3.3. Determinando a Qualificação do Requisito

Para a qualificação do requisito, definem-se três aspectos que caracterizam e qualificam o requisito e estão representados na tab.3:

Requisito Funcional atributo.1 atributo.2 atributo.3
1.Qualificação Funcional do Requisito 1.1.Operacional 1.2.Tático 1.3.Estratégico
2.Área Origem do Requisito 2.1.Interno 2.2.Externo 2.3.OrdemLegal 
3.Relação Dependência de Requisitos 3.1. Grupo  3.2.Secundário 3.3. Individual

tab.3- Relação entre Requisito e Origem Informação


 


Analisando-se todas as possibilidades de caracterização do requisito, a tab.4, apresenta um quadro completo das situações possíveis, conforme os níveis de decisão da fig.4 anterior.
 
Quadro Demonstrativo da Qualificação do Requisito, Identificação da Área de Origem e Dependência 
QualificaçãoRequisito Funcional Caracterização do Requisito Funcional: área origem, relação dependência
qualif.funcional Operacional
1
1
1
1
1
1
1
1
1
  Tático                  
2
2
2
2
2
2
2
2
2
                  
  Estratégico                                    
3
3
3
3
3
3
3
3
3
área origem Interno
1
1
1
            
1
1
1
            
1
1
1
            
  Externo      
2
2
2
            
2
2
2
            
2
2
2
      
  Ordem Legal            
3
3
3
            
3
3
3
            
3
3
3
rel.dependência Grupo
1
    
1
    
1
    
1
    
1
    
1
    
1
    
1
    
1
    
  Secundário  
2
    
2
    
2
    
2
    
2
    
2
    
2
    
2
    
2
  
  Individual    
3
    
3
    
3
    
3
    
3
    
3
    
3
    
3
    
3
Valor Atribuído
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2

A cada condição atendida atribui-se um valor pelo grau de importância no contexto (8=alto,4=médio,2=baixo)
 


tab.4 - Possibilidades de Qualificação de Requisitos


 


3.4. Determinando o Grau de Risco de Implementação do Requisito

Primeiro, é necessária a qualificação do requisito, conforme especificado no item 3.3 anterior, com informações sobre o conhecimento que se obteve no trabalho de extração. O parecer terá o resultado correspondente ao valor atribuído, única opção representada na última linha da tabela tab.4. Somente é permitida uma opção do rol das 27, em seguida, ponderada conforme tab.5, agrupada em 9 colunas (3 a 3). O cálculo ponderado resultará em um valor único no intervalo que varia de 2 a 72, observando as 27 colunas de possibilidades.
 
Valor Atribuído
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
Atribui Peso(*)
9
8
7
6
5
4
3
2
1
Resultado 
72 36 18
64 32 16
56 28 14
48 24 12
40 20 10
32 16 8
24 12 6
16 8 4
8 4 2

OBS.: (*)A atribuição de peso representada, refere-se ao requisito de nível operacional. Para o nível tático aplicar ( 6 5 4 9 8 7 3 2 1) e para o nível estratégico aplicar (3 2 1 6 5 4 9 8 7), podendo desta forma ser variável, como uma alternativa de reforçar o enfoque da qualificação funcional do requisito.
 


tab.5 - Resultado da Atribuição de Peso (opção única)


 


O passo seguinte é obter da pessoa, fonte de informação, o parecer do nível de exigência do requisito sob a ótica do ponto de vista próprio, conforme especificado no item 3.2 anterior. Cada parecer terá o resultado correspondente ao valor atribuído, única opção representada na última linha da tabela tab.2, ponderado conforme tab.6, agrupada em 9 colunas (3 a 3). O cálculo ponderado resultará em um intervalo que varia de 2 a 72. Em seguida, efetuar a somatória de todas as opções por coluna. Da somatória do total de pareceres ponderados, obtém-se a média simples dividindo-se pelo número de pessoas participantes, por coluna, que é o resultado final.
 
Valor Atribuído
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
8
4
2
Atribui Peso
5
7
9
4
6
8
1
2
3
Resultado 
40 20 10
56 28 14
72 36 18
32 16 8
48 24 12
64 32 16
8 4 2
16 8 4
24 12 6

tab.6 - Resultado da Atribuição de Peso


 


Parâmetros do Resultado da Aplicação do Modelo:

a) na qualificação da fonte de informação b) na qualificação do requisito

1.caso - a média varia de 01 a 20 1.caso - a média varia de 01 a 20

2.caso - a média varia de 21 a 40 2.caso - a média varia de 21 a 40

 3.caso - a média varia de 41 a 72 3.caso - a média varia de 41 a 72

c) quadro comparativo de riscos

  a)fonte de informação
b)requisito
01-20
21-40
41-72
01-20
alto
meio alto
meio baixo
21-40
meio alto
médio
baixo
41-72
meio baixo
baixo
baixo

tab.7 quadro avaliação risco


 


4. Contribuição na Área de Engenharia de Requisitos

Nas pesquisas realizadas sobre o assunto foram identificados vários artigos que abordam sobre a seleção de requisito a ser implementado: priorização de requisitos[6], seleção de requisitos[7], identificando conflitos e atributos de qualidade de requisitos[2] e medição de sucesso do processo de engenharia de requisitos[1].

Karlsson[6], trata sobre priorização de requisitos de software a partir da informação participativa do cliente. Utiliza-se de duas técnicas: a primeira, é de comparação de requisitos em pares (dois a dois),baseado no processo de hierarquia analítica (AHP Analytic Hierachy Process) que estabelece a seleção pelo grau de importância relativa do requisito num rol de requisitos, atribuído numa escala 1 a 9; a segunda, é de assinalamento numérico, baseada no princípio que cada requisito tem seu grau de importância absoluta, atribuído numa escala 1 a 5

Karlsson & Ryan[7], tratam sobre seleção de requisitos de software com candidato prioritário para implementação, em virtude da escassez de recursos, tendo como determinante a satisfação do cliente. Utiliza a técnica AHP descrita acima para seleção de prioridade de requisito e sua importância em relação ao custo. O objetivo é gastar melhor o recurso optando pela seleção dos requisitos mais prioritários.

Bohem[2], trata como resolver conflitos e atributos de qualidade de requisito. Propõe identificar e negociar os conflitos, diagnosticando conflitos e atributos de qualidade sob uma base de conhecimento (ferramenta QARCC).

Emam[1], trata como mensurar o sucesso no processo de engenharia de requisitos, sob os aspectos de qualidade do produto e qualidade do serviço(sucesso e causas de falha). Apresenta uma lista de 34 critérios para assegurar o sucesso do processo de engenharia de requisitos.

Comparando com as contribuições pesquisadas, o modelo de qualificação proposto aproxima-se da abordagem de Karlsson & Ryan[6,7], na técnica de assinalamento numérico para enquadramento importância absoluta do requisito, no caso, o nível de exigência do requisito.

A proposta do modelo enfatiza a qualificação da fonte de informação e do requisito como um procedimento que precede à priorização ou seleção de requisito para implementação. Mesmo que o processo de extração de requisito seja de reuniões conjuntas, a proposta prevê uma participação individual e exclusiva do agente da informação ao emitir parecer, e o resultado será apropriado para o rol de informações sobre o requisito e comporá a média sobre a qual incidirá a ponderação que quantificará o grau de risco de representatividade do requisito. Entende-se que a meta é atingir uma participação e colaboração efetiva do maior número de representantes de fonte de informação que são afetados pelo requisito ou que o definem. Por esta razão, a qualificação da fonte de informação e das características do requisito durante o processo de extração, constitui-se fator essencial para a validação do requisito.

5. Vantagens e Limitações do Modelo Proposto

A expectativa das vantagens a serem obtidas com a aplicação prática do modelo é principalmente demonstrar os conflitos de interesses das pessoas na definição do problema no contexto organizacional. Com isto possibilitar o estabelecimento de pontos de negociação de interesse essencial para a organização em detrimento dos interesses particulares de poder e domínio da informação. A forma de negociação é apresentar os resultados obtidos do processamento das informações relativos ao grau de risco apresentado e identificar os pontos que devem ser revistos antes de dar seqüência ao processo de desenvolvimento. Requisito válido é pré-condição para posterior priorização de implementação.

O modelo proposto restringe-se aos pontos declarados conforme apresentados na tab.1 e tab3. É pontual no que se refere a exigência de obrigatoriedade de preenchimento de todos os três níveis de quesitos, tanto para qualificação da fonte de informação cliente, como para o requisito.

Como trabalho futuro, além da aplicação prática do modelo para ajustes de atribuição de valor e ponderação, pretende-se na seqüência estender o estudo também aos requisitos não-funcionais e especificações que envolvem a solução do problema com a tecnologia de software, características de qualidade, expandindo áreas sombreadas no modelo da fig.3.

6. Conclusão

Como resultado da aplicação do modelo proposto espera-se a partir da qualificação da fonte de informação e seu grau de influência no contexto organizacional, bem como a qualificação do requisito, obter os índices comparativos de enquadramento dos parâmetros definidos para o modelo para validar os níveis de risco de implementação do requisito, sugerindo a revisão do processo de extração quando os indicativos alertarem abaixo da média.

Conclui-se que o documento final de requisitos deve ser realmente um objeto de contratação de produtos e/ou serviços com maior grau de certeza de aplicação e garantia de atendimento do cliente e, para isso, depende de requisitos válidos.

Referências Bibliográficas

[1] EMAM, Khaled El; MADHAVJI, Nazim H. Measuring the Success of RE Processes.

ISRE’95 Second International Symposium on Requirements Engineering

1ed. USA : IEEE CSP, Los Alamitos, CA. Proceedings, 1995, march, 3 p.

[2] BOHEM, Barry; IN Hoh.. Identifying Quality-Requirement Conflicts.

1ed. USA : IEEE Software, 1996, march, 11 p.

[3] GAUSE, Donald C., WEINBERG, Gerald M. Exploring Requirements (Quality Before Design)

1ed. USA : Dorset House Publishing Co. Inc., 1989, 300 p.

[4] GAUSE, Donald C., WEINBERG, Gerald M. Are Your Lights On?

1ed. USA : Dorset House Publishing Co. Inc., 1990, 157 p.

[5] JACKSON, Michael. Software Requirements and Specifications: A Lexicon of Pratice,

Principles and Prejudices

1ed. USA, Massachustes: Addison-Wesley, Reading. 1995, 228 p.

[6] KARLSSON, Joachim. Software Requirements Prioritizing

ICRE’96 Second International Conference on Requirements Engineering

1ed. USA : IEEE CSP, Los Alamitos, CA. Proceedings, 1996, april, 6 p.

[7] KARLSSON, Joachim; RYAN, Kevin. Supporting the Selection of Software Requirements

IWSSD'96 Eighth International Workshop Specification and Design

1ed. USA : IEEE CSP, Los Alamitos, CA. Proceedings, 1996, march, 4 p.

[8] KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements Engineering (Processes and Techniques)

1ed. England : John Wiley & Sons Ltd, 1998, 282 p.

[9] MACAULAY, Linda A. Requirements Engeneering

1ed. Great Britain : Springer-Verlag London Limited, 1996, 202 p.

[10] SOMMERVILLE, Ian; SAWYER, Pete. Requirements Engineering (A Good Practice Guide)

1ed. England : John Wiley & Sons Ltd, 1997, 391p.

[11] SOMMERVILLE, Ian; SAWYER, Pete; VILLER, S.

Viewpoint for requirements elicitation: a practical approach.

ICRE’98 Third International Conference on Requirements Engineering

1ed. USA : IEEE CSP, Los Alamitos, CA. Proceedings, 1998, april, 8 p.

[12] ZAVE, Pamela; JACKSON, Michael. Four dark corners of requirements engineering

1ed. USA: ACM, Inc - Association for Computing, 1997 (janeiro), vol.6, n.1, pag 1-30