Aengenharia de requisitos um processo que engloba todas as atividades que contribuem para a produo de um documento derequisitose sua manuteno ao longo do tempo.Este processo deve ser precedido deestudos de viabilidadeque, a partir das restries do projeto, determinam se este ou no vivel e se deve prosseguir para a identificao dos requisitos. Uma outra atividade que se pode considerar que faz tambm parte deste processo, se incluirmos a fase posterior produo do documento, agesto dos requisitos(change management, sendo que as alteraes podem ser causadas pelos mais diversos fatores desde inovaes tecnolgicas a mudanas na natureza do negcio, entre outras.Estudos de viabilidadeAntes de se avanar com uma anlise mais detalhada dos requisitos de um projeto, deve ser feito um estudo de viabilidade.Tal como o nome sugere, pretende-se com este estudo avaliar sob o ponto de vista tecnolgico e organizacional se o projeto vivel.Uma forma de avaliar a viabilidade de um projeto obter, atravs da interao com "as partes interessadas" (oustakeholderem ingls) do projeto (em reunies ou entrevistas, por exemplo), a resposta s seguintes questes: Ser que o sistema contribui para os objetivos da organizao? Dadas as restries tecnolgicas, organizacionais (econmicas, polticas, ambientais, recursos disponveis) e temporais associadas ao projeto, ser que o sistema pode ser implementado? Caso haja necessidade de integrao entre diferentes sistemas, ser que esta possvel?A questo mais crtica a primeira, j que um sistema que no contribua para os objetivos da organizao no lhe traz qualquer valor acrescentado e como tal a sua existncia no se justifica. Apesar de parecer bvia, so frequentemente desenvolvidos sistemas que no contribuem para os objetivos das respectivas organizaes, quer seja por interesses externos (polticos ou organizacionais) ou por falta de clareza na definio dos objetivos da organizao.Deve portanto identificar-se que informao necessria para responder a estas questes e quem possui esta informao, procedendo-se de seguida recolha de todos os dados disponveis para clarificar ao mximo o mbito do projeto e avaliar a sua viabilidade.Tipicamente, quem poder fornecer esta informao sero os usurios dos sistemas atuais e do sistema a implementar, os responsveis pelos departamentos nos quais o sistema ser usado, tcnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes), responsveis pela manuteno futura do sistema a implementar e, de um modo geral, todos aqueles que tero qualquer tipo de interao com o novo sistema (ou que sejam por ele afetados).IdentificaoCaso se determine que o projeto vivel, o passo seguinte a identificao dos requisitos.Atividades envolvidasAlgumas das atividades envolvidas nesta fase incluem: Compreenso do domnio: muito importante para o analista compreender o domnio no qual a organizao e o projeto se inserem; quanto maior for o conhecimento acerca do domnio, mais eficaz ser a comunicao entre o analista e as partes interessadas. Identificao das partes interessadas: estes j devero ter sido identificados nos estudos de viabilidade, porm para efeitos de identificao de requisitos convm concentrar as atenes nos usurios do sistema. Captura: consiste na obteno com o cliente dos requisitos (funcionais e no-funcionais) pretendidos para o sistema. Identificao e anlise de problemas: os problemas devem ser identificados (e a sua definio deve ser consensual) e devem ser propostas solues em conjunto com as partes interessadas.DificuldadesEsta fase no trivial, sendo que existem algumas dificuldades tpicas que lhe esto associadas: O cliente pode no saber exatamente o que deseja para o sistema, ou sab-lo mas no conseguir articul-lo (o que bastante comum). Os requisitos identificados podem no ser realistas (do ponto de vista econmico ou tecnolgico, por exemplo). Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessrio - atravs de um bom conhecimento do domnio - identificar estas situaes.Tcnicas para levantamento de requisitosExistem diversas tcnicas de identificao de requisitos, e que so adequadas a diferentes situaes, entre as quais podemos citar:Entrevistas e QuestionriosEntrevistas e Questionrios talvez a tcnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obteno de dados (e mesmo de esclarecimento de algumas dvidas), est condicionada a alguns fatores: Influncia do entrevistador nas respostas do cliente: convm que o entrevistador d margem ao entrevistado para expor as suas ideias sem as enviesar logo partida. Relao pessoal entre os intervenientes na entrevista. Predisposio do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afetado pela introduo de um sistema na organizao, este pode propositadamente dificultar o acesso informao. Capacidade de seguir um "plano" para a entrevista: na ausncia destes planos natural que haja tendncia para que os intervenientes se dispersem um pouco, levando a que a entrevista demore mais tempo do que seria suposto. Caso a entrevista se torne demasiado longa, as pessoas podem cair na tentao de "querer despachar" sendo os ltimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados).Workshops de requisitos OWorkshop de Requisitosconsiste numa tcnica usada atravs de uma reunio estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente1, para ento obter um conjunto de requisitos bem definidos. Ao contrrio das reunies, promove-se a interao entre todos os elementos presentes no workshop fomentando momentos de descontrao como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel conduzir o workshop e promover a discusso entre os vrios intervenientes (ainda que no tenha realmente poder de deciso). As tomadas de deciso devem seguir processos bem definidos e devem resultar de um processo de negociao, mediado pelo facilitador. Uma tcnica que tambm til em workshops o uso debrainstorming(tempestade de idias) como forma de gerar um elevado nmero de ideias numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentao que reflita os requisitos e decises tomadas sobre o sistema a implementarCenrios (Srie de Eventos Hipotticos Uma forma de levar as pessoas a imaginarem o comportamento de um sistema o uso de cenrios. Atravs de exemplos prticos descritivos do comportamento de um sistema, os seus usurios podem comentar acerca do seu comportamento e da interao que esperam ter com ele. Trata-se de uma abordagem informal, prtica e aplicvel a qualquer tipo de sistema. De um modo geral, os cenrios devem incluir os seguintes elementos: estado do sistema no incio do cenrio; sequncia de eventos esperada (na ausncia de erros) no cenrio; listagem de erros que podem ocorrer no decorrer dos eventos do cenrio e de como estes erros sero tratados; outras atividades que podem ser executadas ao mesmo tempo que as deste cenrio; estado do sistema depois de o cenrio terminar.PrototipagemO uso deprototipagem feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificao, anlise e validao). Trata-se de uma verso inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que atravs da comunicao verbal no so to facilmente identificveis. O uso de prottipos deve ser considerado apenas mediante uma anlise custo-benefcio, j que os custos de desenvolvimento de um prottipo podem facilmente crescer, sendo particularmente teis em situaes em que a interface com os usurios , para eles, um aspecto crtico.Estudo etnogrficoOsEstudos Etnogrficosso uma anlise de componente social das tarefas desempenhadas numa dada organizao. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, de se esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Atravs de uma observao direta das atividades realizadas durante um perodo de trabalho de um funcionrio possvel encontrar requisitos que no seriam observveis usando tcnicas convencionais. Esta observao pode ser acompanhada de registros udio/vdeo, porm no convm us-los em demasia visto que o tempo necessrio para os processar pode ser demasiado. Nesta tcnica assume-se que o representante do cliente observado desempenha as suas funes "corretamente", pelo que convm ter algum cuidado na escolha do mesmo.Anlise e negociao dos requisitosAps a identificao dos requisitos do sistema, segue-se etapa de anlise dos requisitos e negociao.Atividades envolvidasAlgumas das atividades envolvidas na anlise de requisitos incluem: classificao: agrupamento de requisitos em "mdulos" para facilitar a viso global do funcionamento pretendido para o sistema; resoluo de conflitos: dada a multiplicidade e diversidade de papis das partes interessadas envolvidas na captura e anlise de requisitos, inevitvel a existncia de conflitos nos requisitos identificados; importante resolver estes conflitos o mais breve possvel; priorizao: consiste na atribuio de uma "prioridade" a cada requisito (por exemplo elevada/mdia/baixa); obviamente, este pode ser um fator gerador de conflitos; confirmao: confirmada com as partes interessadas a completude dos requisitos, sua consistncia e validade (de acordo com o que se pretende do sistema).Estas fases no so independentes entre si, pois uma informao obtida numa delas pode servir para as demais fases.A identificao e anlise de requisitos um processo iterativo que se inicia com a familiarizao do domnio do futuro sistema e termina na confirmao dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho.DificuldadesAs dificuldades encontradas na anlise so de diversas naturezas: fatores externos (polticos) podem influenciar os requisitos (alguma parte interessada, com poder de deciso, pode exigir requisitos especficos que sirvam aos seus interesses e no aos da organizao, ou forar o seu ponto de vista em detrimento dos demais interessados que iro operar o sistema); o ambiente (econmico e/ou organizacional) em que a anlise feita possui fatores dinmicos, e como tal, os requisitos esto sujeitos a alteraes em decorrncia destes (por exemplo: novas partes interessadas so envolvidas no projeto, ou alteraes em prazos e oramentos disponveis).NegociaesNa fase de negociao, tornam-se necessrios alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Algumas sugestes so: saber lidar com ataques pessoais (evitando-os sempre que possvel, remetendo a sua resoluo para mais tarde, fora de reunio), de preferncia nunca tomando partidos; fomentar a justificao das posies (negativas) tomadas pelos intervenientes na negociao; salientar (e procurar encontrar) os benefcios que uma soluo apresenta para todos os envolvidos; relaxar restries, quando se torna bvio que as atuais no levaro a um consenso.Especificao e documentao nesta fase que se d a produo propriamente dita doDocumento de Especificao de Requisitos.Em todos os tipos de especificao h 2 tipos de requisitos a considerar: Requisitos funcionais: descrevem as funcionalidades que se espera que o sistema disponibilize, de uma forma completa e consistente. aquilo que o utilizador espera que o sistema oferea, atendendo aos propsitos para qual o sistema ser desenvolvido. Requisitos no-funcionais: referem-se a aspectos no-funcionais do sistema, como restries nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos no-funcionais de: Utilidade, Confiana, Desempenho, Suporte e Escalabilidade.Pode-se tambm considerar os requisitos do domnio, que tal como o nome indica derivam do domnio e no de necessidades especficas dos usurios, podendo depois ser classificados como funcionais ou no-funcionais.A documentao produzida poder ter diferentes destinatrios e como tal diferentes objetivos. Podem-se distinguir trs tipos de especificao: especificao derequisitos do usurio ou utilizador; especificao derequisitos do sistema; especificao dodesign da aplicao.A vantagem de conceber mais do que uma especificao para um dado sistema a de em cada especificao se comunicar apenas um determinado tipo de informao adequado ao leitor a que se destina (usando "linguagens" que o utilizador conhea). Por exemplo, enquanto que nos requisitos do utilizador apenas feita uma abordagem de alto nvel das funcionalidades do sistema e suas restries, usando linguagem natural e eventualmente diagramas (esquemas), nos requisitos do sistema cada requisito descrito com mais detalhe introduzindo j alguns conceitos relativos arquitetura do sistema, fazendo-se uso de linguagens estruturadas (notaes grficos como diagramas de casos de uso).Requisitos do utilizadorOsrequisitos do utilizadordestinam-se portanto aos vrios nveis hierrquicos da organizao na qual o sistema ser implementado (desde gestores a usurios), pelo que so descritos usando apenas (conforme j foi referido) linguagem natural, formulrios e diagramas muito simples. Obviamente, neste nvel de especificao surgem algumas dificuldades: Ambiguidade: torna-se difcil descrever os requisitos de uma forma inequvoca sem tornar a sua descrio muito longa ou de difcil compreenso. Confuso: ainda que possa no ser to relevante do ponto de vista do cliente, a distino entre requisitos funcionais/no-funcionais e objetivos do sistema torna-se difcil. Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difcil separar claramente os requisitos, o que leva a que vrios requisitos sejam expressos como sendo apenas um.Algumas consideraes teis a ter em conta ao escrever uma especificao de requisitos do utilizador: Usar o mesmo formato em todos os requisitos (evitam-se omisses e facilita-se a verificao dos requisitos). Distinguir claramente entre comportamentosesperadosedesejveisdo sistema atravs do uso de expresses como "O sistema permitir criar (...)" ou "Dever ser possvel criar (...)" respectivamente. importante deixar claro o que o sistematemde fazer e sugestes de como odevefazer e, acima de tudo, usar este tipo de expresses de forma consistente ao longo de todo o documento. Usar formatao de texto para salientar determinados aspectos do documento (usando negrito, por exemplo). Evitar usar termos demasiado tcnicos ou fora do mbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessrio us-los.Requisitos do sistemaOsrequisitos do sistematm um carcter mais tcnico, consistindo numa descrio detalhada dos requisitos do utilizador correspondentes recorrendo ao uso, para alm da linguagem natural, de linguagens estruturadas e notaes grficas. Estes requisitos destinam-se ainda aos usurios do sistema (e particularmente aos engenheiros que trabalhem nessa organizao) e destinam-se tambm s equipes de especificao de arquitetura do sistema e de desenvolvimento. Tal como nos requisitos do utilizador, o uso de linguagem natural levanta problemas, embora alguns deles sejam ligeiramente diferentes: As mesmas palavras podem, de acordo com a interpretao de cada pessoa, designar conceitos diferentes. O mesmo requisito pode ser descrito de formas diferentes, o que leva a que cada pessoa tenha de saber quando que descries diferentes se referem ou no a requisitos diferentes.Design da aplicaoPor fim, a especificao dodesign da aplicaoconsiste num documento usado pela equipe de desenvolvimento do sistema no qual esto definidos pormenores, em um nvel mais tcnico, acerca da implementao do sistema e sua arquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento no meio do projeto dever ser capaz de "se situar" quando precisar de comear a codificar, compreendendo a forma como a implementao, em um nvel global, est a ser feita, mas sem conhecer necessariamente os detalhes de implementao aprofundados. No convm cair na tentao de deixar toda a implementao detalhada, uma vez que convm que os desenvolvedores tenham alguma margem de manobra tanto para inovar como para resolver problemas encontrados em sub-sistemas de formas que uma especificao inicial da arquitetura no consegue prever.Documento de Especificao de RequisitosApesar da existncia dos 3 tipos de especificao vistos nos itens anteriores, existe uma especificao que a usada como declarao oficial dos requisitos do sistema.Este documento, normalmente chamado deDocumento de Especificao de Requisitos(Software Requirements Specificationou SRS) inclui uma combinao dos requisitos do utilizador e do sistema e tem diferentes utilidades para diferentes pessoas2: Clientes: confirmar a completude dos requisitos e propor alteraes. Gestores: oramentar o sistema e planejar o processo de desenvolvimento. Engenheiros: compreender o sistema a desenvolver. Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos. Engenheiros (manuteno): compreender o sistema e a ligao entre as suas partes.Existem diversos padres para este documento, embora no se possa apontar nenhum como o "ideal". Uma estrutura proposta peloIEEEque talvez a mais usada o IEEE/ANSI 830-19933.ValidaoNesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de fato, ao sistema que o cliente pretende. semelhana do que sucede na anlise dos requisitos, pretende-se encontrar problemas/conflitos na especificao, porm ao contrrio das fases anteriores esta fase lida com uma especificaocompletados requisitos.A validao especialmente importante em sistemas de grandes dimenses uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou j depois de o sistema estar a ser usado) no documento de requisitos tm repercusses proporcionais dimenso do projeto. Uma vez que alteraes em requisitos j consolidados tm um custo muito superior a alteraes no cdigo ou design, este tipo de erro traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava j concludo.Durante a fase de validao dosrequisitos, devem ser verificados (atravs dechecklists) os seguintes atributos dos requisitos: Validade: a especificao resulta da anlise dos requisitos identificados junto das diversas partes interessadas envolvidas. Como tal, requisitos identificados individualmente (isto , junto de cada parte interessada) podem diferir da especificao final que se atinge aps o cruzamento de informao e necessrio que cada cliente compreenda e aceite a especificao final obtida. Consistncia: no devem existir conflitos entre os requisitos identificados. Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequvoca pelas partes interessadas. Completude: todas as funcionalidades pretendidas devem fazer parte da especificao do sistema. Realismo: dadas as restries do projeto (tecnolgicas, financeiras e temporais) o sistema especificado tem de ser implementvel. Verificabilidade: de forma a evitar futuras discordncias quanto concretizao dos requisitos especificados, estes devem ser descritos de modo a que seja possvel verificar se foram ou no concretizados, isto , se o sistema final corresponde especificao inicial. Rastreabilidade: a origem dos requisitos, em relao ao cliente, deve estar claramente identificada. Entre outros motivos, isto importante para facilitar a gesto futura dos requisitos. Conformidade com normas: para alm dos aspectos funcionais dos requisitos, a sua especificao deve obedecer s normas usadas ao longo de todo o documento.Tcnicas de validaoPara tornar a validao mais eficaz, existe um conjunto de tcnicas que podem ser empregadas:Revises dos requisitos (Verificao de Validade)Uma equipe de revisores pode analisar sistematicamente a especificao produzida de forma a garantir que esta corresponde ao sistema pretendido; em revises informais, a equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior nmero possvel de representantes das partes interessadas, acerca dos requisitos produzidos; em revises formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critrios que todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos usurios finais), rastreabilidade (a origem dos requisitos deve ser identificvel) e adaptabilidade (capacidade de sofrer alteraes sem produzir efeitos em todos os outros requisitos).Prototipificao(Ou prototipao) A implementao de um prottipo (por exemplo, da interface do sistema) pode ser til para os usurios finais (e demais interessados), j que se trata do elemento do sistema final com o qual tero mais contacto quando o sistema estiver operacional; esta tcnica tambm eficaz, embora tenha desvantagens: o tempo gasto na sua implementao pode no justificar o seu uso, pode enviesar os usurios (levando a desiluses com a verso final do sistema, no caso de esta ser muito diferente do prottipo) e pode ainda levar os programadores a cair na tentao de usar o prottipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o prottipo deva ser implementado noutra linguagem que no aquela usada pelo sistema, eliminando por completo esta tentao).Gerao de casos de testeUma vez que cada requisito deve ser testvel, deveria ser possvel criar (desenhar) os respectivos testes desde a fase de validao de requisitos; se isto no for possvel, sinnimo de que a implementao deste requisito ser difcil e que este poder ter de ser reconsiderado.Anlise de consistncia automticaAtravs da especificao formal de modelos para o sistema possvel, recorrendo a ferramentas adequadas (como asferramentas CASE), testar de forma automtica a consistncia dos modelos criados; apenas a consistncia testada nesta tcnica, pelo que tem de ser complementada com uma das outras tcnicas referidas.RecomendaesA fase de validao no deve ser encarada de nimo leve: trata-se de uma fase muito importante na engenharia de requisitos e da qual dependem elevados custos a mdio e longo prazo.Por depender bastante dos retornos transmitidos pelos clientes (que no so peritos em validao de requisitos) bastante falvel e regra geral h erros que no so encontrados num primeiro momento, o que leva inevitavelmente a discordncias numa fase posterior, j com o documento validado e o projeto em desenvolvimento ou concludo. Quando isto sucede, torna-se necessrio negociar e chegar a um acordo quanto forma de corrigir o erro detectado.Gesto de requisitosOs requisitos de um sistema, em especial em sistemas minimamente grandes, esto em evoluo constante.De um modo geral, isto pode suceder em razo do problema abordado no conseguir ficar completamente definido antes da produo do documento de requisitos (ou mesmo antes de o sistema ser implementado) ou, por outro lado, pode tambm acontecer por os prprios requisitos se alterarem no decorrer do projeto (reflectindo evolues tecnolgicas ou alteraes na organizao na qual usado). natural que surjam requisitos por parte dos usurios por diversos motivos: Conforme j foi referido, a resoluo de conflitos entre requisitos resulta num compromisso que procura equilibrar as necessidades das diferentes partes interessadas. Este equilbrio pode ter de ser modificado e s com o uso do sistema que possvel avali-lo convenientemente. Para alm de conflitos entre requisitos de diferentes usurios do sistema, h ainda a considerar os conflitos entre usurios e "elementos executivos" da organizao, isto , aqueles que tm o poder de deciso e que podem impr requisitos perante os analistas (que podem no contribuir para os objetivos da organizao). A orientao do negcio da organizao pode-se alterar, nova legislao ou regulamentao pode pr em causa alguns dos requisitos do sistema, alteraes a nvel tecnolgico podem surgir na organizao (afetando particularmente, no caso de alteraes dehardware, os requisitos no-funcionais), podem surgir novos sistemas que precisem de suporte, a nvel de interao, por parte do sistema implementado, e toda uma srie de alteraes imprevisveis pode surgir levando a que o sistema tenha de se adaptar a todo este tipo de requisitos.Existem requisitos que, tipicamente, so mais volteis do que outros (como por exemplo requisitos que dependam da entidade poltica governante num dado momento), enquanto que outros so relativamente estveis (os que se referem natureza do negcio (domnio) propriamente dita).Na prtica, a gesto de requisitos acaba por coincidir com o incio de novos processos de engenharia de requisitos (para os "novos" requisitos, isto , os "antigos" que sofreram alteraes). Como tal, o planejamento uma parte importante da gesto de requisitos. Devem estar definidas desde o incio da gesto de requisitos polticas para: Identificao de requisitos: identificao unvoca em especial para facilitar a rastreabilidade. Processo de gesto de mudanas a utilizar: conjunto de atividades que permitem avaliar o custo e impacto das alteraes. Rastreabilidade: relaes entre os requisitos e relaes entre requisitos e design; estas podem precisar de manter associada a cada requisito informao como a parte interessada que a props, dependncias de outros requisitos e associao a mdulos especficos do design do sistema. Ferramentas a utilizar: para sistemas grandes, a quantidade de informao a processar pode ser elevada, sendo o uso deferramentas CASEaconselhado.Para manter a consistncia entre as vrias alteraes pedidas (e para estas serem feitas de um modo controlado), importante que o processo de gesto de mudanas esteja definido de um modo formal, sendo que dever incluir as seguintes trs fases: Anlise do problema e especificao da alterao a fazer: identificao do problema existente nos requisitos originais e proposta de alterao a fazer aos requisitos do sistema. Anlise da alterao e seu impacto: atravs das polticas de rastreabilidade definidas previamente, avaliao do impacto da alterao no sistema. Implementao da alterao: alterao no documento de requisitos e, conforme seja necessrio, no design e implementao. importante seguir este processo conforme foi enunciado j que cair na tentao de implementar a alterao diretamente e s depois, retrospectivamente, atualizar os requisitos pode levar a dessincronizao entre requisitos e implementao.