Processo de Engenharia de Requisitos
Upcoming SlideShare
Loading in...5
×
 

Processo de Engenharia de Requisitos

on

  • 4,757 views

 

Statistics

Views

Total Views
4,757
Views on SlideShare
4,735
Embed Views
22

Actions

Likes
0
Downloads
147
Comments
0

2 Embeds 22

http://www.slideshare.net 21
https://www.galileo.edu 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Processo de Engenharia de Requisitos Processo de Engenharia de Requisitos Presentation Transcript

  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos Processo de Engenharia de Requisitos Origem: Wikipédia, a enciclopédia livre. A engenharia de requisitos (no contexto da engenharia de software) é um processo que engloba todas as actividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. Este processo deve ser precedido de estudos de viabilidade que, a partir das restrições do projecto, determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. O processo de engenharia de requisitos é composto por quatro actividades de alto nível (Soares, 2005): 1. Identificação. 2. Análise e negociação. 3. Especificação e documentação. 4. Validação. Uma outra actividade que se pode considerar que faz também parte deste processo, se incluirmos a fase posterior à produção do documento (isto é, a sua quot;manutençãoquot;), é a gestão dos requisitos (change management (http://en.wikipedia.org/wiki/Change_management#Change_management_in_information_technology) , sendo que as alterações podem ser causadas pelos mais diversos factores desde inovações tecnológicas a mudanças na natureza do negócio (e consequentemente nos requisitos), entre outras). Índice Estudos de viabilidade Antes de se avançar com uma análise 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 se, de um ponto de vista tecnológico e organizacional, o projeto é viável. Uma forma de avaliar a viabilidade de um projeto é obter, através da interacção com quot;as partes interessadasquot; (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas, por exemplo), a resposta às seguintes questões: Será que o sistema contribui para os objetivos da organização? Dadas as restrições tecnológicas, organizacionais (econômicas, políticas, ambientais, recursos disponíveis) e temporais associadas ao projeto, será que o sistema pode ser implementado? Caso haja necessidade de integração entre diferentes sistemas, será que esta é possível? A questão mais crítica é a primeira, já que um sistema que não contribua para os objetivos da organização não lhe traz qualquer valor acrescentado e como tal a sua existência não se justifica. Apesar de parecer óbvia, são frequentemente desenvolvidos sistemas que não contribuem para os objectivos das respectivas organizações, quer seja por interesses externos (políticos ou organizacionais) ou por falta de clareza na definição dos objetivos da organização. Deve portanto identificar-se que informação é necessária para responder a estas questões e quem possui esta informação, procedendo-se de seguida à recolha de todos os dados disponíveis para clarificar ao máximo o âmbito do projeto e avaliar a sua viabilidade. Tipicamente, quem poderá fornecer esta informação serão os utilizadores dos sistemas actuais e do sistema a 1 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos implementar, os responsáveis pelos departamentos nos quais o sistema será usado, técnicos que estejam familiarizados com as tecnologias envolvidas (do novo sistema e dos sistemas existentes), responsáveis pela manutenção futura do sistema a implementar e, de um modo geral, todos aqueles que terão qualquer tipo de interação com o novo sistema (ou que sejam por ele afetados). Algumas das questões que podem ser postas nesta coleta de informações são, por exemplo: Se o novo sistema não fosse implementado, quais seriam as alternativas para a organização? Quais são os problemas que os sistemas atuais apresentam e como é que um sistema novo irá resolver estas falhas? De que forma é que o sistema irá contribuir diretamente para os objetivos da organização? É possível a integração com os outros sistemas da organização (de um ponto de vista tecnológico)? Com que facilidade é que se consegue partilhar informação entre estes sistemas? O estudo de viabilidade deverá culminar com a produção de um relatório e deverá determinar a continuação do desenvolvimento do projeto, tornando mais claras as restrições (econômicas, temporais e organizacionais) do projeto e definindo mesmo alguns requisitos de alto nível. Identificação Caso se determine que o projecto é viável, o passo seguinte é a identificação dos requisitos. Atividades envolvidas Algumas das atividades envolvidas nesta fase incluem: Compreensão do domínio: é muito importante para o analista compreender o domínio no qual a organização e o projecto se inserem; quanto maior for o conhecimento acerca do domínio, mais eficaz será a comunicação entre o analista e as partes interessadas. Identificação das partes interessadas: estes já deverão ter sido identificados nos estudos de viabilidade, porém para efeitos de identificação de requisitos convém concentrar as atenções nos utilizadores do sistema. Captura: consiste na obtenção com o cliente dos requisitos (funcionais e não-funcionais) pretendidos para o sistema. Identificação e análise de problemas: os problemas devem ser identificados (e a sua definição deve ser consensual) e devem ser propostas soluções em conjunto com as partes interessadas. Dificuldades Esta fase não é trivial, sendo que existem algumas dificuldades típicas que lhe estão associadas: O cliente pode não saber exatamente o que deseja para o sistema, ou sabê-lo mas não conseguir articulá-lo. Os requisitos identificados podem não ser realistas (do ponto de vista econômico ou tecnológico, por exemplo). Cada parte interessada pode expressar os mesmos requisitos de formas diferentes, sendo necessário - através de um bom conhecimento do domínio - identificar estas situações. Técnicas para elicitação de requisitos Existem diversas técnicas de identificação de requisitos, e que são adequadas a diferentes situações, entre as quais podemos citar: Entrevistas e Questionários Entrevistas e Questionários é talvez a técnica mais simples de utilizar. Ainda que seja bastante eficaz numa fase inicial de obtenção de dados (e mesmo de esclarecimento de algumas dúvidas), está condicionada a alguns factores: 2 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos Influência do entrevistador nas respostas do cliente: convém que o entrevistador dê margem ao entrevistado para expor as suas ideias sem as enviesar logo à partida. Relação pessoal entre os intervenientes na entrevista. Predisposição do entrevistado: caso, por exemplo, o papel do entrevistado venha a ser afectado pela introdução de um sistema na organização, este pode propositadamente dificultar o acesso à informação. Capacidade de seguir um quot;planoquot; para a entrevista: na ausência destes planos é natural que haja tendência 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 tentação de quot;querer despacharquot; sendo os últimos pontos da entrevista abordados de forma superficial (ou podem nem chegar a ser abordados). Workshops de requisitos O Workshops de Requisitos consiste numa técnica usada para através de uma reunião estruturada, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente[1], obter um conjunto de requisitos bem definidos. Ao contrário das reuniões, promove-se a interacção entre todos os elementos presentes no workshop fomentando momentos de descontracção como forma de dinamizar o trabalho em equipe, existindo um facilitador neutro cujo papel é conduzir a workshop e promover a discussão entre os vários intervenientes (ainda que não tenha realmente poder de decisão). As tomadas de decisão devem seguir processos bem definidos e devem resultar de um processo de negociação, mediado pelo facilitador. Uma técnica que é também útil em workshops é o uso de brainstorming (tempestade de idéias) como forma de gerar um elevado número de ideias numa pequena quantidade de tempo. Como resultado dos workshops deve ser produzida documentação que reflita os requisitos e decisões tomadas sobre o sistema a implementar. Cenários Uma forma de levar as pessoas a imaginarem o comportamento de um sistema é o uso de cenários. Através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento e da interacção que esperam ter com ele. Trata-se de uma abordagem informal, prática e aplicável a qualquer tipo de sistema. De um modo geral, os cenários devem incluir os seguintes elementos: Estado do sistema no início do cenário. Sequência de eventos esperada (na ausência de erros) no cenário. Listagem de erros que podem ocorrer no decorrer dos eventos do cenário e de como estes erros serão tratados. Outras actividades que podem estar a ser executadas ao mesmo tempo que as deste cenário. Estado do sistema depois de o cenário terminar. Prototipagem O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos (por exemplo na identificação, análise e validação). Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis. Neste tipo de abordagem apenas são desenvolvidas algumas funcionalidades sendo normalmente desenvolvidas primeiro aquelas que são mais fáceis de compreender por parte do utilizador e que lhe podem trazer maior valor acrescentado (principalmente na prototipificação evolutiva, isto é, aquela que mais tarde é evoluída para a fase de desenvolvimento). O uso de protótipos deve ser considerado apenas mediante uma análise custo-benefício, já que os custos de desenvolvimento de um protótipo podem facilmente crescer, sendo particularmente úteis em situações em que a interface com os utilizadores é, para eles, um aspecto crítico. Estudo etnográfico Os Estudos Etnográficos são uma análise da componente social das tarefas desempenhadas numa dada organização. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa, é de esperar que esta sinta 3 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo. Através de uma observação directa das actividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. Esta observação pode ser acompanhada de registos áudio/vídeo, porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções quot;correctamentequot;, pelo que convém ter algum cuidado na escolha do mesmo. Análise e negociação dos requisitos Após a identificação dos requisitos do sistema, segue-se à etapa de análise e negociação dos mesmos. Atividades envolvidas Algumas das atividades envolvidas na análise de requisitos incluem: Classificação: agrupamento de requisitos em quot;módulosquot; para facilitar a visão global do funcionamento pretendido para o sistema. Resolução de conflitos: dada a multiplicidade e diversidade de papéis das partes interessadas envolvidas na captura e análise de requisitos, é inevitável a existência de conflitos nos requisitos identificados; é importante resolver estes conflitos o mais breve possível. Prioritização: consiste na atribuição de uma quot;prioridadequot; a cada requisito (por exemplo elevada/média/baixa); obviamente, este pode ser um factor gerador de conflitos. Confirmação: é confirmada com as partes interessadas a completude dos requisitos, sua consistência e validade (de acordo com o que se pretende do sistema). Estas fases não são independentes entre si, pois uma informação obtida numa delas pode servir inclusive para as demais fases. A identificação e análise de requisitos é um processo iterativo que se inicia com a familiarização do domínio do futuro sistema e termina na confirmação dos requisitos, aumentando o grau de compreendimento do sistema a cada ciclo de trabalho. Dificuldades As dificuldades encontradas na análise são de diversas naturezas: Factores externos (políticos) podem influenciar os requisitos (alguma parte interessada, com poder de decisão, pode exigir requisitos específicos que sirvam aos seus interesses e não aos da organização, ou forçar o seu ponto de vista em detrimento dos demais interessados que irão operar o sistema). O ambiente (económico e/ou organizacional) em que a análise é feita é possue fatores dinâmicos, e como tal os requisitos estão sujeitos a alterações em decorrência destes (por exemplo: novas partes interessadas são envolvidas no projeto, ou alterações em prazos e orçamentos disponíveis). Negociações Relativo à negociação, torna-se necessário ter alguns cuidados para que esta decorra sem problemas, chegando-se logo a consensos. Para tanto, faz-se algumas sugestões: Saber lidar com ataques pessoais (evitando-os sempre que possível, remetendo a sua resolução para mais tarde, fora de reunião), de preferência nunca tomando partidos. Fomentar a justificação das posições (negativas) tomadas pelos intervenientes na negociação. Salientar (e procurar encontrar) os benefícios que uma solução apresenta para todos os envolvidos. Relaxar restrições, quando se torna óbvio que as actuais não conseguem levar a um consenso. Especificação e documentação 4 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos É nesta fase que se dá a produção propriamente dita do documento de especificação de requisitos. Em todos os tipos de especificação 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 ofereça, atendendo aos propósitos para qual o sistema será desenvolvido. Requisitos não-funcionais: referem-se a aspectos não-funcionais do sistema, como restrições nas quais o sistema deve operar ou propriedades emergentes do sistema. Costumam ser divididos em Requisitos não-funcionais de: Utilidade, Confiança, Desempenho, Suporte e Escalabilidade. Pode-se também considerar os requisitos do domínio, que tal como o nome indica derivam do domínio e não de necessidades específicas dos utilizadores, podendo depois ser classificados como funcionais ou não-funcionais. A documentação produzida poderá ter diferentes destinatários e como tal diferentes objectivos. Podem-se distinguir três tipos de especificação: Especificação de requisitos do utilizador. Especificação de requisitos do sistema. Especificação do design da aplicação. A vantagem de conceber mais do que uma especificação para um dado sistema é a de em cada especificação se comunicar apenas um determinado tipo de informação adequado ao leitor a que se destina (usando quot;linguagensquot; que o utilizador conheça). Por exemplo, enquanto que nos requisitos do utilizador apenas é feita uma abordagem de alto nível das funcionalidades do sistema e suas restrições, 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 (notações gráficos como diagramas de casos de uso). Requisitos do utilizador Os requisitos do utilizador destinam-se portanto aos vários níveis hierárquicos da organização na qual o sistema será implementado (desde gestores a utilizadores), pelo que são descritos usando apenas (conforme já foi referido) linguagem natural, formulários e diagramas muito simples. Obviamente, neste nível de especificação surgem algumas dificuldades: Ambiguidade: torna-se difícil descrever os requisitos de uma forma inequívoca sem tornar a sua descrição muito longa ou de difícil compreensão. Confusão: ainda que possa não ser tão relevante do ponto de vista do cliente, a distinção entre requisitos funcionais/não-funcionais e objectivos do sistema torna-se difícil. Agrupamento de requisitos: ao descrever as funcionalidades de um sistema, pode tornar-se difícil separar claramente os requisitos, o que leva a que vários requisitos sejam expressos como sendo apenas um. Algumas considerações úteis a ter em conta ao escrever uma especificação de requisitos do utilizador: Usar o mesmo formato em todos os requisitos (evitam-se omissões e facilita-se a verificação dos requisitos). Distinguir claramente entre comportamentos esperados e desejáveis do sistema através do uso de expressões como quot;O sistema permitirá criar (...)quot; ou quot;Deverá ser possível criar (...)quot; respectivamente. É importante deixar claro o que o sistema tem de fazer e sugestões de como o deve fazer e, acima de tudo, usar este tipo de expressões de forma consistente ao longo de todo o documento. Usar formatação de texto para salientar determinados aspectos do documento (usando negrito, por exemplo). Evitar usar termos demasiado técnicos ou fora do âmbito do sistema, identificando-os e definindo-os de uma forma clara quando for absolutamente necessário usá-los. Requisitos do sistema Os requisitos do sistema têm um carácter mais técnico, consistindo numa descrição detalhada dos requisitos do utilizador correspondentes recorrendo ao uso, para além da linguagem natural, de linguagens estruturadas e 5 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos notações gráficas. Estes requisitos destinam-se ainda aos utilizadores do sistema (e particularmente aos engenheiros que trabalhem nessa organização) e destinam-se também às equipes de especificação 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 interpretação 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 descrições diferentes se referem ou não a requisitos diferentes. Design de aplicação Por fim, a especificação do design da aplicação consiste num documento usado pela equipe de desenvolvimento do sistema no qual estão definidos pormenores, a um nível mais técnico, acerca da implementação do sistema e sua arquitetura. A partir deste documento, um elemento que entre para a equipe de desenvolvimento a meio do projeto deverá ser capaz de quot;se situarquot; quando precisar de começar a codificar, compreendendo a forma como a implementação, a um nível global, está a ser feita, mas sem conhecer necessariamente os detalhes de implementação dos componentes mais pequenos. Não convém cair na tentação de deixar toda a implementação detalhada, uma vez que convém que os desenvolvedores tenham alguma margem de manobra tanto para inovar como para resolver problemas encontrados em sub-sistemas de formas que uma especificação inicial da arquitetura não consegue prever. Documento de Especificação de Requisitos Apesar da existência dos 3 tipos de especificação vistos nos itens anteriores, existe uma especificação que é a usada como declaração oficial dos requisitos do sistema. Este documento, normalmente chamado de Documento de Especificação de Requisitos (Software Requirements Specification ou SRS) inclui uma combinação dos requisitos do utilizador e do sistema e tem diferentes utilidades para diferentes pessoas (Kotonya e Sommerville, 1998): Clientes: confirmar a completude dos requisitos e propor alterações. Gestores: orçamentar o sistema e planear o processo de desenvolvimento. Engenheiros: compreender o sistema a desenvolver. Engenheiros (testes): desenvolver testes para validar o cumprimento dos requisitos. Engenheiros (manutenção): compreender o sistema e a ligação entre as suas partes. Existem diversos padrões para este documento, embora não se possa apontar nenhum como o quot;idealquot;. Uma estrutura proposta pelo IEEE que é talvez a mais usada é o IEEE/ANSI 830-1993 (Thayer e Dorfman, 1993). Validação Nesta fase pretende-se demonstrar que o documento de requisitos produzido corresponde, de facto, ao sistema que o cliente pretende. À semelhança do que sucede na análise dos requisitos, pretende-se encontrar problemas/conflitos na especificação, porém ao contrário das fases anteriores esta fase lida com uma especificação completa dos requisitos. A validação é especialmente importante em sistemas de grandes dimensões uma vez que erros encontrados demasiado tarde (durante o desenvolvimento ou já depois de o sistema estar a ser usado) no documento de requisitos têm repercussões proporcionais à dimensão do projecto. Uma vez que alterações em requisitos já consolidados têm um custo muito superior a alterações no código ou design, este tipo de erros traduz-se em elevados custos e necessidade de refazer muito do trabalho que se julgava já concluído. Durante a fase de validação dos requisitos, devem ser verificados (através de checklists) os seguintes atributos dos requisitos: Validade: a especificação resulta da análise dos requisitos identificados junto das diversas partes 6 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos interessadas envolvidas. Como tal, requisitos identificados individualmente (isto é, junto de cada parte interessada) podem diferir da especificação final que se atinge após o cruzamento de informação e é necessário que cada cliente compreenda e aceite a especificação final obtida. Consistência: não devem existir conflitos entre os requisitos identificados. Compreensibilidade / Ambiguidade: os requisitos devem poder ser compreendidos de forma inequívoca pelas partes interessadas. Completude: todas as funcionalidades pretendidas devem fazer parte da especificação do sistema. Realismo: dadas as restrições do projecto (tecnológicas, financeiras e temporais) o sistema especificado tem de ser implementável. Verificabilidade: de forma a evitar futuras discordâncias quanto à concretização dos requisitos especificados, estes devem ser descritos de modo a que seja possível verificar se foram ou não concretizados, isto é, se o sistema final corresponde à especificação inicial. Rastreabilidade: a origem dos requisitos, em relação ao cliente, deve estar claramente identificada. Entre outros motivos, isto é importante para facilitar a gestão futura dos requisitos. Conformidade com normas: para além dos aspectos funcionais dos requisitos, a sua especificação deve obedecer às normas usadas ao longo de todo o documento. Técnicas de validação Para tornar a validação mais eficaz, existe um conjunto de técnicas que podem ser empregues: Revisões dos requisitos Uma equipe de revisores pode analisar sistematicamente a especificação produzida de forma a garantir que esta corresponde ao sistema pretendido; em revisões informais, a equipe de revisores pode simplesmente ter uma conversa, envolvendo o maior número possível de representantes das partes interessadas, acerca dos requisitos produzidos; em revisões formais, a equipe de revisores deve confirmar junto do cliente um conjunto de critérios que todos os requisitos devem cumprir, nomeadamente: verificabilidade, compreensibilidade (por parte dos utilizadores finais), rastreabilidade (a origem dos requisitos deve ser identificável) e adaptabilidade (capacidade de sofrer alterações sem produzir efeitos em todos os outros requisitos). Prototipificação A implementação de um protótipo (por exemplo, da interface do sistema) pode ser útil para os utilizadores finais (e demais interessados), já que se trata do elemento do sistema final com o qual terão mais contacto quando o sistema estiver operacional; esta técnica também é eficaz, embora tenha desvantagens: o tempo gasto na sua implementação pode não justificar o seu uso, pode enviesar os utilizadores (levando a desilusões com a versão final do sistema, no caso de esta ser muito diferente do protótipo) e pode ainda levar os programadores a cair na tentação de usar o protótipo para continuar o desenvolvimento do sistema (pelo que, idealmente, o protótipo deva ser implementado noutra linguagem que não aquela usada pelo sistema, eliminando por completo esta tentação). Geração de casos de teste Uma vez que cada requisito deve ser testável, deveria ser possível criar (desenhar) os respectivos testes desde a fase de validação de requisitos; se isto não for possível, é sinónimo de que a implementação deste requisito será difícil e que este poderá ter de ser reconsiderado. Análise de consistência automática Através da especificação formal de modelos para o sistema é possível, recorrendo a ferramentas adequadas (como as ferramentas CASE), testar de forma automática a consistência dos modelos criados; apenas a consistência é testada nesta técnica, pelo que tem de ser complementada com uma das outras técnicas referidas. Recomendações 7 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos A fase de validação não deve ser encarada de ânimo leve: trata-se de uma fase muito importante na engenharia de requisitos e da qual dependem elevados custos a médio e longo prazo. Por depender bastante dos retornos transmitidos pelos clientes (que não são peritos em validação de requisitos) é bastante falível e regra geral há erros que não são encontrados num primeiro momento, o que leva inevitavelmente a discordâncias numa fase posterior, já com o documento validado e o projecto em desenvolvimento ou concluído. Quando isto sucede, torna-se necessário negociar e chegar a um acordo quanto à forma de corrigir o erro detectado. Gestão de requisitos Os requisitos de um sistema, em especial em sistemas minimamente grandes, estão em evolução constante. De um modo geral, isto pode suceder por o problema abordado não conseguir ficar completamente definido antes da produção do documento de requisitos (ou mesmo antes de o sistema ser implementado) ou, por outro lado, pode também acontecer por os próprios requisitos se alterarem no decorrer do projecto (reflectindo evoluções tecnológicas ou alterações na organização na qual é usado). É natural que surjam requisitos por parte dos utilizadores por diversos motivos: Conforme já foi referido, a resolução de conflitos entre requisitos resulta num compromisso que procura equilibrar as necessidades das diferentes partes interessadas. Este equilíbrio pode ter de ser modificado e só com o uso do sistema é que é possível avaliá-lo convenientemente. Para além de conflitos entre requisitos de diferentes utilizadores do sistema, há ainda a considerar os conflitos entre utilizadores e quot;elementos executivosquot; da organização, isto é, aqueles que têm o poder de decisão e que podem impôr requisitos perante os analistas (que podem não contribuir para os objectivos da organização). A orientação do negócio da organização pode-se alterar, nova legislação ou regulamentação pode pôr em causa alguns dos requisitos do sistema, alterações a nível tecnológico podem surgir na organização (afectando particularmente, no caso de alterações de hardware, os requisitos não-funcionais), podem surgir novos sistemas que precisem de suporte, a nível de interacção, por parte do sistema implementado, e toda uma série de alterações imprevisíveis pode surgir levando a que o sistema tenha de se adaptar a todo este tipo de requisitos. Existem requisitos que, tipicamente, são mais voláteis do que outros (como por exemplo requisitos que dependam da entidade política governante num dado momento), enquanto que outros são relativamente estáveis (os que se referem à natureza do negócio (domínio) propriamente dita). Na prática, a gestão de requisitos acaba por coincidir com o início de novos processos de engenharia de requisitos (para os quot;novosquot; requisitos, isto é, os quot;antigosquot; que sofreram alterações). Como tal, o planejamento é uma parte importante da gestão de requisitos. Devem estar definidas desde o início da gestão de requisitos políticas para: Identificação de requisitos: identificação unívoca em especial para facilitar a rastreabilidade. Processo de gestão de mudanças a utilizar: conjunto de actividades que permitem avaliar o custo e impacto das alterações. Rastreabilidade: relações entre os requisitos e relações entre requisitos e design; estas podem precisar de manter associada a cada requisito informação como a parte interessada que a propôs, dependências de outros requisitos e associação a módulos específicos do design do sistema. Ferramentas a utilizar: para sistemas grandes, a quantidade de informação a processar pode ser elevada, sendo o uso de ferramentas CASE aconselhado. Para manter a consistência entre as várias alterações pedidas (e para estas serem feitas de um modo controlado), é importante que o processo de gestão de mudanças esteja definido de um modo formal, sendo que deverá incluir as seguintes três fases: Análise do problema e especificação da alteração a fazer: identificação do problema existente nos requisitos originais e proposta de alteração a fazer aos requisitos do sistema. Análise da alteração e seu impacto: através das políticas de rastreabilidade definidas previamente, avaliação do impacto da alteração no sistema. 8 of 9 8/3/2008 03:42
  • Processo de Engenharia de Requisitos - Wikipédia http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitos Implementação da alteração: alteração no documento de requisitos e, conforme seja necessário, no design e implementação. É importante seguir este processo conforme foi enunciado já que cair na tentação de implementar a alteração directamente e só depois, retrospectivamente, actualizar os requisitos pode levar a dessincronização entre requisitos e implementação. Notas 1. ↑ este grupo deve ser escolhido levando-se em conta a organização e o contexto em que o sistema será usado Referências Kotonya e Sommerville (1998). Requirements Engineering: Processes and Techniques. Gerald Kotonya, Ian Sommerville. Wiley. 1998. Sommerville (2001). Software Engineering. Ian Sommerville. Addison Wesley. 2001. Thayer e Dorfman (1993). Software Requirements Engineering. R. H. Thayer, M. Dorfman. IEEE Computer Society Press. 1993. Soares (2005). Introdução, Identificação e Análise em Engenharia de Requisitos. António Lucas Soares. 2005. Obtido em quot;http://pt.wikipedia.org/wiki/Processo_de_Engenharia_de_Requisitosquot; Categoria: Engenharia de Requisitos Esta página foi modificada pela última vez a 22h56min, 9 de Dezembro de 2007. O texto desta página está sob a GNU Free Documentation License. Os direitos autorais de todas as contribuições para a Wikipédia pertencem aos seus respectivos autores (mais informações em direitos autorais). 9 of 9 8/3/2008 03:42