Klaus Poht - Chris Rupp Fundamentos da Engenharia de Requisitos Um Guia de Estudo para o Exame CPRE-FL Certified Professional for Requirements Engineering — Foundation level ‘em conformidade com o padrao IREBSumiio 15 Sumario PROLOGO DO EDITOR 5 #0 FVOLLIMOS PARA INTEGRAR A ENGENHARIA DE TESTES COM A ENGENHARIA DE REQUISITOS € PORQUE RESDLYEMOS THADUZIRESTELVRO PARA LINGUA PORTUGUESA BRAS RA 5 (© EXAME CPRE “CERTIFIED PROFESSIONAL FOR REQUIREMENTS ENGINEERING” 7 PREFACIO DO ORIGINAL ° CCONTRIBUICGES ADICIONAIS u SUMARIO a Downonos 23 SYLLABUS CPRE-FL (ementa do conhecimento requerido por um engenheiro de Requisitos pare o certificagtio CPRE-FL) 23 a 23 GLOSSARIO de termos da engenhario de requisites 236 DICAS DE ESTUDO E PREPARAGAO PARA A CERTIFICACAO CPRE-FL | -Estude cada um das nove unidades de ensino na sua sequencig numérica a Gulde CPRE-FL' Syl Us CPRE-FLE3Este Livro) l—Estude de forma Visual, Auditiva e Cinestésica e aplique na prética stude cada Unitade de Ensino alternando entre as trés visdes/quias alsponiveis (Quic ‘Sumario 1V- Quer saber mais? Consulte a bibliografia indicada e ou realize um curso de preparagdo conosco26 1 INTRODUGAO E FUNDAMENTOS LL inrrooucko 11.1 Dados e Fates de Projetos Comuns 41,2. 0 Que Ea Engenharia de Requisitos? 1.1.3 Incorporara Engenharia de Requisitos em Modelos de Processo 1.2 FunpantenTos 0a TeoRi6 D8 COMUNICACAD (Canacrenisticas Ot UM ENGENIEIRO 9€ REQUISITOS TnaponrANcia € CateGoRIzA¢#O De REQUISITOS DE QUALIDAD 3 14 Tose Requisttos 5 6 ResuMo 2 OSLIMITES DO SISTEMA E DO CONTEXTO 21 Context0 90 Sistema 2.2 DemNiRos Livisp0 SisTEMA 60 Comtex 2.2.4 Deflalro Limite do Sistema 2.22 Definiro Limite do Contexto 23. DacuwexraRo Conrexro Do SsTEMA 24 Resumo 3. ELICITAR REQUISITOS 3.1 FoNTES be ReaussTos B.L1 Stakeholders e sua Impo ‘sholders no Projeto 105 CoNFORME © Moneta D& KANO 7 a a 28 at a1 32 3 35 36 39 39 40 at a 4 45 a7 a7 a a8 50= Sumario 0 2 Técnicas de Pesquisa 58 z Técnicas de Criatividade 5a - 3.3.4 Técnicas Baseades em Documentos 56 3.3.5 Técnicas de Observagéio 57 ~ 3.36 Técnicas de Apoio 58 - 3.4 Resumo 59 o 4 DOCUMENTAR REQUISITOS a 2 4.1. Design po Documenro 61 4.2 Twosne Docuneenagho e 4.21 As Trés Perspectivas dos Requisitos 62 a 4.2.2 Documentagtio de Requisites Usando Linguagem Natural 63 4.2.3 Documentagdo de Requisitos Usandlo Modelos Conceituais 63 4.2.4 Documentas de Requisitas Hibridos 64 4.3 Estaurueas pos Documenros 65 4.3.1 Estraturas Padronizads de Documentos 65 43.2 Contetidos Padréio Customizadas 66 39 4.4 —_Usonos Documentos De ReausiTos 6a 29 4.5 Chuténios o€ QUALIDADE PARA DOCUMENTOS De REQUISTOS. 69 45.1 Ndo-ambiguidade e Consisténcia 69 45.2 Estruture Clara 70 aa 45.3 Modificabiidade e Extensiblidede 70 4s 4.5.4 Completude 70 as 455° Rastreabilidade 7 a7 4.6 ChiTéeI0s D€ QUAUDADE PARA RedUistTOS n 0 47 Giossinio B 47 48 Resumo 75 5 DOCUMENTAR REQUISITOS USANDO LINGUAGEM NATURAL 7 5.1 EFBTOSMA LINGuAsens NATURAL 7 5.1.1 Mominalizagio 7818 Sumétio 5.1.2. Substontivos sem Indi rador de Referéncia 79 5.1.3 Quantificadoses Universais 80 5.14 Condigées Especificadas de Forma Incompleto 20 5.5 Verbas de Processo Especificados de Forma Incompleto 81 5.2 Constaucko be Requisros usanoo T 82 53 RESUMO 86 6 — DOCUMENTAR REQUISITOS USANDO MODELOS 37 61 OTEaMo MoDaLo 37 6.1.1 Propriedades de Modelos 38 6.1.2 Linguagens de Modetagem 38 6.1.3 Modelos de Requisitos 9 6.14 Vantagens dos Modelos de Requistos 9 6.1.5 Uso Combinade de Models e Linguagem Notural 20 6.2 Mooevosoe Meras v0 6.2.1 Documentagio de Metas Usando Arvores E/OU 91 6.2.2. Exemplo de Arvares £/OU ot 63 CAsosoE USO 92 63.2 Diagramas de Cosos de Uso UML 632 Especifiagbies de Cosos te Uso 6.4 Tats Penseecrivas soBRe ReausiTos 98 6.5 MODELAGEM DE REQUISITOS NA PERSPECTIVA ESTRUTURAL 100 65.1 Diagramas Entidade-Relacionamento 65.2 Diagramas de Classes UML 6.6 MODELAGEM O€ REGUISITOS Na Pes 6.6.1 Diagramas de Fluxo de Dados 6.6.2 Modelos da Perspectiva Funcional e Fluxos de Controle 663 Diogramas de Atividades UML 6.7 MODELAGEM 0¢ REQUISITOS NA PERSPECTIVA COMPORTAMENTAL 67.1 statecharts 3 6.7.2 Diogramas de Estados UMLSumério 8 68 ReuMo VALIDAR E NEGOCIAR REQUISITOS 7.1 FuNoawenTOs Dk VauDagso ve Reausiros 7.2 Fuwoawentos pa NEGOCIACAD DE REQUISTTOS 7.3. Asoscros os Quauioace 00s Reausitos "Contesido” 7.3.1 Aspecto de Quolidade 7.3.2 _Aspecto de Quolidade "Documentacdo 7.3.3 Aspecto de Qualidade "Acordo" 7.4 Prnicinios oe Vauoacko Oe Regustos 7.4.1 Principio 1: Envolvimento dos Stakeholders Cor 742 Separacao Entre a identificagéic de Falhas ea Correcio de Erros 243 Validacdo a Partr de Diferentes Pontos de Vista 7.44 Principio 4: Mudange Adequada de Tipo de Documentacao 7.4.5 Principio 5: Construgdo de Artefatos de Desenvolvimento 7.4.6 Principio 6: Revaidagio de Requisitos 7.5 TECWICASOE VaLIogio BE RequisTos 7.54 Parecerde Especiaista Commenting) 75.2 Inspecéo 753 Walkthrough 7.54 Leitura Baseada em Perspectiva 7.5.5 Validacéo por Protétipos 7.56 Utileacio de Checklist para a Validacdo 7.6 — Nesocur Requiros 7.6.1 Identificacdo de Confitos 7.6.2 Andlise de Con tos 7.53 Resolugéo de Confitos 7.64 Documentacio da Resolucdo de Confitos 77 Resume GERENCIAR REQUISITOS 20 121 134 136 138 138 aaBA Desienan ATRBUTOS PARA REQUISITOS 8.1.1 _Atributos para Requisitos em Linguagem Natural e Modelos 8.2. Esqueme de Atributos 8.1.3 Tipos de Atributos de Requistos 8.2. Visunuaagoes De ReauisTOs 8.2.1 Visuaizagdes Seleivas da Base de Requisitos 8.2.2 Visualizagdes Consolidadas dos Requisitos 8.3. Pruonaacho oe Reaussros 83.1 Método de Priorizacoo de Requisitos 83.2 Técnicas de Prorizago de Requisitos 8.4 RAsTREARIIDADE DE ReQUISTOS 86.1 Vantagens de Requisitos Rostredvels 842. Rastreabilidade Definido por Finaidade 8.43. Classfcagdo de Relacionamentos de Rastreobilidade 8.4.4 Representacdo de Rastreabilidede de Requisitos 85 Vensionaento oe Reausros 85.1 Versbes de Requisitos 85.2. Confiquractes de Reguisites 85.3 Baselines de Requisitos 8.6 GrneNCAMENTO DE MuDANCAS De ReQusi 8.6.1 Mudancas de Requisitos 8.6.2 0 Comité de Controle de Mudoncos 863. ASolicitagbo de Mudange 8.6.4 Classificagto dos Solicitagdes de Mudancas Recebides 8.6.5 Método BAsico para Mudancos Corretivas e Adaptatives 8.7 ResUMO @ APOIO POR FERRAMENTA 9.1 Apo) PORFERRAMENTA: Visa GFRAL 6.2. FeRraMewrasoe MoDeLAGet 9.3 FERRAMENTAS PARA GERENCIAMENTO OF REQUIITOS wat 143Sumétio 2 9.3.1 Ferromentas Especializadas para Gerenciamento de Requisttos wv 9.3.2. Aplicativos Podrtio de Escritério 172 8.4 Inrmoouanoo FeRRAMENTAS 173 9.5 AVAUACHO DE Feneamentas 174 95.1 Perspectiva do Projeto 175 9.5.2 Perspective do Usueirio 176 9.5.3 Perspectiva do Produto 176 95.4 Perspectiva do Processo 176 9.5.5 Perspectiva do Fornecedor 176 95.6 Perspectiva Técnica wr 9.5.7 Perspectiva Econémica 7 9.6 Resuwo v7 BIBLOGRAFIA 179 INDICE REMISSIVO, 185,Downtoads > Downloads Os seguintes materiais complementares e traduzidos para o portu; para download em www.tmtestes.com.br ¢ ou WWW.il esto disponiveis qts.com.br SYLLABUS CPRE-FL (ementa do conhecimento requerido por um engenheiro de Requisitos para a certificagao CPRE-FL) QUICK-GUIDE CPRE-FL (guia pietogréfico do Syllabus desenvelvido pela T&M) 0Dica ie Estudo e Preparagto para a Certifi Dicas de Estudo e Preparacdo para a Certificacao CPRE-FL 1 -Estude cada um das nove unidades de ensino na sua sequencia numérica Os nove capes de ito gf “= SHUABIS GHRERTE compost a Unda e 5) ] correspondem exactamente is Topicosde Encino | nove unidades de ensino (com ig = Witedueioe Fundamentos (6 vm total de 93 tbpicos de inifes e Contexto dos Sistemas 4) ensino). Cada unidade de anteriores Ug decumentasso de egubiest = Documentar Requlslios usando Lnguagem Natural) —) ardoquado de assimitagao G0. \OG/= Decanter Requitoz usando Models a] couhscimento, pelo menos + Vaare Nerd Reaaies 7 tama semana por unidade de = 7 Gerendlar Requisitoe 7] } ensino, estudando uma hora SerendierRequistes (77d) for diac voce csra Qf St0 par Foran) ) preparado, II -Estude cada U disponiv jidade de Ensino alternando entre as tres. iS (Qui ‘Ses/guias Guide CPRE-FL® Syllabus CPRE-FL “Este Livro) BO Quick-guide CPRE-FL & um guia pictogrifics do Syllabus. 0 Syllabus CPRE-FL ¢ a descrigio do conhecimento necessitio ¢ suficiente lo de um Fi Requsitos, H Ese Livro 6 um guia de est detalhado de cada unidade de ensino, —§ gs ri le se prefere estudar do as a0 eral (Quick- se prefere estudar eo (LivrosQuick- Brat] Gao Fundarierios da EngenharladeIl —Estude de forma Visual, Auditiva e Cinestésica e aplique na pratica IV - Quer s € suffeiente para dominar Apenas ler 0s materiais su ¢ rico quanto a Engenbaria de Requisitos. Estimule seu aprendizado ¢ fixagao do contetido estudando usando seus ts seatidos: Visual Auditivo e Cinestésica, como s Peca a uum conhecido escolher aleatériamente um assunto em alguma pigina no Quick Guide CPRE-FL”, no Syllabus CPRE-FL™ ou neste livro, Discorra sobre este assunto em vo7 alta (auditivo). Faga tim resumo por escrito deste assunto (cinestésico). Represents 0 assunto através de uma figura no power-point (visual). Estudos em grupo onde cada um desafia a conhecimento do outro ~ © aproveita para larecer eset esclareeido — so outra forma muito eficaz de aprendizado, presente 0 assunto, uma nidade de ensino por vez e uma sub-unidade de ensino por vez a po de colegas. Talvez cles nto aprendam muita coisa mas vocé aprender com certeza obrir nestas apresentagics que ainda nao domina o assunto jé & um aprendizado e um cestimulo a saber mais e melhor). Pratique a Engenharia de Requisitas segundo 0 modelo IREB no seu dia-a-dia, Divides surgirdo, Procute possiveis respostas nesic livre, no Quick-Guide CPRE-FL” © ou no Syllabus CPRE-FL aber mais? Consulte a bibliografia indicada e ou realize um curso de preparacio conosco I-B-Q-TS Q®carso de Introduce Fundamentos 1 Introducao e Fundamentos © impacto da Engenharia de Requisitos (ER) no desenvolvimento de sistemas de sucesso ¢ focados no eliente no pode mais ser ignorado. Tornou-se prtica eomum destinar recursos 4 engenharia de requisitos. Além disso, & cada vez maior a compreenséo de que o papel do engenleiro de requisites ¢ claramente diferenciado ee abrange uma série de atividades complexas. 1.1 Introducio Segundo dados do Chaos Report publicado pelo S coisa melhorou na execuctio indish Group em 2006, muita projetos de software nos 1n9s entre 1994 2006. Enquanto aproximadamente 30% dos projetos de software investigad 1994 falbaram, esse nlimero foi de apenas 20% em 2006. O niimero de projetos que nao cumprirain os prazos, esfouraram o oreamento ou nilo corresponderam as expectativas do cliente caiu de 53% pars 46% [Chaos 2006]. Jim Johnson, presidente do Standish Group, cita trés motives para © desenvolvimento positive desde 1994 Um deles € que a comunicagio de requisitos melhorou muito nos iltimos dez anos. Esses dados tém impertincia, pois a mancira como sto manipulados os requisitos de lum sistema é um fator que contribui significativamente para a falha de projetos clon Prazos e orgamentos estouras 1.1.1 Dados e Fatos de Projetos Comuns Segundo estudos realizados no pasado, cerca de 60% de tegos os ertos em projetos de desenvolvimento de software tém origem durante a fase de engenharia de roquisitos [Bochm 1981]. Esses erros, no entanto, frequentemente so descobertos apenas em estagios mais avangados do projeto, ou depois que o sistema foi implementado, pois requisitos incorretos ou incompletes podem ser interpretados por desenvolvedores de tal maneira que paregam (subjetiva e subconscientemente) corretos au completos. A falta de requisitos muitas vezes ndo € detectada durante a fase de projeto e execuclo, porque os desenvolvedores confiam que 0 trabalho rege pelos engenheiros de requisitos soja de alta qualidade. Os desenvolvedores implementam aquilo que o documento de requisites diz, ou aquilo que acham que i dizendo. Requisitos ambigues, incompletos ou incorretos inevitavelmente -vam ao desenvolvimento de um sistema que no possui proptiedades criticas, ou Por que fer cengenharia de requisitos A de requisitos deerros maharia28 jpossui propriedades que nao foram solicitadas, Durante o desenvolvimenta do projeto, quanto mais tarde um defeito nos requisitos for corrigido, mais altos sero os custos associades com sua corregao. Por ‘xemplo, o esforgo necessério para ecorrigir um defeito durante a programaglo € até 20 vezes maior do que realizar 2 corregao durante a engenharia de requisitos. Se © ‘efeito for corrigido durante os testes de aceitagao, 0 esforgo exigido pode ser até 100 vezes maior {Bochum 1981]. Os sintomas de uma engenharia dé smerosos quanto suas causas. Com frequéncia, requisites estio faltando om no equisitos inadequads sto to se 03 requisitos nao refletem as esto claramente formulados. Por exemp necessidades do clicate de forma precise, ou se estio descritos de_mangira 0 resultado muitas vezes imprecisa, permitindo dessa forma diversas interpretacde um sistema que niio alende as expectativas do cliente ou dos usuies. (© motive mais comum para requisitos deficientes 6 a nopio equivocads por parte dos stakeholders de que muitas coisas so dbvias nXo previsam ser texplicitadas, Isso resulta em problemas de comunicagto entre as partes envolvidas decorrentes de diferengas em experiéncia e conhtecimento. Para piorar as coisas, & fcomum que 0 cliente muitas vezes deseja uma rapida integracdo de resultados mais ‘em um sistema produtiva A crescente importéncia de sistemas baseados intensivamente em software nos projetos industriais, bem como a necessidade de lanear no mereado sistemas ada vee mais inovadores, individualizados e abrangentes ~ ¢ isso de maneira mai rapida, melhor ¢ com um nivel mais alto de quali ige uma cngenharia de requisites eficiente. Requisitos completos sem defeites formam a base para o Gesenvolvimento bem sucedido de sistemas, Os riscos em potencial devem ser engenharia de requisites ¢ obrigatoriamente ser reduzidas 0 ue 0 projeto progrida com sucesso. Falhas ¢ Jdemtificados durante a mais cedo possivel part permitir Tacunas no documento de requisitos devem ser descobertas num estégio inieial para cvitar cansatives processos de mudanga 1.1.2 O Que E a Engenharia de Requisitos’ Para o desenvolvimento bem sucedido de um projeto, & necessirio canhever os equisitas para o sistema ¢ documentar os mesmos de maneira adequada, O custo dos rtos durante @ ragenharia de roquisitos Sintomas e engenaria de roquisitos doficiente A importincia ‘uma bow. engenharia de requisitesntrodugdo e Fundamentos Defined 141, Requisiin (4) Uma condigdo ou capacidade ‘Gin problons# o1 ean um abit ssinia pala win usuaice revolver (2) Uma concieao ou capacmlade que deve ser aicanyada ou sbi ‘Dresonte em am sistema ou componente de sistema pace saiislazc ‘un conttato, nomi. esnecifieseso en ates documenta nentomposte @) Una repres | camo en (Ie [EFF Standard 610.12-1990) ip dementia de uma candice on capacieade 0s s nire outras coisas, as mais importantes fontes de requisites, Nao levar um terme stakeholder & esseneial na engenheria de requ stakeholder em considera ta em uma clicitago fragmentada quisitos, isto ¢, resulta em requisites incompletos [Macaulay 199: Stakeholders sao aquelas pessoas ou organizages que tém algum impacto sobre os -oquisites. [sso inelué as pessoas que indo interagit com o sistema (Por exemplo, Usuarios ou administradores), pessoas que simplesmente tém interesse no sistema mas provavelmente nao irdo utilizi-lo (Por exerplo, » alta geréncia; um hacker do qual o sistema precisa ser protegido, stakeholders de sistemas concorrentes), mus também entidades legais, insttuigses, ete., pois clas sio formadas por pessoas de sme e oss0 que podem muito bem decidir influenciar ou definir of requisites do Definigo 1-2: Statehionley Lim siakealder dem sistema & uma pessoa ou uma orwanizacao aus influeneia (gets ou tndireta) aos requisios de'um sistema | ‘StakeholdersIntrodugao e Fundamentos Durante 0 processo de desenvolvimento, u engenharia de requisitos deve eicitar os | Meta da ada, validar © engenharia de de vida do requisit verilicar os requisites, e gerenciar os requisitos 20 sistoma [Poh 1996 Eoiweea ie ee ee ae as } Detinigao 1-3: Frvcnharis de veauisites (1) A cnwentiatia de requisites de qualidade sejam tao objetives ¢ verificiveis quanto possive. Isso tipieamente feguer qu os sequistos sejam uantfieados. Por exemplo, um reawinto de ‘nulidade telacionado a eficigncia do sistems poderia especifiear que wm sistema dJoverd processar 95 por cento de todas as requisiedes dentro de 1.5 segundos, «due Srprocessamento de requisighes no devera exceder 4 segundos em qualauer themento. Isso pode fazer com que os requisites de qualidade sejam refinados por gio de requisites fincioneis adicionais, como no caso de um requisito de Safad relacionado & sepuranga do sistema, em que um requisite funcion) seciica 0 algoritmo exsto 2 criptogtafia para tender a nevessidade de Griplogtafa exigida por determinado requisito de qualidade, Requisitos de qualidade estlo muitas vezes associados 2 diferemes roquisites funcionais. Como resultado, requisites de qualidade devem sempre ser tantidos separados dos requisites funcionais. Em outras palav ‘aos requisitos funcionais © de fqualidade nao devem ser_misturados sementads separadamente, com uma documentacso explicita sobre sua rela ‘com os requisites funcionais 1.6 Resumo enharia de requisitos & indispensivel para desenvolver sistemas que 1 os prazas € se mantenham dentre do orgamento, forma, satisfagam o eliente, cumpr theta ca engenharia de requisitos & documentar os requisites do cliente ' dualifieada possivel, bem como identiicar e resolver problemas mais complIntrodusao ¢ Fundamento ‘nos requisitos © mais cedo possivel. Uma engenharia de requisites bem sucedida deve fimdamentalmente incluir os stakeholders certos e incorporar as quatro atividades cemtrais da engenharia de roquisitos (eticttardo, documentacac validagdu/negociacdo e gerenciamento) no processo de dosenvalvimento. do sistema. No centro das atengdes encontta-se o engenheiro de requisites, profissional je atua come 0 principal ponto de contate na enge ria de requisites e possu profundo conhecimento tanto do dominio quanto do processo, além de uma grande variedade de competénci ais (soft sillnites do Sistema ¢ do Contexto 39 2 Os limites do Sistema e do Contexto Os requisitos de um sisiemna a ser desenvolvido no “existem” simplesmente, precisam sor elicitados. Na engcaharis de requisitos, o propdsito de definit os lo sistema ¢ do contexto é identificar a parte do ambiente que influencia 0s i2.a ser desenvolvido, 2.1 Contexto do istema No processo de desenvolvimento, a engenharia de requisitos cumpre a fanglo d Identificar todos aqueles aspectos materiais ¢ imateriais que tém algum sistema em relucionamento com o sistema. Para isso, antecipa-se como o sistema fleara quando eperag30 se tomar realidade. Ao fazer isso, aqueles aspectos do mundo teal que indo possivelmente influenciar os requisitos de um sistema podem ser idemtificados, Para gue se possam especificar os requisitos de um sistema de mancira correta e completa, & necessirio identificar os relacionamentos entre aspectos materiais ¢ imateriais individuais da forma mais precisa possivel. A parte da realidade que é relevante para os requisites de um sistema 6 chamada de contexto do sistema, ==] Definisa0 2-1; Contexta do Sistenia Orconfexto do sistema € 2 parte do ambiente do sistema que & relevante para a defintgde ea compreensio dos requisitos de um sistema a ser desenvolvido, Entre outros, os seguintes aspeotos da realidad influenciam 0 contexto de um — Aspectos de sistema: sistema 1 Possoas (stakeholders ou grupos de stakeholders), “nas emt operagio (outros sistemas téenices ou hardware), Process (1éenicos ou fisicos, processos de negécio), Eventos (téenicos ou fisicas).Os Limites do Sistema e do Contexto Documentos (les, nosmas, a documenta da sistema), Nao considerar o contexto do sistema de forma correta ou completa durante = tengenharia de requisfis pode resultar em requisilos incorretes ou incompletos. Isto far com que 0 sistema opere com base em requisites incorretos ou ineompletos, © ‘que frequentemente esti por tris de falhas do sistema durante a operagio, Tas eros rmuitas vezes nao so detectados durante os procedimentos de validagio, que guisitos especificados, mas somente d ‘a operacao, acarrecando consequéncias as vezes catastrticas determinam se o sistema atende 20s e no contexto do sistema a A otigem dos requisites do sistema encontea- ser deseavolvido. Por exemplo, stakeholders, normas pertinentes e diretrizes exigem propriedades funcionais especificas que o sistema a nvolvida deve possuir em suas interfaces, Assim, um requisito € definido para um conte especifico ¢ somente pode scr definide corretamente em relagiio a esse contexto especifico. Quanto melhor compreendido for o contexto de um requisite exemplo, por que o sistema tSenieo "X" no contexto do sistema ¢ a 0 Aererminado requisite), mais baixa seré a probabilidade da interpretagao incorreta o requisito, Dai a importincia de uma documentaeao do contexto do sistema ou de informagdes sobre 0 contexto do sistema que sejam orientadas para sua finalidade de uso 2.2 Definir os Limites do Sistema e do Contexto © engenheiro de requisites é responsivel pela definigto adequada do contexto do Para tanto, & necessério estabelecer uma separacfo entre o contexto do fe ser tomada: Quais aspectos pertencem ao sistema a ser desenvolvido fe quais aspeetes fazem parie do vontexto do sistema? 1 Definir o limite do contexto: Ao defini 0 lim do contexto, 2 pergunta & ‘em al io com o sistema a so parte do ambiente irtclevante? Consoquéncins da consideragtio incorreta ou incompleta do Contexte do cantexto roquisito| do: Os Limites do Sistema ¢ do Contexto 4 Contexto do sistema -Aasbieinie Reet 3 Figura 2-1 Limites do sistema c do contexto de um sistema 7 Assim, os limites do sistema © do contexte definem o contexte do sistema, O 7 lento do sistema abrange todos 0s aspectos que sio relevantes em relacio aos : ‘cquisites para o sistema @ ser desenvolvide. Esses aspectos nfo podem so : ados ou modificades pelo processo de desenvolvimento do sistema, definem 0 1 Definir o Limite do Sistema , na) do sa scopo do desenvolvimento (isto é s aspectos que so cobertos pelo sistema a ser desenvolvido) quanto es aspectos Quando o limite do sistoma é detinido, tanto 0 sHo parte do sistema sio detcrminades. Por esse motive definimos o limite sistema come Definiezo 2 inne do Sistemi finite do sistema senara 0 sistema a ser déseavolvide:do seu. ambiette Visto & pais H parte la realidade quo pode soe madiffesda omaltorada pelo pros svolvimento) daqueles aspettos do ambienteriue-nd imodilfcados pelo processo de desenvolvimento, re ode poem ser-muidades on Assim, todos os aspectos que se encontram dentro do limite do sistema podem ser aiterados durante o desenvolvimento do sistema, Por exemaplo, um sistema exis consistinda de componentes de hardware ¢ softwa que sera substituido pelo ovo sistema pode estar dentro do limite do sistema, Aspectos dentro do contexto de sistema podem ser © rocessos, cio, provessos téenicos soas e papéiOs Limites do Sistema e do Cont estnmaras onganizacionais e componentes da infiaestrutura TI. A figure 2-2 mostra de forma esquemiética 0 contexto do sisters de um sistema, O contexto do sistema € constivuido por outres sistemas, por grupos de stakeholders que de uma forma ou otra uilizam a interface do sistema a ser desenvolvido, além de Fontes adicionais de requisitos e suas intertelagbes i ee ee Figura 2-2 Tipos de aspectos dentro do contexto do sistema Fontes © destinos [DeMarco 1978], entre outros, podem ser utilizados para identificar as interfaces do sistema com scu ambiente. Fontes fornecem dados de entrada (inputs) ao sistema, Destinos recebem dados de saida (ow/puts) do sistema, Possiveis fontes e destinos para um sistema (Grupos de) stakehoicters ‘m _Sistemas existentes (tanto téenicos quanto nido téenieos), Fontes © destinos imteragem com o sistema a ser desenvolvido por meio das jnterfaces do sistema. Usando essas interfaces, o sistema fornece sua funcionalidade ao ambiente, monitora 0 ambiente, influencis pardmetros do ambiente e controla foperagies do ambiente. Dependendo de tipo da sespectiva fone ou destino, 0 sistema necessita diferentes tipos de interface (interface homem-miquins, interfac die hardware ou interface de software). O tipo de imterface por sua vez pode também por restrigdes especificas ow fontes adicionais de requisites pars o sistema a ser desenvalvido, Frequentemente 0 limite do sistema nilo & definido de forma precisa até 0 final do prosesso de engenharia de requisitos. Antes disso, algumas om mesmo ‘arias interfaces, bem como fungdes © qualidades esperadas do sistema a ser Fontes & ponto de partida Interfaces Interacio entre sistema e ambicnte Zona cinzenta cantexto doOs Limites do Sistema e do Contexto 4 jesenvolvido Sto apenas parcialmente conhecidas, ou nem sequer sto conhecidas, sistem! Nos nos referimos a essa separagao inicialmente vaga do sistema e de seu contexte como 2 zona cinzcata entre 0 sistema ¢ © contexto (ver figura 2-3}. No inieio de $0 de engenharia de requisites, por exemplo, pode nao es ° tema deveria implementar certa fing jo (como por exemplo, "pagar com cartao rédito”), ou se existe algum outro sistema no eontexto do sistema fomecenda angio que deveria ser usado (por exemplo, "processamento de Nilo somente 0 limite do. sistema po car-se dentro da zona Ajuste da zona cinzenta( na figura 2-3), mas a propria zona einzenta pode desiocar-se durante 0 cinzenta ocess0 aharia de na figura 2-3), Este tipo de deslocamento é causado por aspectos que inicialment sm ao contexto do sistema mas so modificados durante o desenvolvimento do sistema, Tal siu in de requisitos, por exemplo, quando no context do si ro se determinadas atividades de um processo comercial deveriam ou nto ser plementadas ou suportadas pelo sistema a ser desenvolvido. Nessa situacdo, ndo claro quais aspectos pertencem a0 sistema ~ p mudades oa modifi s pertencem ao contexto do sistema, Isto cau na ¢ 0 comtexto do spondente des ‘pooner {zona cnnrta ea, {ose temo) Figura 2-3 Zona cinzenta do limite do sistema zona cinzenta se desloca, por exemplo, quando interfaces sho atribuidas ao Finite istema e 2 ona cinventa & ampliada para incluir aspectos do ambiente elacionados a essas interQs Limmites do Sistema e do Contexto 2.2.2 Definir o Limite do Contexto © limite do contexto estabelece a distingtio entre os aspectos do contexto, isto & aqueles aspectos do ambiente que precisam ser considerados durante a engenharia ie requisitos (como fontes de requisites, por exemplo} e aqueles aspectos que so irrelevantes para o sistema. O limite da contexto pode ser definido como segue: © limite do eowesto Scpare a pane rclevanee do anibyette de um sistema a . bem como um resultado esperado (outcome). ‘ada caso de uso ¢ uma funcionalidade que deve ser suportada pelo sistema a ser deseavolvide (ver seydo 6.3) 1 Protétipos so apropriades para questionar requisites estabe elicitar requisitos em situagdes oni \dos @ e os stakeholders apenas tm wma vaga Blicitar Requisitos Ipprenvicing Mapas mentais Workshops Cartdes CRC Gravagaes de audio e video Modelar sequencias de ages Pros6tiposseessita ser desenvolvide, Conseq mplo, protétipas de izados ra pritica para en fsitos Funeionais 3.4 Resumo A clivitagdo de requisitos € uma atividade fos documentos ¢ sistemas legados, 0s si aria de requisitos. Além oa principal fonte de luistos. E importante estabelecer inictalmente um acordo sobre direitos -esponsabilidades mituas entre os stakeholders © © engenheito de requisites para litar a comunicago e a eooperagiio, bem como para integrar os stakeholders no processo de clicitagto. A escolha da tenica de elicitagto correta para o respectiva ta pelo engenheiro de requisitos com base nas restrigdes culturuis, nas e de dominio encontradas.4 Documentar Requisitos Na engenharia de requisitos, informagées que tenham sido cstabelecidas 01 claboradas durante diferentes atividades deve —obrigatoriamente ser documentadas. Ente sas informagies plo, protecolos de olicitagdes| mentagio na engeabaria para o sistema de de mudangas. A principal ¢ mais importa de requisites, «1 forma propriada, santo, consiste em documentar 08 1 4.1. Design do Documento Uma técnica de documentago & qualquer tip formal que faciita a comunicagio entre stak roquisitas dos pode ser utili Tin de representagio mais ox menos imentados, Em principio, qu ada pe ntar requisites, seja uma doc agem natural e redigida em prosa livre, um texto também em linguagem uer tipo de téenica de documentagao sco baseada na natural, porém mais estruturado, ou tenieas mais formais, como diagramas de Definigao 4-1: Docimento de Requisitos / Especificacio de Requisitos Lina especificagao de requisites & uma colegio de requisitos representada de forma sistematica, tipicamente para um sistema ou compenente, atendende a determinados eritrios Durante 0 ciclo de vida de um documento de requisites, muitas pessoas so Rav6es para a carvegadas da documentacao. Durante a comunicagio, a documentagio documenta mpenha um papel de apoio © de orientagao a objctivos. As principais razbes pera documentar requisitos 580 ines: © Requisitos formam a base para o desenvolvimento do sistema, Requisitos Papel central de qualquer tipo influenciam, direta¢ inditctamente, a andlise, o design, a dos requisites, implementagao e as fuses de teste. A qualidade de um requisito ou de um Documentar Requisitos 6Dacumentar Requisitos documento de requisitos tem forte impacto sobre o projeto, ¢ por consequéncia, sobre seu éaito, ‘elevancia lzgal. Requisitos sto legalmente vineulantes o comtratante e 0 contratado, sendo que o contratante pode mover um 0 contra o contratado em caso de ndo cumprimento, Documentar ajudar a rapidamente resolver conflitos legais entre mentos de requisites sdo complexes. Sistemas com milhares de que por sua vez sho caracterizades por complexas interdependéncias em miltiplos niveis, nfo séo incomuns na prdtica. Sem. uma documer vada, mantcr a siruagho sob controle pode se tomar bastante difieil para os envolvides, Reguisizus devem ser acessivels para todas as partes envoridas. Projetos tendom a passar por dererminadas "deseavolvimentos" com o decorter do tempo — tanto em termos de contetido quanto de pessa os requisitos podem ser acessados de forma permanente € desconhocimentos, © novos membeas da equipe podem rapidamente colocar-se a par do projeto dos quase nunca compastlham a mesina compreensio de um determinado assunto. Sendo assim, requisitos devem ser decumentades de forma a atender as exigéncias de qualidade de tods os envolvides 4.2 Tipos de Documentacaio Requisitos pars um sistema podem set documentados a partir de trés perspectivas diferentes. Na pritica, tanto a linguagem natural quanto a modclagem conceitual Slo utilizadas para esse fim, ou muitas vezes omprega-se uma combinagto spropriaula enire a5 dus. 4.2.1 As Trés Perspectivas dos Requisitos ‘tos. para_um sistema po documentades a partir de wes perspectivas diferentes do sistema a ser desenvolvido: Perspectiva esuural: Na perspectiva estrutural, adota-se uma perspectiva estitico-estrutural dos requisitos do sistema, Por exemplo, 2 estrutura dos dados de entrads ¢ saids, os aspectos estitico-estruturais de ‘uso, bem como as relacdes de dependéncia entre o sistema ¢ 0 contexto do sistema podem ser documentados (par exemplo, as servigos de um Relevancia leg Complexidade Perspectiva estruturalDocumentar Requisites sal: A. perspectiva funcional documenta guais cebidas do contexta do sistema c proces pelo sistema ou por uma de suas fungdes. Esta petspectiva também ta quais dados retornam para © contexco do sistema. A ordem de es que processam os dados de entrada também € exccucdo das fn ada, = Perspective informagoes sobre o sistema ¢ sobre contexto do sistema sf documentadas 2 partir dos estados do sistema documentando-se as reagdes do sistema tos no contexto do sistema, as condiges que justificam uma transigao de estados, bem como 05 efeitos que o sistema deverd ter sobre scu ambiente (por exemple, cfeites do sistema sob anélise que representam eventos no contexto do sistema de outro sistema) erspectiva comportamental mo o sistema esti integrado ao ite a ev 4.2.2 Documentagao de Requisitos Usando Linguagem Natural A linguagem natural, especialmente a prosa livre, & u forma de documentagio de requisites mais aplicada na prities. Comparado com outras formas de documentagio, a prosa possui uma nitida vantagem: neahum stakeholder precisa fprender uma nova notagdo. Além disso, a liaguagem pode ser usada para grande riedade de finalidades ~ 0 engenheira de requisites pode utilizar a lingua tural para expressar qualquer requisito, A documentaeao bascada na linguagem natural é apropr documentar requisitos em qualquer das trés perspectivas. Entretanto, a lingua natural pode resultar em requisites ambiguos. Além disso, requisites de diferent lipos © perspectivas cortem o risco de serem misturados, ainda que nao intencionalmente, durante a dacumentagao. Nesse caso, ¢ dificil isolar informagdes relacionadas a uma determinada perspectiva em meio a todos os requisitos em inguagem natural ida para 4.2.3 Documentagao de Requisitos Usando Modelos Conceituais © coniririo da linguagem natural, os diferentes tipos de modelos conceituats modem ser utilizados universalmente, Ao documentar requisitos por meio de tiodelos, linguagens especiais de modelagem relacionadas com a perspectiva sropriada devem ser utilizadas, Mesmo que a linguagem de modelagem selecionada para uma tareft de documentagao seja aplicada corretamente, seu rego garante que 0s modelos eriads retratam informagOes relacionadas apenas com a respectiva perspeetiva. © modelo retrata os requisitos documentados de orm muito mais compacta, sendo assim de eampreensio m: s facil para um leitor Perspectiva funcional Pecspoctiva Vaniagens do uso da linguagem natural Desvantagens do uso di linguagem natural64 Documentar Reguisitos natural, Além disso, modelas conceituais oferecem erpreiagao) do treinado do que a linguagem um menor grau de ambiguidade (isto &, menos possibilidades de i que 3 linguagem natural, devido a seu maior grau de formalidade, Entretanto, usar linguagens de modelagem conceitual para 2 documentagio de requisites exige conhecimentos especifices de modelagem. A lista abaixo inclui curtas descrigses dos mis importantes diagramas discutidos mais detalhadamente no capitulo 6. Um dliagrama de caso de uso permite obter uma ripida visto geral das Visto geral das funcionalidades do si ficado. Um caso de uso descreve quais _fungves do fangtes sto oferecidas ao ususrio pelo sistema e como essas fungées se sistema relucionam na interago com outras entidades externas, Todavia, casos de so no descrevem as responsabilidades des fungSes detalhadamente (vor soo 6.3 nas de classes sto utilizados na engenharia de requisitos, entre | Modelagem cutras coisas, para documentar requisitos com respeito & estrutura estitica _estrutural dos dos dados, para documentar dependéncias estético-estruturais entre dados e sistema ¢ 0 contexto do sistema, ou para documentar termos complexes estruturamento do dominio de forma estrumurada (ver Seei0 6.5.2) de termes fi 1 O.uso de iagramas de atividades tora possivel documentar processos de i negllo, 04 dependéncias sequencinis do sistema em relagio a processes sequencias Dingramas de aividades também si aproprindos para modelaro carter sequencial dos casos de uso ou para rodelar uma 10 dealbada da interagao das fangBes que processam dados 5.63) i no contexto do sistem = Diagramas de estados $20 wlilizades na engenharia de requisitos para Comporia- documentar comportamenios de um sistema desencadeades por mtentos determinados eventos (event-driven behavior). O foco desse tipo de desencadeados ‘modelo so 0s estados individuais em que o sistema pode se encontrar. os por eventos e suas respectivas condigdes que desencadeiam uma transisgo de determinados estados, bem como os efeitos que o sistema tem no ambiente eventos 4.2.4 Documentos de Requisitos Hibridos Acima de tudo, documentos de requisitos contém requisites. Além disso, em ‘muitas situagdes faz sentido documentar decisdes, explicagies importantes e outras informagées relevantes também. Dependendo do publico-alvo do documento, da perspectiva sobre o sistema e do conhecimento documentado, selecionam-se tipes apropriados de documentagio, Tipicamente os documentos contém uma combinagdo de linguagem natural e modelos conceituais. A combinagilo permite diminuir eventuais desvantagens de um dos dois tipos de documentagio através dos pontos fortes do outro tipo. A combinagao dos tipos de documtentago explora as ‘vantagens de ambos. Por exemplo, modelos podem ser complementados por comentirios © requisites em Tinguagem natural, 20 passo que requisitos em Tinguagem natural podem ser resumidos e suas dependéncias representadas_Documentar Requisitos claramente por meio de modelos, 4.3 Estruturas dos Documentos Documentos de requisitos incluem uma grande quantidade de informacds diferentes, que devem ser bem estruturadas para 0 leitor, Para i890, pode-se fazer uso de estruturas padronizadas de documentos ou definir individualmente uma estrutura documental customizada, 4.3.1 Estruturas Padronizadas de Documentos padronizados de documentos oferecem uma estrutura previamente : mentos de requisites (por exemplo, para verificar se o documento esti 0s completo) Modelos padronizades permitem a reutilizay conteiidos dos documentos de requisites. simplificada dos fe observar que essas estruturas devem ser ajustadas para as propricdades cifieas do projeto para atender as suas respectivas restrigbes. Ni rafos, téS das estruturss padronizadas de documentos mais amplamente Sgadas Serd apresentadas. © RUP (Rational Unified Process) (Kruchten 2001] & geralmente ado pata sistemas de soitware desenvolvides com 0 uso de métodas tados a objetos. O cliente cria um modelo ce negécio que eontém diferentes ‘os do mundo dos negécias (por exemplo, regras de negécio, casos de uso © Scio), 08 g para requisitos do sistema ac longo do envolvimento, © contratado usa as estruturas da especificagdo de is servem de base Influéacia dos requisitos na satisagao Adapiagao de padronizadas exisientes Rational UnifiedDocumeniar Requisitos sas estruturas estdo estre fication, on SRS) para mente visitas de sistema (sof documentar todos os requisiios de software. E: ‘onadas coin a norma IEEE $30, como descrito 2 A norma IEEE standard §30-1998 [IEEE Std. $30-1998] (Pritica IEEE standard Recomendada para Especificasio de Requisitos rare) contém uma §30-1998 | #i0 que foi especialmente projetada para o documento d estrutura padrio sugere dividir 0 dacumento de requisitos em teés eserutura quisites de software. capitulos pr 1 Inirodugto (por exemplo, metas do sistema, limites do sistema), m Deserigio Geral (por exemplo, perspectiva do sistema, earacteristicas dos usuarios, restrigdes de desenvolvimento), 1 Requisitos Especificos (por exemplo, requisitos fincionais, de desempeniho, requisitos de qualidade, interfaces) (© Modelo-V [V-Medell 2004] do Ministério do Interior da Alemanba (BMI, na Modelo V {{—sigla em alemio) define diferentes estrururas, dependendo de quem € 0 autor do documentos de requisitos A Expecificagio de Requisitos do Cliente, conhecido em aleméo como Lastenheft, on Cadema de Encargos, & criada pelo contratante (a cliente) ¢ desereve todas a8 exizéncias impostas ao contratado em relago ao ccontrato, isto é, 0s entregawis e servigos. Além disso, ci muitos casos as cexigéncias «los usuarios também so documentadas, incluindo todas as a0 sistema e a0 proceso de desenvolvimento. Portanto, 0 cadema de eneargos geralmente descreve u feito restr mA Especificagdo de Requisitas do Sistema, conhecido em alemao como Pflicktewheft, oa Cadema de Obrigagdes, tem como base o cademo de mntém as sugestdes de implementagdo elaboradas pelo contratado, Porianto, 0 caderno de obrigacdes desereve como concretizar fs requisite as restrigdes do cademo de ena 4 Como deserito na sepa 4.3.1, estruturas padronizadas de documentos sto 0 conteiido adaptadas as condigées especiticas do projeto. As seguintes questdes deveriam ser _minimo de uma ‘sbordadas por qualquer esirutura selecionada, especilicagao de Requisitos Contetidos Padrio Customizados Introdugio A introdugdo contém informagdes sobre o documento como um todo. Essas informagées permitem obter uma visdo geral do sistema,iio de Docum tar Requisitos 0 discute 0 propdsito para o qual © documento foi ca 0 publico-alve do documento de requisites, ralidade: Essa se ctindo e identi B Cobertura do sistema, Essa parte consiste do sistema a ser desenvolvido. Ela indica © nome do sistema ¢ os principais objetivas val agen que resultam da implementagaa do sistema | Stakeholder: Essa sego comém uma lista de stak informac ™ Definigdes, acrénimos ¢ abreviagdes:” Nesta segto, 0s termos utilizedos nno documento so definidos para que possam ser usadas de forma consistente em todo 0 do. sed 3.1.1) | Referéncias:’ Todos os documentos referenciades pelo documento de requisitos sto listados aqui, | Yisdo Geral: Ao final do capitulo intredutério, 0 conteddo ¢ a estrutura das secdes subsequentes do documento de requisites devem ser brevemente explicados. Perspeetiva Geral Nesta seefo, documentam-se informagdes adicionais que aumentam a compreensibilidade dos requisitos. Ao conttirio da introducdo, essas informagbes So meramente operacionais ¢ nfo dizem respeito 4 administragie, a0 igerenciamento ou aos aspectos organizacionais do documento de requisites. Ambiente do sistema: A integracdo do sistema dentco do ambiente é uma questio chave nesse parigrato. Aqui podem sor encontrados os resultados da definigdo sobre os limites do sistema e do contexto, resort as inter ‘operacionais do sistema (por exemplo, interfaces de usuarios, interface de hardware © sofiware, interfaces de comunicagio). Além disso, informagdes adiciouais, relacionadas, por exemplo, com limitagies de armazenamento, tambem sio discutidas. 10 da arquitenra: Nesta segio documentanm-s. ™ Funcionalidade do sistema: Esta sega descrove Fancionalidades ¢ tarefas do sistema, Isso pode ser doc exemplo, usando um diagrama de casos de uso. lobalmente as nentado, por | Usuirias ¢ puibtico-alvo: Os diferentes usuarias do sistema que compoem © publico-alve sao listados nessa segdo, a seo também pode vrata ome um aptndioe dod Bs esto tine pe als oDocumentar Requisitos ‘des: Nessa sogdo devem ser list foram documentadas até este ponto e que podem interferir na eo) de roquisito das todas as condigbes que nao saharia = Pressupostos: Aqui sto documentadas det tais como nao ‘mplementar cerios aspectos do sistema por razdes orgamentirias, os outros pressuposios globais sobre 0 contexto do sistema nos quais os | roquisitos se baseiam. | Requisitos Essa parte contém requisites funcionsis e requisitos de qualidade. Apéndices Nos apéndices podem ser decumentadas informagdes adicionais que completam 0 documento, Por exemplo, os apéndices podem incluir documentos adicionais felacionades com as caracteristicas dos usuérios, normas, convenes ou 1 informagée: sais sabre o documento de req indice © indice tipicamente coniém um sumario (isto 6, a estrutura dos capitulos) © um indice remissivo, Em documentos de requisites altamente dinamicos, essa pode ser uma seg2o critica a ser atualizada constantemente. 4.4 Uso dos Documentos de Requisitos Ao longo do projeto, os documentos de requisites servem de base para diferentes Documentos de tarefas: requisitos como base para 0 desenvolvie mento do = Projeto arguiterdnico: Os requisites detalhados documentados sistema Guntamente com as restrigdes) servem de base para 0 projeto arquit 1 Plancjamento: Com base no documento de requisites & possivel definir pacotes concretos de trabalho e marcos para a implementacao do sistema. nico do sistema, = Implementacdo: Com base no projeto arquiteténico, 0 sistema é implementado fazendo uso dos requisites. Teste: Baseado nos requisitas que constam no documento de requisites, & possivel desenvolver casos de teste que podem ser uilizados mais tarde na validagdo do sistema, Gerenciamemo de mucancas: Quando 0s requisites mudam, o documentoDocument oquisites 6 de requisitos pode ser utilizado como base para analisar até q onto tes do sistema serio atingidas, o que possibilita estimar o esforgo exi = Use ema foi desenvolvido, o documento de requisitos ¢ usado para fins de manutengio © apoio, Dessa forma o documento de requisitos pode ser utilizado para analisar defeitos ¢ deficiéncias concretas que surgirem durante 0 uso do sistema. Por exemplo, 6 passivel deduzir so um defeito resulta do uso Incorreto do sistema, de um erro nos requisites ou de um ero na implementagao, do sistema ¢ manutenedo do sistema: Depois que 0 © Gerenciamento do conirato: O documento de requisites em muites casos 0 principal objeto de um contrato entre wn coatratante ¢ um contratado, 4.5 Critérios de Qualidade para Documentos de Requisitos Para fomar-se uma base para os processos subsequentes de desenvolvimento, 0 documento de requisites deve atender certos critérias de qualidade. Além dos critévios de qualidade sugeridos na norma IEEE §30-1998, © documento de requisitos deve possuir uma estrutura clara e ser razoavelmente compreensivel Assim, o documento de requisitos deve atender aos seguintes critérios: & Nao-ambigui de e consisténcia (IEEE Std. 830-1998 Fstratora clara, Modificabilidade e extensbilidade (IBEE Std. 830-1998} Completude [IEEE Std. 830-1998] Rastreabilidade (IEEE Std. 830-1998}. 1 Na mbiguidade e Consisténcia Documentos de requisitos somente podem ser consistentes ¢ no amt 0s requisitos individusis forem consistentes e nao ambiguas. Além disso, & preciso assegurar que os requisites individuais nio se contradigam mutuamente, Para ta recomenda-se o uso de modelos conceituais (ver capitulo 6). Outro aspecto da no ambiguidade envolve a identifieacdo unica de um documento de requisitos, ou de um requisito, entre o conjunto de todos os documentos de requisites, ov de todos os quisi rminada projeto de desenvolvimento (ver sega A qualidade requisitas individuais & présrequisito tthe Commannecor ats aiDocumentar Requisites 4 Para assegurar que o docum 5.2 Estrutura Clara 10 de requisites pessa ser lido por qualquer stakeholder, 9 documento deve set adequadamente abrangente e claramente struturada, Infelizmente, nfo ¢ possivel oferecer sugesides simples claras a respeito da abrangéncia adequada de um documento de requisitos. Um documento de roquisitas muito abrangente e bem cstruturado pode ser to apropriado quanto uum documento menos abrangente, pois uma esirutura clara ira permitir que um leitor pule as partes que nfio slo relevantes para ele. Um documento mio estruturada ou mal estruturad, por outro lado, nao seria apropriado com o mesmo alto nivel de abrangéncia, pois o documento precisaria ser lido integralmente antes que o stakeholder pudesse identificar as partes relevantes para ele. Um bom ponto inicial sGo as estruturas descritas na seqio 4.3.1 4, lidade ¢ Extensibilidade Documentos de requisitos deve ser facilmente extensiveis. Sempre ha requisitos a serem modificados, alterados, adieionades ou removidos conforme um projeto progride. Sendo assim, a estrutura dos documentos de requisitos deve ser facilmente modificavel ¢ extensivel, Os documentos de requisitos de um projeto de gerenciamento pelo controle de versbes do projet. 3 Modifical Jevem ser pas 4.54 Completude Documentos de requisites devem ser completos, isto é, eles devem conter todos os requisitos relevantes (além das informagées adicionais exigidas) © cada requisito deve ser documentado de forma completa.’ Para cada fungdo do sistema, devem ser tdescrites todos os dados de entrada (puts), os fatores que o influenciam ¢ as reagies exizidas do sistema, Isso inclui a deserigao de err0s e casos eo em particular. Adicionalmence, requisites de qualidade, tais como requisitos que dizem Fespeita aos tempos de resposia ou a disponibilidade © usabilidade do sistema, dover ser snotados. Fatores formais também contribuem para a completude, Graficos, ddiagramas c tabelas dever ser rotulades adequadamente. Outro aspecto importante & que os diretorios de referéncia e indice devem ser consistentes. Adicionalmente, ddolinigdes e referéncias normativas que denotam termos especificos devem ser incluidas em qualquer documento de requisites. A abrangéneia de um documento dd requisitos constitui um desafio durante a engenbaria de requisites. Muitas vezes { preciso encontrar um meio-termo entre os recursos de tempo disponiveis © 2 Ta ent land, esa afenasfo verdadere apenas para 9 documenta de requisitos da prénira release do Permite leitura seletiva estrutura devem promover a modificabili- dade Deis tipos de completude em documentos de requisites Fatores formals, Evidéncias, Roferéncias € Fontes contribuem para a completudex B) Permite feitura E a . c ’ fy corunrs devem .-. : , ca para eopletude Documentar Requisitos completude dos documentos de requisites. 4 Rastreabilidade Um importante critétio de qualidade é a rastcabilidade de relacionamentos entre documentos de requisitos e outros documentos {por exem provesso comercial, planos de teste ou planos de projeto). Esses documen podem ter sido eriados em fases anteriores ou em fases subsequentes de desenvolvimento, ou a0 mesmo tempo que os documentos de requisites. Entre outras coisas, 2 rastreabilidade proporciona apolo para gerenciamento de imudangas (ver Sesto 8.4). lo, 0 modelo de um 4.6 Critérios de Qualidade para Requisitos Os eritérios de qualidade definidos na norma LEEE 830-1998 podem ser aplicados tanto pare requisites individusis como para documentos completes de requistos Além dos eriterios formais, critérios adicionais de qualidade para requisitos individusis podem ser estipulados e tém o propésito de aumentar a aceitago da especificagao por parte do leitor. Os criterias formais conforme & norm IEEE 830. 1998 e os critérios que aumentam a accitagdo dos requisites por parte do leitor esto brevemente explicados na lista abaixe: 1 Acordado: Um requisito esté avordado se ele esta correto na opinido dos stakeholders, ¢ todos os stakehokders 0 aceitam como valido. % Priorizado: [IEEE Std. 830-1998} Quando a complexidade 0} abrangéncia de um sistema alcanea um certo litnias, € important classiticar os requisites em termos de importancia, obrigatoriedade le ou prioridade. Esse & 0 caso especialmente quando nem todas as funcionalidades de um sistema podem ser implementadas imediatamentc em determinada versdo do sistema. Nesse caso, 08 stak classificar os requisicos. holders d Nao ambiguo:[IEBE Std, 830-1998] Um requisito que esta dacumentado de forma nao ambigua pode ser interpretado somente de uma maneira, far o requisito de mancira diferente. Todos 0 leitores do requisito devem ch requisito Nao deve ser possivel inter: rar ao mesmo entendimento do 1 Viilido e atualizado: Um requisito documentado deve representar os fatos © condigaes do contexto do sistema de forma a ser vilido no qui as caracteristicas atuais do contexto do sistema, Essas caracteristicas podem ser as ideias dos diferentes stakeko se refere Relacionamento documentas de desenvalvi- riterios de qualidade para smentar & aceitagto do leitorDocumentar Requisitos = Cor = Consistente: (IEFE St interfaces para sistemas extermes. 10: {IEEE Std, 830-1998) Lm requisito esté vorreto se cle repre de forma adoquada a idcia do stakeholder requisito pode nfo expressar mais do que aquilo que o stakef tentanto dizer. Para verificar isso, 0 stakeholder deve poder ler & compreender a documentaczo dos requisitos. Portanto, o grau de exatida de uma especificacie somente pode ser verificado se 0 criterio de compreensibilidade for atendido. <9 tamibsm significa que 0 der estava 1830-1998) Requisitos dey ‘lagdo a todos 08 outros requisites, isto ¢, os requisites no devem contradizer-se mutuamente, independente do seu grau de detalhamento ou do tipo de ormulado de modo a permitie consisténcia consigo mesmo, isto &, 0 requisito ndo pode radizer-so 1 Ferifieével: (IEEE Sud, 830-1998} Um requisite és forma a permitir sua verificagdo. Isso significa que testes ou mensurages que comprovem a funcionalidade exigida pelo requisito possam ser locumentagio. Além disso, um requisito deve ser ce ser deserito de realizadas, io de cada requisito deve ser possivel, observadas as restrigdes organizacionais, leg nicas ou financeiras. Isso signifiea que um membro da equipe de desenvolvimento deveria envolver-se na avaliagdo dos abjetivos e requisitos para poder indicar os limites téenicos da implementagao de determinado requisito, Além disso, ‘os custos da implementagio devem ser incorporados i avaliagdo. Ha situa~ (90es em que stakeholders retiram um requisito quando os custos de sua imple hecido Rasiredvel. [IEEE Std. 830-1998] Um origemn ¢ implementaedo, bem como sua relagdo com outros documentos. podem ser retracadas, isto & se 0 requisito permite o rastreamento das ‘mesmas, Tsto pode ser feito por meio de identificadores iinicos de requisitos. Usando esses identificadores tinivos, requisitos derivados de outros requisitos em algum nivel diférente de especificagio podem ser canectados. Por exemplo, um objetive de sistema pode ser rastreado por todos 08 niveis de abstraglo, do projeto até a implementagao © Deralhes podem ser eneontados na segdo 8.4 © Completo: {IEFE Std. 830-1998] Cada requisite individualmen deserever completamente a funcionalidade que ele es {que ainda esttio incompletos devem ser especificamente mateados, por ‘exemplo inserindo "ASD" (a ser definide) no respective campo de texto, ou determinando um es podem ent8o ser localizadas sistematicamente, adicionando-se devidamente informagbes que falta. ntaglo se tornam c squisito € rastredvel se a sua 2 de cifica, Reguisitos is correspondent. Essas marca} ] Compreensivel. Requisitos deven ser compreensivels para cadaDocuments Requisitos stakeholder. Consequentemente, 0 tipo de documentagao de requisites (ver segdo 4.2) pode variar significativamente, dependendo do estigio de desenvolvimento (e portanto, dependendo do pessoal envolvido). Na igenharia de requisites, ¢ importante definir estritamente os lermos utilizados, Além dos eritérios de fun lidade para requisiios, existe ainda duas regras smentais que aprimoram a gibilidade de requisitos: Frases curtas e pardgrafos curtos: Considerando a lin ccurto praza humana, circ deseritas em nao mais do que sete ada meméria de si dexeriam sor s relacionadas ent © Formula ape io por frase: Utilize a voz ativa para fornnular um verbo di agGes subordinadas, devem ser evita requisitos, empr complesas, entremeadas processo. Frases lan; 4.7 Glossario Uma causa frequente de conilitos na envolvidas no pracesso de desenvolvimento { termos. Para evitar esses conflites, € necessirio que todos os envolvidos no processo do desenvolvimento compartilhem mesmo entendimento da lerminologia utilizada. Portanto, todos os termos relevantes devem ser definidas em wn glossézio comum. Um glossario ¢ uma colegio de definigses p apresentando 0 jenbaria de requisites & que as pessoas E de mn diferentes. interpretagt Conccitos do diva-dia que possuem um sentido especifico no dado Sindnimos, isto ¢, tenos diferentes com o mesmo sentido. Homénimos, isto &, temos idénticas com semiidos diferentes. Ao definir 0 significado de termos, € possivel aumentar consideravelmente a compreensibilidade das requisites. Mal-entendidos ¢ retagdes diferentes de termos, que podem levar a contlites, podem ser fesde 0 inicio. Com frequéncia em diferentes projetos sto utitizadas termos similares, ou ai mesmo idémticos, Isso pode ocarrer, por exemplo, quando um sistema & wolvido para diferentes clientes mas dentro do mesmo dominio, Nesse caso, Prineipios fundamentais de compreensibili- Gade Definigdies consistentes Routilizagio d verbetes ossirios Ctasee, mnDocumentar Requisitos lerberes de glossérios jf existentes deveriam ser reutilizados, Pode até ser vidvel efinir fais termos em um glossério universal para virios projetas. O esforgo adieional para criar tal glossdrio sera compensado em futuros projetos. Para certos dominios, ja existem compilades publicamente acessiveis de definigdes para termos, Elas podem servir como fundamento para a definicto de glossarios especifices. Por exemplo, na noma IEEE Std. 610.12-1990, encontraim-se definigaes de termos tipicos da engenharia de software. Regras para Usar um Glossario Visto que a eriagdo de um glossério é absolutamente obrigatoria, os seguintes aspectos devem ser considerados: BO glossaria deve ser gorenciado de forma centralizada: Em qualquet dado momento somente pode haver um glessirio valido, que também dove ser acessivel de forma centtalizada, Nao pode haver miltiplos glossarios valides. 4 responsabilidade deve ser atribuida: Uma pessoa especitica reeeber a atribuicdo de manter o glossirio e assegurar sua consisténcia © atualizagao. Os recursos necessérios para realizar essa tarefi devem ser inchuidos no plano do projet. glossirio deve ser mantide ao longo do projeto: Para assegurar a consisténcia ¢ atualizagio do glossirio, ele deve ser mantido ao longo do ciclo de vida do prajeta pela pessoa ineubidda dessa responsabilidade. O glossério deve ser de acesso comum: As definighes dos termos devem estar acessiveis para todo o pessoal envolvide no projeto. Essa é iinica ‘maneira de poder assegurar uma compreensio comum dos termes, A utilizagado do glosstirio deve ser obrigatéria: Todo 0 pessoal envolvido no projeto deve ser obrigada # utilizar exclusivamente os termos e dlefinigées de termos da forma como foram definidos no glossitio. 0 glossdrio deve incluir as fontes dos rermos: Para que se possam resolver questaes ¢ problemas em qualquer momento ao longo do ciclo de ‘vida do projeto, a origem de um dado termo deve poder ser determinada, © glessirio deve ser aprovado pelos stakeholders: Somente stakeholders podem walidar de forma confidvel as definigdes operacionais, para seu respective context de projeto. Cada definigao deve ser validada lo stakeholders ou seus representantes. Alm disso, as definigies individuais de termos no glossirio devem ser explicitamente aprovadas. Essa aprovagdo sinaliza que o respective termo est correto e que seu usd Os verbetes no glossrio devem possuir- uma estrutura consistente: Todos fos verbetes no glossério devem ser estrumurados da mesma forma. Para. servie de apoio para uma documentaglo consistente, recomenda-se utilizar Regras basicas paranusar um alessirioDocumentar Requisitos i lum template para definigdes de glossirio. Além da definigto e do significado de um termo, o emplate deve especificar possiveis sinénimos e homénimas, Para reduzir 0 trabalho de ajustar termos constantemente, recomenda-se iniciar a ompilagio do glossiio ja no comeeo do projeto, 4.8 Resumo A documentagdo de requisitos desempenha um papel central na engenharia de requisites. Considerando que a quantidade de requisites € geralmente muito vast ¢ muito importante estruturar os requisitos de forma clara, para que pessoal no envolvido no projeto também compreenda os requisites. Alem disso, dessa maneira 2 localizactio © a modificagio de requisites é simplificada e accleradka, Isso facilita muito o alendimento des critérios de qualidade dos documentos uutilizagdo de estruturas customizadas de documentagao demonstrou ser aproprinda para esse propdsito. Essas estruturas slo preenchidas com requisites especificas do projeto, escritos em linguagem natural, em copjunto com modelos conceituais de requisites, requisites. ADocumentar Requisites usando Linguagem Natural 5 Documentar Requisitos usando Linguagem Natural Requisites elicitados para © sistema a ser desenvolvido sto frequentemente documentados usando Tinguagem natural. A Tinguagom natural tem a vantagem de (supostamente) nfo exigir tempo de preparo para ser lida © comproendida pelos stakeholders [Robertson © Robertson 2006). Além disso, a linguag universal no sentido de que pode ser utilizada para descrever quaisquer circunstincias, Entretanto, existem algumas dificuldades associadas a0 uso da Tinguagem natural para a documentagao de requisitas gem natural & 5.1 Efeitos da Linguagem Natural Come a linguagem natural é inerentemente ambigua ¢ sentengas em linguagem Percengao natural muitas ve7es podem ser interpretadas de mniltiplas manciras, é necessério subjetiva colocar énfase especial nas eventusis ambiguidades de tais senteneas para fazer 0 eritério de ndo-ambiguidade. Rexisitos slo definidos ¢ lides por was com diferentes iv tes experiéaci de conhecimento, diferentes origens sociais © A diversidade entre as pessoas envelvidas nos processos de FORNECER V Ap | pare \ \\ | osisrema | Cszmess [7] DEVERIA A=) ser tomes | J\ | capactonoe —] |\ oes /\_ SER CAPAZ be ate TIPO 3 Figura §-2 O niiclea de um requisito € sua obrigatoriedade Template Tipo + Atividade auténoma de § utilizado quando requisitos so construidos para © primeiro tipo de tem representar atividades que s80 cxecutadss de forma auténoma, O usuario nfo atividade. Definimos o seguinte template de requisites interage eon SISTEMA DEVERA/DEVERIA/TRA svetbo de processo> conta um verbo de provesso conforme descrito no passo ‘mir no caso de uma funcionalidade de impressio, ou ‘Template Tipo Verb de processe> represt Tnterago com 2 acima, por exemplo, inj ‘ealcular para algum célculo executado pelo sistema Se o sistema fomece uma funcionalidade para um usuario (por exemplo rnirada), ou se 0 sistema interage diretamente com © através de uma interface de e tisuario, as requisitos so construides usando o remplate tipo 2 O:SISTEMA DEVERAMDEVERIAGR 4 sfornccer 7a. quem?> a ‘capacidade de = verbo de provesse= (© uswério que interage com 0 sistema esta integrado ao requisite por meio de Template Tipo 3: Requisito de quem? ¢ depende de sistemas adjacentes, Se o sistema executa uma atividade de template. Sempre que mensagens ou dados So executando um interface deve reagit dover ser utilizado 0 tipo recebides de um sistema adjacente,aoe : r Dacumentar Requisitos usando Linguagein Natural comportamento especifico, O seguints femplate tem se mastrade apcopl os! TEMA DEVERAIDEVERIAMRA sex capa de “verbo de proses Passo 4: Inserir Objetos e Complementos Alguns verbos de process necessitam um ou mais objetos adicionais para serem Completar 4.08 Objetos que verbos de mpletes (ver segde 5.1.5). No Possivelmente estiverem faltando, bem como os comple das ¢ adicionados ao requisito. Por objetos. sto identi plo, 0 fe requisitos para o verbo de processo imprimir & complementado com as informa sobre 0 que esti senda impresso © onde esti sendo impresso, A complementagto pode ser vista na figura 5-3 & DEVERA | | | & Dn 2RDsh2-a9, ‘eneae” {—1 DEVERIA |-{-| s -—} Passo 5: Determinar Condicdes Légieas e Temporais ntam funcionalidades contiauas, mas sim Adicionar sob certas condigdes condigdes Tipieamente 08 requisites: nao docu alidades que s20 executadas ou forneeidas som as ou temporais, Para diferenciar facilmente entre condigdes logicas e naporal "assim que" para condigées tempor A conjuneao “quando” std sendo descrita e deveria temporais, escothemos a conjunc ondicional "se" para condides 16 20 portanto ser evitada No passo 5, requisitos de qualidade que deserevem as condigdes nas quais um requisite do sto adicionadas ao inicio do requisito ‘como uma oragdo subordinada,Documentar Requisicos usando Linguagem Natural | peveRA Figura 5-4 0 semplate de roquisitos completo, com especificago de condigses Templates de sequisitos devem ser usados quando os membros do projeto tém interesse em um processo formal de desenvolvimento. Estilo ¢ criatividade so foriemente limitados quando remplares de requisitos S80 uiilizados. A experitacia mostra que a melhor prética ndo é impor 0 uso des templates de requisites de Forma compulséria, mas oferecer treinamento para utilizar o método e trati-lo como uma rramenta complementar. 3.3. Resumo Requisites de sistema so documentades frequentemente em lingw ns derivadas da linguagem natural ineluem uma melhor legibilidade dos requisitos, a aplicabilidade universal da li qualquer circunstincia, além da nfo-exigéncia de qualquer experiéncia prévia em termos de notagio. Por outro lado, existem virias desvantagens que resultam do fato que os requisites em linguagem natural ndo tém um estrutura formal. por exemplo, a ambiguidade. Como os membros do projeto interpretam requisites de modo diferente devido a diferengas em seus respectives. conhecimentos, suas rigens sociais e suas experiéncias, o uso de linguagem natural na prética muitas vezes causa mal-entendidos. As desvantagens podem ser minimizadas durante a documentacso de requisites — por exemplo, através do uso de templates de requisitos © da verificagio de efeitos transtormacionais de linguagem nos roquisitas\do Modelos Documentar Requisitos 6 Documentar Requisitos Usando Modelos Durante a dacumentagao de requisites usando modelo na engenharia de roquisitas, tr8s tipos de requisites sto documentadas de forma independente e utilizados de forma eonjunta Metas descrevem as intengdes dos stakeholders ou de grupos de stakeholders. Metas podem potencialmente estar em contTito entre si sencias de utilizagho do sistema Caos ce use @ cendrios documentam seq) Conérios sio agrupados em easos de uso, -almente denominados de requisites) descrevem. Reguisitos ingBes qualidades que o sistema a ser desenvolvido dctalhadamen er implementar ou apresemtar. Além disso, requisitos de sistema fornecem informagdes completas e precisas que servem como subsidios para os passos subsequentes do desenvolvimento, Na pratica, os sequisitos sto froquentemente documentados usando a linguagem natural, Entretanto, podemos obscrvar que requisites estia senda docamentados ada vez mais através de modelos. Modelos de requisitos sio utilizados adicionalmente a documentagio ce requisites em linguagem natural o substituern parcialmente requisitos que seriam documentados em inguagem natural 6.1 OTermo Modelo ¢ ou que famciona como uma em pode ser aplicada a mma realidade a Um modelo € uma imagem que abstrai da realidad jo abstrata da realidade a ser criada. A modelay iais ou imateriais de uma realidade existente ou ser desenvolvida. Seguindo [Stachowiak 1973], definimos 0 termo madelo como Modelos como abstratas da reaidade ‘a3 + armen CA ‘(ohne ansDocumentar Requisitos usaudo Modelos Detinicdo 6-02 rade Uin miodslo € uma sepresentagfio dbstrain’de sines realidade eXistente’ ow denn reatidade a sev crinds. Cada n 6.1.1 Propriedades de Modelos nodelo possui tt€s importantes propriedades, que também so as vanta prevalentes dos modelos: 1m Redugio da reatidade: Os m fioade: Cada modclo representa cettos aspcetos da Representacio dda re m. A criagfo de realidade observada sobre seus elementos de modelagei modelos pads ser descritiva ou preseritiva por natureza, Ne eonstrugde de modelos descritivas, 0 modelo resultante documenta a realidade existente. modelos. preseritivas, 0 modelo resultante serve de prototipo para uma realidade fictfeia, Dependendo da perspectiva, os proprios modelos podem ser des compo. Por exemplo, um modelo & deseritivo em relagio concepgio do stakeholder que esti construindo o modelo © preseritivo em relacie 8a sistema a ser desenvolvido, Na construglo eritivas ou prescritivos ao mesmo Jos reduzem a reatidade mapeada, E 0, apenas comum éift entre selegZo e compressio. Durante a selega aspectas especificos que fizem parte do discurso do sistema sio modelados. Na compressio, ao contririo, resumem-se aspectos do cconteaido do sistema = Pragmatismo: Um modelo € sempre construido para uma finalidade Tipicamente, utilizam-se modelos grificos na engenharia ‘a e denito de um contexto especial, O propdsito do modelo pode expect afetar a construgge e a redug%o propositada da realidade dentro dos modelos. Ideelmente, um modelo contém apenas as informagtes nevessatrias para sua respectiva finalidads, elementos de modelagem sto conceitualizagses de objetos materiais ow imateriais, fou de pessoas, na cr lidade, 6.1.2 Linguagens de Modelagem tagens especifices de modelogem sto utilizadas para const sem ¢ definida por sua sintaxe e semantica: juais. Uma lingnagem de mods em de modelagem define os & es valida 1m Sintaxe: A sintaxe de uma ling rem uiilizados e especifica as comb de modelagem a atre el = Semantics: A soménticn define o si modelagem individuais, servindo assim de fundamento para jr modelos mentos ‘ficado dos elementos de Sintaxe © semanticszem de modelagem, cm conceitual podem ser classificadas como formas, dependendo de seu grau de formalizagio. O grau de formalizagio de uma Tinguagem de modelagem depende da rigidez das definigies formais (por exemplo, eéleulo matemétieo) 6.1.3 Modelos de Requisitos Modelos conceituais que documentam os requisitas de um sistema sio chamadas modelos de requisitos. A UML (Unified Modeling Language) & frequentemente utlizads para construir modelos de requisitos [OMG 2007]. A UML praticamente tomov-se 0 padrio para a consirucdo de sistemas de software baseada em modelos, A linguagem UML consiste de um conjuate de linguagens de modclagem parcialmente complementares, utilizadas especificamente na engenharia de Fequisitos para modelar os requisitos de um sistema a partir de diferentes perspectivas, Extensos exemplos de modelagem ullizando a UML podem ser encontrados em [Rupp etal. 2007], por exemple. Uma diferenga considerivel entre 0 uso convencional de modelos couceituais no desenvolvimento do sisiema ¢ 0 uso de modelos para a ocumentago de requisites € que os modelos convencionais documentam solugbes eseolhidas durante © desenvolvimento do sistema, uo passo que os modelas de requisitos retratam aspectos especificos do problema de fundo. 6.1.4 Vantagens dos Modelos de Requisitos A pesquisa sobre a cognigdo humana demonstrou que informagées podem sé pereebidas © memorizadas de forma mais répida © melhor quando retratadas aficamente em vez de usar a linguagem natural (Glass e Holyoak 1986], {Kossiyn 1988} € [Mietzel 1998}. Essas descobertas podem ser aplicadas particularmente para o uso de modelos de requisites Uma vantagem adicional do uso de modelos de requisitos & que, 2c contrivio da linguagem natural, as linguagens de modelagem utilizadas tém um enfoque estritamente definido, Um exemplo seiam os diferentes tipos de mapé que podem ser desenhados para representar uma cidade. Dependendo de qual ispecto da cidade esti sendo mapeado (modelado), diferentes tipos de abstragao podem ser ulilizadas para consiruir © mepa. Por exempla, um mapa do met vai Ses ¢ as linhas de metrd. No entanto, a distincia entre cada ponto do mapa pode nio ret representar, em ver disso, uma estimativa do tempo de deslocamento en tagdes. Um mapa das ruas da cidade, por outro Tado, retrata ficlmente as rua mnOStraL as cst estagées, mas tar precisamente a distancia entre Dilferentes graus de formalizagio Modelos de requisites vs, modelos de projeto Maior fuclidade de compreensio Foco nas ‘Sing waaavenidas a localizagio dos pontas turisticos. Os dois modelos retratam @ mesma realidade, mas cada um apresenta um enfoxue diferente a partir da absiracao definida por sua finalidade. Os modelos de requisitos também apresentam & vantagem de que os diferentes sipos de elementos de modelagem dentro da mes modelagem determinam tanto 0 mstode de abstragse quanto o que es abstrafdo e 0 que ndo est. 6.1.5 Uso Combinado de Modelos e Linguagem Natural (© uso combinado de linguagem natural ¢ modelos de requisites permite explorar as vantagens das dias téenicas de dacumentagao, enquanto minimiza suas desvantayens, Por exemplo, requisites formulados em linguagem natural podem ser resmidas e ter suas interrelagbes representadas através do uso de modelos, Por ‘ouira lado, a linguagem natural pode enriquecer os modelos de reguisitos © os Jagem com inlormagbes adicionais elementos de mod 6.2 Modelos de Metas Muitos métodas na engenharia de requisites sf0 baseados nas considernctes explicitas das intengies dos stakeliolders através de metas (van Lamsweerde ct al 1991] [Yu 1997], Normalmente, é minimo o esforco exigido pare explicitamente cconsiderar metas durante 9 cngenhria de requisitos. No entanto, a modelagem de metas tem um impacto muito positive sobre a engenharia de tequisitos e sobre a qualidade e abrangéncia dos requisitos. Metas sdo a desericao — uuma pessoa ou uma organizacio} — de uma propriedade ut do projeto de desenvolvimento. ita por um stakeholder (isto caracteristica do sist Metas sto muito apropriadas para refinar a visdo de um sistema. Refinar tuma meta também & conheeide como decompasicio de metas. Metas podem set documentadas usando Lingtiagem natural (par exemplo, através do uso de templates previamente preparados) ou modelos de metas. Uma téeniea de modslagem de ‘metas largamente conhecida ¢ empregada ¢ o uso de arvores F/OU. Por meio de Grvores E/OU, decomposigtes hierarquicas podem ser documentadas. O tipo de 10 de rofinamento € descrito pela representagio prafica das ramifieagbes, ou arestas. A direcdo da decomposigio de metas nfo é representada pelas arestas, mas pela estratura top-down da drvore, Documentagao baseada em| natural ¢ em modelosDocume far Requisitos usando Modelos ol 1 Documentagao de Metas Usando Arvores E/OU Ses de decomposigio usando irvores E/OU juerntica esses tipos de decomposigho, bem coma listinguir dois tipes de 1 mostra de forma ‘OU — decomposicéa | E~ decomposicgo etas Metas at.|_- t= SSubmetas Submetas .... Submetas |} Submetas Submetas .. Submetas i = a decomposigo-QU. No caso da decomposicio-E, cada uma das metas E vs. fF subordinadas deve ser atingida para que a meta superordenada (a raiz) seja decomposigao- i sungida. Em contrapartida, na decomposicaa-OU., para que a meta superordenads OU We atingida & suficiente que pelo menos uma meta subordinada seja atingida, PS ia f 6.2.2 Exemplo de Arvores E/OU 4 figura 6-2 mostra uma drvore E/OU que documenta a decomposigao hierarquica mera "Nav 1cho até 0 destino” Navegacio contortive! ‘até a desting a Célculo din&mico da rota A insergo de destino © acompanhamento "a ‘com relacéo 20 @ faci ce user 2 rota € confortavel congestionamento de trénsito ae ries de sto cos aces do wansto Figura 6-2 Modelo de meta na forma de uma arvore E/OUSimone Como mostra o modelo de meta na figura 6- até o destino” & falmada em ttés metas subordinadas ~ “eilelo dinmico da rota em relaso cons fos de trinsita”, "inserga do destino” e "acompanhamento da rota” Sontrave de uma decomposigo E. O modelo expressa que todas as metas Subordinadas devem set atingidas para que a meta superordenada possi, ser aepaiderada atingida. A meta subordinada "cdlculo dindmmico da rota em relagio @ COnsestionamenios de transito", por sua vez, € refinada em duns metas SGherdinadas: inser manual de condigdes de transito’” © “atualizagso amatica de dados de teinsto”, O tipo de relago de decomposigdo expressa que apenas uma das metas subordinadas precisa ser atingida para que meta sréenada possa ser considerada atingida 6.3 Casos de Uso Casos de uso foram propostes pela primeira vez por [Jacobson et al. 1992] como tum meétodo para documentar as funcionalidades de um sistema em plangjamento ou tcxistente por meio de modetos simples. A abors tm dais conceitos utilizados em conjunto: m dos casos de uso & bascada Dingramas de Casos de Uso. mt Especificagdes de Casos de Uso 6.3.1 Diagramas de Casos de Uso UML Diagramas de casos de uso UML [OMG 2007] (ver sepio 4.2.3) slo modclos simples para documentar de forma esquematica as fancdes de um sistema @ parte dio poute de vista do Usurio, bem como as jnter-relagtes das fungdes de um es ¢ seu ambiente. entre essns fi -amas de Casos de Uso UML, Elementos de Modelagem dos Dia os de modelagem mais essenciais dos diagramas idos na UML {OMG 2007] A figura 6. de casos de uso, conforme defi presenta os clemer Modelagem de ‘metas com, farvores E/OUnitar Requisitos usando Modelos 3 Objetas Retacies OF ores Ye cawesiss toe (omona x or leetor=) pene “rome] | (eetacae ateranva) = XC cerca Figura 6-3 Ele neiis de modeiage 30s de uso. em diagramas de © — Casos de uso: De ipses. Essas elipses contem o nome do nidos para o sistema sfo representados por meio de 50 de uso. Outra altemativa & @ —Arores: Encontram-se fora do limite do sistema e representam pessoas ou do ator € @ rénalo «ator». Se o ator for sistemas g gem com lado, Atores sio repre [por um retingulo que recebe o n uma pessoa, pode ser ttlizada tuma feura humana estilizada, Se o ator for uum sistema, tanto pode ser utilizado um retingulo ou uma figura, em » sistema: Dentro do diagrama de easos de uso separam as partes 1a pode partes (pessoas ot sis ‘esto fora do limite do sistema, Como op520, © no ‘anotado junto ao limite do sistema no diagrama, © Relagao de extensao (extend): Uma relagio a que uma 1e [az parte do caso de uso A \pGes para © caso de uso B em um ponto especificado, sequencia de interacoes alguma © Relagdo de incluso (include): Uma relagdo de incluso de um case ‘para outro case de use indica que a seguéncia de interagies do primeiroDocumentar Roquisites usando Modelos _ 25 do outro case de 80. Relacdo enire atores e casos de uso: Se hi comunicagao entre um caso de tuso © um on mais atores durante a execugdo de um caso de uso, a através de uma relagao de comunicagao entre Exemplo de Diagramas de Caso de Uso UML A figura 6d apresenta tim exempla de um diagrama de caso de uso Figura 6-4 Um exemplo usando elementos de modelagem em diagramas de caso deuso (© modelo abrange os glementos de casos de uso "fazer download de informacies de transito”, "recuperar posigdo arual” e “inserir destino”, As relagdes na figura 6-4 jdentificadas por nimeros sio explicadas em maior detalte abaixo: © caso de uso “navegar para destino” esti assoviado aos casos de us Ynserir destino” e "recuperar posicio atual” através de uma relagio incluso, A relaeao indica que os passos de interagio definides nos casos de uso "inserir destino” ¢ "recuperar posigio atusl” estao incluidos no easo de uso "navegar para destino” A relagdo de extensiio entre os casos de uso "Lazer download de Friend informagses de transito” ¢ "navegar para destino” indiea que os passos de fnteragio definides no caso de uso "fazer download de informagies deDocumentar Requisites usando Modelos do caso de uso "navegar itar co riinsito" esto incluidos nos passos de interay vara destino” se uma certa condigd0, tal como estiver dada, © ponto de no caso de uso “navegar para destino” no qua interacio so executados io "evitar congestionamento” indica 0 passo ‘98 pasos adicionais de A UML também fornece uma relugio d Nesse caso, os casos de uso eu atores herdam as propriedades dos casos de usa ou das atares "generalistas” (Rumbaugh etal. 2005). Por exemplo, os ttores "meednico da assisténeia técnica” e "representante do atendimento ao neralizadas como @ ator "funcionério". O ator generalista eine todos 05 aspecios que os alores “mecanico da assisténcia téenica” € ‘epresentante do atendimento go cliente” tém em comum (por exemplo, a identidade do funcionario) ire casos de uso eatores. Generalizagio ; cliente" podem ser 6.3.2. Especificagies de Casos de Uso Diagramas de casos de uso apresentam as fungSes relevantes do sistema a partir da rspectiva de um usuario, bem como as relagdes expeciticas entre as funcdes do iema ou entre fungdes do sistema ¢ determinades aspectos no contexto do sistema. Com a exeegio da name do caso de uso e suas relagées, os diagramas de sos de uso ndo documeniam qualquer informagao sobre os casos de uso ragao sistemtica entre um caso de uso e um miaglo & documentada testualmente por meio dete izades conjuntamente com diagramas de casos de uso. viduals, tal como a in {por exemplo, [Cockburn 2001). Esses remplares definem de informagées que devem ser documentadas para tun caso de uso € s rotura apropriada para as informagses. Portanto, as referéncias de template de casos de uso camentum © vonhecimento (baseado na experiéncia) a respeito da documentaco al estruturads de casos de uso. O temp/are na tabela 6-1 & apropriado para ficar textualmente casos de uso, eréncia para a jerem documentagio plate para Documontacao Textual de C Seo { (Conluide Expire Teentifieacio Uso lenificadorinico do caso de uso Nome Denominago dnica do caso de wo, Autores ‘Noms dos autores nvolvidos nessa deseriedo de e280mentar Requisites usando Modelos [oT ee Tmnportincia do caso de uso de acordo coma Genies de) Cricalidad 4 | Prioridade Critiestidade 6 | Fome Responsivel ‘Nome do evento que Gispara a expeugao do case a sacootar imediatamente aps exccugio do cenirio nip serigio dos Tiados produidos Grane a | Resultado exccurlo do caso 14 _| Cendrio principal Deseriggo do cenrio -righo dos cendtios afematives do aso de Wo, OF lista dos eventos desene alternatives. Frequentemente, podem acorte pos _ condigdes diferentes daguclas desortas no porto (12) i DeserieGo das certos de exceyio do vaso de uso, ou 'sta dos eventos desencadeadenes de cenirios do do. Frequentement, pés-concigdes diferentes | aquetas deseritas no ponto (12) podem ecort Referéncias eruzad Cenirios de excesio | Qualidades pata requisitos de qualidade Fabela 61 Temp para dacumeniagto textual de caso de uso -asos de uso contém os seguintesatributos. itons de um femplate caso de use template pars a especiticagao de '&Atributos para a identificagio nica de casos de uso (linhas 1 e 2) | Atributos de gerenciamento (linhas 3a 7). 1 Atributos para a descricao do caso de uso (linha 8), = Atributos especiticas de caso de uso, por exemplo, 0 wrigger (evento desencadeador) (linha 9), atores (aha 10), pré e pos-condigdes (linhas 11 © resultado do caso de uso (linha 13), 0 venério principal (linha 14), cenirios altemativos & de excogao (inhas 15 ¢ 16) e as referéncias ‘eruzadas para os requisitos de qualidade (linka 17)iia ah Prioridede Citicalidade on Reponsival Deserigio Cenavio principal Documentar Requisitos usanda Modelos presenta @ especificagio do casa de uso "navegar para destino” re de referéacia s ido na tabela 6 Alto. C. Warmer (espectalisa de dominio | navegacdo) Smith ‘O condutor do veleulo digta o nome do devine, O Stamm in © condutor para o destino deseiado. z 0 condutor deseja navegar até seu destin - ‘Condutor, ervsor de informagses de transite, sistema de (© condurorinsereo destino desejado, ( sistema de navegagaolocalian 0 desing eam seus mapas. Baseando-se na posipio esejado, 0 sistema de navegasio calcula uma rola adequads, 0 sistema de nav longo do eaminho, 0 coTeta uma list de pontos de rota a0 O sistema de navegsg0 mostra um mapa da posiglo tual © ars o praximo ponte de rota, Quando itm panto de rai f nav palayras "Dest 4a O caleulo da rota deve observarasinformaydes de tinsito 41. O sistema de navegapio solcitainformagies dd winsito atuslizadas do servidee 422.0 sisters sla unCeniriosd inal OPS) (Qualidades > ROLIS (icildade de operagio) Tabela 6-2 Exemplo de document 6.4 Trés Perspectivas sobre Requi Ao documentar requisites com modelos, distingue-se tipicamente trés tipos de perspectivas: dados, funsiio e comportamento (wer soxdo 4.2.1), Cada perspectiva & ocumentada separadamente, usando linguagens de modelagem conceitual aapropriadas [Davis 1993], [Pohl etal, 2008. Perspectiva estrutural: Nessa perspectiva, sho documentadas as estraturas dos dados de entrada ¢ saida, bem como aspectos estitico-estraurais das relagses de uso e dependéncia do sistema no contexto do sistema, Perspective funcional: Essa ct informa context do sistema est manipulada pelo. sistema ‘a desenvolvido © quais dados esto sendo transmitidas para o context do sistema pelo sistema, Perspectiva comportamental: Nessa perspectiva, documenta-se_ a {ntegracao do sistema no coniexto do sistema com base em estados. Isto pode ser feito, por exemplo, pela documentagio da reagio do sistema frente a eventos que ocorrem no contexte do sistema, das condicées que desencadgiam uma mudanga de estado ou dos efeitos que o sistema tem sobre seu ambiente A figura 6-5 ilusira as ar8s perspectivas sobre requisites fincionais e dé um exemplo de uma linguagem de modclagem adequada para cada perspectiva qu pode ser utilizada para documentar os requisites. Assim, aspectos de requisitos relacionados com a estrutura estatica podem ser medelados usando diagramas de classes UML, por exemple. Requisitos na perspectiva funcional podem ser modeladas usando diagramas de atividade UML. Requisitos na perspectiva comportamental podem ser medelados usando diagramas de estados (ver seeoes 6606.2), Documentagio separada por cada perspective Exemplas das trés perspectivesDocumentar Requisites usande Mo Certos aspecios dos. wctiva espeettica podem também ser encon das. Por exemple, os dadas que tm sua estrutura estitica ida num diagrama de classes UML podem cventualmente também se onal, pois representam as ent perspectivas, portanto, no so totalmente mneontrados na perspectiva fun @ saidas de ages cm um diagrama de atividade UML. Como as 18s perspectivas nao sao separad: modelos podem 56 ente em termmos de ito 8 informagio modelada nas i 8s perspectivas so totalmer separadasDocumentar Requisites usando Modelos 6.5 Modelagem de Requisitos na Perspectiva Estrutural ropriadas para modelar aspestos sirututal. Normalmente modelo tradicional relacionamento conforme Chen 1976] c cada vez mais, diagramas classes UML (por exemplo, [Rumbaugh et al. 2005) estéo sendo usados modelos para requisites na perspes 6.5.1 Diagramas Entidade-Relacionamento diagramas entidade-relacionamenta sao tradicionalmente utilizados para modelara_O modelo perspectiva estrutural pois apresentam a estrutura de um objeto de um universo de tradicional d iscurso através de tipos de entidades e tipos de relacionamentos [Chen 1976]. entid lacionamento Viirias extensdes ttm sido st modelo de entidade- Extensdes para relacionamento, Fssas eXtensGes envolvem principalmente os relacionamentos deo modelo de Jiolespecializacdo, os mecanismos de heranga ¢ os papéis das entidades, entidade ago (min, mx) para as cardinalidades dos relscionamento (0s de modelagem de Diagramas de Entidade-Relacionamento Conforme [Chen 1976], a linguagem de modelagem utlizads p diagramas de entidade-relacionamento inclui os elementos de mor “Tipo eridade Tipo Reacdo arributa corshaliates Figura 66 Importintes elementos de modelagem em diagramas de entidade- relacionamento, conforme Chen Tipos de entidades definem um conjunto de entidades dentro do universo de Classificagio: dliseurso (isto ¢, objetos com as mesmas propriedades, tais como pessoas ou itens). Abstracto a im tipo de entidade (mvitas vezes erroneamente chamado de entidade) abstrai a partir de obje== = Decumentar Requisites u cconcretas dessas entidades © consequentemente classifica lum coajunto em entidades umiformes. Por exemplo, 0 tipo de entidade "piloto’ classifica todas as pessoas dentro do universo de discurso que tém a caracteristica de possuirem uma licenea de pilota Umm tipo de relacionamento abstrai a pacts de uma caracteristica cont de um relacionamento e de entidades relacionadas entre si. Um tipo de relacionamento classifica 0 conjunto de relacionamentos uniformes © cntidades dentro do universo de discurso. Por exemplo, o tipo de relacionamento “executa" pode ser definido entre os dois tipos de entidade "piloto” e "voo" para representar relacionamentos "execute" concretas entre pilotos concrctas ¢ veos coneretos. Se um relacionamne 0" for definido entre um passageiro concreto "John Locke" e um voo conereto com o niimero da voo "OA 815%, enldo esse relacionamento indica que "John Locke" & um passageiro da voo com 6 némero de voo "OA 815 cla Fe tipos 0 conereto "é passag Um arribuio pode se definide tanto para tipos de entidades quanta para tipos de relacionamentos. Um atributo define as propriedades de um «ipo de entidade ou de um tipo de relacionamento. Atributos possivcis para o tipo de cntidade "passageiro" poderiam ser. por cxemplo: "nome de familia”, “nome préprio", Ynimero da passaperte” ¢ "niémero do assento” Um modelo de entidade-relacionamento documenta a estrutura de um universo de discurso por meio de tipos de entidade (isto ¢, classes de entidades tuniformes) e relacionamentos (isto é, classes de relacionamentos uniformes). Um modelo entidade-relacionamento & definido no nivel de madelagem e define 0 cconjunta de todas as instincias vidas no nivel de insténcia A cardinalidade de um relacionamento (bindrio) define © nimero de instincias de relacionamento das quais uma entidade pode fazer parte (Elsmari e Navathe 2006]. Se nenhume cardinalidade esti anotada para um tipo dc relacionamento especificn, assume-se que um nizmero arbitrario de entidades (em jutras palavras, no minimo zero entidades) poxiem participar de tal relacionamento, Usar eardinalidades para relacionamentos, portanto, limita 0 nimero de inst2ncias {que sto em principio possiveis em um diagrama entidade-relacionamento. Exemplo de um Diagrama Entidade-Rela ramento © modelo entidade-relacionamento spresentado na figura 6-7 mostra quatro tipos de entidades (isto é, classes de entidades) e trés tipos de relacionamento (isto &, classes de relacionamentos). Os tipos de entidade individuais possuem atributos * Rais prasisomen ts uma catade que & ura insténea do tp de enidad puto "ke Lac pcs ose “orm rca 20 valor des Me prosisumsa, sh ura en ‘alor de suibulo"OA S15" pare oat gue © ua insane do po de etd “v00" ee poset concretos Abstragio a partir de relacionamentas Propriedades de tipos de centidades e tipos de relacionamentos Nivel de modelagem ¢ nivel de instincia ‘Nimero de instincias 4 relacionam 0” © que poss uma eis otidde rica © 0102 Documentar Requisitos usando Modelos que descrevem propriedades espe lipo de entidade "informagbes ‘nsito” possui 0s tributes "via", "inicio" e "exiensio", que indicam, respectivamente, a via na qual no momento hé um congestionamento, as coordenadas GPS do ponto inicial do ccongestionamento ¢ a extensio do congestionamento, Q tipo de relacionamento consulta” entre 0s tipos de entidade "dispositive de navegacio" e "informagses sobre congestionamento de transito” significa que no nivel de instincfa existe um relacionamento entre um dispositive de navegaeo concreto e a informagio sobre zero ou mais congestionamentos concretos, As cardinalidade dos tipos de entidades em relagio ao tipo de relacionai onsulta" significam que um dispositive de navegagio concreta pode consaltar informacies sobre um nimero arbittério ("N" estionamentos de transito. Ne diregio inversa, qualquer informagio sobre ds por um niimera arbitririo ("MI") das, Par exemplo, 0 bre congestionamemo Figura 6-7 Diagrama entidade-relacionamento(modelo de ddos) conforme Chen 6.5.2 Diagramas de Classes UML Diagramas de classes UML também podem ser utilizados para modelar a iva estrutural dos requisitos de um sistema a ser desenvolvide. Um diagrama de classes consiste em um conjunto de classes © associagdes entre classes. Classes ¢ ascociagses em diagramas de classes UML 40 semelhantes a tipos de entidades © tipos de relacionamenios nos diagramas entidade- relacionamento. Modelos de classes possuem elementos adicionais de mode (por exemplo, elementes que permitem a especificasio de operagies vilidas nas instancias de uma classe) tém, portanto, maior poder de ‘Umm visio gor dos fronts clmemtos de Perspectiva sstatiea: Dados Estrutura Jagsm UML pode se enconirda, por explo, em [OMG 2007].Elementos de modelagem [Nome] |) at MGmeiS fabutoc] Astodiaglo Agregneto | fod mel Clesses —Ganeraizago Compose” wyppiioaee Exemplos de modelagem 1 cuciaades possi On pr proprietario fabricacéo carro} [ Caminhae de carga | vassentos a 6-8 apresenta importantes UML, bem como diversos exemplos de mod Uma elasse & ntada por um retingulo separado em (também, fe compartimentos). A se¢lo superior apresenta atributos inferiores,, instineia da classe. Na escritos em maiores detalhes pe encontram-se fisiadas tod mn ser cxecutadas com as ‘nstincias da classe, Dependendo gem, isto &, dopendendo da jnalidade do modelo, os compartimentos para ou métoos tambe podem ser ocultados ou exeluidos completamente Associagées entre classes sio representadas por linhas. AssociagSes podem opcionalniente receber nomes. Além disso, multplicidades podem ser ada ponta de uma associagtio. Mul instancias de uma cl aivel de ins 54 Classes Associagdes, ades multiDocumentar Requisitos usando Modelos podem ser associadas de uma mancira especifica com um nimero definide Instancias de outra Ao anotar papéis opeionais em uma das pontas de uma associagdo, ou em ambus, o significado das instincias de uma classe em relagao & associagao pode ser refinado adicionalmen AgregacBes e composicdes so tipos especificas de associagdes. Ambos fem um relacionamento entre um todo e suas partes constituintes. Uma composicdo documents uma associagao mais forte do que uma agresagto, poi lima parte constituinte de uma composiego no pode existir sem o todo. Em sses UML, uma agregacto & representada como um losango vazio, 6 representada por um losango preenchido, Além disso, generalizagées entre classes podem set documentadas em nas de classes. Uma generalizacao entre classes UML ¢ um relacionamento uuma classe mais especifica (2 subclasse) ¢ uma classe mais geral (a superclasse). A subelasse em um relacionamento de generalizago herda toda propriedades da superclasse, podendo adapiar eYou aumentar essas propriedades, Exemplo de um © diagrama de classes na figura 6-9 abrange seis classes, todas com Tespectivos atributos. AS associacdes entre as classes $20 representadas por lin Por exemplo, existe uma associagao com o nome “calcula” entre a classe "dispositivo de navegagio” e a classe "rota". Considerando as multiplicidades associagdo indica que um sistema de navegagso pode calcular um nimero arbitrario de rotas (no minimo zero, como indicado por um asterisco *), contrapartida, cada rota pode ser calculada por um nlimero arbitririo (*) de dispositives de navegaeao. Uma rota é uma agregagao de no minimo um, mas arbitratiamente muitos (1...) segmentos de vias, @ cada segmento de via pertence a tum nGimero arbitririo (*) de rox wento de via é definido por umn nome de via e por pontos iniciais ¢ finais. A figura 6-9 também mostra que "dispositive de navegacto com fungdo evitar voy wentos” & uma especializagio da classe geral "dispositive de navegagio" belasse “dispositiva de navegagae com finedo evitar congestionamentos" herda ax propriedades (neste caso, 0 aitibuto "identificaedo") de sua superclasse “dispositive de navegacio” e ‘sumenta o cconjunto de atributos com um atributo que especifiea um Timite determinado para a ssko do congestionamento (limiar de congestionamento), 0 qual, uma vez ultrapassado, desencadeia um recalculo da rota composigae GeneralizagioDocumentar Requisitos usando Modetos 05 in roaovia Figura 6-9 Diagrama de classes em notagdo UMLIP Simtae ( 06 ocumentar Requisitos usando Modelos 6.6 Modelagem de Requisitos na Perspectiva Funcional A perspectiva funcional de requisites esti veltada pars @ transformacio clonal de req a vol da liberal o ambi de entrada recebidos do ambiente em dados d ontes baseadas em mod a, Existem vitias abord: ut para modelar a perspectiva fun teenies nas abordagens de andlise estruturad 5 dos anos 70.0 80, tnis como a andlise estruturada [DeMarco 1978, Weinberg 1978] ou a anzlise cial de sistemas [McMenamin ¢ Palmer 1988] 6.6.1 Diagramas de Fluxo de Dados No centro das atengdes da model itos enoontsam-se diagramas que le do respective sistema po meio de processos (fungdes), repasitirios de dads, fontes (sources) © destines wxos de dados. Unt tipo de modelo s) ne ambiente do 5) funcional de uso comuum sto os diagramas de fluxos de da struturada [DeMarco 1978). Modelos d sm do sisterna em dl forme propostos permitem a mod nas de Fluxo de Dados atos de Modelagem nos Diagr: smas de apresenta os elementos de modclagem enconirados em di por [DeMarco 1978 fluxo de dados, na notaco proj Deposito Entdades externas Process ds datos (fontes/destinos) Fluxo de dadas elementos de modelagem pars diagramas de fluxo de 2 G10 Important dados, conforme DeMarcoProcessos tepresentain as fungdes ne fransformar os dadas que flue para processo absorve os dados de entrada, proces forma de dados de saida, De que maneira (isto & co transformados ndo esti representado nos diagramas de fluxo de d 10) os dades so Repositérios, ow depéstios de dads 0 conceitos abstrates. projetades pare represeniar dados persistentes. Processos podem acessar dados em um depésito de dados no modo leitura ou escrita, Dessa forma, os processos podem tanto obter acesso a dados necessérios de entrada quanto amazenar de forma pem dados de saida Fontesidestinos descrevem objetos (como pessoas, grupos de pessoas, departamentes, organizagées ou sistemas) no ambiente do sistema que trocam dados com o sistema, Fontesidestinos so aspectos do ambiente do sistema ¢ n30 podem ser alterados durante @ desenvolvimento do sistema (ver Seg30 2.1). Fonte so aspecios co ambiente do sistema que fornecem dados ao sistema, #0 passo que destinos recebem dados do sistema. Um fluo de dados descreve dados que slo transportados entre processos, depositos de dados e fontes/destinos [Yourdon 1989]. Nos modelos de requisitos, uum fluxo de dados pode maclelar © transporte de objetos matctiais e imaterias, isto 6, fluxo de dados ou fluxo de material. Tipicamente, apenas os fluxas de dados mais importantes so modelados em diagramas de fluxo de dados. Fluxos de dados fnrelevantes para os requisitos do sistema podem ser ignorados. Exemplo de um Diagrama de Flux de Dados A figura 6-11 apresenta um dingrama simplifieado de fluxo de dados sistema de navegagio, usando a notagdo propesta por DeMarco, As interfaces do sistema para o contexta so definidas pelos fluxos de dados para as font a de satglite GPS" e "servidor de informagdes de teansito", bem como para o destino ‘condutor" ‘sist A funcionalidade do sistema de naw distintos. O processo 1, denominad “ealcular rota", recebe informagGes de trinsito atualizadas por meio de sua interface com a fonte "Servidor de informacses de tuansito", bem como dados sobre a locafizagio ataal do veiculo através de sua face com a fonte "sistema de satélite GPS", Além disso, 0 processo "calcular reeche do condutor do veiculo o destino desejado, A rota calculads & ayo € dividida em t1€s processos * Ns anise eruurade, faxed dads, mformages, documentos ov atria so eonsiderados um Manipuagao de dados Dados persistontes Objetos no do ambien sistema Fhuxo de dados Interfaces do Prosesso "ealeular rotaYALEES 1° Biman Domeins Coste ek 108 squisitos usando Modelos mazenada no deposito de dados "dads da rota” co deposito de Processo O pro ‘determinar o proximo ponto de rota", aces dados para dele extrair dados relacionados com a rota atwal. Q proceso determina "determinar ‘o proximo panto de rota ¢ gera essa informagio. novo ponto de raga uma nova rola para o destino. Para Processo fonte "servidor de "recaleular rota” tal, 0 infer: rota recalcul de trdnsito” e, eventualmente, informacdes sobre a posigo atual. A da § armazenada no depésito de dados "dados da rota" X82 eusca otoriste —S , ee —\ *e \ } Figura 6-11. Diagrama de fluxo de dados, na notasio proposta por Del 6.6.2 Modelos da Perspectiva Funcional e Fluxos de Controle Em diagramas de flaxo de dados niio ¢ possivel visualizar quais condigSes devencadeiam quais processos. Os diagramas apenas apresentam as dependéncias de dados dos processos em um sistema ¢ documentam os dados de entrada ins, bem como os dados de saida gerados. Abordagens utilizadas na anélise retanto, muitas vezes of crigées adicionais de xo de controle. [sso pode ser alcancado seja pelo uso de como mini-especificagdes na analise as de linguagem des modelos de bilitam a modelagem de aspectos ngBes, como cm SA/RT [Ward estruturada de sistemas, ‘comportamento © di mas especificas de documen ururad, fluxo de dados. Extensdes de dicionais, por exemplo, 0 Muxo dé ¢ Mellor 1985, Hatley e Pirbhai 1988)ane umentar Requisitos usando Modelos 6.6.3 Diagramas de Atividades UML Diagramas de atividades UML sto aptopriados para modelar sequi [OMG 2007}. Aléin desses diagramas, podem ser utlizadas cadei deierminados por eventos (EPC, na sigla em inglés, ou even hains) para modelar sequéncias de atividades [Keller et al. 1992} no desenvolvimento de sistemas de informagio. Diagramas de atividades UML 1x0 de controle entre atividades ou ages, No caso de um: representam 0 progress sequencial de ages, uma ago subsequente & executada depois que cada ago precedente termina, A figura 6-12 apresenta impor mentos dk modelagem dos diagramas de stividades UML [OMG 200" [trim Je aeaaitvoae Decisa0 Barra de sincronizacio OP woceince © vecetemme ee Fork ——— at sin 16 da decisée i (cordigie) co ee Ihroranene —— £ Merge decontrale 2) | mel | Nome) | fixe de obyeto ae nuxe altemnve ro} Figura 6-12 Elementos de modelagem em diagraimas de atividades UM! Dingramas de ativida Sho grificos de fluxo de control atividade e do fluxa de controle entre esses nes (isto é, as setas no arética de fluxo c controle representando tansigbes). Nés de atividade exeeutam uma acto, OS nos de inicio e de fim nos diagramas de atividades tém uma seméintica definida. O no de inicio representa wn evento que inicia a execusdo do diagrama de atividades. (Os nds de fim 20 nés especiais que representam o firn do diagrama de ativida de fuxos de controle em dia atividades pode ser obtida at de nés de decisio, Nesses nos dé > sdo anotadas as condigses que desencadeiam fiuxos alternativos de controle ras de sineronizagio permitem a execugio concorrente de Muss de ipo especial de fluxos de controle sto os fluxos de objetos. Atmvés do uso de linhas divisorias de (swimlanes), diferentes atividades podem ser documentadas come respon bilidades de atores espevitices. Nos de anDocamentar Requisitos usando Modelos Modclagem de Sequéncia usando Diagramas de Atividades UML © diagrama de atividades na Ggura 6-13 documenta o processo "navegar para destino”. Dados de entrada e saida podem ser documentados através agem de flusos de objetos adicionais ao longo das linhas. Os fuxos de dados e ¢ io tipos especiais de fluxos de controle do diagrama de atividades, Cada ag executada se, e somente se, determinadas ages prévias foram exccutadas ¢ todos fos fluxos de entrada de objetos estiverem disponiveis, O diagrama de ago na figura G-13 também epresenta fluxos de objetes que sio documentades além das 180s ¢ dos Fluxos de controle, ® wra 6-13 Diagrama de atividades em notagdo UML © diagrama de atividades acima documenta a sequéncia de agBes necessérias para que um dispositive de navegacio calcule uma rata. © modelo documenta que inicialmente o destino desejado & solicitado e a localizagto atual do veiculo & determinada, Essas das agbes ocorrem simultaneamente, independentes uma da ‘uta, © destino informado ({luxo de objeto: objeto > destinacao: estado inserir) € a localizagio determinada (lluxo de objeto: objeto > localizacéo, estado > determinada) so transmitidos. ‘© condutor tenha selecionado a oppo de evitar congestionamentos de tAnsito automaticamente, 0 sistema bu informagaes atualizadas de trinsito. Uma vez recebidas as informages atualizadasDocumentar Requisites usando Modelo de transite, ou caso o condutor nao tenha selecionado a opgio de evitar congestionamentos de transito automaticamente, o sistema ealeula uma rota até 0 destino, A rota calculada € transmitida para o condutor, Di Ge exceetio. Nés de decisao representam ramifi ccenitio principal e os cenéios alternatives ¢ d ws de atividades so apropriaclos para documentar os altemativos e es no fluxo de coatrele entre 0 8 condigies de exeeugho de cendrios princi Fluxo de Controle de Cenarios Principais ¢ Alternati © diagrama de atividades na figura 6-14 apresenta o fluxo de controle do cendric Principal e altemativo do caso de uso a destino” documentado na figura 6-2. Ramificagdes alternativas de fluxo de controle eomecam nos és de decisio que documentam os cendrios respectivamente allematives e de exeegio de ‘um cendrio principal esp © diagrama de atividades indica que inicialmente a agao "comecar 10” & executada, Depois disso, as agdes "inserit destino” e “determiner as coordenadas GP'S" sto execuladas sinmultaneamente ¢ de forma independente entre si. Uma ve7 executadas as dus apes, o sistema pergunta se o condutor deseja que a rota seja calculada dinamicamente (ago "perguntar se dessja calcular a rota dinamicamente"), Se condutor no solicitar que a rota seja calculada dinamicamente (selegio "no evitar congestionamentos de trnsito"), nenhuma a sera tomada (ver tabela 6-1 > cenario principal). Se 0 condutar © cileulo dinmico de roia (sclesa0 "evitar congestionamentos") wibagdes atualizadas de tansito sero determinadas (agio "consultar informagies de trinsito", ver tabela 6-1 cenario ulternativos). Depois disso, rota ¢ valeulads (ago "eéleuto da rota") ¢ informada ao condutor (agdo "informar rola"), Soquéncias de gem de tum caso de uso Cenatio principal ¢ ativeComeumacsotl 4 85 Documentar Requisites usando Modelos navegagéo ~ rada destino Determine 2s coordanadas GPS Pergunte se deseja o calcula da rota dinamicamente {evitarcongestonamento] {consuitar informagio de tréfego Calcule 2 rote CO) [ornece rota Figura 6-14 Documentagto do fluxo de controle de cenéries usando diagramas de atividades UMLDocumentar Requisitos usando Modelos 6.7 Modelagem de Requisitos na Perspectiva Comportamental rdagens de modelagem bascadas na teoria dos autdmatos. A definigho de um maqui finitos eng! conjunto de estados e um conjunte de Gependendo do estado atual da maquina, so executadas a partir de No Ambito da modelagem de sistema, utilizam-se com frequéncia extensdes de miquinas de estacos finitos baseadas nos conceites das chamadas respectivamente, Nas méquinas de joore [Moore 1956 os dados de saida dependem do estado sual da miquina e dos dadas de entrada, Em eontraste, nasmaquinas de Moore, 05 dads de 6.7.1 Statecharts tais como a falta de apoio para abstragao), cito de autématos tornou-se um: tecnica para modclar 0 comporiamento reativo de um sistema, Uma técnica amplamente utilizada para mmportamento de um sistema € 0 uso de statecharts (Harel 1987]. Starechavts sto usm tipo de auttimatos baseados em maquinas de estadas finitos, mas que io estendidos para suportar a hierarquizagao dos com a finalidade de documen ‘comportamentos concort es de estados de transicao 5 apresetta 0s rel [Harel 1987} mentos de ais care Figura 6-15 Flementos de modlelagem em statecharts Um estado define um momento no qual o sistema apresenta um comportamente to ocorrer para eno executar uma transigfio Maguinas de estados finitas Miiquinas Mealy ¢ Moore Magus i stados bierarquizagio + Estado#6 iP Siée Dnwelag Compatact00 A ng Documentar Reguisitos usando Medclos Uma transigio & desencadeada por um evento especifice gue ocorre em um determinado estado, Uma transigao descreve a mudanga de um estado para 0 ados pode adicionalmente depender de especificas se o sistema se proximo. A mudanga de condigao, O sistema pode executar atividade: fem determinado estado (camportamento tipico de maquinas de Moers) ou s° 0 1 tansigio para outro estado (comportamento tipico de maquinas de Mealy), Pssas atividades podem ser direcionadas para 0 proprio na ov para 0 ambiente do sistema sistema executa u Statecharts permitem a decomposigao hierirguica (ou refinamento hierdrquica) de fesiados, que por Sua vez representa autGmatos. O estado inici a Genominagto superestado, sendo definide por diversos estados decompostos. A. hierarquizagdo permite abstrair detalhes inrelevantes de um estado considerando elou modelande — dependendo da finalidade do modelo ~ apenas 0 superestado, © doo subautémato completo que define 0 superestado, O comportamento detalhado do sistema pode, caso necessario, ser decomposto (refinado) pela definicao dos respectivos autGmatos parcia ‘Além da decomposigio hierirquica de um estado em autématos detathadas, um estado pode ser decomposto em virios autématos concorrentes. Os utématos concorrentes podem ser sincronizados através de condigdes de transigo (por exemplo, "estando 0 autémato A no estado 4"), A figura 6-16 apresents um modelo comportamental de um dispositive de nevegagio veicular através de am statechart. O dispositiva de navegaglo encontra-se inicialmente "0 est dispositive de navegagio inativo" Se navagarso 3 aig pispesitiv denavegacto ative @ | Figura 6-16 Starechart simplificado de um dispositive de navegacde veicular Ao ligat dispositive de navegagto (evento “dispositivo de navegagao ativado"), © sistema transita para o superestado "dispositive de navegagto ativo" (mais precisamente, o sistema transita para estado inicial "sem sinal do GPS" do Superestado “dispositive de navegagio ativo"). O superestado “dispositive de finada por un auiémato parcial que consiste em dois estados. seebido no estado "dispositive 4 Por exemplo, se tm sinal de GPS atividade Hierarquizagao ce abstraga0 Concorréncia “Transi¢ao para superestadoDocumentar Requisitos usando Model ativo: sem sinal do GPS", o sistema transita para o estado "dispositive de dio ativo: sinal do GPS" e emite um aviso. Se o dispositive ¢ desativado do. “dispositive de navegacio ative” ( fo"). 0 sistema. tran: sitivo de navegacdo dest 6.7.2 Diagramas de Estados UML Para modelar © comportamento reativo de sistemas, a Unified Modeling Languagi UML) (OMG 2007] iquinas. de bbascadas em starecharis. A figura 6-17 apresenta os mais importantes elementos de modelagem para dis ados UML. A notaga0 dos elementos de model diagramas de estados UML foi em grande parte adaptada a partir dos statec UML 2, no entanto, 0s elementos de modelagem dos stafecharis possibilidade, por exemplo, de definir pontos explicitos de entrada ¢ saida de siados hieritquicos [OMG 2007 seroma an ° parle todo nicl ao tol Trnsieio = ene maquina Gb eeioeoncatentes poniodeeiuade PoNaUEalia Heraulzecio Figura 6-17 Ele entos de madelagem UML 2 para miquinas de estados Da mesma forma como nos starecharts, um estado define um periodo durante 0 3 esperando que um qual um sistem apresenta um comportamento esp determinado to ocorra, Uma transigio € de: corre em um estado especifico © descreve a préxima. Uma igo pode ser dependente de uma condigso. Além disso, 0 idas ao préprio sistema ou a seu ambiente Dependendo da finalidade do modelo, maquinas de estados permitem a ccombinagao hierirgica de estados cm superestados, dessa forma abstraindo os Alem di comportamentos potencialmente muito complexos desses Modelagem de comportamento reativo de ura UML Estados ¢ Hierarquizacéoquisitos usando Modelos decomposigg0 hierira) s em autdmatos parciais, um estado pode ecomposto em varias ™m fe. Assim como em statecharts, a sineronizaglo entre maqu ncorrentes pode obtida através de condigdes. A UML 2 define pontos de enirada ¢ de saiéa (Enry’ P como uma extensto dos si permitem uma hierarquiza Fsisonal de iados. Um ponto de entrada ¢ um pscudoestado externamente visivel imediatamente associado a um estado interno. Um ponto de safda é um pseudoesiado extermamente do como origem um estado intemo. Um superestado dentro d= ama maquina de estados pode ter um mimero arbitrario de de entrada e de saida, 9 Je dentificades por um nome ura 6-18 apresenta um diagrama de estados UML possuindo dois ritos de entrada explicitamente espocificadas ("inserir novo destino” e "altimo destino") ¢ um ponte de saida ("navegaedo coneluida’) elem dos clementos de rmodielagem apresentados na segio 6.7.1 secconodo , nosuestno! —— sucesso ns Eno Figura 6-18 Diagrama de estados na notagio UM! ‘© comportamento reativo de um dispositive de sistema encontni-se no estado ispesitivo pronto para uso". Ao selecionas "naveger par." o sistema muda para a superestado "navegagio ative" e, dentro do superestado, para o subestado "snseri dados de destino” através do posto de entrada “inserir novo destino" ‘Alternativamente, o sistema passa do estado “dispositive pronto para uso” para o ‘stado interno "ediculo da rota” do superestado “navegagao ativa" através do ponte Ge entrada “iltimo destino” assim que oeorrer o evento "naveger par dlkimo esting”. Apds 0 estado "navegagio ativa: inserir dados de destino", o sistema transite para o estado "navegaciio ativa; cSlculo de rota", desde que os dados de destino sejam vilidos. Depois de caleulada a rola no estade "navegagiio ativa: caleular a rota”, © Encapstlamento de extadosDocumentar Requisitos usando Modelos venelo ativa: informar rota", Se um des da rote calculada") no estada "navegagio ativa’ 0 (evento: “des céleulo de rota", o condutor ¢ notificado (atividade: "ni sistema transita do estado "navegacdo ativa” para o estado "dispositive pronto para nio "eancelar”. Se o sistema esta a rota” e 0 destino aleangado, o sistema sai do super 120 ativa” pelo ponio a ‘dispositive pronto para uso 6.8 Resumo Além da Jinguas ocumentades por meio d ‘modelos. Requisitos em linguagem natural e mode equisites S20 tipieamente empregados em conjunto, 0 que permite explorar as vant documenta -m natural, requisitos podem ser las duas formas de isitos com ba a, en deserieses graf podem ser mais répida e melhor do que descrigges em Finguagem te usados na engenharia forma de compreendidas de mane: natural. Entre os modelos frequen contram-se os mode! casos rds perspectivas: estrutural, fu tes per nal e comportamental, Para c wens de modelagem conceit ida uma dessas aproprindas, dotadas de meios especificos para documentar as informagées apr conform a finalidade de cada uma, respectivamente.Validar © avordar requisitos d assegurar que os requisites documentados pr determinades, como exatidao principios apresentados podem ser utilizados p: sompletos de requisites. individiais ou dacumen’ 7.1 Fundamentos da Validagiio de Requisitos Durante a engenbaria de requisites necessério revisar a qualidade dos requ desenvolvides, Entre outros. obj stakeholders com 0 propésito de identificar desvios entr cs desejos ¢ necessidades reais dos stakelroders. ivOs, 05 requisilos So apresentados aos requisites definidos ¢ Dura nivel nevessario de qualidade (ver capitulo 4) alidagdo dos requisites, a decisto se um comaula, € se 0S requisites podem ser aprovados para uso nas demais ativ projeto, implementagdo ¢ teste). Essa di cexitérios de aceita ser tomada com ba 0 previamente detinides, ivo da validagie de requisites é descobrir erros ni documentadas. Exemptos tipicos de erros em requisites sio ambiguidade, ude e contradicaes (ver segt0 7.3). requisi incom! sto documentos de wolvimento Conseques Documentos de requis demais atividades ded ia para todas as afetam desenvolvimento, Um erro de negativamente todas as atividades posteriores di requisito descoberto quando o sistema j& esté implementado e operando exige a 0s afetados pelo erro, tais como codigo fonte, artefatos de revisio de todos os art tee deseriges de arquitetura, Portanto, a carreeao de exros nos requisites quando 10 impliea custos signifi ‘ sistema jf esti em opera Um contrato entre eliente & documentas de requisites, Erros criticos om requisites podem cumprimento de acordos contratuais, como par exemplo, o escopo de suprimento & perada ou os prazas de conclusio, contratado baseia-se frequentemente em servigas, a qualidade 1g Requisitos ever sei Objetivo da validacao Proliferagao de Riscos legais7 tempers uisitos 7.2. Fundamentos da Negociacao de Requisitos Se no houver conser a respeito dos roquisitos, € se ‘consequentemente os requisitos no puderem ser implementados cofetivamente no sistema, cria-se um conflito no somente entre os requisitos contraditérios, mas tambem entre os stakeholders que exigem requisitos contraditéries. Por exemple, lum stakeholder poderia cxigir o desligamento do sistema em caso de fala enguanta ouiro stakeholder poderia exigir @reinicializagao do sistema, A accitagto do sistema & ameagada por conflitos nto resolvidos, ps conflitos fazem com que 0s requisitas de pelo menos uin grupo de stakeholders i possam ser implementados. No pior cenario, um conflito pode causar a retiadn de apoio por parte do stakeholder, levando a0 fracasso do proj jesenvolvimento (ver (Easterbrook 1994)), Além de representar riscos, contlitos podem també servit de oportunidade para a engenharia de re conflitos entre cholders exigem «ma solugio que tem o potencial de ajudar a revelar novas Se apres into (ver [Gause & ‘Weinberg 1989). Portanto, lidar abertan ¢ procurar resolvé-lo ors enharia de requisites pode au O objetivo da r 10 chegar a uma compreensio comum e acordada dos requisitos do sistema a ser desenvolvide entre todos 0s stakeholders. A validagio e negociayio de requisites é uma atividade a ser realizada (em mus variados de intensidade) 20 lougo de todo 0 processo de engenharia de Toquisitos, Portanto, a validacao © negociagdo de requis fe, consequentemente, enstos adicionais, Entretanto, as. vanta validaglo e negociacao de requisitos conforme deseritas acima (redugao do custo lobal, aumento de aeeitagdo, estimulo para solugbes critivas ¢ inovaydes) so em geral significativamente maiores do que os eustos gerados pelo esforgo adicional 7.3 Aspectos de Qualidade dos Requisitos Uma das principais metas da uilizagtio de critérios de qualidade (como por exemplo, completude, inteligibilidade, acordo) na validag3o de requisitos © 8 possibilidade da (0 sistemsitica de requisites (ver seygo 1.1.2). Para ssegrirar uma validagiio objetiva e consisiente € necessirio que cada critério de {qualidade soja substanciado © detalhado. Em conformidade com 0s objetivos slobais do processo de engenharia de requisitos, a validagao € realizada com os Regquisites contraditérios conflitos Riscos e ‘oportunidades dos contflitos posteriores121 icitados © docemen nivel apropriado de detalhamento? © Documentacdo: Todos 0s requisites foram documentedos em a conformidade com as documentagio e capecificacio . previamente determinadas , 1 Acordo: Todos s concordam com os _requisitas ocumentades eto conhecidos foram n q Cada um dos ts objetivos imp que enfoca aspectos Tres aspectos especificos de qualidade dos requisites. Os seguintes aspecios de qualidade foram . portanto definid 1 Aspecto de qualidade Aspecto de qualidade 1 Aspecto de qualidade "a {Um requisito deve ser aprovado para as atividades posteriores de desenvolvimento _ apenas se todos os trés aspectos de qualidade tiverem sido verificados. C ee de qualidade serdo descritos em dotalhe nas, sguntes ¢ substanciados com P diversos crtérios de qualidade para aumentar a sutleza de sua diferenciagao (sem . que a descrigie, no eulanto, tenha a pretensdo de ser completa, s : ; 7.3.1 Aspecto de Qualidade "Conteado" idade "conteiido" refere-se & verificagdo de err Tequisitos. Eros de conteuda em requisitos influenciam atividades subsequentes de desenvolvis sejam bascadas em informagdes que apresemiam falhas, O aspecte de g Critérios de entas de requisites (ver teste do Enos de contedde em requisites ocor qualidade para requis seeao 4.5) so violados, A validacto de requisitos com respeito ao aspecto de aspecto de qualidade "conteido” seré considerada bs sequintestipos de erros sem que falhas significativas tenham sido detectadas: m quando critérios espe: 8 (ver segiio 4,6) ou para doc nrsucedida uma yee aplicada

Você também pode gostar

• Requisitos Não Funcionais

  

  Documento20 páginas

  Requisitos Não Funcionais

  pccresende

  100% (9)
• Diagrama de Classe

  

  Documento23 páginas

  Diagrama de Classe

  Lukassu

  Ainda não há avaliações
• Análise e Modelagem de Processos de Negócio

  

  Documento2 páginas

  Análise e Modelagem de Processos de Negócio

  Paola Esteves

  0% (4)
• • Revistas
  • Podcasts
  • Partituras
• C J Date Introducao A Sistema de Banco de Dados PDF

  

  Documento1 página

  C J Date Introducao A Sistema de Banco de Dados PDF

  Eduardo Sanchez

  60% (5)
• Modelo para Documento de Requisitos

  

  Documento7 páginas

  Modelo para Documento de Requisitos

  Valquíria

  Ainda não há avaliações
• Access Livraria Projeto Completo PDF

  

  Documento19 páginas

  Access Livraria Projeto Completo PDF

  Fabiano Souza

  Ainda não há avaliações
• Banco Dados I

  

  Documento254 páginas

  Banco Dados I

  Luiz Henrique Queriquelli

  Ainda não há avaliações
• Algoritmos Lógica para Desenvolvimento de Programação de Computadores PDF

  

  Documento5 páginas

  Algoritmos Lógica para Desenvolvimento de Programação de Computadores PDF

  Ronaldo De Almeida Batista

  Ainda não há avaliações
• Livro Banco de Dados Mysql

  

  Documento89 páginas

  Livro Banco de Dados Mysql

  MatheuZ

  Ainda não há avaliações
• Modelagem de Dados, Peter Chen

  

  Documento80 páginas

  Modelagem de Dados, Peter Chen

  Leandro Lima

  100% (2)
• LIVRO - O Que É Comunicação Empresarial - Paulo Nassar

  

  Documento45 páginas

  LIVRO - O Que É Comunicação Empresarial - Paulo Nassar

  Lucio Fleck

  75% (4)
• Capítulo 1 - Princípio de Sistema de Informação - Ralph M. Stair

  

  Documento49 páginas

  Capítulo 1 - Princípio de Sistema de Informação - Ralph M. Stair

  Talita Oliveira

  100% (8)
• Informática Aplicada À Gestão

  

  Documento164 páginas

  Informática Aplicada À Gestão

  Gêmison Amaral

  100% (2)
• Bem-Vindo Ao COSO

  

  Documento12 páginas

  Bem-Vindo Ao COSO

  CiceroTasaca

  Ainda não há avaliações
• Criando Uma Calculadora Com NetBeans

  

  Documento5 páginas

  Criando Uma Calculadora Com NetBeans

  isaaccesar3251

  Ainda não há avaliações
• Engenharia de Requisitos

  

  Documento23 páginas

  Engenharia de Requisitos

  renan_ogliari1173

  50% (2)
• CMMI em Português

  

  Documento591 páginas

  CMMI em Português

  Marceloakio

  100% (4)
• Levantamento de Requisitos - Sistema de E-Commerce

  

  Documento26 páginas

  Levantamento de Requisitos - Sistema de E-Commerce

  Luis Padua

  40% (5)
• 02 - Técnicas e Ferramentas Da Engenharia de Requisitosdjjdjdjd

  

  Documento26 páginas

  02 - Técnicas e Ferramentas Da Engenharia de Requisitosdjjdjdjd

  douglas777

  0% (1)
• Exercicios Casos de Uso (Gabarito)

  

  Documento15 páginas

  Exercicios Casos de Uso (Gabarito)

  Daniel Martins

  50% (2)
• Reading On Info Tech - Inglês para Informática

  

  Documento88 páginas

  Reading On Info Tech - Inglês para Informática

  Leonardo Rocha

  100% (2)
• Lógica de Programação E Algoritmos Com Javascript: Uma Introdução À Programação de Computadores Com Exemplos E Exercícios para Iniciantes

  

  Documento1 página

  Lógica de Programação E Algoritmos Com Javascript: Uma Introdução À Programação de Computadores Com Exemplos E Exercícios para Iniciantes

  DenisDSilveira

  100% (1)
• Apostila - Módulo 2 - API

  

  Documento55 páginas

  Apostila - Módulo 2 - API

  pierryangelo6944

  100% (1)
• Analise de Pontos de Funcao - M - Renato Machado Albert

  

  Documento408 páginas

  Analise de Pontos de Funcao - M - Renato Machado Albert

  dsisconeto

  100% (3)
• Treinamento Pentaho Data Integration

  

  Documento32 páginas

  Treinamento Pentaho Data Integration

  markevis

  Ainda não há avaliações
• Engenharia de Requisitos

  

  Documento15 páginas

  Engenharia de Requisitos

  seibrows

  Ainda não há avaliações
• Manual BizAgi 2.4 em Português

  

  Documento13 páginas

  Manual BizAgi 2.4 em Português

  marcos_rigotti

  100% (2)
• 2.23 - Exercício - Operadores Lógicos

  

  Documento3 páginas

  2.23 - Exercício - Operadores Lógicos

  João Ferreira

  100% (1)
• Apostila - SQL 2016 - Modulo III 1 PDF

  

  Documento680 páginas

  Apostila - SQL 2016 - Modulo III 1 PDF

  Jeova Leite

  100% (2)
• Fundamentos de Gerenciamento de Projetos

  

  Documento7 páginas

  Fundamentos de Gerenciamento de Projetos

  TARCÍSIO FERNANDES GOMES

  100% (1)
• Gestão de Riscos em Projetos

  

  Documento126 páginas

  Gestão de Riscos em Projetos

  Ronaldo Souza

  Ainda não há avaliações
• Diagramas de Componentes e Implantação

  

  Documento30 páginas

  Diagramas de Componentes e Implantação

  api-1752250

  0% (1)
• Aula 01 Tutorial Pdi

  

  Documento78 páginas

  Aula 01 Tutorial Pdi

  jarleynobrega

  Ainda não há avaliações
• Trabalho Individual de Negociação

  

  Documento9 páginas

  Trabalho Individual de Negociação

  Thiago Pereira

  100% (1)
• Mapa Das Regiões de Governo e Municípios Do Estado Do Rio de Janeiro - 2019 - CEPERJ

  

  Documento1 página

  Mapa Das Regiões de Governo e Municípios Do Estado Do Rio de Janeiro - 2019 - CEPERJ

  sergio tavares

  100% (1)
• Criando Aplicações Desktop em Java

  

  Documento15 páginas

  Criando Aplicações Desktop em Java

  Anderson Kerlly

  100% (1)
• FATEC - Apostila Completa Sobre Delphi

  

  Documento196 páginas

  FATEC - Apostila Completa Sobre Delphi

  rlginformatica8106

  100% (5)
• Analista de Negocio 2.0

  

  Documento133 páginas

  Analista de Negocio 2.0

  Rildo F Santos

  100% (2)
• Exercícios Resolvidos

  

  Documento21 páginas

  Exercícios Resolvidos

  Carlos

  83% (6)
• Apostila Engenharia de Software Profa. Dilça1

  

  Documento33 páginas

  Apostila Engenharia de Software Profa. Dilça1

  Jefferson Sousa

  100% (1)
• Analise e Projeto de Sistemas PDF

  

  Documento2 páginas

  Analise e Projeto de Sistemas PDF

  Fabiola Souza

  Ainda não há avaliações
• Engenharia de Software Na Prática

  

  Documento23 páginas

  Engenharia de Software Na Prática

  Eriton Santos

  Ainda não há avaliações
• Linguagem Java COMPLETA PDF

  

  Documento161 páginas

  Linguagem Java COMPLETA PDF

  natan

  100% (1)
• Data Science Finanças PDF

  

  Documento55 páginas

  Data Science Finanças PDF

  jamilfelippe

  Ainda não há avaliações
• NR 32 - Acid Trabalho Material Biologico

  

  Documento1 página

  NR 32 - Acid Trabalho Material Biologico

  CPSST

  Ainda não há avaliações
• Revista Pergunte e Responderemos - Ano XLVIII - No. 545 - Novembro de 2007

  

  Documento54 páginas

  Revista Pergunte e Responderemos - Ano XLVIII - No. 545 - Novembro de 2007

  Apostolado Veritatis Splendor

  100% (1)
• Resumo Sobre o Pais

  

  Documento1 página

  Resumo Sobre o Pais

  José Rafael

  Ainda não há avaliações
• Asturias, Patria Querida

  

  Documento1 página

  Asturias, Patria Querida

  Mai Ta

  Ainda não há avaliações
• Edital Nº 14 - Seleção de Estagiários Direito

  

  Documento2 páginas

  Edital Nº 14 - Seleção de Estagiários Direito

  Phillipe Nogueira

  Ainda não há avaliações
• Revista Pergunte e Responderemos - Ano XLIX - No. 555 - Setembro de 2008

  

  Documento66 páginas

  Revista Pergunte e Responderemos - Ano XLIX - No. 555 - Setembro de 2008

  Apostolado Veritatis Splendor

  100% (4)
• Paulo Lima Silva Psicanalise Dos Excessos

  

  Documento11 páginas

  Paulo Lima Silva Psicanalise Dos Excessos

  ZZZ

  Ainda não há avaliações
• Palavras para Iniciar Paragrafos No TCC Monografia Artigos

  

  Documento2 páginas

  Palavras para Iniciar Paragrafos No TCC Monografia Artigos

  AjbIng

  Ainda não há avaliações
• Viva La Vida Violines

  

  Documento4 páginas

  Viva La Vida Violines

  jorge

  100% (1)
• Exercícios de Arpejos - Violão

  

  Documento1 página

  Exercícios de Arpejos - Violão

  LEO

  0% (1)
• Britoo e Jacques, Cenografias e Corpografias Urbanas

  

  Documento8 páginas

  Britoo e Jacques, Cenografias e Corpografias Urbanas

  Lia

  Ainda não há avaliações
• Identificação de Bacilos Gram Negativos

  

  Documento6 páginas

  Identificação de Bacilos Gram Negativos

  Sabrina Rodrigues

  Ainda não há avaliações
• Audi A4 2.6 Abc 94-97 PDF

  

  Documento2 páginas

  Audi A4 2.6 Abc 94-97 PDF

  Jorge Daniel Diaz

  100% (1)
• Conversas Com Woody Allen I Pequenos Truques PDF

  

  Documento4 páginas

  Conversas Com Woody Allen I Pequenos Truques PDF

  Helder Daniel Badiani

  Ainda não há avaliações
• Mapa Anástacio-MS

  

  Documento1 página

  Mapa Anástacio-MS

  patriciomontagemagroindustrial

  Ainda não há avaliações
• Papel MM

  

  Documento2 páginas

  Papel MM

  hisede

  Ainda não há avaliações
• Raa3 Proposta

  

  Documento8 páginas

  Raa3 Proposta

  Weslei Costa

  Ainda não há avaliações
• Quadro de Processos PMBOK 5aed

  

  Documento1 página

  Quadro de Processos PMBOK 5aed

  Weslei Costa

  Ainda não há avaliações
• IREB CPRE FL PracticeExaminationQuestionnaire Set BR 2012-Public V1.4 Oficial

  

  Documento26 páginas

  IREB CPRE FL PracticeExaminationQuestionnaire Set BR 2012-Public V1.4 Oficial

  Weslei Costa

  Ainda não há avaliações
• Metodologia Otimizada de Gerenciamento de Projetosvconsultoria

  

  Documento11 páginas

  Metodologia Otimizada de Gerenciamento de Projetosvconsultoria

  Weslei Costa

  Ainda não há avaliações
• Diagr Classes

  

  Documento57 páginas

  Diagr Classes

  THAisELA

  Ainda não há avaliações
• Esparte3 PDF

  

  Documento42 páginas

  Esparte3 PDF

  Weslei Costa

  Ainda não há avaliações
• Seg Adm Redes

  

  Documento39 páginas

  Seg Adm Redes

  jhonga

  Ainda não há avaliações
• Bons Use Cases RSDC PDF

  

  Documento53 páginas

  Bons Use Cases RSDC PDF

  Weslei Costa

  Ainda não há avaliações
• 04 25 Silva PDF

  

  Documento24 páginas

  04 25 Silva PDF

  Weslei Costa

  Ainda não há avaliações
• 107 VF

  

  Documento11 páginas

  107 VF

  Graficayes Yag

  Ainda não há avaliações
• Sistem As

  

  Documento1 página

  Sistem As

  Weslei Costa

  Ainda não há avaliações