5. Tipos de Requisitos, Restricdes e Premissas “—Vocé me diria, por favor, qual caminho eu devo seguira partir daqui? — Isso depende bastante de para onde voce quer ir. — Eu nao me importo muito onde. — Endo ndo interessa qual caminho voeé vi." Lewis Carroll (Alice no Pais das Maravithas) “O mapa ito ¢ 0 terrtério.” Alfred Korzybski 0 objetivo deste capitulo ¢ apresentar uma estrutura de classificagao para os requi- sitos, explicando quais necessidades de informago caracterizam cada um desses tipos, sua finalidade e importancia, e contextualizando isso no dominio do problema € da solugdo. Além disso, também se explica o que sao restrigdes e premissas, a diferenga entre esses fundamentos para o conceito de requisito e como eles se rela- cionam ao trabalho do analista de requisitos. A Figura 5.1 ilustra essa estrutura de classifieagto de requisites. 5.1. Dominio do problema dominio do problema é onde surge o motivo para a mudanga facilitada pela Enge- nharia de Requisitos. £ a partir desse ponto que se deve buscar entendimento antes de desenvolver uma solugio, sob 0 risco de ter a solugdo perfeita para o problema cerrado, Ter informagdes sabre isso ¢ importante porque “deve-se conhecer a meta antes de conhecer o percurso” (Jean Paul Sartre)Tipos de Requisitos, RestricBes e Premissas 75 Dominio da Solugao Requisitos do Software requisitos funcionais quisitos nao funcionais rece requisites (ou necessidades) cde negécio — por que” Dominio do Problema Refinamento Nivel de Inforr Figura 5.1. Os diferentes tipos de requisitos abordados pela Engenharia de Requisitos. Para entender a importincia do dominio do problema, cabe uma pergunta impor- tante para toda a Engenharia de Requisitos: o que motiva uma organizagao a agir? dominio é uma érea em anilise, Ela corresponde as fronteiras de unidades orga- nizacionais ou mesmo organiza¢do como um todo; as partes interessadas chave © suas interagdes com 0s recursos compreendidos dentro das fronteiras. Se a pergunta fosse o que motiva uma pessoa a agir e estabelecer novos abjetivos, ‘ento uma resposta vilida seria medo e esperanga. Para as respostas, o imagindrio popular criou uma simbologia associada ao chicote ¢ & cenoura, ainda que no mundo atual entenca-se que isso no seja o suficiente (Figura 5.2).76 Engenharia de Requisitos Pea TeTT pennant Figura 5.2. A oportunidade ou 0 problema como motivacio (crédito: Shutterstock). Quando se coloca a mesma questo em uma perspectiva organizacional, deve-se antes definir onde as decisdes sobre os objetivos que uma organizagio persegue so tomadas. Esse espaco é 0 chamado dominio do problema. O dominio do problema compreende uma drea — ou mais —sujeita a analise. E compreendido por trés itens, como indicado na Figura 5.3. > Fronteiras que delimitam cada uma dessas areas. Sempre que se fala em ‘uma fronteira, costuma-se pensar em um territério com um governo que estabelece regras de convivio (leis) vilidas para aquele territério, No con- texto da Engenharia de Requisitos, esses territérios sio organizagées, como empresas e Orgios piiblicos. Eles também podem ser uma ou mais reas funcionais de uma organizago, por exemplo: coordenago de con- tratos, departamento de marketing, diretoria financeira, equipe de manu- tengo etc. > Por trds de qualquer gaverno sempre hi pessoas no comando. As partes interessadas chave sto os agentes responséveis por estabelecer e perseguir objetivos usando os recursos compreendidos nessas fronteiras. Exemplo: diretores, gestores, conselhos de administragdo, responsiveis técnicos et. > Por fim, as partes interessadas chave possuem autoridade e responsabili- dade que estabelecem como elas interagem com os recursos contidos nas fronteiras, como: decisdes, resolugdes, normas ¢ politicas.Tipos de Requisitos, RestrigOes e Premissas 77 de compreender res spin’ ‘ndica do Problema Figura 5.3. 0 dominio do problema em termos de seus elementos componentes. Enesse espaco que nascem os requisitos (ou necessidades) de negécio. 5.1.1. Qual é a sua importancia? 0 dominio do problema delimita o escopo inicial de uma solugio em termos de reas funcionais ou processos de negécios. E nele que esto as partes interessadas chave, que so o ponto de partida para toda a atividade da Engenharia de Requisitos. E nesse espago que se encontram as informagdes sobre as relagdes de autoridade & responsabilidade que devem orientar o analista de requisites a diferenciar o que é ‘uma opiniaio do que é um fato. 5.2. Requisitos (ou necessidades) de negécio Requisitos (ou necessidades) de negocio sto declaragdes de mais alto nivel de obje~ tivos, metas ou necessidades da arganizagio, Eles deserevem as razbes pelas quais ‘um projeto foi iniciado, as metas que 0 projeto deve atingir ¢ as métricas que seraio ‘utilizadas para aferir 0 seu sucesso, Requisitos de negécio descrevem necessidades dda organizagio como um todo ¢ ndo de grupos ou partes interessadas,78 Engenharia de Requisitos 5.2.1. 0 que sao? As necessidades do negécio s40 problemas a resolver — resultados de algum medo xno paralelo tragado com individuos — por exemplo, um concorrente passa a ofere- cer ao mercado um novo produto com potencial de reduzir a sua base de clientes, las também podem ser oportunidades a aproveitar —como a esperanca de alcangar algum beneficio — por exemplo, entrar em novo mercado até entdo nao explorado. Os exemplos citados sto bastante abrangentes, mas isso nilo precisa ser assim. Eles podem ser bem menos abrangentes, como um chefe de departamento que vé @ opor- tunidade de reduzir falhas na inspego por meio de um melhor acesso & atualizagao da documentagao dos procedimentos operacionais padrao. objetivo de resolver problemas ou aproveitar oportunidades é manter as condigdes atuais ow alteré-las para um novo cendrio em que se deseja operar. Um exemplo associado manutengio das condigdes atuais ¢ 0 esforgo com as adequagdes neces- sérias para se continuar operando em um determinado ambiente (“manutengdo da lideranca de mercado”), e um exemplo associado alteragao das condigies atuais € a iniciativa para oferecer um novo servigo. ‘As necessidades de negécio representam os objetivos que uma area busca alcan- gar. Sio as métricas que servirdo de base para avaliar o grau de sucesso ao final de iniciativas para o seu atendimento, Por exemplo, reduzir em $0% 0 custo atual do processo de arrecadagao de contas de energia elétrica da concessionéria do servigo, 5.2.2. Qual 6 a sua importancia? Com o conhecimento das necessidades de negocio, hid mais liberdade para imaginar possiveis solugdcs. E comum a solicitagdo da area de negécio chegar na forma de um pedido para colocar o que é feito atualmente em uma planitha eletronies em um sistema de informagao, Sem conhecer a motivacao por detris da planilha e do pedi- do, € possivel entregar 0 que foi pedido. Isso ndo tem o mesmo efeito de entregar 0 que é necessério. Conhecer de forma clara as necessidades de negécio fornece importantes referéncias sobre o valor para 0 negécio das solicitagdes recebidas e, com isso, € possivel mais facilmente estabelecer prioridades. Iniciativas mais longas podem envolver o esforgo de trabalho de muitas pessoas a0 longo de meses ou anos. Facilmente, cenarios assim so propicios a desvio dos objetivos estabelecidos. Ao interagir com os usuarios, eles vaio apresentando variasTipos de Requisitos, Restrigdes e Premissas 79 necessidades. $6 que 0 analsta de requisitos deve sempre buscar estabelecer ums Tigagto entre essas necessidades ¢ 0s requisitos de negécio, $e m8 ha essa ligaglo, significa que a necessidade est fora do escopo do projeto € nBo deve Ser atendida, pois todos os requsios da soluglo dever estar relacionados a0 menos © 18 dos pegusitos de neyécio do projet. Tal ligaglo, ou astro, ser tratada com mais énfase ‘0 apresentar o tema da rastreabilidade no Capitulo 9. Revsitar as necessidades de negécioe 08 objetivos associndos em marcos de valida go intermedifria permite avalia se o camino pereortido nko $= desviou do alvo & se ele representa a melhor soled. 5.2.3. Critérios de qualidade ‘As necessidades de negdcio esto em um alto nivel, no sentido de nao entrar nos detalhes sobre a solucdo. AS solicitagdes de negdcio com as intengdes iniciais costu- mam conter informagdes vagas € um tanto genéricas. ‘Ainda que elas se mantenham ain um alto nivel, em seu desenvolvimento final elas nao devem se manier VaghtS dover se tomar especificas o suiciente para nortear o desenvolvimento dos requi- Sites ¢ a sua posterior validagio. O objetivo deste tépico & apresentar critérios de qualidade que podem ser usados para ajudar nesse refinamento, Malcolm Forbes disse: "é to mais fil sugerir uma solugdo quando vors no sabe tlemais sobre o problema”, Sem conhecer de manciraespecifica os eritérios ae Pa” seta avaliaro sucesso da soluglo, muito maior & 0 universo de escalhas possivel ‘Contudo, seri que com isso a necessidade sera atendida? ‘Um exemplo de declaragdo genérica ¢ nebulosa de uma representacao preliminar ddas nocessidades de negécio & “aumentar a satisfaedo do cliente com o servis de atendimento”. Deve-se, portanto, estabelecer metas para o desenvolvimento das solicitagdes com as intengBes iniciais em informagdes que possam ser usadas a0 longo do projeto: sem que com isso se distancie das necessidades de negocio. se as necessidades de negécio representam objetivos a serem alcangados, entdio possivel usar © conhesimento desenvolvido na coneepeto da Administragao Por Dhjetivs (APO). Trata-se de um processo de entendimento dos objetivos de uma organizaglo, de maneira que « administraglo ¢ os funcionérios desempenhem as ores fungdes de acordo com os Objetivos tragados e que os compreendam |A,APO introduziu o método SMART para avaliara validade dos objetivos. Ele pode ser aplicado para avaliar se o estudo do dominio do problema ‘produziu representa-80 Engenharia de Requisitos Ges das necessidades de negécio que permitam 0 trabalho prosseguir em diregio aos requisitos da solucao, O método SMART tem 0 objetivo de avaliar a validade de objetivos, que devem, ser: ‘S—eSpeetfico: descreve algo que apresenta um resultado observavel. M—Mensuravel: sao resultados passtveis de acompanhamento e medigao, A Aleangivel: as necessidades de negécio consideram a viabilidade do investimento. R— Relevante: elas esto alinhadas com a visio, a missdo e os objetivos-chave da organizacao. ‘T — Tempestivo: os objetivos definidos tém uma janela de tempo definida que & consistente com as oportunidades ou os problemas associados. Ainda que haja critieas quanto a eficicia da APO nos seus objetivos na adminis- tragdo de empresas, 0 método SMART ¢ uma boa ideia para apoiar a definigdo das necessidades de negécio para os propésitos da Engenharia de Requisitos ( analista de requisitos no costuma ter poder para conduzir o trabalho em diregao declaragao de uma necessidade de negocio que seja aleangavel, relevante ou tem- pestiva; contudo, ele sempre deve garantir os dois primeiros critérios: especifica e ‘mensuravel. ‘A intengao inicial de “aumentar a satistagtio do cliente com-o servigo de atendimen- to” ndo representa um resultado observavel e nfo pode ser medido de maneira obje- tiva, Ao provocar de maneira proativa as partes interessadas chave em busca desses objetivos, poderiam ser langadas perguntas: 0 que ¢ a satisfagao do cliente? Como medi-la? Qual a meta de aumento? E se descobre que na verdade o cliente tem um problema que é um indice alto de reclamagées devido 4 espera para atendimento, E que o seu desejo seria diminuir esse tempo, para que essa fonte de insatisfagdo fosse eliminada, “Neste caso, ainda se poderia perguntar qual o tempo de espera que seria toleravel, e entdo o requisito seria reformulado como: “reduzir o tempo de espera no atendimen- toa, no maximo, trinta segundos”,Tipos de Requisitos, RestrigBes © Premissas 81 5.2.4. Quando sao elaborados? Os requisitos de negécio so elaborados em atividades de andlise de negécio, ante- riores & criaedo do projeto. Normalmente sio atividades que esto fora do escopo de atuagio da érea de TI, porém & comum que a TI apoie algumas dessas atividades. ‘Nas empresas & comum nomed-las como: pré-projeto, anteprojeto, estudo de viabili- dade, andlise de viabilidade, andlise de negécio etc. 5.2.5. Papel do analista de requisitos Quando ha atividades sérias de planejamento prévio, as intengdes iniciais ja sfo desenvolvidas em necessidades de negécio que observam as metas definidas pelo SMART. Porém, frequentemente é dificil encontrar as inteng&es iniciais observando naturalmente essas metas. Os requisitos de negécio deveriam ser elaborados pelos préprios responséveis do negécio interessados no projeto. O papel do analista de requisitos é refiné-los (se necesséric), identificando questdes que — uma vez respondidas — permitam melhor compreensio das intengdes iniciais, ainda que sem buscar alternativas de solueao, Por exemplo, considerando 0 requisito de negécio do estudo de caso do anexo 20 final do livro: “agilizar a coleta de informagdes de obras de médio grande porte”, algumas perguntas podem ser elaboradas para entender 0 dominio do problema ¢ representar as necessidades de negicio de maneira adequada, como: v Quais so as principais dificuldades na fiscalizagao ¢ que dificultam a co- leta de dados? Qual & 0 tempo médio gasto no preenchimento manual dos formuliios? Qual & sua ideia de agilidade de coleta de dados proposta? Agilizar em quantos % 0 processo de coleta de informagio? Como se mede a coleta de informagdes? vvvV Esse assunto sera discutido mais profundamente nos capitulos 6 ¢ 7. 5.2.6. Onde ficam registrados? 3s requisitos de negécio costumam estar presentes em documentos que justifiquem © projeto e sao originalmente elaborados pelas partes patrocinadoras da iniciativa em solicitagdes informais ou formais, como, por exemplo: > Casos de negdcio (business case).‘82 Engenharia de Requisitos > Estudos de viabilidade. > Anteprojetos. »® Termos de abertura de projetos. A partir desses documentos ow 2 partir do levantamento e da angilise juntos as partes interessadas chave (quando de solicitagdes informais), o analista de requisites tipi- camente elabora um documento de visio. Esses mesmos documentos também cumprem o papel de capturar as partes interes- sadas, restrigdes e premissas, todos conceitos discutidos nos t6picos seguintes. 5.3. Restrigdes e premissas O objetivo deste tépico € definir e exemplificar restrigdes © premissas de forma que possam ser identificadas e tratadas de maneira adequada ao longo do desen- volvimento dos requisitos. Ambas so informagies relevantes pata 0 sucesso do desenvolvimento do projeto ¢ que devem ser descobertas, analisadas ¢ tratadas a0 estudar 0 dominio do problema. Elas so requisitos? Nao, mas afetam diretamente aa sua definigao. 5.3.1. Restrigdes Do ponto de vista da gestdo de projetos, restrigdes slo limitagdes as opgdes para executar 0 projeto, Para o enfoque da Engenharia de Requisitos, restrigao é qualquer limitagdo as possiveis solugdes de software em desenvolvimento. Neste caso, o en- fogue € nas limitagdes a0 produto a ser entregue e no ao projeto em si. Nao repre~ sentam diretamente requisitos, mas induzem a definigia de requisitos especificos. [As restrigdes podem ser de origem de negécio ou téenicas e afetam 0 desenho da solugdo, sua construgao, testes, validagdo e implantagio, SAo aspectos da situago tual ou do estado futuro planejado que nao podem ser mudados, Ou seja, restrigdes so impostas, nfo se negociam, 5.3.1.1. Papel do analista de requisites Muitas restrigdes jé sto definidas na criagao do projeto; outras so descobertas a0 longo do trabalho de requisitos. No entanto, é importante que toda restrigo identi- ficada seja validada, pois muitas vezes ela é falsa. E isso pode levar 0 projeto para uma proposta de solugdo que nao é a mais adequada.190 Engenharia de Requisitos 5.5. Requisitos das partes interessadas ‘A fungi das partes interessadas no desenvolvimento dos requisitos & fornecer in- formagdes ¢ feedback quanto a compreensio destes. A essas informagdes se di 0 nome de requisitos das partes interessadas. O objetivo deste t6pico é entender o que so esses requisitos e as suas particularidades, Hé um comentdirio de Miles Davis que descreve a importincia de entender e saber tratar os requisitos das partes interessadas: “se vocé entendeu tudo o que eu voce deve ser eu”. Ainda que sejam requisitos intermedirios, é a partir deles que surgem oportunidades para identificar conflitos a serem resolvidos e oportunidades de consolidar requisitos semethantes. Se, 3s requisitos das partes interessadas sio os resultados intermedidrios do desenvol- vimento das necessidades de negécio em diregdo a especificagao da solugao e devem ser fundamentados por esses iltimos. Eles: > slo obtidos junto as partes interessadas; descrevem suas necessidades de informagao para o desempenho de suas tarefass representama visto da parte interessada sobre a sua interagio coma solugaio; sfo produtos das atividades de elicitagao de requisitos (descrita no Capi- tulo 7); so insumos das atividades de anilise de requisitos (descrita no Capitulo 8). v vy v 5.5.1. Onde ficam registrados? ; Como resultado das atividades de levantamento de informagdes junto as partes in- teressadas e da volatilidade da meméria humana, devem Ser criados registros que documeniem as informagdes levantadas e as decisdes tomadas nas mais diferentes formas. Esses registros podem ser: > gravacdes; > notas, > atas, Durante a condugao do evento de levantamento, pode ser adequado registrar: 2) apenas os pontos-chave em notas, b) a gravacio em éudio e/ou video de todo o evento; ou ainda ©) aelaboragao de uma ata.Tipos de Requisitos, Restrigbes e Premissas 91 © termo ata tem sido usado com um significado diferente do associado @ atividade de secretariar uma reunido registrando todos os atos e fatos ocorridos naquele even- to, Ele se aproxima de um documento de entendimento ou meméria de leventamen- to, elaborados apds o evento de levantamento. Explorar as condicionantes pars essas opgdes sera objeto de discussiio em eada tée- nica apresentada no Capitulo 7. O tépico sobre o nivel de detalhe dos requisitos do Capitulo 2 também ¢ pertinente, ao descrever os requisitos das partes interessadas. O exemplo na Figura 5.5 ilustra um documento com a meméria de levantamento, Ao longo dos capitulos 7 ¢ 8 o leitor receberd orientagao pratica, principalmente sobre como elaborar melhor a pauta que servird como fio condutor para os assuatos trata- dos nas atividades de levantamento e anslise de requisitos fetdemiicagao penis Detalhamento sobre o processo propasto de arrecadacto ‘e008 [Data reunido [Inicio —Trérmine — [Leeat re 3/02/2018 0500 vias | Sala de reurigo 109 a) Levantamento de informagdes sobre a arrecadacio de contas "Assuntos tratados oes. mien aaa 4) A arrecadacéo de contas serérealizada por agentes arrecadadores farmclas,loterias e pequenas Jojas| e nem sempre com acesso internet b) Os agentes arrecadadores que no possuem acesse a internet realizardo a transferéncia dos dados de arrecadacio ao final do dia por meio de malote. 19.0 controle da taxa de arrecadlag3o devida ao agente depende da forma como este transmite os dados e do volume de arrecadacéo. 0 valor arecadacio pelosagentesseré depositadorna conta da controladoria, © os dados serao trans- rmitidos conjuntamente com os dados da arrecadacio. Responsavel | Critic. Versio ‘Autor Data ObservacSes 10 Carlos Eduardo Vazquez 08/02/2018 Versio inicial Figura 5.5. Exemplo de documento com requisites das partesinteressadas. Fonte: FATTO Consultoriae Sistemas.192 Engenharia de Requisitos 5.6. Requisitos da solugao Os real interessadas original é i cunas de informagao, opartinidades We Facionalizagto, enfim, representam infor- ‘magées ainda nao estruturadas ¢ devem ser organizados em especificagdes antes degsgzem usados no desenvolvimento do. softies, gpasduletdesieatcabalho de resolugao dos contfitos, el igo das lacunas de informagao ¢ ue das Os reguisiins dausalilg, descrevem suas garacteristicas de forma wae requisitos de negécio ¢ 0s requisitos das ee forma andloga'sos Tinos das partes 2 SATS SDE ora areidade ente os requisites da solugao e os requisitos anteriores gue © fundamentam; 0 Capitulo 9 explica o tema da rastreabilidade e orienta em sua utilizagao. 5.6.1. Qual é a sua importancia? ee As espggificacdes com 0s requisitos da solucao capturam todas as decisdes tom; sobre o escopo.e 0 comportamsuia.rsperado pars de tal forma que nao se peream nem sejam esquecidas. Faso isso acontecesse, entdo haveria retrabalho de algum profissional responsavel por outra disciplina da enge- nharia de software para revisitar assuntos jé discutidos e decididos. © proprio processo de elaborar as especificagdes antecipa a descoberta da nec dade de novas decisy fee Mnieressadas em desenvol- vimento, Tsso evigassumir pres ‘irias em atividadgs subse: Engenharia & Requisttos. Com as especificanics.é possivel validar 0 entendimento da solusio enissaainies- "5 deMais partes inleressa des de negécio. Melhor identificar isso neste momento do que no teste de aceitagdo do usudtio!Tipos de Requisitos, RestrigSes-e Premissas 93 5.6.2. Processo geral de desenvolvimento dos requisitos De maneira resumida, um processo para 0 desenvolvimento dos requisitos consiste ‘em trés pasos, ilustrad — . > Organizar os requisitos das partes interessadas em um escopo da solugdo; foce ha abfangencia e sem pro} i > Desenvolver 05 requisitos das partes interessadas, resolver contfitos, eli rminar redundaneias, superar lacuna ( para Fever 0 escopo v erase em onsite escape ara sohigdo 7 Figura 5.6. Uma viséo geral das etapas do desenvolvimento dos requisitos das partes interessadas (0s globos absixo) para as especificacées (0s paralelepipedos acima). 5.7. Requisitos de transigao Imagine que na construcao de um edificio seja necessario construir um vestidrio um refeitério para os operdrios. Ao final da obra, 0 vestidrio e 0 refeitério serio des- montados, pois nao farao parte do prédio propriamente dito — seu uso foi necessério apenas durante a construgao. No caso da Engenharia de Requisitos, esses seriam os requisitos de transi¢ao,94 Engenharia de Requisitos Eles cumprem o papel de permitir que a nova solugdo que seri desenvolvida possa entrar em operagao plena, da forma desejada pelo cliente. Quando nfo hi uma so- luco atual, entio cles estao ausentes ¢ trata-se de uma solugio de inovagaio total les nao podem ser definidos até que o desenho da solugio seja finalizado © sio descartados apés a solugdo ser entregue por completo, Sua identificagao ¢ seu de- senvolvimento requerem as mesmas tarefas e técnicas dos requisitos da solugdo. ‘Também sio materializados em uma especificagio de requisitos, fruto de atividades de anélise de requisitos, Exemplos de requisitos de transigdo resultantes dessa anélise nfo se limitam a0 software e podem ineluir elementos como: os dados de agentes arrecadadores e de clientes com seus respectivos his- trieos serio migrados dos fichérios hoje mantides manualmente para novo sistema informatizado; > os agentes arrecadadores sero treinados na utilizago do novo sistema antes de sua entrada em produc; no primeiro més de operagio da nova solugio em produgio, a solugaio atual continuatd em funcionamento em paralelo e serd descontinuada a partir desse periodo; > 0s dados de contrato sero migrados do sistema legado para 0 ERP, apés filtragem e ajustes manuais. v Desses exemplos, para o foco do trabalho do analista de requisitos, devem-se segre~ ‘gar 0s que apenas envolvem o desenvolvimento de software dos que envolvem ages em outras esferas (por exemplo, gesto de projetos). Mas, em resumo, os exemplos mais comuns de requisitos de transigao so migragdes de dados do sistema velho para o novo sistema que esta sendo desenvolvido. 5.7.1. Qual 6 a sua importancia? A motivagdo para haver um tipo de requisito para descrever a transicZo para a nova solugdo é propiciar a melhor organizago das especificagdes na gestio de requisitos. Tal organizagdo permite uma melhor gestdo do conhecimento, comunicagdo e me- digo funcional do projeto de software, ‘A gestdo do conhecimento (ou pelo menos a sua retencdio) exige a segregagao dos requisitos da solugo, que continuam validos apds a entrega, dos requisitos de tran- sigdo, que duram 0 tempo de vida do projeto. Essa segregacdo também facilita o en- ‘endimento entre a equipe de desenvolvimento e seus clientes, melhorando com isso comunicagao entre essas partes. Por fim, os requisitos de transigaio so insumos para identificagdo de funcionslidades de conversio na analise de pontos de Fungo.Tipos de Requisitos, Restricdes e Premissas 95 Para muitos projetos a maior complexidade esti justamente na transi¢fo endo no produto a ser construido, Imagine uma companhiia aérea que deseja trocar seu sis- tema de vendas de passagens, Seri que seria aceitivel a estratégia de implantar novo sistema solicitando aos usuarios do departamento comercial que digitassem no novo sistema todas as passagens vendidas no sistema velho ¢ que ainda no foram tusadas? Ou que a venda de passagens fosse suspensa por algumas horas enquanto os dados do sistema velho slo transferidos para 0 novo sistema? Provavelmente no. O ‘mais plausivel ¢ que o cliente deseje uma transi¢do na qual a sua operacao de vendas _ndo seja interrompida por nenhum momento. E isso ja faz com que a transigdo a ser elaborada deixe de ser trivial. 5.7.2. Papel do analista de requisitos A identificagao dos requisitos de transigao deve ser precedida da avaliagio de dois cenéirios: 0 cendrio-alvo, necessario 4 nova solugio em funcionamento (fo-be), ¢ 0 cenétio atual, indicando a situag2o atual como esté (as-is). A partir da comparagio desses dois cendrios, identificam-se itens de ago que devem ser atendidos (fo-be) para que a solugao entre em plena operagio, 5.8. Requisitos de software: solugao + transigao Os requisitos de software so compostos pelos requisitos da solugio (0 produto a ser entregue) e pelos requisitos da transigdo (se houver), Ambos so compostos por requisitos funcionais e requisitos ndo funcionais, como ilustrado na Figura 5.7. Descrrene uso sate ‘ve fr 7 ail Regquisitos do Software requisitos Tuncionais. = Teo Fequsitos nao funcionais. sree r— ano Lal Resipes —Eabetce eases nis sien comes seni quese ‘cfr oie Spr pd ‘eho Ota Figura 5.7. Os requisitos de software definidos por requisitos funcionais e no funcionais.96 Engenharia de Requisitos Resumidamente, os requisitos funcionais deserevem 0 que 0 software faz, consi- derando uma perspectiva de tarefas ¢ servigos de seus usuarios em especifico. Os equisitos nao funcionais descrevem qualidades que 0 produto de software deve observar para ser efetivo e limitagdes gerais a0 funcionamento dos requisitos fun- cionais estabelecidos para o software. 5.8.1. Onde sao armazenados? Os requisitos de software sao mantidos em diversos tipos de artefatos, que variam conforme a metodologia de desenvolvimento de software usada pela organizagao. Por exemplo: Documento de visdo, Lista de requisitos Historia de usuario. Caso de uso, Modelos. Layout de telas ¢ relatérios. Especifieagdo funcional. Especificagdo complementar. Glossirio. VV VV YY 5.9. Requisitos funcionais Os requisitos funcionais descrevem 0 comportamento que 0 software deve ter em termos das tarefas ou servigos do usuério. Isso se opde & descrigzio do desenho da arquitetura da solugo ou de sua implementacdo em uma plataforma tecnolégica usando determinadas linguagens de programago. Um requisito funcional nto é ¢ nem substitu uma especificagio de programas, de componentes ou coisa similar, ‘Vale ressaltar que os requisitos funcionais no descrevem 0 desenho da arquitetura de solug2o, mas sio profundamente afetados por ela. Nao se deve supor que o trabalho de arquitetura se inicia somente apds 0 trabalho de requisitos, Decisées arquiteturais de alto risco devem ser tomadas 0 mais cedo possivel, e determinados requisitos funcionais em um cenirio de arquitetura passam a ser requisitos nao funcionais em outro, Por exemplo, o controle de acesso de usué- rios corporativos. Dependendo das decisdes arquiteturais tomadas no inicio do ciclo de vida, 0 controle de acesso pode ser parte da especificagto funcional ou entio parte de uma infraestrutura comum de suporte que aborda requisitos nao funcionais de seguranga.Tipos de Requisitos, Restrigdes e Premissas 97 © comportamento esperado pelo software e descrito em um requisito funcional se refere ao intercambio de informagdes entre o usuario, o software sendo descrito ¢ os meios de armazenamento até que um objetivo especifico seja alcangado. Esse objeti- ‘vo especifico — um objetivo do usuario ~ é concluir a tarefa sob sua responsabilidade de tal maneira que seus resultados possam ser usados como insumos em outras tare- fas por usuarios com outras responsabilidades ou em outros momentos — seja por um usuario com as mesmas responsabilidades ou nao, A Figura 5.8 ilustra essa relagao centre os requisitos funcionais Restos que poston securaior er owas Inircimbi dea pours ecm lomarssente 0 ules spose sofas sto ‘enaresioaseu § cetio obi Tenino eign manor cancaruna Ress U2 posta ser usados teria estsban —_emoutas tues ma afer ro restate BOOpwacoal, dda gu ba oe ‘mesma responsatiliade Figura ,0 que s80 0s requisitos funcionais ea natureza da inter-relacao entre eles. 5.9.1. Onde séo armazenados? (Os requisitos funcionais podem estar presentes como parte de varios artefatos, como: documento de visio, listas de requisitos, histirias do usuirio, especificagdes de casos de uso e modelos de provesso. Esses tipos de artefatos sero abordados no Capitulo 8. Para fins de simplificago, se denominard especificacao funcional um documento que contenha requisitos funcionais, ainda que estes estejam em processo de desen- volvimento e nao em seu estigio final. 5.9.2. Papel do analista de requisitos ‘Sto exemplos de requisitos em especificagdes funcionais descrigdes como: 1. Bfetuar a gestio dos cursos. 2. Emitir 0 certificado de participagdo do aluno no curso.98 Engenharia de Requisitos 3. Garantir que somente alunos com frequéncia superior a 75% possam emi- tirseu certificado. Todos esses exemplos sto de requisitos funcionais, contudo apenas o segundo esté especificamente associado a uma nica tarefa ou servigo do usuario, Isso € muito comum. Boa parte do trabalho do analista é refinar requisitos mais abran- gents, como o apresentado no primeiro exemplo, ou consolidar fragmentos, como 0 apresentado no terceiro exemplo, até que se chegue ao nivel adequado da especificagio. (Ou seja, durante o desenvolvimento dos requisitos o esperado € que haja nas es- pecificagdes funcionais elementos que tenham diferentes granularidades. A seguir explica-se melhor o que seja nivel de granularidade no ambito de uma especificago funcional. 5.9.3. Nivel de granularidade O nivel de granularidade € a maior ou menor abrangéncia na descrigo do comporta~ ‘mento esperado para o software em uma especificagao funcional. Essa abrangéncia esta relacionada ao tipo de objetivo associado ao requisito presente nessa especifica- gio. A Figura 59 ilustra a relagdo entre esses objetivos e o nivel de granularidade. Seri usada uma classificagao de trés niveis de granularidade proposta por Cockburn (2000) para casos de uso e generalizada pelos autores para requisites funcionai Requistes eltvos tarts o a8 servos ousuto varslrdos para soars Figura 5.9. Diferentes niveis de granularidade em requisitos presentes em ‘uma especificago funcional e sua relacéo com os objetivos associados.Tipos de Requisitos, RestrigGes e Premissas 99 5.9.4. Requisitos funcionais com objetivo de usuario Se nada for dito ao contrario quando se refere a um requisito em uma especificagtio funcional, entdo se trata do préprio requisito funcional como descrito anteriormente. E 0 requisito funcional especificado: > no nivel de uma tinica tarefa soba responsabilidade de um nico individuo; > em um determinado momento no qual 0 usuério tem tudo 0 que precisa para que a tarefa seja concluida até o limite de sua responsabilidad no fluxo operacional em que ela se insere. Ao final da tarefa, o usuario cumpre seu objetivo, fica satisfito, ndio ha nada mais a se fazer. Se um trabalho envolve mais de um individuo, é porque ha mais de uma tarefa presente, ‘Sao exemplos de requisitos funcionais identificados neste nivel: > Efetuar baixa do titulo na relagao de contas a receber. > Emitir carta de renovagao de contrato. > Emitir certificado de participagio do aluno no curso, Em todos os exemplos, uma vez que determinado requisito tenha sido concluido, tudo que deveria ser feito em resposta a um evento externo foi feito. 5.9.4.1. Qual é a su ‘A importancia de saber identificar um requisito funcional neste nivel & poder deli- near 0 escopo do sofware em desenvolvimento de maneira inequivoca; sem divides quanto a sua abrangéncia. O escopo descrito por meio de requisitos funcionais neste nivel pode mais facilmente ser validado ¢ compreendido. jportancia? si Este é 0 tinico nivel de descrigao de processos que pode ser padronizado e & por consequéncia, aquele utilizado por todos os métodos de medigto do tamanho fun- cional padronizados pela norma ISO/IEC 14143, Por ser passivel de padronizagao, 0 requisito funcional especificado neste nivel pode ser verificado de maneira objetiva quanto & conformidade com politicas de qualida- de previamente estabelecidas, O requisito funcional estar especificado neste nivel é o critério de qualidade presente em diversas metodologias. Ele ¢ o nivel em que um caso de uso deve ser identificado e elaborado antes de ser empacotado e encaminha- do para projeto e implementagao; o mesmo é valido para uma historia de usuario,100 Engenharia de Requisitos 5.9.5. Requisitos funcionais com objetivo agregador Silo requisitos que agregam varios objetivos de usuérios individuais em uma Unica especificagao de alto nivel. Quanto maior o nivel, mais gerais sio seus objetivos ~ para que um objetivo de maior nivel seja alcangado, outros de menor nivel devem ser alcangados. Referem-se, portanto, a objetivos mais gerais ¢ esto em um nivel de abrangéncia associado a objetivos colaborativos; aos processos de negécio de alto nivel. Nao se referem a uma tinica tarefa ou servigo. Resumem um conjunto de tarefas de um ou mais usuarios. A Figura 5.10 ilustra 0 objetivo de “Controlar Aditivos” como um conjunto de obje~ tivos de menor nivel subordinados. Para simplificar, considera-se 0 nome “requisitos agregadores” para denominar 0s elementos na especificagao de requisitos funcionais associados a um objetivo agregador. ‘Sao exemplos de requisitos agregadores: > Controlar fluxo de caixa. > Gerirrelacionamento com clientes > Efetuar gestio dos cursos. Quais sao especificamente as tarefas associadas a esses requisitos? Talvez sejam dbvias para o leitor da especificagao (¢ por isso néo stio detalhadas) ou ainda nto sejam conhecidas, Contudo, neste tltimo caso, sabe-se que ha tarefas que devem ser sobre esse requisito, pois se decidiu que elas so parte do escopo do software em desenvolvimento. _ Objet do Requsito: ~ ontrolar Aditivos ‘4 Agroga vatios bjevos do usuéo Figura 5.10. Controlar aditivos como um objetivo ‘agregando varios objetivos subordinados.Tipos de Requisitos, Restrigées e Premissas 101 5.9.5.1. Qual é a sua importéncia? O propésito de descrever um requisito agregador é resumir um conjunto de tarefas do usuario em um iinico item quando ainda nao se sabe exatamente quais delas exis- tem, quais existirdo ou quais delas serdo objeto de informatizago ou automagaio no escopo do projeto em desenvolvimento, 5.9.5.2. Papel do analista de requisites Em momentos preliminares do desenvolvimento, talvez boa parte dos requisitos identificados para compor a especificagao funcional sejam requisitos agregadores, Isso se da porque varias decisdes sobre o escopo final do software em desenvolvi- mento ainda estéo pendentes, E um item a ser definido; geralmente, rotulado como TBD (to be defined), Identificar requisitos agregadores nao se trata de uma estratégia de desenvolvimen- to. Os requisitos que esto no nivel adequado para um requisito funcional devem ser identificados e descritos independentemente do momento em que se esteja no ciclo de vida, Ao longo do desenvolvimento dos requisitos, o analista deve refinar os requisites neste nivel agregador no sentido de identificé-los e descrever de maneira mais espe- cifiea até que se chegue ao nivel adequado a um requisito funcional, No entanto, alguns requisites funcionais possuem um comportamento padronizado que dispensam um detalhamenio como 0 proposto aqui. Um exemplo sao 0s re guisitos associados & manutengio cadastral e, normalmente, denominados CRUD (Create, Read, Update, Delete). ‘ 5.9.5.3. Requisitos de negécio x requisitos agregadores Um cuidado para o qual se deve atentar é diferenciar um requisito agregador de uma necessidade de negécio. Afinal, enquanto a necessidade de negécio est’ no dominio do problema com todo um universo de solugdes em potencial, o requisito agregador tem o objetivo de descrever a solucdo escolhida. Diferencié-los & importante por que os seus usos séo distintos. Nao fazer isso significa confundir a solugao como problema. Para ilustrar um € outro, por exemplo, considere os dois casos ilustrados na Figura 5.11: “Controlar Aditivos” e “Diminuir 0 Risco Operacional”.102 Engenharia de Requisitos Dominio da Solugzo Cote do Regus: == 77 = ‘Cento Aivos de negécio — “por que” ction Diminuiro rsco operacional ‘ | com servigos contratados mas t abeatee 10 formalzados le 5 Dominio do Problema Figura 5.11. Comparati ‘entre requisite agregador erequisito de negdcio. [A descrigao de “Controlar Aditivos” corresponde g um requisito agregador porque agrega varios objetivos em um nivel de objetivo de usuirio, E nao hi pistas de um problema ou oportunidade de negécio. Ainda que ao longo da Engenharia de Requi- sitos ele deva ser refinado, j4 esté decidido que ele faz parte do dominio da solugto. Ha, todavia, uma série de decisdes ainda em aberto para 0 atendimento das neces- sidades de negocio. 46 a descrigdo associada a “Diminuir o risco operacional com servigos contratados ‘mas no formalizados” indica uma necessidade de negécio, pois descreve um pro- blema. Ela foi o ponto de partida para uma série de decisdes que, nesse estigio do desenvolvimento, culminou com 0 estabelecimento do objetivo de “Controlar Adi- tivos” como parte do escopo para a solugao da organizagao estar exposta a riscos operacionais, Portanto, no confunda o problema com a solugaio. Entregar um software ao cliente 6a parte mais ficil do trabalho, Entregar um software que o satisfaga é que é a ques tdo-chave. E para isso ¢ necessario ter a visio clara do problema.Tipos de Requisitos, Restricoes e Premissas 103 5.9.6. Requisitos funcionais com objetivo de subfungao Anilogos aos requisites agregadores, mas em sentido inverso, so fragmentos que compéem uma especificagao funcional em um nivel inferior ao nivel dos objetivos do usuiirio: s0 passos e regras. Ou seja, isoladamente nao atendem a um objetivo do usuario. Por simplificagao, esses fragmentos de requisitos so denominados especi- ficagdes funcionais de subfungGes. Os passos descrevem o interedmbio de dados em ambas as diregdes entre o usuario € 0 software; ¢ entre este tltimo e os requisitos de armazenamento. Para um exemplo de requisito de subfungao como conjunto de pasos, podemos citar « autenticagtio de um cliente em um servigo de autoatendimento para realizar transagdes bancérias, Este é um excelente exemplo de uma sequéneia de passos que deve ser especificada em separado dos requisitos funcionais que a inserem. Nao ha, neste cenério, a figura de um login onde o usuario se identifica e, feito isso, pode realizar transagdes para as {quais esteja autorizado, Cada tipo de transagao individual (saque de conta corrente, transferéncia, pagamento, investimento ete.) requer 0 mesmo conjunto de pasos para a identificagio do cliente, que poderiam ser: Verificar se 0 cartio existe, se esta vigente e se nflo esta bloqueado, Verificar se a operacao desejada é compativel com 0 tipo do cartao. Verificar se a senha informada esta correta. Incrementar erros de senha se a senha informada for incorreta, Zerar erros de senha se a senha informada for correta. ‘Ainda que isoladamente essa sequéncia de passos ndo atenda aos critérios para um requisito funcional, sua especificagdo como um requisito no nivel de subfungao & apropriada. 4 vvvyy ‘As rogras normalmente estilo ligadas a leis que regem 0 negécio e descrevem de for- ma complementar o funcionamento de seus processos ~ por isso, muitas vezes sao chamadas de regras de negécio, Elas descrevem politicas corporativas, a legislag&o pertinente, as regulamentagdes governamentais ¢ os padres de mercado aos quais 1 soluedo deve se subordinar. Blas nao estio especificamente ligadas & solugao (e, portanto, ao software), mas ao dominio do problema em que clas se inserem. Elas existem independentemente do software; do processo de negécio estar automati- zado ou nfo. As regras de negécio deveriam também ser tratadas como um ativo organizacional e nao apenas como parte do projeto ou do produto de software. Além disso, o software pode ter regras que ndo so do negécio, mas relativas ao seu modo especifico de funcionamento; estdo ligadas ao software em especifico.104 Engenharia de Requisitos Sao exemplos de regras de negécio: > Somente alunos com frequéncia igual ou superior a 75% podem emitir seu certificado, Somente clientes com idade superior a 18 anos podem ser correntistas. Somente compras acima de RS 500,00 podem ter pagamento parcelado. Criangas de até 23 meses transportadas no colo do responséivel no pagam passagem. v vv 5.9.6.1. Qual é a sua importancia? No caso das regras de negocio, € comum que elas sejam compartilhadas entre di- {ferentes requisitos funcionais, inclusive alocados a produtos de software diferentes, Portanto, especifici-las de forma independente dos requisitos funcionais em que se aplicam contribui para uma methor gestao de requisitos (facilidade de modificagao e principalmente de reutilizagao). Uma tendéneia quando se utilizam ferramentas de BRMS (Business Rules Mana- gement System) & que, além de especificar as regras de negécio em separado dos requisitos funcionais, estas sejam mantidas e implementadas fora de uma mesma aplicagio de software em particular. J4 no caso de uma sequéncia de passos, s6 se justifica a sua especificagaio em sepa- ado como uma subfungao quando hé um comportamento compartilhado por varios requisitos funcionais. Isso torna os documentos de requisitos mais facilmente adap- taveis a mudangas, pois diminui redundncia de informagao. 5.9.6.2. Papel do analista de requisites . © analista de requisitos, quando obtém a informagdo das partes interessadas como subfungdes, deve saber identificé-tas como tal para investigar em quais requisitos funcionais essas subfungdes se inserem. Por outro lado, quando ele for o autor das especificagdes funcionais, deve identificar as oportunidades como as deseritas para uma methor gest de requisitos. “Isso nao é um requisito, ¢ uma tegra de negécio!”, Um comentério muito comum, principalmente entre os profissionais responsiiveis pela medigao do tamanho funcio- nal de software, é que determinado requisito em uma especificagao funcional nao & ‘um requisito, mas uma regra de negécio. © comentirio trata-se na verdade de um jargio. Afinal, uma regra de negécio é um requisito! A intengao por tras do comentdirio & indicar que aquela regra de newTipos de Requisits, Restrigdes e Premissas 105 do é um requisito funcional no nivel de objetivo do usuario como deserito neste tex- to., portanto, trata-se de uma subfungdo que niio deve ser tratad como uma fungao. 5.10. Requisitos nao funcionais Este topico trata dos requisites no funcionais que descrevem limitagdes de ordem geral aos requisitos funcionais e, isso, complementam a especificagio do software. ‘Afinal, ele nfo deve apenas funcionar; deve funcionar bem. Ao descrever 0 que seja ‘esse “funcionar bem”, 0s requisitos nao funcionais acabam por estabelecer niveis de servigo esperados para o funcionamento do software Enquanto os requisitos funcionais referem-se especificamente a uma tarefa do usud- rio, os requisitos nalo funcionais indicam restri¢des de ordem geral que abordam aspectos relatives: ‘Ao ambiente: como interoperabilidade, seguranga, privacidade, sigilo. ‘A organizagao: por exemplo, locais para operagao, hardware alvo, ade- réncia a padres. > A implementagio: como plataforma de software, hardware, linguagem de programagie. > Agqualidade: por exemplo, a facilidade de uso, a confiabilidade, a eficién- cia, a portabilidade a facilidade de manutensao. vv Essa relagdo é apenas ilustrativa de alguns tipos de requisitos ndo funcionais e nao ‘busca ser uma lista completa. {A Figura 5.12 representa 0 papel dos requisitos no funcionais de estabelecer niveis de servigo que direcionam como seré o projeto da arquitetura que suporta as cama- das de software voltadas ao atendimento dos requisitos funcionais,- ‘we canescens Requisios do Software ‘requis ndo funcionais Fesiges do Recreate inoene ingererian OpENeaO ‘equistos funcionais —0 een fsrigee Ratt Toons uae coma nivel de sorvigo Figura 5.12. Relacio entre requisites nao funcionals e requisites funcionais.106 Engenharia de Requisitos ‘Um aspecto que facilita a identificagao dos requisitos nao funcionais & que eles cos tumam ser constantes entre os projetos ou mudam pouco de um projeto para outro ‘na mesma organizagdo, Por isso, mesmo em fases bem iniciais de um projeto, se consegue ter uma boa visibilidade sobre os aspectos nao funcionais necessarios ao software, Embora nfo seja uma regra, uma caracteristica que costuma diferenciar os requisi- tos funcionais dos ngo fincionais € que os no funcionais costumam se manifestar de forma geral sobre 0 software, ¢ os funcionais de forma especifica. Por exemplo, facilidade de uso do software & um tipo de requisito nao funcional, e uma definigao sobre essa questo em geral iri valer para todo o software. J os requisitos fun- cionais tratam de tarefas especificas que o software realiza, eles nfio costumam se espalhar por todo o produto. Outro racioeinio itil para essa distingao, e consequéncia do pardigrafo anterior de- vido @ esse comportamento geral, ¢ que o requisito nao funcional frequentemente & alocado parte arquitetural do software que dara suporte as funcionalidades. Para organizagdes que possuem uma metodologia madura de desenvolvimento de software, a identificagdo de boa parte dos requisitos nao funcionais é também faci- litada, pois muitos aspectos téenicos ¢ de qualidade dos projetos sdo padronizados pela metodologia através de guias especificos. Por exemplo: guia de usabilidade, guia de seguranga, guia de portabilidade. Por isso os requisitos nao funcionais de ‘um projeto tendem a set em menor niimero que os requisitos funcionais, o que faci- lita sua gestao, : ‘Veja alguns exemplos de padrdes corporatives do governo federal brasileiro que de- finem diversos aspectos relativos aos tequisitos nao funcionais para seus softwares desenvolvidos: > Padrdes Web em Governo Eletronico (e-PWG): http:/www.governoeletronico.gov.br/acoes-e-projetos! padroes-brasil-e-gov > Modelo de Acessibilidade de Governo Eletrénico (e-Mag): http:(www.governoeletronico.gov.br/acoes-e-projetos/e-MAG > Arquitetura de Interoperabilidade de Governo EletrOnico (e-PING): hutp:/eping governoeletronico.gov.br/