Estudo Comparativo sobre as Tcnicas de Elicitao de

Requisitos do Software
Anderson Belgamo u9816034@fcti.unimep.br
Luiz Eduardo Galvo Martins (Orientador) lgmartin@unimep.br
Universidade Metodista de Piracicaba - UNIMEP Rod. do Aucar, Km 156 13400-901
"Campus" Taquaral - Piracicaba-SP
Resumo Este artigo tem como objetivo apresentar um
estudo comparativo sobre as tcnicas de elicitao de requisitos do software, sendo que a
elicitao de requisitos a primeira fase dentro da Engenharia de Requisitos. A elicitao de
requisitos de extrema importncia para a construo do software, oferecendo significativas
contribuies para a Engenharia de Software. Na elicitao de requisitos existem dois grupos de
problemas: essenciais e acidentais. Para o enfrentamento desses problemas vrias tcnicas de
elicitao de requisitos tem sido propostas, as quais esto sendo estudadas e avaliadas de forma a
apontar as diferenas e semelhanas entre elas. Na avaliao das tcnicas estudadas, propomos
vrios parmetros de avaliao. Entendemos que estes parmetros so importantes dentro do
processo de avaliao das tcnicas, pois so balizas teis para a comparao entre as mesmas.
Abstract The goal of this article is to show a
comparative study about the software requirement elicitation techniques, where the requirements
elicitation is the first step in the Requirements Engineering. The requirements elicitation is very
important for software construction, offering meaningful contributions for Software Engineering.
During requirements elicitation there are two problem groups: essential and accidental. To
overcome these problems several requirement elicitation techniques have been proposed, which
are being evaluated and analyzed to point out the differences and similarities among them. In
evaluation of the techniques studied we propose a lot of parameters of evaluation. We
understand that these parameters are important in the process of evaluation of the techniques,
because they are useful references in the comparison among them.
Palavras-Chave Requisitos, Elicitao de Requisitos, Engenharia de Requisitos
1. Introduo
Este artigo resultante das atividades desenvolvidas no projeto de iniciao cientfica
intitulado Um Estudo Comparativo sobre as Principais Tcnicas de Elicitao1 de Requisitos do
Software. Este projeto, que ainda encontra-se em desenvolvimento, tem como objetivo estudar
as principais tcnicas de elicitao de requisitos do software, comparando-as de forma a
explicitar pontos fortes e fracos de cada tcnica. A elicitao de requisitos do software uma
atividade importante da Engenharia de Requisitos, que est inserida dentro do contexto da
Engenharia de Software. A Engenharia de Requisitos se preocupa com a elicitao,
especificao, anlise, verificao e gerenciamento dos requisitos do software. A elicitao de
requisitos oferece a base para as demais atividades da Engenharia de Requisitos.
2. Engenharia de Requisitos
2.1. Definio
A engenharia de requisitos, segundo (Thayer, 1997), a primeira etapa dentro de todo o
processo da engenharia de software, a qual estuda como coletar, entender, armazenar, verificar e
gerenciar os requisitos. A principal preocupao na engenharia de requisitos entender quais so
os reais requisitos do sistema, bem como a documentao dos mesmos.
2.2. Fases da Engenharia de Requisitos
Como especificado em (Thayer, 1997) as fases da Engenharia de Requisitos so: elicitao,
anlise, especificao, verificao e gerenciamento. Elicitao: o processo atravs do qual
clientes e usurios so questionados por um desenvolvedor para falarem o qu o software deve
fazer (ou seja, os requisitos). Esta fase ser mais detalhada na seo 2.3. Anlise: o processo
onde so analisadas as necessidades dos clientes e usurios para se chegar na definio dos
requisitos de software. Especificao: o processo de criao de um documento no qual esto
definidos todos os requisitos analisados. Verificao: o processo que busca assegurar que a
especificao de requisitos de software est em concordncia com os requisitos elicitados e
analisados nas fases anteriores, ou seja, esto de acordo com o desejo do cliente. Gerenciamento:
o planejamento e controle da atividade de elicitao, especificao, anlise e verificao dos
requisitos.
2.3. A Elicitao de Requisitos do Software
A elicitao de requisitos o incio para toda a atividade de desenvolvimento de software,
onde tcnicas de elicitao so utilizadas. Embora a elicitao de requisitos seja a primeira
atividade na engenharia de requisitos, esta atividade no acontece somente uma vez, seu
processo iterativo, ou seja, todas as demais etapas da engenharia de requisitos podem conter
elicitao de requisitos. Para comearmos a elicitao precisamos identificar as pessoas certas,
ou seja, os usurios finais. Ao iniciar a elicitao, os usurios podem ter um forte papel no
processo de desenvolvimento, atravs de seus conhecimentos e experincias (Goguen, 1997).
Para a escolha dos usurios precisamos nos preocupar que todas as informaes dadas por eles
sejam de confiana, ou seja, estas informaes sero usadas para a fase de projeto, estando de
acordo com a necessidade da empresa. Portanto, este usurio de extrema
1 A palavara elicitao vem do ingls elicitation, que significa descobrir algo obscuro.
importncia, pois a escolha de uma pessoa errada acarretar em uma perda de tempo e dinheiro
para ambas as partes envolvidas no desenvolvimento do software.
Como a natureza dos requisitos mutante, ao iniciarmos a fase de elicitao de requisitos, os
clientes podem mudar seus pensamentos, uma vez que eles vem vrias possibilidades mais
claramente em momentos posteriores (Goguen, 1997), fazendo com que os requisitos mudem e,
consequentemente, toda a fase de elicitao e anlise dos requisitos sofrem alteraes. Essas
possibilidades podem vir de mudanas nos fatores sociais, financeiros, psicolgicos e/ou
polticos. Alm da identificao dos usurios o desenvolvedor precisa conhecer o contexto no
qual as informaes esto situadas. Segundo (Jark, 1994) o contexto dividido em 3 mundos:
sujeito, uso e sistema. O sujeito representa uma parte do mundo exterior, onde o sistema
representado por alguma descrio estruturada existe para servir algum indivduo ou usurio
(Siddiqi, 1997). Segundo Goguen, requisitos so informaes e todas as informaes esto
situadas num contexto e isto determina o significado dos requisitos. Levar em considerao o
contexto, significa prestar ateno em fatores sociais e tcnicos. Requisitos emergem de
situaes sociais entre usurios e analistas (Siddiqi,1997). Dessa interao com o usurio que
nascem os requisitos para a construo do software, porm, a parte mais difcil da elicitao de
requisitos no o ato de registrar o que os usurios querem; na verdade a atividade de elicitao
exploratria e desenvolvimental, ajudando os usurios a compreenderem melhor o que eles
querem (McConnel, 1998). Uma antecipao do projeto, onde todos requisitos ainda no estejam
elicitados, levaria a um erro, pois o software desenvolvido no estaria de acordo com as
necessidades do cliente, acarretando gastos financeiros e de tempo.
2.4. Problemas encontrados durante a Elicitao de Requisitos do Software
Durante a elicitao de requisitos, e at mesmo no incio da elicitao, aparecero muitos
problemas. No incio da elicitao temos o problema da escolha dos usurios a serem
entrevistados, pois uma escolha errada pode levar perda de tempo e prejuzos financeiros para o
desenvolvedor e para os clientes. J durante a elicitao aparecero problemas de escopo, de
entendimento e de volatilidade. Alm dos problemas citados acima teremos dois grandes grupos
de problemas: problemas acidentais e problemas essenciais (Faulk, 1997). a) Problemas
Acidentais: So aqueles oriundos da falta de controle sobre aquilo que precisa ser construdo,
dentre os quais podemos destacar: pouco esforo despendido no levantamento de informaes
junto ao usurio; documentao pobre sobre os requisitos obtidos, pouca reviso dos requisitos
obtidos; especificaes incorretas dos requisitos e tendncia em iniciar logo o processo de
desenvolvimento do software (Martins, 1999), o que leva o usurio a no estar satisfeito com o
resultado final do projeto. As dificuldades acidentais, segundo (Faulk, 1997), so: 1)
Documentao escrita como uma reflexo tardia: isto continua sendo uma prtica comum, onde a
documentao de requisitos desenvolvida depois que o software tenha sido escrito. Tal
procedimento inevitavelmente viola o princpio da definio do o que o sistema deve fazer
antes de como. 2) No projetada para ser proveitosa: freqentemente, na vontade implementar
logo, pouco esforo despendido para projetar, escrever, checar, ou gerenciar a administrao da
criao e evoluo do documento de especificao. O resultado mais bvio uma organizao
pobre do software. O documento resultante no uma referncia tcnica efetiva. A especificao
difcil para usar e difcil para manter. b) Problemas Essenciais: So aqueles inerentes
elicitao de requisitos, dentre os quais podemos destacar: dificuldades do usurio em saber
efetivamente o que ele quer, dificuldade de comunicao entre usurio e desenvolvedor e a
natureza mutante dos requisitos (Martins,
1999). Segundo (Faulk, 1997) os problemas essenciais seriam causados por dois fatores
primordiais: 1) Compreenso: pessoas no sabem o que elas querem. Isto no significa que as
pessoas no tenham uma idia geral do que o software far. Ao invs disso, eles no comeam
com um preciso e detalhado entendimento de que funes pertencem ao software, o que as sadas
devem fazer para cada possvel entrada, quanto tempo cada operao deveria levar, como uma
deciso afetar outra, e assim por diante. Muitas decises ainda no foram tomadas, e
expectativas mudaro na medida que o problema melhor entendido. 2) Comunicao:
requisitos de software so difceis para se comunicar efetivamente. A dificuldade inerente da
comunicao composta pela diversidade de pessoas e audincias para a especificao de
requisitos. c) Diferenas: Podemos afirmar que os problemas acidentais so mais fceis de se
evitar, dependendo apenas da utilizao das fases da engenharia de requisitos citadas na seo
1.2. Porm, os problemas essenciais envolvem a comunicao entre pessoas e esse processo deve
levar em conta o contexto, as habilidades pessoais do entrevistado, o lado psicolgico, ou seja,
apenas uma abordagem tecnolgica no poder solucionar esses problemas, pois os aspectos
sociais assumem grande importncia na elicitao dos requisitos (Martins, 1999).
3. Tcnicas de Elicitao de Requisitos
Para uma boa elicitao de requisitos, existem tcnicas para o melhor entendimento e
comunicao entre clientes e analistas, para que problemas, como os citados nas sees
anteriores, no ocorram, ou se ocorrerem, que sejam mais facilmente resolvidos. Segundo
(Jackson, 1995), uma tcnica deve explorar as caractersticas especficas do problema e como as
caractersticas do problema variam muito, ns precisamos de um repertrio de mtodos para cada
classe de problema (Siddiqi, 1997). O problema da elicitao de requisitos no pode ser
resolvido com uma abordagem puramente tecnolgica, porque nesta fase o contexto social mais
crucial do que na fase de programao, especificao e projeto. A seguir ser apresentado um
elenco de tcnicas que foram pesquisadas e que sero comparadas na tabela da seo 4.
a) Observao
A observao possibilita um contato pessoal e estreito do pesquisador com o fenmeno
pesquisado, o que apresenta uma srie de vantagens. (Damian, 1997) . As tcnicas de observao
so extremamente teis para descobrir aspectos novos de um problema. Isto se torna crucial
nas situaes em que no existe uma base terica slida que oriente a coleta de dados. Ao mesmo
tempo em que o contato direto e prolongado do pesquisador com a situao pesquisada apresenta
as vantagens mencionadas, envolve tambm uma srie de problemas. Algumas crticas so feitas
ao mtodo de observao, primeiramente por provocar alteraes no ambiente ou no
comportamento das pessoas observadas. Outra crtica a de que este mtodo se baseia muito na
interpretao pessoal. Alm disso h criticas no sentido de que o grande envolvimento do
pesquisador leve a uma viso distorcida do fenmeno ou a uma representao parcial da
realidade.
b) Entrevista
Entrevista uma tcnica de elicitao de requisitos muito usada. O engenheiro de
requisitos ou analista discute o sistema com diferentes usurios , a partir da qual elabora um
entendimento de seus requisitos. H basicamente, segundo (Kotonya, 1998), 2 tipos de
entrevista: a) entrevistas fechadas onde o engenheiro de requisitos procura as perguntas para um
conjunto um pr-definido de questes; b) entrevistas abertas onde no h agenda pr- definida e
o engenheiro de requisitos discute, de modo aberto, o que os usurios querem do sistema.
Entrevistas podem ser efetivas para desenvolver um entendimento do problema e para elicitar
muitos requisitos gerais do sistema. Usurios finais so usualmente felizes para descreverem
seus trabalhos e as dificuldades que eles enfrentam de forma relativamente natural, entretanto
eles podem ter expectativas no realistas sobre o suporte que o computador dar. Portanto,
entrevistas so muito menos efetivas para entendimento do domnio da aplicao e para o
entendimento das questes organizacionais as quais afetam os requisitos.
c) Anlise de Protocolo
A anlise de protocolo pede pessoa se engajar em alguma tarefa e correntemente falar
sobre esta tarefa, explicando o seu pensamento do processo. Usurios alegam que esse tipo de
linguagem pode ser considerada uma verbalizao direta do processo cognitivo especfico. A
anlise de protocolo no um guia confivel sobre o que as pessoas esto pensando, ela est
sujeita a problemas de interpretaes pelos analistas. A restrio em estudar protocolos que as
pessoas podem produzir linguagens que oferece um perfil de atividade cognitiva autnoma.
Segundo (Goguen, 1997), mesmo se fosse possvel conseguir um perfil de atividade cognitiva
autnoma da pessoa, tal objeto seria inapropriado para o processo de requisitos, porque o cliente
no tem qualquer modelo mental pr-existente do sistema desejado. Os clientes tm
conhecimento sobre negcios e necessidades organizacionais, enquanto o time de requisitos tem
conhecimento sobre as possibilidade tcnicas.
d) JAD2
JAD uma marca registrada da IBM. O tema principal do JAD colocar autoridades
representativas e gerenciais juntas dentro de um workshop estruturado para promover decises.
Segundo (Damian, 1997) JAD consiste de 5 fases: definio do projeto, pesquisa, preparao
para a sesso JAD, a sesso JAD, o documento final. As fases de definio de projeto e pesquisa
no processo JAD lidam com a coleta de informaes. A sesso JAD ento usada para validar as
informaes recolhidas nas fases anteriores. O processo JAD concentra- se na sesso JAD, e
deste modo JAD contribui para a elicitao de requisitos como significado para validar as
informaes j colhidas. Na sesso JAD, as pessoas certas tm que estar envolvidas, e a presena
de um facilitador pode ajudar a manter a sesso focalizada e minimizar ataques e defesas
emocionais improdutivas. JAD promove cooperao, entendimento, e trabalho em grupo entre os
vrios grupos de usurios e o pessoal de sistemas de informao.
e) PD3
Tradicionalmente valores democrticos, os quais tem sido levados em conta no processo
de projeto, tem sido somente aqueles concentrados em fatores tcnicos e econmicos. Mas com o
uso do PD fatores tcnicos-sociais tem sido levados em conta. O projeto deveria ser feito com o
usurio. Aprendizado mtuo deveria ser uma parte importante
2 Joint Application Development 3 Participatory Design
do trabalho em um grupo de projeto, no sendo meramente uma visita aos laboratrios de
pesquisa (Damian, 1997). Trabalhadores e clientes so inteligentes e criativos, contribuidores
produtivos para as organizaes, desde que sejam encorajados a expressarem seus desejos,
aplicarem sua esperteza e exercitarem suas capacidades de tomar decises, assumindo
responsabilidades do impacto de suas aes.
f) QFD4
O termo qualidade definido como um conjunto de meios para produzir
economicamente produtos ou servios, os quais satisfaam os requisitos do cliente. QFD um
conceito que prov meios de interpretar requisitos do cliente em requisitos tcnicos, apropriados
para cada estgio do desenvolvimento e produo do produto (Damian, 1997). As fases iniciais
do QFD podem ser descritas como sendo simplesmente um sistema de identificao e
priorizao das necessidades do cliente obtidas de cada recurso avaliado. QFD um conceito
que aplica-se bem para a elicitao de requisitos, especialmente num modelo de elicitao onde a
voz do cliente o guia para a criao de requisitos.
g) CRC5
Como definido em (Zhu, 1998), CRC uma sesso de grupo, que similar ao JAD, onde
os papis dos participantes e o papel do facilitador so claramente definidos. Em CRC,
participantes consistem no somente de usurios e facilitador, mas tambm de outras pessoas
envolvidas indiretamente no sistema. CRC diferente de JAD e QFD pois ele foca-se no usurio
operativo.
h) Prototipao
Este mtodo para elicitao de requisitos utiliza-se do uso de uma tcnica de prototipao
para a avaliao do usurio. O conjunto inicial de requisitos usado como base para criar o
Prottipo de Interface do Usurio com o sistema inicial (simplificado). Para essa criao, o
projetista precisa manter o prottipo to simples quanto possvel. O ponto forte desta atividade
apresentar muitas alternativas para o usurio antes de se gastar muito esforo para qualquer
prottipo em particular. Aps a aceitao do prottipo pelos usurios, os desenvolvedores
precisam criar um documento de especificao dos requisitos paralelo ao prottipo de interface
(McConnel, 1998).
i) Cenrios
Usurios finais e outros agentes do sistema acham a utilizao de cenrios mais fceis
para relacionar-se aos exemplos da vida real do que descries abstratas das funes realizadas
pelo sistema. Por essa razo, freqentemente til desenvolver um conjunto de interao dos
cenrios, e usar estes para elicitar e clarear requisitos de sistema. Cenrios so exemplos de
sesses de interao as quais so concentradas com um tipo nico de interao entre um usurio
final e o sistema. Usurios finais simulam suas interaes usando cenrios. Eles explicam para o
time de engenheiros de requisito o que eles esto fazendo e a informao da qual eles precisam
do sistema para descrever a tarefa descrita no cenrio.
4 Quality Function Deployment 5 Cooperative Requirements Capture
4. Parmetros de Avaliao das Tcnicas de Elicitao de Requisitos
A partir das tcnicas citadas na seo 3, foram propostos vrios parmetros para a avaliao
das tcnicas (vide tabela 1). Os parmetros propostos so explicados abaixo: a) Grupo/Indivduo:
indica se a tcnica aplicada em grupo ou individualmente; b) Contexto: indica se a tcnica leva
em conta o ambiente onde est se realizando a elicitao; c) Carter de interao: indica se o
entrevistador e entrevistado sentem-se a vontade, num clima de estmulo e de aceitao mtua;
d) Usa lado introspectivo: voltar-se a si prprio e pensar como seria o servio; e) Confiabilidade:
se as informaes colhidas so confiveis para o desenvolvimento do projeto; f) Custo: esforo
gasto no uso da tcnica; g) Qualidade: um critrio de validao onde perguntado se na tcnica
h democracia, aprendizado mtuo, educao e resoluo de conflito; h) Padronizao: se a
tcnica possui uma regra para seu uso; i) Produtividade: se uma tcnica produtiva; j)
Quantidade: um critrio de validao onde perguntado se na tcnica h ndices de
performance e economia de tempo; k) Descrio de aes dos usurios: se a tcnica registra as
gesticulaes e faces do rosto do usurio; l) Compartilhamento de informaes: se todos os
indivduos do grupo compartilham as informaes; m) Tempo: tempo despendido para a
elicitao de requisitos; n) Promover cooperao: se a tcnica promove a cooperao entre os
indivduos do grupo; o) Facilitador: se possui uma pessoa com a funo de guiar, levantar
questes e discusses num grupo; p) Validar requisitos com os usurios: se a tcnica valida seus
requisitos com os usurios; q) Conflitos entre usurios do grupo: se na tcnica existe um meio
para lidar com conflitos em grupo; r) Atividade prematura de projeto: se a tcnica evita que os
analistas pensem que todos os requisitos j foram elicitados e que o projetista j possa comear a
elaborao do sistema.
Tabela 1 - Cruzamento entre as tcnicas de elicitao com os parmetros de avaliao propostos
Parmetros de Avaliao
Tcnicas de Elicitao
Obser- vao
Entrevista Anlise de
Protocolo
JAD PD QFD CRC Proto-
tipa- o
Cen- Rios
Grupo/ Indivduo
Grupo/ Indivduo
Indivduo Indivduo Grupo Grupo Grupo Grupo Grupo/i ndivdu o
Grupo/In divduo
Considera o contexto
Sim Sim Sim Sim Sim Sim Sim Sim Sim
Carter de Interao
No Sim No Sim Sim Sim Sim Sim Sim
Liberdade de Percurso
Sim Sim No No No No No No Sim
Usa lado introspectivo
Sim Sim Sim No No No No No No
Confiabilidade Mdia Alta Baixa Alta Alta Alta Alta Alta Alta Custo Baixo Mdio Mdio Alto Alto Alto Alto Alto Alto
Qualidade Mdia Mdia Baixa Alta Alta Alta Alta Alta Alta Padronizao No No Sim Sim Sim Sim Sim Sim Sim
Produtividade Baixa Mdia Baixa Alta Alta Mdia Alta Alta Alta Quantidade Baixa Alta Baixa Alta Mdia Mdia Mdia
Mdia Mdia Descreve aes dos usurios
Sim No No No No No No No Sim
Compartilha- Mento de informaes
No No No Sim Sim Sim Sim Sim Sim
Tempo Longo Mdio Mdio Longo Longo Longo Longo Mdio Longo Promove cooperao
No No No Sim Sim Sim Sim Sim Sim
Facilitador No No No Sim Sim No Sim No No Valida requisitos com os usurios No Sim No Sim Sim
Sim Sim Sim Sim Conflitos entre os usurios do grupo
No No No Sim Sim Sim Sim Sim Sim
Evita atividade de projeto prematura
No No No Sim Sim Sim Sim Sim Sim

5. Concluso
O projeto exposto dever resultar em uma monografia sobre o assunto, que auxiliar no
desenvolvimento do ensino de engenharia de software em disciplinas do curso de Cincia da
Computao. Os parmetros de avaliao das tcnicas foram obtidos estudando e analisando as
diferentes tcnicas de elicitao encontradas nos artigos, livros e pginas na Internet. Durante o
levantamento bibliogrfico sobre o tema no foi encontrado nenhum material propondo
parmetros de comparaes entre as tcnicas, reforando a relevncia do estudo comparativo das
tcnicas de elicitao de requisitos.
Um estudo de caso est sendo realizado e servir como uma forma de aplicao das tcnicas,
que tambm auxiliar no refinamento dos parmetros de avaliao propostos. O motivo desse
estudo de caso realizar uma avaliao efetiva entre as tcnicas, podendo diferenci-las, obtendo
dados para avaliar onde cada tcnica seja melhor aplicada, de maneira a ajudar o engenheiro de
requisitos a escolher a tcnica mais adequada para a situao defrontada. Durante o estudo de
caso j foram aplicadas as tcnica de observao, questionrio, anlise de protocolo, JAD e
entrevista. Aps a aplicao das demais tcnicas poder ser feita uma melhor avaliao de seu
uso, oferecendo subsdios para o engenheiro de requisitos escolher a tcnica de elicitao mais
adequada para a situao defrontada.
6. Referncias Bibliogrficas
DAMIAN, Adrian, et al. Joint Application Development and Participatory Design 1997.
<http://www.cpsc.ucalgary.ca/~pand/seng/613/report.html> FAULK, Stuart R. Software Requirements: A
Tutorial in Software Requirements Engineering, IEEE-CS
Press, Second Edition, 1997, p.p. 128-149 GOGUEN, Joseph A. Techniques for Requirements Elicitation
in Software Requirements Engineering, IEEE-
CS Press, Second Edition, 1997, p.p.110 122 HARWELL, Richard. What Is a Requirement in Software
Requirements Enginnering, IEEE-CS Press, Second
Edition, 1997, p.p. 23-29 JACKSON, Michael. Software Requirements and Specifications , Addison-
Wesley, Reading, Mass., 1995. JARK, M e POHL, K. Requirements Engineering in 2001: (Virtualy) Managing a
Changing Reality , Software
Requirements Engineering, Nov. 1994, p.p. 257-266. KOTONYA, Gerald e SOMMERVILLE, Ian.
Requirements Engineering Processes e Techniques. John Wiley
and Sons, 1998 MARTINS, Luiz E. G. Utilizao dos Preceitos da Teoria da Atividade na Elicitao de
Requisitos do
Software , XII Simpsio Brasileiro de Engenharia de Software, Out. 1999. McCONNEL, Steve. Software
Project Survival Guide: How to Be Sure Your First Important Project isnt Your
 Last. 1998, p.p 113-124. SIDDIQI, Jawed. Requirements Engineering: the emerging wisdow in Software
Requirements Engineering,
IEEE-CS Press, Second Edition, 1997, p.p. 36-40. THAYER, R. H. e DORFMAN, M.; Introduction to
Tutorial Software Requirements Enginnering in Software
Requirements Engineering, IEEE-CS Press, Second Edition, 1997, p.p. 1-2. ZHU, David. Requirements
Engineering. 1998. <http:// www.cpsc.ucalgary.ca/~zhud/seng693.html>