A Engenharia do Sistema

necessria a utilizao de termos de referncia que no so mais do que os requisitos para

um trabalho. um documento que deve ser elaborado na fase inicial do trabalho.
Os termos de referncia tm como funo comunicar o objectivo do projecto, as pessoas
envolvidas, prazos, custos, qualidade, a forma de gesto do projecto, etc.
A engenharia de software torna-se bastante til no que se refere construo do software,
centrado nas suas questes tcnicas (desenhar, codificar, testar, etc). O trabalho associado
com o desenvolvimento de software contm 3 fases: definio, desenvolvimento e suporte.
Existem alguns modelos de desenvolvimento: modelos de desenvolvimento clssicos (cascata,
em V, etc) e os modelos de desenvolvimento evolutivos (de entrega incremental, em espiral,
etc).

Especificaes de Requisitos de Software

Norma IEEE Std 830-1998

Joaquim Henriques Carvalho (N 20081616)

Planeamento Estratgico de Sistemas de Informao
Instituto Superior Politcnico do Oeste
Torres Vedras, Portugal
joaquimhcarvalho@gmail.com

Resumo: Este documento descreve a norma IEEE Std 830-1998, "IEEE Recommended Practice
for Software Requirements Sprecifications, que orientada especificao de requisitos de
software a serem desenvolvidos, mas tambm pode ser aplicada na assistncia de produtos
comerciais ou desenvolvidos pela prpria empresa.

Palavras-chave: desenvolvimento; software; requisitos; especificaes; modelo; norma;

830-1998; processos; IEEE-SA

I. Introduo
Este documento foi adaptado da leitura da norma IEEE 830-1998, pelo que contm algumas
partes que so a transposio integral da norma para portugus. Tive o cuidado de resumir o
documento colocando aqui apenas o que considerei mais relevante para o trabalho em
questo.

O Institute of Electrical and Electronics Engineers (IEEE) tem no seu seio o I nstitute of Electrical
and Electronics Engineers Standards Association (IEEE-SA) que tem como principal funo
produzir standards para uma vasta gama de indstrias, tais como: alimentao e energia,
biomdica e sade, tecnologia da informao, telecomunicaes, transporte, nanotecnologia,
segurana da informao, e muitas outras. Na rea das tecnologias da informao (TI), so
imensas as normas j produzidas, em reviso ou em produo, das quais destaco:
a) IEEE 610-1990, Standard Computer Dictionary: Compilation of IEEE Standard
Computer Glossaries;
b) IEEE 610.2-1987, Standard Glossary of Computer Applications Terminology;
c) IEEE 730-2002, Software Quality Assurance Plans;
d) IEEE 830-1998, Recommended Practice for Software Requirements Specifications;
e)
IEEE 1012-2004, Software Verification and Validation;
f)
IEEE 1016-2009, System Design--Software Design Descriptions;
g) IEEE 1028-2008, Software Reviews and Audits;
h) IEEE 1045-2002, Software Productivity Metrics;
i) IEEE 1058-1998, Software Project Management Plans;
j) IEEE 1059-1993, Guide for Software Verification And Validation Plans;
k)
IEEE 1074-2006, Developing a Software Life Cycle Process;
l) IEEE 1219-1998, Software Maintenance;
m) IEEE 1220-2005, Aplication and Management of the Systems Engineering Process;
n) IEEE 12207-2008 - System and software engineering -- Software life cycle processes.
A norma a que irei dedicar especial ateno neste artigo e que consta no ttulo do mesmo, tem
como objectivo facilitar a elaborao de um documento completo de especificaes de
requisitos de software (ERS).

II. Consideraes para a produo

de um documento de ERS
A. Natureza do documento
No documento dever constar uma especificao particular de um produto, programa ou
conjunto de programas que executem certas funes num ambiente bem determinado. Pode
ser escrito pelo fornecedor, pelo cliente ou por ambos. recomendado que sejam ambos a
elabor-lo.
Devem ser tomados em conta os seguintes aspectos:
a) Funcionalidade: o que deve fazer o software?
 b) Interfaces externas: como interage o software com as pessoas, com o hardware do
sistema e com outro software?
c) Performance: qual a velocidade, disponibilidade, tempo de resposta, tempo de
recuperao das vrias funcionalidades, etc.?
d) Atributos: quais as consideraes relativas portabilidade, correco, maleabilidade,
segurana, etc.?
e) Restries de desenho impostas numa implementao: existem exigncias padro,
linguagem de implementao, polticas para integridade da base de dados, limites de
recursos, ambientes operacionais, etc.?
Na elaborao do documento deve-se evitar a introduo de exigncias de desenho ou de
projecto, contudo, caso seja mesmo necessrio, deve-se seguir as recomendaes das alneas
G e H deste captulo.

B. Ambiente do documento
Um documento de ERS tem um papel bem definido no processo de desenvolvimento de
software, pelo que, quem o escreve, deve ter cuidado para no passar os limites do mbito a
que se destina. Isto quer dizer que o documento:

a) deve definir correctamente todas as exigncias do software. Uma exigncia do

software pode existir devido natureza da tarefa a ser resolvida ou devido a uma
caracterstica particular do projecto.
b) no deve descrever nenhum detalhe de desenho ou implementao. Estes devem ser
descritos na fase de desenho do projecto.
c) no deve impor restries adicionais ao software. Estas esto devidamente
especificadas noutros documentos tais como o plano de garantia de qualidade do
software.
Por isso, o documento deve limitar a fronteira de desenhos vlidos, mas nunca vincular
nenhum desenho em particular.

C. Caractersticas do documento
Um documento de ERS deve ser:
a) Correcto: o documento est correcto se, e s se, todas as exigncias nele expressas
sero correspondidas pelo software;
b) No ambguo: o documento no ambguo se, e s se, todas as exigncias nele
expressas tm uma nica interpretao, isto requer que cada uma das caractersticas
sejam descritas usando termos simples e nicos;
c) Completo: o documento considera-se completo se, e s se, inclui os seguintes
elementos: todas as exigncias significantes, independentemente da tipologia, esto
definidas as respostas a todas as classes de dados para todas as situaes e todas as
figuras, tabelas e diagramas tm legendas e referncias completas;
d) Consistente: se existirem outros documentos relacionados com o mesmo projecto, o
 documento dever estar em concordncia com os outros;
e) Classificvel por importncia e/ou estabilidade: tipicamente, as exigncias de um
produto de software no so da mesma importncia. Algumas exigncias podem ser
essenciais, especialmente para aplicaes crticas, enquanto que outras podem ser
apenas desejveis. Cada exigncia deve conter identificaes que tornem estas
diferenas claras e explcitas, ou seja, estar associada a um identificador de estabilidade
e/ou importncia;
f) Verificvel: um documento diz-se verificvel se, e s se, cada exigncia especificada
verificvel. Uma exigncia verificvel quando existe um processo finito e de custo
aceitvel atravs do qual uma pessoa ou uma mquina pode verificar que o produto de
software cumpre essa exigncia;
g) Modificvel: um documento diz-se modificvel se, e s se, a sua estrutura e estilo so
tais que mudanas a exigncias podem ser efectuadas de forma fcil, completa e
consistente, preservando simultaneamente estrutura e estilo;
h) Rastrevel: um documento diz-se rastrevel se cada uma das suas exigncias clara e
facilitadora da identificao da mesma exigncia em verses futuras do desenvolvimento
ou da documentao;

D. Preparao conjunta do documento

O processo de desenvolvimento de software deve comear com o acordo por parte do cliente e
do fornecedor acerca daquilo que o software, uma vez completo, deve fazer. Este acordo,
includo no documento, deve ser preparado de forma conjunta. Isto importante pois
usualmente nem o cliente nem o fornecedor esto completamente qualificados para escrever
um bom documento de ERS de uma forma unilateral porque:
a. os clientes normalmente no compreendem o suficiente dos processos de desenho e
desenvolvimento de software para o escrever.
b. os fornecedores normalmente no compreendem os problemas e os negcios dos clientes o
suficiente para descreverem as exigncias de forma satisfatria.

E. Evoluo do documento
O documento pode necessitar de evoluir medida que o desenvolvimento do produto de
software avana, por ser impossvel especificar todos os detalhes na altura em que o projecto
iniciado. Mudanas subsequentes do documento podem ser encaradas como deficincias ou
imprecises descobertas no documento, ainda que revises evolutivas se prevejam inevitveis.
Assim, as modificaes aprovadas nas exigncias devem ser incorporadas no documento de
forma a:
a) providenciar um historial de modificaes auditvel, preciso e completo;
b) permitir a reviso de pores correntes ou j substitudas do documento original.
F. Prototipagem
A prototipagem utilizada frequentemente durante a fase de desenvolvimento de exigncias
porque mais fcil de reagir a um prottipo que ler um documento de exigncias, e isso
permite respostas mais rpidas e acelera a convergncia de interesses na elaborao do
documento. Vrias ferramentas podem ser utilizadas de forma a permitir a criao de um
prottipo que exiba algumas caractersticas do sistema, de forma rpida e fcil. Consulte
tambm a norma ASTM E1340-96.

G. Incorporao do desenho no documento

Uma exigncia especifica uma funo externamente visvel ou um atributo de um sistema. O
desenho descreve um
sub-componente particular do sistema e/ou as suas interfaces com outros sub-componentes.
Quem escreve o documento deve distinguir claramente entre a definio de restries de
desenho e o vnculo a um desenho especfico. Note-se que cada exigncia limita as
alternativas de desenho.
O documento deve especificar quais as funes que devem ser levadas a cabo em que dados,
de forma a produzir que resultados, em que local, e para quem. O documento de ERS deve
focar-se nos servios a desempenhar.
O documento no deve especificar os seguintes itens de desenho:
a) Subdiviso do software por mdulos;
b) Alocao de funes a mdulos;
c) Descrever o fluxo de informao ou controlo entre mdulos;
d) Escolha de estruturas de dados.

H. Incorporao das exigncias do projecto

O documento de ERS deve focar-se no produto de software e no no processo de produo do
produto de software.
As exigncias do projecto representam um entendimento entre o cliente e o fornecedor sobre
questes contratuais relacionadas com o processo de software e assim no podem ser
includas nas exigncias. Nestes itens incluem-se referncias a:
a. Custo;
b. Datas de entrega;
c. Procedimentos de reporte;
d. Mtodos de desenvolvimento de software;
e. Certificao de qualidade;
f. Critrios de verificao e validao;
g. Procedimentos de aceitao;
Exigncias do projecto so especificados em outros documentos, tipicamente num plano de
desenvolvimento de software e num plano de certificao de qualidade de software.

III. Partes de um documento de ERS

Se bem que o documento no tenha de seguir esta estrutura ou utilizar os nomes aqui
sugeridos para os seus componentes, um bom documento de exigncias deve incluir toda a
informao aqui descrita:

A. Introduo
A introduo do documento de ERS deve providenciar uma viso geral sobre o documento
inteiro. Deve por isso conter as seguintes sub-seces:
1. Propsito
Esta seco deve:
a. Delinear o propsito do documento;
b. Especificar a audincia alvo do documento.
2. mbito
Esta seco deve:
a. Identificar o produto de software a desenvolver pelo seu nome;
b. Explicar o que o produto ir fazer, e se necessrio, o que no ir fazer;
c. Descrever a aplicao do software, incluindo benefcios relevantes e
objectivos;
d. Ser consistente com outros documentos similares ou de mais alto nvel (por
exemplo, a especificao das exigncias do sistema), caso existam.

3. Definies, acrnimos e abreviaturas

Esta sub-seco deve fornecer as definies de todos os termos, acrnimos e
abreviaturas necessrios interpretao do documento de ERS. Esta informao pode
ser fornecida por referncia a um ou mais apndices do documento ou por referncia a
outros documentos.
4. Referncias
Esta seco deve:
a. Fornecer uma lista completa de todos os outros documentos referenciados
pelo documento de ERS;
b. Identificar cada documento pelo seu ttulo, nmero de relatrio (quando
aplicvel), data e organizao que o publica;
c. Especificar as fontes de onde as referncias podem ser obtidas;
Esta informao pode ser fornecida por referncia a um apndice ou a outro documento.
 5. Organizao
Esta seco deve:
a. Descrever o contedo do documento;
b. Explicar a organizao do documento.

B. Descrio geral
Descreve os factores gerais que afectam o produto e as suas exigncias. Esta seco
no enumera exigncias especficas. Ao invs, fornece um contexto para essas
exigncias (que so definidas em detalhe na prxima Seco do documento), e facilita a
sua compreenso.
Consiste habitualmente em 6 sub-seces:
1. Perspectiva do produto
Esta sub-seco do documento deve colocar o produto em perspectiva relativamente a
outros produtos relacionados. Se o produto independente e totalmente auto-contido,
isso deve ser explicitado aqui. Se o documento define um produto que forma parte de um
sistema maior, como frequentemente o caso, ento esta sub-seco deve relacionar as
exigncias do sistema envolvente com a funcionalidade do software e deve identificar
interfaces entre o sistema e o software.
Devero ser usados diagramas que facilitem a interpretao das interligaes e
interfaces.
Deve tambm descrever a operao do software dentro de vrias restries. Por
exemplo:
a. Interfaces de sistema;
b. Interfaces com o utilizador;
c. Interfaces de hardware;
d. Interfaces de software;
e. Interfaces de comunicao;
f. Memria;
g. Operaes;
h. Adaptaes ao local de instalao.
2. Funcionalidades do produto
Deve fornecer um resumo das principais funes que o software vai desempenhar. Por
exemplo, para um programa de contabilidade pode usar esta seco para referir
manuteno de contas de cliente, balanos e preparao de recibos, sem mencionar as
vastas quantidades de detalhe que cada uma dessas funes necessita.
Por vezes o resumo de funes que necessrio para esta seco pode ser retirado
directamente da seco de especificao de alto nvel (caso exista) que atribui funes
particulares ao produto de software. Note-se que, para bem da clareza:
a. As funes devem ser organizadas de um modo que torne a lista de funes
compreensvel para o cliente, ou quem quer que esteja a ler o documento pela
primeira vez.
b. Mtodos textuais ou grficos podem ser usados para mostrar as diferentes
 funes e as suas inter-relaes. Tais diagramas no se destinam a mostrar o
desenho tcnico do produto, mas simplesmente a mostrar as relaes lgicas
entre variveis.
3. Caractersticas do utilizador
Esta sub-seco do documento de ERS deve descrever as caractersticas gerais dos
utilizadores alvo do produto, incluindo nvel de formao, experincia e proficincia
tcnica. No deve ser usada para ditar exigncias especficas, mas sim para fornecer as
razes pelas quais certas exigncias especficas so necessrias.
4. Restries
Aqui deve constar uma descrio geral de quaisquer outros itens que limitem as opes
de desenvolvimento. Estes incluem:
a. Regulamentos;
b. Limitaes de hardware;
c. Interfaces com outras aplicaes;
d. Operao em paralelo;
e. Funes de auditoria;
f. Funes de controlo;
g. Exigncias de alto nvel da linguagem;
h. Protocolos de signal handshake;
i. Exigncias de fiabilidade;
j. Criticalidade da aplicao;
k. Consideraes de segurana.
5. Assunes e dependncias
Esta sub-seco do documento deve listar cada um dos factores que afectam as
exigncias descritas. Estes factores no so restries de desenho do software mas sim
factores que, ao mudarem, afectam as exigncias presentes no documento. Por
exemplo, pode ser assumido que um determinado sistema operativo estar disponvel no
hardware designado para o produto de software. Se mais tarde se verificasse que tal
sistema operativo no est de facto disponvel, o documento teria ento de ser alterado.
6. Diviso e atribuio das exigncias
Esta sub-seco do documento deve identificar as exigncias que podem ser adiadas
para verses futuras do sistema.

C. Exigncias especficas
Esta seco do documento de ERS deve conter todas as exigncias de software a um nvel de
detalhe suficiente para permitir que seja feito o desenho de um sistema que as satisfaa e que
sejam feitos testes que o demonstrem. Ao longo desta seco, cada exigncia enumerada
deve ser externamente perceptvel por utilizadores, operadores ou outros sistemas externos e
deve incluir, no mnimo, uma descrio de cada entrada (estmulo), cada sada (resposta), e
todas as funes levadas a cabo pelo sistema em resposta a uma entrada ou em suporte de
uma sada.
Uma vez que esta frequentemente a parte maior e mais importante do documento de ERS,
aplicam-se os seguintes princpios:
a) Exigncias especficas devem ser ditadas de acordo com todas as caractersticas
descritas no captulo II.C;
b) Exigncias especficas devem fazer referncia a documentos anteriores que estejam
relacionados;
c) Todas as exigncias devem ter uma identificao nica;
d) Deve ser dada ateno cuidada organizao das exigncias, de forma a maximizar a
legibilidade.
Antes de examinar formas especficas de as organizar til entender os vrios itens em que
consistem, como de seguida se descreve:
1. Interfaces externas
Deve-se aqui fazer uma descrio detalhada de todas as entradas e sadas do sistema
de software, assim como complementar as descries de interfaces j enumerados e
no se deve repetir informao anteriormente detalhada.
Pretende-se assim cobrir quer contedo quer formato, da seguinte maneira:
a. Nome do item;
b. Descrio do objectivo;
c. Fonte da entrada ou destino da sada;
d. Intervalo de validade, preciso e/ou tolerncia;
e. Unidades de medida;
f. Temporizaes;
g. Relao com outras entradas/sadas;
h. Formato / organizao de ecr;
i. Formato / organizao de janela;
j. Formatos de dados;
k. Formatos de comandos;
l. Mensagens finais.

2. Funes
As exigncias funcionais devem definir as aces fundamentais que existiro no
programa. So geralmente listadas usando frases na forma "O sistema deve...", e incluir:
a. Validaes da entrada;
b. Sequncias exactas de operao;
c. Reaces a situaes anormais, incluindo:
i. Overflow
ii. Falhas de comunicao
iii. Tratamento e recuperao de erros
d. Efeitos dos parmetros;
e. Relao de entradas com sadas, incluindo
i. Sequncias de entrada / sada
ii. Frmulas de converso da entrada para a sada
Pode ser apropriado dividir as exigncias funcionais em sub-funes ou sub-processos.
Isto no implica que o desenho do software tambm venha a ser dividido da mesma
 forma.
3. Exigncias de desempenho
Esta sub-seco deve especificar exigncias numricas estticas e exigncias
numricas dinmicas impostas ao software ou interaco humana com o software
como um todo.
As exigncias numricas estticas so por vezes identificadas sob uma seco separada
intitulada Capacidade e podem incluir os seguintes pontos:
a. O nmero de terminais a suportar;
b. O nmero de utilizadores simultneos a suportar;
c. Quantidades e tipos de informao a processar.
As exigncias numricas dinmicas podem incluir, por exemplo, o nmero de
transaces e tarefas e a quantidade de dados a processar num determinado perodo de
tempo, em condies de carga normal e carga mxima.
Todas estas exigncias devem ser definidas em termos quantificveis. Por exemplo,
"95% das transaces devem ser processadas em menos de 1 segundo" em vez de "O
operador no deve ter de esperar que a transaco complete".
4. Exigncias lgicas da base de dados
Aqui devem ser especificadas as exigncias lgicas sobre qualquer informao que deva
ser colocada numa base de dados. Isto pode incluir o seguinte:
a. Tipos de informao usados pelas vrias funes;
b. Frequncia de uso;
c. Capacidades de acesso;
d. Entidades e relaes;
e. Restries de integridade;
f. Exigncias de reteno dos dados.
5. Restries de desenho
Aqui devem ser especificadas as restries ao desenho que possam ser impostas por
outras normas, limitaes de hardware, etc., como por exemplo as que derivem de
normas ou regulamentos existentes. Podem incluir os seguintes:
a. Formato de relatrios;
b. Nomeao de dados;
c. Procedimentos contabilsticos;
d. Rastreio e auditoria.
6. Atributos do sistema de software
Existe um nmero de atributos do software que podem servir de exigncias. importante
que os atributos requeridos sejam especificados de modo a que o seu cumprimento
possa ser objectivamente verificado.
Alguns exemplos so:
a. Fiabilidade: factores necessrios para estabelecer a fiabilidade exigida ao
sistema de software no acto da entrega;
b. Disponibilidade: factores necessrios para garantir um nvel definido de
disponibilidade para todo o sistema, tais como o ponto de verificao,
recuperao, e reincio.
 c. Segurana: factores que protejam o software do acesso, do uso, da
modificao, da destruio, ou da divulgao acidental ou maliciosa. As
exigncias especficas nesta rea podem incluir a necessidade de:
i. Utilizar tcnicas de codificao;
ii. Manter um histrico ou registo de dados especifico;
iii. Atribuir determinadas funes a mdulos diferentes;
iv. Restringir comunicaes entre algumas reas do
programa;
v. Verificar a integridade de dados e variveis crticas.
d. Capacidade de manuteno: atributos do software que se relacionam com a
facilidade de manuteno do mesmo.
e. Portabilidade: atributos do software que se relacionam com a facilidade de
mover o software para outras mquinas e/ou sistemas operativos. Podem incluir
o seguinte:
i. Percentagem de componentes com cdigo
dependente da mquina;
ii. Percentagem de cdigo dependente da mquina;
iii. Usar linguagens portveis;
iv. Usar um compilador ou um subconjunto especfico da
linguagem;
v. Usar um sistema operativo especfico.
7. Organizao das exigncias especificas
As exigncias detalhadas tendem a ser extensivas quando se trata de um sistema no
trivial. Por esta razo recomenda-se uma considerao cuidadosa por forma a organizar
as exigncias de uma forma simples de compreender. No existe uma organizao
ptima para todos os sistemas. Diferentes classes de sistemas inclinam-se para
diferentes organizaes de exigncias. Algumas dessas organizaes so:
a. Modo de sistema;
b. Classes de utilizadores;
c. Objectos;
d. Caractersticas;
e. Estmulos;
f. Resposta;
g. Hierarquia funcional.
8. Comentrios adicionais
Sempre que contemplado um documento de ERS novo, h vrias tcnicas
organizacionais possveis de ser empregues. Nestes casos, organizam-se as exigncias
especficas para as mltiplas hierarquias ligadas s necessidades do sistema que est a
ser tratado.
Quaisquer exigncias adicionais podem ser postas numa seco separada no fim do
documento.
Existem muitas notaes, mtodos e ferramentas de apoio automatizado disponveis
para ajudar na documentao de exigncias, que so, em grande parte, utilizadas em
 funes da organizao. Por exemplo, ao organizar por modo, mquinas de estados
finitas e tabelas de estados podem ser teis; ao organizar por objecto, anlise orientada
a objectos por ser til; ao organizar por caracterstica, sequncias de resposta de
estmulos podem ser teis; e ao organizar por hierarquia funcional, diagramas de fluxo
de dados e dicionrios de dados podem ser teis.
Todos os esboos da chamada "Exigncia funcional" podem ser descritas na lngua
natural, em pseudocdigo, numa linguagem de definio do sistema ou em quatro
sub-seces chamadas: Introduo, Entradas, Processamento e Sadas.

D. Informao de suporte
9. Inclui toda a informao de suporte que torna o documento de ERS mais simples de
usar, como por exemplo:
a. Tabela de contedos;
b. ndice remissivo;
c. Apndices : amostras de formatos de entrada/sada, descries de estudos de
anlise de custos ou resultados de questionrios, informao de suporte ou de
fundo, descries dos problemas a serem resolvidos pelo software, instrues de
empacotamento especiais para o cdigo e para os suportes de distribuio, etc.
Quando so includos apndices, o documento de ERS deve explicitamente referir se
estes devem ser considerados parte integrante das exigncias.

IV. Concluso
A Norma IEEE Std 830-1998 um modelo para a elaborao de documentos de especificao
de requisitos que apoiem a concepo de programas de computador. Tem uma sequncia que,
ao ser seguida, facilita no s a elaborao do documento como tambm o prprio
levantamento das necessidades aplicativas, permitindo o no esquecimento de pormenores
que, de outro modo, seriam facilmente deixados por descrever.
Permite ainda a normalizao na forma de conceber este tipo de documentao, facilitando
assim o uso da mesma, se tivermos em conta que poder existir a necessidade de usar vrias
ERS, como em programao modular, por exemplo. Desta forma as vrias ERS de cada
mdulo usariam sempre a mesma estrutura documental, o que leva transparncia e
facilidade na interpretao pelas equipas de desenvolvimento.
Por outro lado, ainda que referir que esta norma no dever ser seguida de forma isolada.
Dependendo das caractersticas do projecto em causa, podero ainda ser usadas as normas
relativas qualidade (IEEE 730-2002), ao design (IEEE 1016-2009), verificao e validao
(IEEE-1012-2004), gesto de projectos (IEEE 1058-1998), manuteno (IEEE 1219-1998),
entre outras igualmente importantes.
A normalizao de procedimentos conduz eficincia e, por essa razo, melhoria do
processo de desenvolvimento, o qual s funciona bem no seio de uma equipa se todos os seus
elementos souberem claramente qual o objectivo final a atingir. Esta norma permite clarificar os
objectivos e esclarecer, tanto junto da equipa de desenvolvimento como do cliente, qual o
propsito aplicacional, quais as suas funcionalidades, caractersticas e layouts.

Referncias Bibliogrficas

Software Engineering Sandards Committee of the IEEE Computer Society, IEEE

Recommended Practice for Software Requirements Specifications, 25 Junho 1998.