Você está na página 1de 9

UniversidadedeÉvora

DepartamentodeInformática

MestradoE­LearningEngenhariaInformatica

ANÁLISEDEREQUISITOS

JoaquimKalala,RuiBebiano

1. DefiniçãodoRequisitodeSoftware

Ao longo das várias décadasapósainvençãodaprogramaçãodecomputadores,os profissionaisdesoftwareaindacontinuamadebatersobreoqueéexactamenteum requisito.

Osprofissionaisdesoftwarenãousamapalavrarequisitotalcomoelaédefinidano dicionário:“condiçãonecessáriaparaaconsecuçãodeumcertofim,exigêncialegal ounecessária”.Algumaspessoasquestionamsedevemosatépriorizarosrequisitos,já que talvez o requisito de baixa prioridade não fosse implementado. Se não for

realmentenecessárioentãonãosetratadeumrequisito[1].

De acordo como o Ian Sommerville e Pete Sawyer [4] os requisitos são uma especificaçãodaquiloquedeveserimplementado.Elessãodescriçõesdecomoum sistema deve se comportar ou de umatributooupropriedadedeumsistema.Eles podemserumarestriçãoimpostasobreoprocessodedesenvolvimentodosistema.

Portanto,umrequisitodesoftwareéumapropriedadequedeveserexibidoporalguma coisa para resolver um problema no mundo real. Ele pode ter como objectivo automatizarpartedeumatarefaparaalguémdemodoaapoiarosprocessosdenegócio de uma organização, corrigir um erro num software existente ou controlar um dispositivo­sóparacitaralgunsdosproblemasparaosquaisépossívelencontraruma soluçãodesoftware.Aformacomoosutilizadores,osprocessosdenegócioeos dispositivos funcionam é tipicamente complexo. Por extensão, no entanto, os requisitos de um software determinado constituem tipicamente uma combinação complexadeváriaspessoasadiferentesníveisdeumaorganizaçãoequeestãodumaou outraformaenvolvidasouligadasàfuncionalidadedosistemanoambienteemqueo

softwareiráoperar[3].

Uma característica essencial de todos os requisitos desoftwareéqueeles,como funcionalidadeindividual,devemserverificáveistantocomorequisitofuncionalouao

níveldosistemacomorequisitonãofuncional.[3]

Osrequisitosincluemaperspectivadousuárionoquetocaocomportamentoexterno

deumsistemaeavisãodoprogramadorquetememcontaalgumascaracterísticas

internas do sistema. Também tem a ver com o comportamento do sistema em determinadascondições.

Osrequisitosdesoftwareincluemumadimensãotemporal.Podemserdefinidosno

presente,descrevendoascapacidadesactuaisdosistemaouelespodemserdefinido

paramédioprazo(prioridadealta).

2. Níveisetiposderequisitos[1]

Osrequisitosdenegócio:éoobjectivodenegóciodealtoníveldaorganizaçãoque

estáenvolvidonaconstruçãodoprodutooudoclientequeoencomendou;

Regradenegócio:umapolítica,umaguia,umpadrãoouregulamentoquedefineou

constrangealgunsaspectosdonegócio.Nãoéumrequisitodenegócioemsimesmo,

masafontedeváriosrequisitosdesoftware;

Restrições:umarestriçãoqueéimpostasobreasescolhasdoprogramadornoquetoca

aodesigneconstruçãodeumproduto;

Requisito de interfaces externos: uma descriçãodumaligaçãoentreosistemade softwareeoutilizador,ououtrosistemadesoftware,ouumdispositivodehardware;

Requisitofuncional:umadescriçãodeumcomportamentoqueosistemadeveexibir

emcondiçõesespecíficas;

Requisitonãofuncional:umadescriçãodeumapropriedadeoucaracterísticaqueo

sistemadeveexibirouumarestriçãoquedevecumprida

Atributo de qualidade: uma espécie de requisito não funcional que descreve um serviçooudesempenhocaracterísticodeumproduto;

Requisitos de sistema: requisitos de alto nível para um produto composto por múltiplossubsistemasquepodemserconstituídosapenasdeprodutosdesoftwareou desoftwareehardware.Tambémsãodescriçõesmaisdetalhadasdasfuncionalidades, serviçoseconstrangimentosoperacionaisdosistemadesoftware.Odocumentodos requisitosdosistemadeverádefinirexactamente oquedeveserimplementado.Poderá fazer parte do contrato entre o comprador do sistema e os desenvolvedores do software.

Requisito do utilizador: um objectivo ou tarefa que uma classe específica de utilizador deve ter a capacidade de desempenhar com o sistema ou um atributo desejadodosistema;

Os requisitos de software incluem três níveis distintos: requisitos de negócio, requisitosdoutilizadorerequisitosfuncionais.Alémdissotodosistemapossuium

conjuntoderequisitosnãofuncionais. Requisitos de negócio: descrevem o porque a organização está a implementar o sistema – os benefícios comerciais a organização poderá obter. O foco está nos objectivos comerciais da organização ou do cliente que solicitou o sistema.

Suponhamosqueumacompanhiaáreapretendereduzirde25%oscustosligadosasseu

pessoaldecaixanosaeroportos.Esteobjectivopodesuscitaraideiadeconstruirum quiosquequeospassageirospoderãoutilizarparafazerocheck­indosseusvoosno aeroporto.Osrequisitosdenegócioprovavelmentevêmdopatrocinadordoprojecto, doclientequevaiadquiriroprojeto,dogestordosutilizadores,dodepartamentode marketing,oudovisionáriodoproduto.Oselementossobreosrequisitosdenegócio

sãoregistadosnodocumentodevisãoemissão[1]

Requisitodosutilizadores:descrevemosobjectivosoutarefasqueosutilizadores devemsercapazesderealizarcomaajudadoprodutoquetraráalgumvaloraalguém.O domíniodosrequisitosdosutilizadorestambémincluemasdescriçõesdosatributos oucaracterísticasdoprodutoquesãoimportantesparaasatisfaçãodoutilizador.Uma dasformasderepresentarosrequisitosdosutilizadoreséatravésdousecases,ouuser stories. Idealmente, os representantes dos utilizadores é que fornecem esta informação.

Requisitosfuncionais:descrevemasfuncionalidadesqueosoftwaredeveexecutar; porexemplo,formatarumtexto,oumodularumsinal.Tambémsãoconhecidoscomo capacidadesoufuncionalidades.Umrequisitofuncionalpodeigualmenteserdescrito comoorequisitoparaoqualumconjuntodepassosdetestepodemserescritopara

validaroseucomportamento[3]

2.1Requisitosfuncionais

Osrequisitosfuncionaisparaumsistemadescrevemoqueosistemadevefazer.Estes requisitosdependemdotipodesoftwarequeestáaserdesenvolvido,dospotenciais utilizadoresedaabordagemgeralseguidapelaorganizaçãoquandoestiveramafazero levamento dos requisitos. Quando formulados como requisitos do usuário, os requisitosfuncionaissãogeralmentedescritosdeformamaisabstractaquepodemser facilmente entendidos pelos utilizadores do sistema. No entanto, os requisitos funcionaismaisespecíficosdosistemadescrevemasfunçõesdosistema,asentradase saídas,excepçõesetc.commaispormenores.

Osrequisitosfuncionaisdosistemavariamentreosrequisitosgeraisqueabrangemo

queosistemadevefazereosrequisitosmuitoespecíficosquereflectemaformade

trabalharlocalouossistemasexistentesdaorganização.

Osrequisitosfuncionaisdousuáriodefinemasfacilidadesespecíficasquedevemser

providenciadaspelosistema.

Em princípio a especificação dos requisitos funcionais de um sistema deve ser completoeconsistente.Completosignificaquetodososserviçosnecessitadospelo

utilizadordeverãoserdefinidos.Consistênciasignificaqueosrequisitosnãodevem conter definições contraditarias.Naprática,paraprojectosgrandesecomplexos,é praticamenteimpossíveldefinirdemodocompletoeconsistentetodososrequisitos. Uma das razões é que é fácil cometer erros e omissões quando de se elabora o documentodeespecificaçãoderequisitosdesistemascomplexos.Umaoutrarazãoé que existem muitos participantes num sistema grande. Uma parte interessada (stakeholder)éumapessoaouumpapelqueéafectadapelosistemadecertaforma.As partesinteressadastêmnecessidadesdiferentesemuitasvezesinconsistentes.Estas inconsistências podem não ter sidos evidentes quando os requisitos foram especificados,assimosrequisitosinconsistentesficamincluídosnasespecificações. Osproblemaspoderãosomentesurgirapósumaanáliseaprofundadaouapósqueo

sistematerásidoentregueaocliente.[2]

2.1Requisitonãofuncionais

São aqueles que tem como finalidaderestringirasolução.Elessãoalgumasvezes conhecidoscomorestriçõesourequisitosdequalidade.Elespodemserclassificados segundoquetemavercomodesempenho,segurança,fiabilidade,interoperabilidadee

outros[3]

Talcomoonomeindicaosrequisitosnãofuncionaisnãodizemdiretamenterespeito aosserviçosoferecidospelossistemasaosutilizadores.Elesestãorelacionadoscom aspropriedadesemergentesdosistemataiscomoafiabilidade,tempoderespostae espaço dearmazenamento.Alternativamentepodemdefinirumasrestriçõessobrea implementação do sistema tais como as capacidades dosdispositivosdeentradae saída,arepresentaçãodedadosusadosnainterfacecomoutrossistemas.

Os requisitos não funcionais tais como o desempenho, segurança, disponibilidade especificamgeralmenteouconstrangemascaracterísticasdeumsistemacomoum tudo.Osrequisitosnãofuncionaissãogeralmentemaiscríticodoqueosrequisitos funcionaisindividuais.Osutilizadoresdeumsistemapodemencontrarumaalternativa quandoumafuncionalidadedosistemanãovaideencontrocomassuasnecessidades. Noentanto,nãocumprirumrequisitonãofuncionalpodetornartodoumsistemainútil. Porexemplo,seumsistemaaeronáuticonãocumpreosseusrequisitosdefiabilidade, nãoserácertificadocomoseguroparaoperações;seumsistemadecontroloembebido não cumprir os seus requisitos de desempenho, as funções de controlo não irá funcionarcorrectamente.

3. Desenvolvimentodosrequisitos

O desenvolvimento dos requisitos é subdivido em elicitação, análise, especificação e validação.Estassubdisciplinasabrangemtodasasactividadesenvolvidascomaexploração, avaliação,documentaçãoeconfirmaçãodosrequisitosdoproduto.

Elicitação

Aelicitaçãoabrangetodasasactividadesenvolvidascomadescobertadosrequisitos

taiscomoasentrevistas,workshops,análisededocumentos,protótiposeoutros.As

acçõeschavessão:

Identificarasclassesdos utilizadoresprevistoseoutraspartesinteressadas;

Compreenderastarefaseobjetivosdosutilizadoreseosobjetivosdenegocio comquesealinhacomasditastarefas;

Aprendersobreoambientenoqualonovoprodutoseráutilizado;

Trabalharcomosindivíduosquerepresentamcadaclassedeutilizadorespor formaacompreenderassuasnecessidadesemtermosdefuncionalidadeseas suasexpectativasemtermosdequalidadedosoftware.

Análise

Analisarosrequisitosenvolvechegaraumacompreensãomaisprecisaericadecada

umdosrequisitosbemcomorepresentarosconjuntosderequisitosdeváriasformas.

Asprincipaisactividadessão:

Analisarainformaçãorecebidadosutilizadoresporformaa fazerumadistinção entre os seus objetivos relacionados como as suas tarefas, os requisitos funcionais,expectativasdequalidade,regrasdenegocio,soluçõessugeridase outrasinformações;

Decomporosrequisitosdealtonívelparaumníveladequadodeprecisão;

Deduzirosrequisitosfuncionaisdeoutrasinformaçõesderequisitos;

Compreenderaimportânciarelativadosatributosdequalidade;

Alocar os requisitos a componentesdesoftwaredefinidosnaarquiteturado sistema;

Negociarasprioridadesdeimplementação;

Identificaraslacunasnosrequisitosourequisitosnãonecessários.

Especificação

Aespecificaçãodosrequisitosenvolvearepresentaçãoearmazenamentodetodosos

requisitoslevantadosdumaformabemorganizadaepersistente.Aprincipalactividade

é:

Traduzirasnecessidadesdosutilizadoreslevantadosemrequisitosescritose diagramas apropriados para compreensão, revisão e uso por parte dos públicos­alvos

Validação

A validação dos requisitos confirma que se tem um conjunto de informação de

requisitos correto que permitirá aos programadores construir uma solução que satisfaçaosobjetivosdenegocio.Asactividadescentraissão:

Fazerumarevisãodosrequisitosdocumentadosporformaacorrigirquaisquer

problemasantesdeseraceitepelogrupodedesenvolvimento;

Realizartestesecritériosdeaceitaçãoporformaaconfirmarqueumproduto baseado nos requisitos cumprirá as necessidades do cliente e alcançará os objectivosdenegócio. Aiteraçãoéachavedesucessonodesenvolvimentodosrequisitos.

4.

Documentoderequisito(SoftwareRequirementSpecification­SRS)

O documento de requisitos de software é uma declaração oficial daquilo que os

programadoresirãoimplementar.Eledeveincluirosrequisitosdosusuáriosparao sistema e uma especificação detalhada dos requisitos do sistema. As vezes os requisitos do sistema e dos usuários estão integradosnumamesmadescrição.Em

outroscasos,osrequisitosdosusuáriossãodefinidosnumaintroduçãoàespecificação

dosrequisitosdosistema.Seháumgrandenumeroderequisitos,osrequisitosde

sistemasdetalhadospoderãoserapresentadosnumdocumentoseparado.

O documento de requisitos é essencial quando um contratante externo está a

desenvolverosistema.

Odocumentoderequisitostemumconjuntodiversodeutilizadores,entreoutrosos

administradores da organização que está a pagar pelo sistema, os engenheiros responsáveispelodesenvolvimentodosoftware.

Adiversidadedospossíveisutilizadoressignificaqueodocumentoderequisitosdeve

conciliarentreacomunicaçãodosrequisitosaosclientes,definircommaiorprecisão

osrequisitosparaosprogramadores,eincluirinformaçãoparafuturasalterações.

Oníveldedetalhequedeveserincluídonumdocumentoderequisitodependedotipo

de sistema que está a ser desenvolvido e do processo de desenvolvimento usado.

Sistemascríticosprecisamterrequisitosdetalhadosjáqueasegurançaeprevenção

devemseranalisadasempormenor.Quandoosistemaédesenvolvidoporumaempresa diferente(atravésdooutsourcing)asespecificaçõesdosistemadevemserdetalhadase precisas.Seosistemavaiserdesenvolvidonaprópriaempresaquefazolevantamento e análise dos requisitos, um processo iterativo de desenvolvimento é geralmente seguido.Nestecasoodocumentoderequisitospodesermuitomenosdetalhado,jáque asambiguidadespoderãoserresolvidoduranteodesenvolvimentodosistema.

4.1. Escritadeespecificaçõesdesistema

Existemváriashipóteses/abordagensparaaescritadasespecificaçõesdesistema.

A utilização de linguagem natural é comumnãoestando,noentantodesprovidade

problemas.

Oobstáculoprincipalàutilizaçãodelinguagemnaturaléaambiguidadeintrinsicada

mesma.Pormaisobjetivoedetalhadoqueaespecificaçãopossaser,existesempre

umamargemdeinterpretaçãodorecetor.Jackson(1995)citadoporSommerville,

apresentaoexemplodosavisospresentesemescadasrolantes.

A flexibilidade e dificuldade de padronizar são outros obstáculos à utilização de

linguagemnaturaltout­court.

Para fazer face a estas dificuldades consideram­se outras alternativas, como a

utilizaçãodelinguagemnaturalpadronizadaoulinguagensdeespecificaçãoparaescrita

dedefiniçõesdesistemas

A abordagem “linguagem natural estruturada” recorre a técnicas como o uso de

modelosparaaespecificaçãoderequisitos.

As linguagens de descrição de projetos têm características em comum com as linguagens de programação tradicionais, disponibilizando ainda recursos mais abstratos.Poderãoincluiroufuncionaremconjuntocomnotaçõesgráficas.Exemplo distosãoaslinguagensSDLeUML.

5.GestaodosRequisitos

Os requisitos de sistemas de software grandes mudam sempre. Durante todo o

processodedesenvolvimentodesoftware,acompreensãodoproblemaporpartedas

partes interessadas muda constantemente. Os requisitos do sistema devem por conseguinteevoluirconstantemente.Osrequisitosdosistemadevemevoluirporforma

areflectiranovavisãodoproblema.

Umavezinstaladoosistemaeregularmenteutilizado,inevitavelmentenovosrequisitos

irão surgir. E difícilosutilizadoreseclientesdosistemaanteciparquaisserãoos efeitosdonovosistema terásobreosseusprocessosdenegocioeamaneiracomoo trabalhoeexecutado.

Agestãodosrequisitoseoprocessoqueconsisteemcompreenderecontrolaras

mudanças feitas ao conjunto de requisitos do sistema. E necessário fazer um

acompanhamentodecadanovorequisitoemanterasrelacoesentreosrequisitosque

dependemunsdosoutrosdemodoaavaliaroimpactodamudançadosrequisitos.E necessário criar um mecanismo formal de recolha de propostas de mudança e relacionarosnovosrequisitos aosrequisitosdosistemaexistentes.[2]

Referências

[1]KarlWiergers,JoyBeatty,SoftwareRequirements,thirdedition,MicrosoftPress,

2013

[2]IanSommerville,SoftwareEngineering,NinthEdition,Addison­Wesley,2011

[3] Pierre Bourque, Richard E. Fairley, SWEBOK v3.0 Guide to the Software

EngineeringBodyofKnowledge,IEEEComputerSociety,2014

[4]Sommerville,I.andSawyer,P(1997).RequirementsEngineering:AGoodPractice

Guide.Chichester:JonhWiley&Sons.