"A IMPLEMENTAO DA ENGENHARIA DE REQUISITOS COMO

FATOR CRTICO DE SUCESSO PARA AS PEQUENAS EMPRESAS DE

DESENVOLVIMENTO DE SOFTWARE".
MARCELO NOGUEIRA
Universidade Paulista
Rua Dr. Bacelar 1212 4 - CEP 04026-002 So Paulo SP.
marcelo@noginfo.com.br

Resumo
As empresas de desenvolvimento de sistemas de pequeno porte tm seus recursos materiais e
humanos tanto quanto sobrecarregados, diante da demanda a ela submetida. Porm a no
implementao da engenharia de requisitos como fator crtico de sucesso no desenvolvimento
de software, ou por falta de cultura ou at por desconhecimento da sua existncia, levam
projetos de suma relevncia ao insucesso e aumentando ainda mais a quantidade de casos dos
sistemas inacabados, conseqentemente desperdiando tempo, recursos financeiros e no
atendendo as necessidades dos clientes e nem do desenvolvedor.
Palavras-chave: Engenharia de Requisitos, Engenharia de Software, pequenas empresas.

Abstract
The systems development companies of small size have their material and human resources as
much as overloaded, in front of the demand to her submitted. However the not implementation
of the requirements engineering as critical factor of success in the software development, or
for lack of culture or until for ignorance of your existence, carry projects of vanishes
relevance to the failure and even increasing the quantity of cases of the unfinished systems,
consequently wasting time, financial resources and not attending the needs to clients and
neither of the developer.
Key words: Requirements engineering, Software Engineering, small size companies.

1.

OBJETIVO

Este trabalho tem por objetivo principal apresentar os mtodos da engenharia de software, no mbito
da engenharia de requisitos, como processo fundamental e fator crtico de sucesso no
desenvolvimento de software atravs de aplicao de um modelo estruturado para resoluo de
problemas / questes apresentadas pelos clientes / usurios.
Este artigo pretende contribuir com outros estudos de implementao da Engenharia de Requisitos
para pequenas organizaes, porm de grande participao na comercializao de software.

2. INTRODUO
Num ambiente competitivo e de mudana cada vez mais complexo, a gesto adequada da
Informao assume uma importncia decisiva no processo de tomada de deciso nas organizaes.
Tratando-se de um tema simultaneamente abrangente e especializado, a adoo da Engenharia de
Requisitos como linha base da Gesto da Informao, possibilitar, no s desenvolver e consolidar

os conhecimentos no desenvolvimento de software, bem como preparar os micros, pequenos e

mdios desenvolvedores para encarar com confiana os novos desafios no mundo dos negcios, e
tambm reforar as competncias profissionais, mantendo-se atualizado em relao ao potencial dos
sistemas de informao e das novas tecnologias numa perspectiva empresarial e competitiva
globalmente.
A partir do conhecimento adquirido da Engenharia de Requisitos de Software, o desenvolvedor ser
elemento multiplicador de solues, contribuindo e agregando valor aos sistemas novos e para os j
existentes, com aplicao de metodologias e tecnologias adequadas, capazes de gerir com sucesso as
informaes relevantes aos negcios aplicveis, trazendo s organizaes, vantagens competitivas.
No estudo da Engenharia de Software, o autor Roger S. Pressman [PRESSMAN02], demonstra
preocupao com a Crise do Software que atualmente ele intitula como Aflio Crnica,
chegando a determinar nmeros expressivos sobre a no finalizao de projetos de sistemas
comeados e no terminados.
Num mundo cada vez mais de recursos financeiros escassos, como possvel aceitar tal desperdcio
de tempo e dinheiro. O mesmo autor tambm aponta para o possvel problema causador de tal
absurdo: A falta de adoo de mtodos, ferramentas e procedimentos no desenvolvimento de
software e a difcil relao de entendimento entre o usurio com o analista desenvolvedor.
Existem vrias tcnicas de levantamento de requisitos e modelagem de software e o analista
desenvolvedor que no s implementam tem dificuldades de realizar um projeto de sistemas livre de
manutenes e re-trabalhos, condenando diretamente a qualidade do produto.
A implementao da Engenharia de Requisitos, pelo micro, pequeno e mdio desenvolvedor de
software, direciona como realizar uma especificao de requisitos que venha estruturar a fase de
anlise do desenvolvimento do software, proporcionando mtodo sistemtico de levantamento dos
requisitos acompanhando todo o processo, permitindo que o software venha representar a realidade
da empresa modelada para gerao de um sistema customizado, atendendo assim as necessidades
desta empresa, obtendo qualidade no software, bem como criar a real possibilidade de extrair de um
sistema, informaes relevantes que venham no s para contribuir com a deciso, mas para ser um
fator de excelncia empresarial, permitindo novos negcios, permanncia e sobrevivncia num
mercado atuante.

3. RELEVNCIA
Segundo o Ministrio da Cincia e Tecnologia [MCT02], a participao de mercado das micros,
pequenas e mdias empresas desenvolvedoras de software correspondem 65,1% do total (Tabela1).
Diante da dimenso deste mercado ainda em franca expanso, que motivou a prestar ateno
especial para este tema.
Tabela 1- Porte das Organizaes, segundo comercializao bruta anual (2000).
Porte das Organizaes

Portes
Micro
Pequena
Mdia
Grande

%
16,5
25,3
23,3
34,9

Atualmente com a viso global permitindo a participao nas exportaes de software para outros
pases, cada vez mais a qualidade no processo de desenvolvimento e do produto de software ganha

maior observao e adoo das melhores prticas e solues tecnolgicas que atendam os requisitos
estabelecidos.
Considerado por Brooks [BROOKS87] como problema essencial:
A parte mais difcil do desenvolvimento de software decidir precisamente o que ser
desenvolvido. Nenhuma outra parte do trabalho to difcil quanto estabelecer (definir) os detalhes
tcnicos necessrios incluindo todas as interfaces para pessoas, mquinas e para outros sistemas de
software. Nenhuma outra parte do trabalho to possvel de ocasionar erros no sistema como essa.
Nenhuma outra parte to difcil de ser posteriormente consertada.
Para compreender melhor a engenharia de requisitos, veremos alguns conceitos e objetivos a seguir
da engenharia de software.

4. ENGENHARIA DE SOFTWARE
Segundo Rezende [REZENDE99], Engenharia a arte das construes, embasada no conhecimento
cientfico e emprico, adequada ao atendimento das necessidades humanas.
Engenharia de Software a metodologia de desenvolvimento e manuteno de sistemas modulares,
com as seguintes caractersticas [REZENDE99]:
-

Adequao aos requisitos funcionais do negcio do cliente e seus respectivos procedimentos

pertinentes;
Efetivao de padres de qualidade e produtividade em suas atividades e produtos;
Fundamentao na tecnologia da informao disponvel, vivel e oportuna;
Planejamento e gesto de atividades, recursos, custos e datas.

Segundo Pressman [PRESSMAN02], Engenharia de Software :

-

O estabelecimento e uso de slidos princpios de engenharia para que se possa obter

economicamente um software que seja confivel e que funcione eficientemente em mquinas
reais;
Descendente da engenharia de sistemas e de hardware. Abrange um conjunto de 3
elementos fundamentais (mtodos, ferramentas e procedimentos), que possibilita, ao gerente,
o controle do processo de desenvolvimento do software e oferece ao profissional uma base
para a construo de software de alta qualidade.

Segundo Martin [MARTIN91], Engenharia de Software :

- o estudo dos princpios e sua aplicao no desenvolvimento e manuteno de sistemas de
software;
- Tanto a engenharia de software como as tcnicas estruturadas so colees de metodologias
de software e ferramentas;
Como concluso, pode-se relatar que engenharia de software um conjunto de prticas para
desenvolvimento de solues de software, ou seja, roteiro que pode utilizar diversas tcnicas.
A seqncia de passos preestabelecidos permite optar e variar de tcnicas e ferramentas na suas
diversas fases [REZENDE99].

5. OBJETIVOS DA ENGENHARIA DE SOFTWARE

De um modo geral, considera-se que os objetivos primrios da Engenharia de Software so o
aprimoramento da qualidade dos produtos de software e o aumento da produtividade dos
engenheiros de software, alm do atendimento aos requisitos de eficcia e eficincia, ou seja,
efetividade [MAFFEO92].
A Engenharia de Software visa sistematizar a produo, a manuteno, a evoluo e a recuperao
de produtos intensivos de software, de modo que ocorra dentro de prazos e custos estimados, com
progresso controlado e utilizando princpios, mtodos, tecnologia e processos em contnuo
aprimoramento. Os produtos desenvolvidos e mantidos, seguindo um processo efetivo e segundo
preceitos da Engenharia de Software asseguram, por construo, qualidade satisfatria, apoiando
adequadamente os seus usurios na realizao de suas tarefas, operam satisfatria e economicamente
em ambientes reais e podem evoluir continuamente, adaptando-se a um mundo em constante
evoluo [FIORINI98].
Associando a esses objetivos, o termo engenharia pretende indicar que o desenvolvimento de
software deve submeter-se a leis similares s que governam a manufatura de produtos industriais em
engenharias tradicionais, pois ambos so metodolgicos [MAFFEO92].
Com base nos objetivos da Engenharia de Software, fica evidente a necessidade da adoo de um
modelo sistmico para padronizar e gerenciar os processos de desenvolvimento de software.

6. CRISE DO SOFTWARE
Para generalizar o termo, ocorre quando o software no satisfaz seus envolvidos, sejam clientes e/ou
usurios, desenvolvedores ou empresa [REZENDE99].
A expresso Crise do Software, que comeou a ser utilizada na dcada de 60, tem historicamente
aludido a um conjunto de problemas recorrentemente enfrentados no processo de desenvolvimento
(Construo, implantao e manuteno) de software [MAFFEO92].
Esses problemas no se referem apenas a programas que no funcionam.Na verdade, a chamada
Crise do Software abrange todos os problemas relacionados a [REZENDE99]:
-

Como sistemas computacionais so construdos;

Como sistemas computacionais so implantados, referindo-se aqui ao processo de substituir
sistemas antigos, desativando sistemas correntemente em operao, ou ao processo de
instalar um sistema inteiramente novo;
Como provida a manuteno da quantidade crescente de software construdo, associado a
sistemas computacionais cada vez mais complexos;
Como fazer face crescente demanda para construo de software, visando satisfazer ao
conjunto enormemente variado de anseios por informatizao, atualmente detectado na
sociedade moderna;
Como administrar as questes comportamentais, envolvendo os clientes e/ou usurios e a
poltica, cultura e filosofia empresarial.

Apesar da enorme variedade de problemas que caracterizam a crise do software, engenheiros de

software e gerentes de projetos para desenvolvimento de sistemas computacionais tendem a
concentrar suas preocupaes no seguinte aspecto: A enorme impreciso das estimativas de
cronogramas e de custos de desenvolvimento (Tabelas 2, 3, 4 e 5) [LEE02].
A no implementao da engenharia de requisitos permite erros no levantamento dos requisitos do

sistema, e somente percebidos na implantao do sistema, gerando assim uma fase de manuteno e
correo do software interminvel, excedendo no custo desta fase (Tabela 2) e alongando o prazo de
trmino substancialmente (Tabela 3).
Tabela 2- Excedentes de Custo [LEE02].

Tabela 3- Excedente de Prazo [LEE02].

Excedentes de Custo

% Excedente de Custo
<20%
21% - 50%
51% - 100%
101% - 200%
201% - 400%
>400%

Excedente de Prazo

% de
Respostas
15,5%
31,5%
29,6%
10,2%
8,8%
4,4%

% Excedente de Prazo
<20%
21% - 50%
51% - 100%
101% - 200%
201% - 400%
>400%

% de
Respostas
13,9%
18,3%
20,0%
35,5%
11,2%
1,1%

O custo do desenvolvimento do software varia de acordo com cada fase de seu processo (Tabela 4).
No entanto com a implementao da engenhara de requisitos, os erros de levantamento de requisitos
identificados na fase de anlise do projeto de software, reduz o custo para correo (Tabela 5).
Tabela 4- Custos em projeto de software por fase de desenvolvimento [LEE02].
Custos em projeto de software por Fase de Desenvolvimento

Etapa de Trabalho
Anlise de Requisitos
Desenho
Programao
Testes
Manuteno

%
3
8
7
15
67

Tabela 5- Custos para correo de erros de software [LEE02].

Custos para Correo de Erros de Software
Fase de desenvolvimento
do software

Anlise de Requisitos
Desenho
Teste do Cdigo e da Unidade
Teste de Integrao
Validao e Documentao
Manuteno Operacional

% de

Erros

Erros

Custo

Desvios

Introduzidos

encontrados

Relativo para

($)
5
25
10
50
10

(%)
55
30

(%)
18
10

Correo
1,0
1,0 - 1,5

10

50

1,0 - 5,0

22

10 100

Muitos desses erros poderiam ser evitados se as organizaes dispusessem de um processo de

engenharia de requisitos definido, controlado, medido e aprimorado. No entanto, percebe-se que
para muitos profissionais de informtica esses conceitos no so muito claros, o que certamente
dificulta a ao dos gerentes no sentido de aprimorar os seus processos de desenvolvimento
[BLASCHEK03].

7. ANTICRISE DO SOFTWARE
Segundo Rezende [REZENDE99], pode-se resumir que a anticrise a unio e trabalho conjunto e
harmonioso de trs elementos: Empresa (Alta Administrao), Cliente e/ou usurio e a unidade de
informtica (Desenvolvedores de solues).
E na prtica, cabe principalmente unidade de informtica aceitar este conceito e fazer o possvel
para a efetivao desta tese (Anticrise), utilizando-se de todos os recursos disponveis para tal.
A Unidade de informtica um dos principais agentes de mudana nas organizaes, preocupandose com o negcio empresarial, auxiliando efetivamente os gestores nos processos de tomada de
deciso, tanto operacionais, como gerenciais e estratgicas.

8. QUALIDADE DE SOFTWARE
Atingir um alto nvel de qualidade de produto ou servio o objetivo da maioria das organizaes.
Atualmente no mais aceitvel entregar produtos com baixa qualidade e reparar os problemas e as
deficincias depois que os produtos foram entregues ao cliente. [SOMMERVILLE03]
Segundo Machado [MACHADO01], para muitos engenheiros de software, a qualidade do processo
de software to importante quanto qualidade do produto. Assim na dcada de 90 houve uma
grande preocupao com a modelagem e melhorias no processo de software. Abordagens
importantes como as normas ISO 9000 e a ISO / IEC 12207, o modelo CMM (Capability Maturity
Model) e o SPICE (Software Process Improvement and Capability dEtermination) sugerem que
melhorando o processo de software, podemos melhorar a qualidade dos produtos.
A qualidade conseqncia dos processos, das pessoas e da tecnologia. A relao entre e qualidade
do produto e cada um desses fatores complexa. Por isso, muito mais difcil controlar o grau de
qualidade do produto do que controlar os requisitos.[PDUA03]
Prev-se que na primeira dcada dos anos 2000, aps ajustarem seus processos para a produo de
software de qualidade dentro de prazos e oramentos confiveis, as organizaes sero pressionadas
por seus concorrentes a reduzir substancialmente os prazos para a entrega de produtos.Organizaes
que sejam capazes de integrar, harmonizar e acelerar seus processos de desenvolvimento e
manuteno de software tero a primazia do mercado [MACHADO01].
A globalizao da economia vem influenciando as empresas produtoras e prestadoras de servios de
software a alcanar o patamar de qualidade e produtividade internacional para enfrentarem a
competitividade cada vez maior. A norma internacional NBR ISO/IEC 12207 Tecnologia da
Informao Processos de Ciclo de Vida de Software [ISO12207: 97] usada como referncia em
muitos pases, inclusive no Brasil, para alcanar esse diferencial competitivo [MACHADO01].
A norma ISO/IEC 12207 trata os requisitos do software como fator fundamental no processo de
ciclo de vida do software, gerando documentao para a fase de desenvolvimento do software,
possibilitando que o produto seja verificado e validado posteriormente, atendendo assim as
necessidades do adquirente.
Diante deste fato, podemos afirmar que por falta de utilizao de mtodos e modelos de
gerenciamento da qualidade de software com base em requisitos, produzimos softwares de qualidade
contestvel e participando efetivamente da Crise do Software [PRESSMAN02].

9. PRODUTO DE SOFTWARE
Quando entregamos a um cliente um pacote bem delimitado e identificado, podemos dizer que
entregamos um produto [SPINOLA98].
A definio para produto de software segundo a norma IEEE-STD-610 [IEEE90] :
O conjunto completo, ou qualquer dos itens individuais do conjunto, de programas de computador,
procedimentos, e documentao associada e dados designados para liberao para um cliente ou
usurio final [PAULK95].

10. PROCESSO DE SOFTWARE

O conceito de processo de software se baseia no conceito generalizado de processo, que pode ser
definido como uma seqncia de estados de um sistema que se transforma [SPINOLA98].
O SEI (Software Engineering Institute), da Carnegie Melon University prope o seguinte [SEI]:
Um processo uma seqncia de passos realizados para um dado propsito. Colocado de maneira
mais simples, processo aquilo que voc faz. Processo aquilo que as pessoas fazem, usando
procedimentos, mtodos, ferramentas, e equipamentos, para transformar matria prima (entradas)
em produto (sada) que tenha valor para o cliente.[PAULK95]
O processo de software pode ser definido como um conjunto de atividades, mtodos, prticas, e
transformaes que as pessoas empregam para desenvolver e manter software e os produtos
associados (ex. planos de projeto, documentos de projeto (design), cdigo, casos de teste, e manual
do usurio).[PAULK95]

11. REQUISITOS
Os problemas que os engenheiros de software tm para solucionar so, muitas vezes, imensamente
complexos. Compreender a natureza dos problemas pode ser muito difcil, especialmente se o
sistema for novo. Conseqentemente, difcil estabelecer com exatido o que o sistema deve fazer.
As descries das funes e das restries so os requisitos para o sistema [SOMMERVILLE03].
Os Requisitos (Requirements) podem ser definidos como as necessidades bsicas do cliente,
geralmente explicitadas como condio de negcio no contrato com o fornecedor. So
caractersticas, tais como especificaes tcnicas, prazo de entrega, garantia, que o cliente requer
do produto [MCT02].
Uma condio ou capacidade necessitada por um usurio, para resolver um problema ou alcanar
um objetivo [IEEE90].
Segundo Tonsig, Os requisitos compem o conjunto de necessidades estabelecido pelo cliente /
usurio do sistema que definem a estrutura e comportamento do software que ser desenvolvido
[TONSIG03].
Segundo Pdua, o fluxo de requisitos rene as atividades que visam a obter o enunciado completo,
claro e preciso dos requisitos de um produto de software. Esses requisitos devem ser levantados pela
equipe do projeto, em conjunto com representantes do cliente, usurios chaves e outros especialistas
da rea de aplicao [PADUA03].

Os requisitos de sistema de software so, freqentemente, classificados com funcionais ou no

funcionais ou como requisitos de domnio [SOMMERVILLE03]:
Requisitos Funcionais: So declaraes de funes que o sistema deve fornecer, como o sistema
deve reagir a entradas especficas e como deve se comportar em determinadas situaes. Em
alguns casos, os requisitos funcionais podem tambm explicitamente declarar o que o sistema
no deve fazer. Exemplo: O software deve permitir ampla consulta sobre os dados dos pedidos
do cliente, inclusive via Internet [TONSIG03].
Requisitos No Funcionais: So restries sobre os servios ou as funes oferecidas pelo
sistema. Entre eles destacam-se restries de tempo, restries sobre o processo de
desenvolvimento, padres, entre outros. Exemplo: O acesso aos recursos do software deve ser
restrito a pessoas autorizadas [TONSIG03].
Requisitos de domnio: So requisitos que se originam do domnio de aplicao do sistema e que
refletem caractersticas desse domnio. Podem ser requisitos funcionais ou no funcionais.
Exemplo: Deve haver uma interface-padro com o usurio para todos os bancos de dados, que
ter como base o padro X [SOMMERVILLE03].

12.ENGENHARIA DE REQUISITOS
O processo de descobrir, analisar, documentar, e verificar as funes e restries do sistema,
chamado de engenharia de requisitos [SOMMERVILLE03].
Engenharia de requisitos, uma subrea da engenharia de software, tem por objetivo tratar o processo
de definio dos requisitos de software. Para isso estabelece um processo pelo qual o que deve ser
feito elicitado, modelado e analisado. Esse processo deve lidar com diferentes pontos de vista e
usar uma combinao de mtodos, ferramentas e pessoal. O produto desse processo um modelo,
do qual um documento chamado requisitos produzido. Esse processo perene e acontece em um
contexto previamente definido e que chamamos de Universo de informaes [LEITE01].
O conjunto de tcnicas empregadas para levantar, detalhar, documentar e validar os requisitos de
um produto forma a engenharia de requisitos [PADUA03].
A engenharia de requisitos fornece um mecanismo adequado para entender o que o cliente deseja,
analisar as necessidades, avaliar a exeqibilidade, negociar uma soluo razovel, especificar a
soluo de maneira no-ambgua, validar a especificao e administrar os requisitos medida que
eles so transformados num sistema em operao. O processo da engenharia de requisitos pode ser
descrito em cinco passos distintos [PRESSMAN02]:
Elicitao de requisitos
Anlise e negociao de requisitos
Especificao de requisitos
Modelagem do sistema
Validao de requisitos
Gesto de requisitos
12.1 ELICITAO DE REQUISITOS
Certamente parece muito simples pergunte ao cliente, aos usurios e a outros quais so os
objetivos do sistema ou do produto, o que precisa ser conseguido, como o sistema ou o produto se
encaixa nas necessidades do negcio e, finalmente, como o sistema ou o produto vai ser usado no
dia-dia. Mas no simples muito difcil.

Na industria de software, as necessidades dos clientes so muito difceis de serem acessados ou

descobertos. Geralmente deve-se deixar margens nos sistemas para futuras mudanas. Os requisitos
geralmente so vagos [FREITAS00].
A seguir, vrios problemas que nos ajudam a compreender por que a elicitao de requisitos difcil
[PRESSMAN02]:
Problemas de escopo: O limite do sistema mal definido. Detalhes tcnicos desnecessrios que
podem confundir, em vez de esclarecer, os objetivos globais do sistema.
Problemas de entendimento: Os clientes no esto completamente certos do que necessrio,
tm pouca compreenso das capacidades e limitaes de seu ambiente computacional e tm
dificuldade de comunicar as necessidades ao engenheiro de sistemas, omitem informaes que
acreditam ser bvia, especificam requisitos que so ambguos ou impossveis de testar.
Problemas de volatilidade: Os requisitos mudam ao longo do tempo.
Para ajudar a contornar esses problemas, os engenheiros de sistemas devem abordar a atividade de
coleta de requisitos de um modo organizado.
Sommerville [SOMMERVILLE03] sugere um conjunto de diretrizes detalhadas para a elicitao de
requisitos, que so resumidas nos seguintes passos:
Avalie a viabilidade tcnica e de negcios do sistema proposto.
Identifique as pessoas que vo ajudar a especificar os requisitos e compreenda seu vis
organizacional.
Defina o ambiente tcnico no qual o sistema ou produto vai ser colocado.
Identifique restries de domnio que limitam a funcionalidade ou o desempenho do sistema
ou do produto a ser construdo.
Defina um ou mais mtodos de elicitao de requisitos (entrevistas, reunies etc.).
Solicite a participao de muitas pessoas de modo que os requisitos sejam definidos de
diferentes pontos de vista; certifique-se de identificar a razo de cada requisito que registrado.
Identifique requisitos ambguos como candidatos para prototipagem.
Crie cenrios de uso para ajudar clientes / usurios a melhor identificar requisitos-chave.
Os produtos de trabalho produzidos como conseqncia das atividades de elicitao de requisitos
vo variar de acordo com o tamanho do sistema ou do produto a ser construdo. Para a maioria dos
sistemas, os produtos de trabalho incluem:
Uma declarao da necessidade e da viabilidade.
Uma declarao delimitada de escopo do sistema ou do produto.
Uma lista de usurios e interessados que participaram da atividade de elicitao de requisitos.
Uma descrio do ambiente tcnico do sistema.
Uma lista de requisitos e as restries do domnio que se aplicam a cada um.
Um conjunto de cenrios de utilizao que fornece entendimento do uso do sistema ou do
produto em diferentes condies de operao.
Quaisquer prottipos desenvolvidos para melhor definir os requisitos.
Cada um desses produtos de trabalho revisado por todo o pessoal que participou da elicitao de
requisitos.
12.2 ANLISE E NEGOCIAO DE REQUISITOS
Uma vez reunidos os requisitos, os produtos de trabalho mencionados anteriormente formam a base
para a anlise de requisitos. A anlise categoriza os requisitos e os organiza em subconjuntos
relacionados; explora cada um em relao aos demais; examina-os quanto consistncia, omisses e
ambigidade; e ordena-os com base nas necessidades dos clientes / usurio [PRESSMAN02].

 medida que medida que a anlise de requisitos comea, as seguintes perguntas so formuladas e
respondidas:
Cada requisito est consistente com o objetivo global do sistema/produto?
Todos os requisitos foram especificados no nvel de abstrao adequado?
O requisito realmente necessrio, ou pode ser essencial para o objetivo do sistema?
Cada requisito limitado e no-ambguo?
Cada requisito tem atribuio? Isto , uma fonte est associada a cada requisito?
Algum requisito conflita com outros requisitos?
Cada requisito realizvel no ambiente tcnico que vai alojar o sistema ou o produto?
Cada requisito pode ser testado, quando estiver implementado?
No incomum que os clientes / usurios peam mais do que pode ser conseguido, considerando os
recursos limitados do negcio.
O engenheiro de sistemas precisa reconciliar esses conflitos por intermdio de um processo de
negociao. Os riscos associados a cada requisito so identificados e analisados. Estimativas
grosseiras do esforo de desenvolvimento so feitas e usadas para avaliar o impacto de cada
requisito no custo do projeto e no prazo de entrega. Usando uma abordagem iterativa, requisitos so
eliminados, combinados ou modificados de modo que cada parte alcance algum grau de satisfao.
12.3 ESPECIFICAO DE REQUISITOS
No contexto de sistemas baseados em computador, o termo especificao significa coisas diferentes
para pessoas diferentes. Uma especificao pode ser um documento escrito, um modelo grfico, um
modelo matemtico formal, uma coleo de cenrios de uso, um prottipo ou qualquer combinao
desses elementos. Para sistemas grandes, um documento escrito, combinando descries em
linguagem natural e modelos grficos podem ser a melhor abordagem. Cenrios de uso podem,
entretanto, ser tudo que necessrio para produtos ou sistemas pequenos que residem em ambientes
tcnicos bem-entendidos [PRESSMAN02].
12.4 MODELAGEM DO SISTEMA
Cada sistema baseado em computador pode ser modelado como uma transformao de informao
usando um gabarito entrada processamento sada. Essa viso pode ser estendida para incluir duas
caractersticas adicionais dos sistemas processamento e manuteno de interface com o usurio e
autoteste [PRESSMAN02].
12.5 VALIDAO DE REQUISITOS
Os produtos de trabalho produzidos como conseqncia da engenharia de requisitos so avaliados
quanto qualidade durante o passo de validao. A validao de requisitos examina a especificao
para garantir que todos os requisitos do sistema tenham sido declarados de modo no-ambguo; que
as inconsistncias, omisses e erros tenham sido detectados e corrigidos e que os produtos de
trabalho estejam de acordo com as normas estabelecidas para o processo, projeto e produto
[PRESSMAN02].
12.6 GESTO DE REQUISITOS
Gesto de requisitos um conjunto de atividades que ajuda a equipe de projeto identificar, controlar
e rastrear requisitos e modificaes de requisitos em qualquer poca, medida que o projeto
prossegue [PRESSMAN02].

10

Geralmente, requisitos corretos no incio do projeto so mudados posteriormente [FREITAS00].

13. ERGONOMIA COGNITIVA

A Cincia Cognitiva, segundo Peters [PETERS01], o estudo de como o conhecimento adquirido,
representado na memria e utilizado na resoluo de problemas. A abordagem da cincia cognitiva
programao de computadores enfoca como os programadores representam o conhecimento, como
as estruturas dos programas so aprendidas e como o conhecimento aplicado no desenvolvimento
de software.
A ergonomia cognitiva o estudo das habilidades de resoluo de problemas, anlise de
informaes e procedurais relativas influncia dos fatores humanos. As questes dos fatores
humanos relativos a estruturas de linguagem de programao, programao de computadores e
interao homem-computador so respondidas de forma cognitiva em termos de esforo mental
exigido.
A limitao da memria de curto prazo o grave obstculo ao desenvolvimento de programas de
computador em grande escala. Isso significa que no possvel compreender tantos elementos ao
mesmo tempo a ponto de controlarem as vrias conexes existentes entre os componentes de um
sistema de software. O agrupamento visto como uma forma de combater esse problema. O
agrupamento o processo de reunir itens com atributos semelhantes ou relacionados para formar um
item nico.
O agrupamento fornece a base para os modelos de compreenso de programas teis na manuteno
de software, ou seja, a compreenso do software auxiliada por representaes internas de um
sistema com planos e esquemas. O processo de entendimento coincide documentos do sistema,
como requisitos, aos planos de programao utilizando regras do discurso para selecionar planos. O
resultado de cada coincidncia de um documento externo com um plano a representao mental
atualizada, que armazenada como um novo plano.
Concluindo, podemos detectar que a dificuldade de compreender e especificar requisitos em
diferentes nveis de abstrao vai defrontar com a nossa capacidade cognitiva de adquirir o
conhecimento para criar solues de software. O estudo da ergonomia cognitiva e sua aplicao
juntamente com a implementao da engenharia de requisitos, sero fatores crticos de sucesso no
desenvolvimento de software.

14. CONCLUSO
importante que os desenvolvedores de software reconheam que no possvel desenvolver
sistemas com qualidade, cumprir prazos e custos e atender s expectativas dos usurios sem ter um
processo de desenvolvimento de requisitos definido, compreendido e utilizado por toda a equipe.
Quanto engenharia de requisitos podemos ainda acrescentar:
-

Adequao aos princpios e objetivos da Engenharia de Software.

O nvel de complexidade da sua implementao pode ser dimensionada de acordo com o
porte do sistema, viabilizando para as pequenas organizaes desenvolvedoras de software.
Possibilita ento ser fator crtico para o sucesso no desenvolvimento de software.
Pode ser utilizada alinhada as normas ISO de qualidade de software 12207, 9000-3.
Com a sua implementao possvel contribuir para o fim da Crise do Software.
Alinhada a cincia cognitiva, permite transformar problemas em agrupamentos menores,
facilitando a compreenso e criao de soluo.

11

Permite para micros, pequenas e mdias empresas que possuem recursos humanos e
financeiros limitados possibilidade de competir com as empresas de maior porte.
Com os processos de desenvolvimento de software controlados, documentados e gerenciados
o pequeno desenvolvedor poder assumir projetos de alta complexidade, aliados a tcnica e
criatividade, pois ter mais chance de sucesso.
Melhor capacitado e provedor de metodologias que levam ao desenvolvimento de software
com qualidade, o desenvolvedor poder criar solues que atendam as necessidades e os
requisitos da empresa, contribuindo para criao de vantagens competitivas, sustentando as
bases estratgicas das organizaes.

15. REFERENCIAS BIBLIOGRFICAS

[BLASCHEK03] BLASCHEK, JOS ROBERTO. Gerncia de Requisitos, o principal problema
dos projetos de software, Artigo Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2003.
[BROOKS87] BROOKS, F. Essence and accidents to software engineering. Los Alamos,
California, IEEE Computer Society, v.4, n.3, 1987.
[FIORINI98] FIORINI, SOELI T., et al. Engenharia de Software com CMM, Rio de Janeiro, Ed.
Brasport, 1998.
[FREITAS00] FREITAS, LUS RICARDO NAPOLITANO, Projetos em Tecnologia da
Informao Como acertar atravs da anlise dos erros. Dissertao de Mestrado, USP-SP, 2000.
[IEEE90] IEEE STD. 610 12-1990, IEEE Standard Glossary of Software Engineering Terminology,
IEEE, Piscataway, NJ, 1997.
[ISO12207: 97] NBR ISO/IEC 12207:1997, Tecnologia de Informao Processos de Ciclo de
Vida de Software, Rio de Janeiro, ABNT Associao Brasileira de Normas Tcnicas.
[LEE02] LEE, RICHARD C. e TEPFENHART, WILLIAM M., UML e C++ - Guia de
desenvolvimento orientado a objeto, So Paulo, Ed. Makron Books, 2002.
[LEITE01] LEITE, JULIO CESAR SAMPAIO DO PRADO, in WEBER, KIVAL CHAVES, et al.
Qualidade e Produtividade em Software, So Paulo, Ed. Makron Books, 2001.
[MACHADO01] MACHADO, CRISTINA NGELA FILIPAK in WEBER, KIVAL CHAVES, et
al. Qualidade e Produtividade em Software, So Paulo, Ed. Makron Books, 2001.
[MAFFEO92] MAFFEO, BRUNO, Engenharia de Software e Especificao de Sistemas, Rio de
Janeiro, Ed. Campus, 1992.
[MARTIN91] MARTIN, JAMES,Engenharia da Informao, Rio de Janeiro, Ed. Campus, 1991.
[MCT02] MINISTRIO DA CINCIA E TECNOLOGIA, Secretaria de Poltica de Informtica,
Qualidade e Produtividade no Setor de Software Brasileiro, Braslia, N.4, 2002.
[PADUA03] FILHO, WILSON DE PDUA PAULA, Engenharia de Software, Rio de Janeiro, Ed.
LTC, 2003.
[PAULK95] PAULK, M.C. et al. The Capatibility Maturity Model Guidelines for improving the
software process, Addison Wesley, SEI series, 1995.
[PETERS01] PETERS, JAMES F. et al. Engenharia de Software,Rio de Janeiro, Ed. Campus,2001.
[PRESSMAN02] PRESSMAN, ROGER S., Engenharia de Software, Rio de Janeiro, Ed. McGrawHill, 2002.
[REZENDE99] REZENDE, DENIS ALCIDES, Engenharia de Software e Sistemas de Informaes,
Rio de Janeiro, Ed. Brasport, 1999.
[SEI] SEI, Software Engineering Institute, Carnegie Melon University, http://www.sei.cmu.edu.
[SOMMERVILLE03] SOMMERVILLE, IAN, Engenharia de Software, So Paulo, Ed. Pearson
Education, 2003.
[SPINOLA98] SPINOLA, MAURO DE MESQUITA, Diretrizes para o desenvolvimento de
software de sistemas embutidos, Tese de Doutorado, USP - So Paulo, 1998.
[TONSIG03] TONSIG, SRGIO LUIZ, Engenharia de Software, So Paulo, Ed. Futura, 2003.

12