Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb 1.

1. INTRODUO O completo entendimento dos requisitos de software um ponto fundamental para o sucesso de um projeto de software. Independente da preciso com a qual um software venha a ser projetado e implementado, ele certamente trar problemas ao cliente/usurio se a sua anlise de requisitos foi mal realizada. A Anlise de Requisitos uma tarefa que envolve, antes de tudo um trabalho de descoberta, refinamento, modelagem e especificao das necessidades e desejos relativos ao software que dever ser desenvolvido. Nesta tarefa, tanto o cliente como o desenvolvedor vo desempenhar um papel de grande importncia, uma vez que caber ao primeiro a formulao (de modo concreto) das necessidades em termos de funes e desempenho, enquanto o segundo atua como indagador, consultor e solucionador de problemas. Esta etapa de suma importncia no processo de desenvolvimento de um software, principalmente porque ela estabelece o elo de ligao entre a alocao do software a nvel de sistema (realizada na etapa de Engenharia de Sistema) e o projeto do software. Desta forma, ela permite que o engenheiro de sistemas especifique as necessidades do software em termos de funes e de desempenho, estabelea as interfaces do software com os demais elementos do sistema e especifique as restries de projeto. Ao engenheiro de software (ou analista), a anlise de requisitos permite uma alocao mais precisa do software no sistema e a construo de modelos do processo, dos dados e dos aspectos comportamentais que sero tratados pelo software. Ao projetista, esta etapa proporciona a obteno de uma representao da informao e das funes que poder ser traduzida em projeto procedimental, arquitetnico e de dados. Alm disso, possvel definir os critrios de avaliao da qualidade do software a serem verificados uma vez que o software esteja concludo.

2. AS ATIVIDADES DA ANLISE DE REQUISITOS A etapa de Anlise de Requisitos caracterizada basicamente pela realizao de um conjunto de tarefas, as quais sero discutidas nas sees que seguem. 2.1. A Anlise do Problema Nesta tarefa inicial, o analista estuda os documentos de Especificao do Sistema e o Plano do Software, como forma de entender o posicionamento do software no sistema e revisar o escopo do software utilizado para definir as estimativas de projeto. Um elo de comunicao entre o analista e o pessoal da organizao cliente deve ser estabelecido, sendo que o gerente de projetos pode atuar na coordenao dos contatos. A meta do analista neste contexto identificar os principais fatores do problema a ser resolvido, pela tica do cliente.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb 2.2. A Avaliao e Sntese Esta segunda tarefa envolve principalmente uma anlise dos fluxos de informao e a elaborao de todas as funes de tratamento e os aspectos de comportamento do software. Ainda, importante que uma definio de todas as questes relacionadas interface com o sistema, alm de uma especificao das restries de projeto. Terminada a anlise, o analista pode iniciar a sntese de uma ou mais solues para o problema. Na sntese das eventuais solues, o analista deve levar em conta as estimativas e as restries de projeto. Este processo de avaliao e sntese prossegue at que o analista e o cliente estejam de acordo sobre a adequao das especificaes realizadas para a continuidade do processo. 2.3. A Modelagem A partir da tarefa de avaliao e sntese, o analista pode estabelecer um modelo do sistema, o qual permitir uma melhor compreenso dos fluxos de informao e de controle, assim como dos aspectos funcionais e de comportamento. Este modelo, ainda distante de um projeto detalhado, servir de referncia s atividades de projeto, assim como para a criao da especificao de requisitos. Em muitas situaes, como forma de reforar o conhecimento sobre a viabilidade do software a ser desenvolvido, pode ser necessrio o desenvolvimento de um prottipo de software como alternativa ou como trabalho paralelo anlise de requisitos. Este ponto ser discutido mais adiante neste documento. 2.4. Especificao dos Requisitos e Reviso A etapa de Anlise de Requisitos culmina com a produo de um documento de Especificao de Requisitos de Software, o qual registra os resultados das tarefas realizadas. Eventualmente, pode ser produzido como documento adicional um Manual Preliminar do Usurio. Embora parea estranho, a produo deste manual permite que o analista passe a olhar para o software da tica do cliente/usurio, o que pode ser bastante interessante, principalmente em sistemas interativos. Alm disso, a posse de um Manual de Usurio, mesmo em estgio preliminar permite ao cliente uma reviso dos requisitos (de interface, pelo menos) ainda num estgio bastante prematuro do desenvolvimento de software. Desta forma, algumas decepes resultante de uma m definio de alguns aspectos do software podem ser evitadas. 3. PROCESSOS DE COMUNICAO O desenvolvimento de um software , na maior parte dos casos, motivado pelas necessidades de um cliente, que deseje automatizar um sistema existente ou obter um novo sistema completamente automatizado. O software, porm, desenvolvido por um desenvolvedor ou por uma equipe de desenvolvedores. Uma vez desenvolvido, o software ser provavelmente utilizado por usurios finais, os quais no so necessariamente os clientes que originaram o sistema.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb Isto significa que, de fato, existem trs partes envolvidas no processo de desenvolvimento de um produto de software: o cliente, o desenvolvedor e os usurios. Para que o processo de desenvolvimento seja conduzido com sucesso, necessrio que os desejos do cliente e as expectativas dos eventuais usurios finais do sistema sejam precisamente transmitidos ao desenvolvedor. Este processo de transmisso de requisitos, do cliente e dos usurios ao desenvolvedor, invariavelmente apresenta relativa dificuldade, considerando alguns aspectos: geralmente, os clientes no entendem de software ou do processo de desenvolvimento de um programa; o desenvolvedor, usualmente, no entende do sistema no qual o software vai executar. Estes dois aspectos provam que existem, efetivamente, um problema de comunicao a ser resolvido para que o processo de desenvolvimento seja bem sucedido. A importncia desta etapa est no fato de que atravs dela que as idias do cliente sobre o problema a ser resolvido pelo sistema a desenvolver so expressas na forma de um documento, se possvel, que utilize ferramentas formais. Uma Anlise de Requisitos bem sucedida deve, normalmente, representar corretamente as necessidades do cliente e dos usurios, satisfazendo, porm s trs partes envolvidas (incluindo o desenvolvedor). O que verificado, em boa parte dos projetos de software que o cliente nem sempre entende perfeitamente quais so as suas reais necessidades, assim como os usurios tm dificuldades para exprimir as suas expectativas com relao ao que est sendo desenvolvido. Um primeiro resultado desta etapa deve ser, sem dvida, o esclarecimento a respeito do que so estas necessidades e expectativas. A obteno bem sucedida de informaes um fator preponderante para o sucesso da Anlise de Requisitos, particularmente nas duas primeiras tarefas descritas anteriormente. A compilao das informaes relevantes para o processo de desenvolvimento uma tarefa bastante complexa, principalmente porque entram, muitas vezes, em jogo um conjunto de informaes conflitantes. Ainda, quanto mais complexo o sistema a ser desenvolvido, mais inconsistncia haver com relao s informaes obtidas. Neste contexto, o analista deve ter bom senso e experincia para extrair de todo o processo de comunicao as "boas" informaes.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb

4. PRINCPIOS DE ANLISE Independente do mtodo utilizado para realizar a anlise de requisitos, existem algumas preocupaes que so comuns a todos eles, os quais discutiremos nos pargrafos que seguem. 4.1. O Domnio de Informao Todo software construdo com a funo bsica de processar dados, no importa a rea de atuao considerada. Como j discutimos no captulo anterior, possvel representar um software na sua concepo mais clssica como um sistema que recebe um conjunto de informaes (ou dados) de entrada, realiza o tratamento ou processamento desta informao e produz informaes de sada. Alm dos dados, um software capaz de processar eventos, onde cada evento est relacionado a um aspecto de controle do sistema, como por exemplo, um sensor que capaz de detectar a ultrapassagem de um determinado limite de presso ou temperatura pode gerar um evento (um sinal de alarme) para que o software de monitorao alerte o operador ou efetue alguma ao previamente definida. Isto significa que os dados e os eventos fazem parte do domnio de informao do software, sendo que basicamente trs pontos de vista podem ser considerados para abordar esta questo: o fluxo da informao, o qual representa a forma pela qual os dados e os eventos se modificam ao longo do sistema. o que pode ajudar a determinar quais so as transformaes essenciais s quais os itens de informao so submetidos; o contedo da informao, que permite representar os dados e os eventos que estejam relacionados a um determinado item de informao (semntica da informao); a estrutura da informao, a qual permite expressar a forma como itens de dados e/ou eventos esto organizados (sintaxe da informao); esta informao pode vir a ser importante para a etapa de projeto e implementao das estruturas de informao via software (linguagens de programao). 4.2. Modelagem A modelagem um outro aspecto de importncia no processo de anlise de requisitos de um software, uma vez que ela permite uma melhor compreenso das questes arquiteturais e comportamentais do problema a ser resolvido com o auxlio do software. Uma boa modelagem de software deve permitir a representao da informao a ser transformada pelo software, das funes (ou sub-funes) responsveis das transformaes e do comportamento do sistema durante a ocorrncia destas transformaes. Um modelo realizado durante a etapa de Anlise de Requisitos deve concentrar-se na representao do que o software deve realizar e no em como ele o realiza. Normalmente, 4

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb desejvel que os modelos sejam expressos atravs de uma notao grfica que permita descrever os diferentes aspectos citados no pargrafo anterior. Nada impede, porm, que um modelo seja dotado de descries textuais complementares, sendo que normalmente, estas descries devem ser realizadas ou por meio de linguagem natural ou de uma linguagem especializada que permita expressar, sem ambigidades, os requisitos estabelecidos. A obteno de um modelo representativo dos requisitos do software pode ser til s diferentes partes envolvidas no desenvolvimento do software: ao analista, para uma melhor compreenso da informao, as funes e o comportamento do sistema, o que pode tornar a tarefa de anlise mais sistemtica; ao pessoal tcnico como um todo, uma vez que ele pode ser uma referncia de reviso, permitindo a verificao de algumas propriedades, como a completude, a coerncia e a preciso da especificao; ao projetista, servindo de base para o projeto atravs da representao dos aspectos essenciais do software. 4.3. Particionamento Em boa parte das vezes, os problemas a serem resolvidos so excessivamente complexos, apresentando grande dificuldade para a sua compreenso (e conseqente resoluo) como um todo. Com a finalidade de dominar de forma completa os problemas sob anlise, um princpio fundamental a decomposio do mesmo em partes menores, o que denominaremos de particionamento. A partir do particionamento de um problema e a partir da anlise de cada parte estabelecida, o entendimento fica mais facilitado. Desta forma, possvel estabelecer as interfaces de cada parte do problema de modo a que a funo global do software seja realizada. Segundo este princpio, as funes, os aspectos de comportamento e as informaes a serem manipuladas pelo programa podero ser alocadas s diferentes partes. De um ponto de vista genrico, o procedimento bsico de particionamento o estabelecimento de uma estrutura hierarquizada de representao da funo ou da informao dividindo em parties o elemento superior, esta diviso podendo ser efetuada segundo uma abordagem vertical (deslocando-se verticalmente na hierarquia) ou horizontal. As figuras 5.1 e 5.2 representam a aplicao sobre um exemplo das abordagens horizontal e vertical, respectivamente. No caso dos exemplos ilustrativos, o particionamento realizado sobre o aspecto funcional do software, mas poderia ser aplicado, segundo uma ou outra abordagem, sobre os aspectos informacionais ou comportamentais.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb 4.4. Concepes essenciais e de implementao Os requisitos de software podem ser especificados segundo dois critrios, dependendo do grau de conhecimento que se tem do sistema ou dependendo do estgio de anlise no qual nos encontramos. O primeiro critrio o da concepo essencial, onde o objetivo contemplar os aspectos essenciais do problema sob anlise, sem preocupao com detalhes de implementao. Considerando o exemplo de problema ilustrado nas figuras 5.1 e 5.2, a concepo essencial da funo ler status ignora o formato dos dados de status ou o tipo de sensor que ser utilizado. A vantagem de realizar a concepo essencial de deixar em aberto as alternativas de implementao possveis, o que adequado para as atividades iniciais do desenvolvimento. O segundo critrio o da concepo de implementao, o qual permite expressar os requisitos do software segundo as funes de processamento e as estruturas de informao do sistema real.

Em alguns casos, uma representao fsica o ponto de partida da etapa de projeto do software mas, na maioria dos casos, grande parte dos sistemas computacionais especificada acomodando alguns detalhes de implementao. O conhecimento de alguns destes detalhes pode auxiliar o analista (e, em seguida, o projetista) na definio de restries impostas ao software pelo sistema.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb

5. PROTOTIPAO DE SOFTWARE 5.1. Motivaes e Etapas da Prototipao A etapa de Anlise de Requisitos engloba um conjunto de atividades de fundamental importncia para o processo de desenvolvimento de um software e deve ser, portanto, realizada independentemente da abordagem e tcnica utilizadas. Em muitos casos, possvel aplicar-se tcnicas de anlise de modo a derivar uma representao em papel (ou em arquivo, no caso da utilizao de uma ferramenta CASE) que sirva de referncia para o projeto do software. Em outras situaes, a partir da coleta de requisitos um modelo do software um prottipo pode ser construdo de modo a permitir uma melhor avaliao por parte do desenvolvedor e do cliente. O paradigma da prototipao tem como ponto de partida uma Solicitao de Proposta encaminhada pelo cliente. A partir desta solicitao, os seguintes passos so realizados: anlise da solicitao para identificar a necessi dade da prototipao; normalmente, softwares interativos e/ou grficos ou softwares que exijam a utilizao de algoritmos combinatrios podem ser objeto de prototipao; no entanto, o fator complexidade deve permitir determinar a realizao ou no do prottipo; outro ponto que deve ser pesado nesta deciso se a equipe de desenvolvimento tem experincia e ferramentas adequadas prototipao; especificao resumida dos requisitos, realizada pelo analista, de modo a representar o domnio da informao e os domnios funcionais e comportamentais do software, de modo que a atividade de particionamento do problema possa ser efetuada; revisada a especificao resumida dos requisitos, realizado um projeto do prottipo, concentrando-se principalmente nos aspectos arquitetnicos e de dados e deixando de lado os aspectos procedimentais; desenvolvimento do prottipo, se possvel a partir da utilizao de blocos de construo de software preexistentes (o que na maioria dos casos so de difcil obteno); por outro lado, a construo de um prottipo pode ser facilitada graas existncia de diversas ferramentas orientadas a esta atividade; apresentao do prottipo (testado) ao cliente, para que este possa efetuar sua avaliao; a partir desta avaliao, o cliente pode sugerir extenses ou reformular alguns requisitos de modo a que o software possa melhor corresponder s reais necessidades; repetio iterativa dos dois passos anteriores, at que todos os requisitos tenham sido formalizados ou at que o prottipo tenha evoludo na direo de um sistema de produo.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb 6. ESPECIFICAO DOS REQUISITOS DE SOFTWARE Como foi exposto no incio do captulo (item 2.4), a etapa de Anlise de Requisitos culmina com a produo de um documento de Especificao dos Requisitos de Software. Este resultado pode vir na forma de um documento em papel utilizando linguagem natural ou grfica, pode ter sido produzida com o auxlio de uma ferramenta CASE, ou ainda pode ser complementada ou expressa a partir de um prottipo construdo nesta etapa. Este documento basicamente o resultado de um trabalho de representao das necessidades para a soluo do problema analisado, devendo expressar os aspectos funcionais, informacionais e comportamentais do software a ser construdo. De modo a obter uma especificao eficiente, alguns princpios podem ser considerados: a separao entre funcionalidade e implementao; utilizao de uma linguagem de especificao orientada ao processo; a especificao deve levar em conta o sistema do qual o software faz parte e o ambiente no qual o sistema vai operar; a especificao deve representar a viso que os usurios tero do sistema; uma especificao deve ser operacional, no sentido de que ela deve permitir, mesmo num nvel de abstrao elevado, algum tipo de validao; uma especificao deve ser localizada e fracamente acoplada, o que so requisitos fundamentais para permitir a realizao de modificaes durante a anlise de requisitos. A figura 5.3 apresenta uma proposta de estrutura para o documento de Especificao dos Requisitos do Software. O documento inicia com uma Introduo, que apresenta as principais metas do software, descrevendo o seu papel no contexto do sistema global. As informaes prestadas nesta seo podem ser, inclusive, inteiramente extradas do documento de Plano de Software.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb A seo de Descrio da Informao deve apresentar informaes sobre o problema que o software deve resolver. Os fluxos e a estrutura das informaes devem ser descritos nesta seo (utilizando um formalismo adequado, como, por exemplo, os DFDs e os Dicionrios de Dados), assim como os elementos relacionados s interfaces internas e externas do software (incluindo hardware, elementos humanos, outros softwares, etc...). A seo seguinte, Descrio Funcional, apresenta as informaes relativas s funes a serem providas pelo software, incluindo uma descrio dos processamentos envolvidos no funcionamento do software. Ainda nesta seo, devem ser apresentadas as restries de projeto, detectadas nesta etapa. A seo de Critrios de Validao, que apesar de ser a mais importante aquela sobre a qual menor ateno dispensada, vai estabelecer os parmetros que permitiro avaliar se a implementao do software vai corresponder soluo desejada para o problema. Definir os critrios de validao significa ter um entendimento completo dos requisitos funcionais e de processamento de informao do software. Uma definio importante a ser encaminhada nesta seo o conjunto de testes que dever ser aplicado implementao para que se tenha uma garantia do funcionamento do software nos moldes estabelecidos pela especificao dos requisitos. Finalmente, devem ser registrados neste documento a lista de documentos relacionados ao software a ser desenvolvido (Plano de Software, por exemplo) e uma seo de Apndices, onde podem ser apresentadas informaes mais detalhadas sobre a especificao do software (descrio detalhada de algoritmos, diagramas, grficos, etc...). Um outro aspecto interessante, no apresentado na figura, refere-se a quando um software ter caractersticas de interatividade com usurios. Neste caso, interessante que um Manual de Usurio (em verso preliminar) seja elaborado, o qual vai conduzir a duas consequncias positivas: forar o analista a enxergar o software do ponto de vista do usurio; permitir ao cliente uma avaliao do que ser o software nesta etapa de desenvolvimento.

7. TCNICAS PARA MELHORAR A ANLISE DE REQUISITOS Embora todo o processo de desenvolvimento de sistemas venha fazendo cada vez mais uso de ferramentas tecnolgicas, que tm levado a processos mais automatizados, o processo de definio de requisitos continua sendo um processo centrado no indivduo, baseado na experincia humana. necessrio reconhecer e entender os requisitos de conhecimento localizados na dimenso tcita, se deseja-se compreender os reais requisitos do usurio.

Neste captulo, procurou-se relacionar algumas tcnicas e recomendaes extradas de alguns autores que se preocuparam com este tema, bem como de nossa interpretao de experincias pessoais, que procuram melhorar a definio de requisitos em relao ao contato pessoal de analistas e usurios.

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb

7.1 Caractersticas dos requisitos para garantia de qualidade Pfleeger (2004) define sete questes para avaliar as caractersticas importantes que um requisito deve ter para garantia de qualidade na definio de requisitos. So elas: 1. Os requisitos esto corretos? Analistas e clientes devem analisar os requisitos para garantir que eles foram definidos sem erros. 2. Os requisitos so consistentes ? Verificar se no existem requisitos ambguos ou conflitantes. Considera-se dois requisitos inconsistentes se for impossvel satisfazer aos dois simultaneamente. 3. Os requisitos esto completos ? O conjunto de requisitos completo, se todos os possveis estados, mudanas de estado, entradas, produtos e restries estiverem descritos por algum requisito. Uma descrio de requisitos internamente completa, se no houver referncias indefinidas entre eles. 4. Os requisitos so realistas ? Deve-se verificar se o que o cliente est pedindo pode realmente ser feito pelo sistema, no gerando falsas expectativas. 5. Cada requisito descreve algo que necessrio para o cliente ? Algumas vezes, um requisito limita os desenvolvedores desnecessariamente ou inclui funes que no esto diretamente relacionadas com o problema em questo. Deve-se rever os requisitos, de forma a manter somente requisitos que atuam diretamente na resoluo do problema do cliente. 6. Os requisitos podem ser verificados ? Devemos ser capazes de planejar testes que demonstrem que os requisitos foram satisfeitos. 7. Os requisitos podem ser rastreados ? Cada funo do sistema deve poder ser rastreada para um conjunto de requisitos que a exige. A idia destas questes funcionar como um checklist para verificar cada possvel requisito, aprimorando e fazendo modificaes, medida que avanamos no projeto de desenvolvimento do software.

10

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb 7.2 Comunicao Efetiva e coleta de informaes Manter o foco na conversao com o usurio, demonstrando ateno, tomando nota, fazendo questes e pedindo para repetir alguns pontos, demonstram que realmente esta se escutando o interlocutor e isto muito importante para comear bem o relacionamento com o usurio. Saiedian (2000), destaca algumas recomendaes para facilitar o processo de comunicao com o usurio: Fazer concluses precipitadas sobre o que o usurio est dizendo, deixa-nos com o foco apenas nos comentrios que do suporte a essa concluso, desprezando detalhes importantes do contexto. Normalmente, os usurios no entendem o que eles querem requisitar do analista para ajud-los em seu trabalho. Nas reunies de levantamento de informaes eles esto em desvantagem em relao ao analista, pois eles apenas conhecem seu trabalho e nada sabem sobre projetos de desenvolvimento de sistemas. Freqentemente, o usurio fica estressado quando o analista pede para que documente suas necessidades. Uma maneira de ajudar neste processo o analista oferecer algo que se assemelhe com o que ele quer. Estabelecer pontos chaves (focal point) de suas necessidades ajudam a esclarecer e organizar os seus requisitos. Porm, isto deve ser feito com cuidado, pois o usurio pode entender que o analista est impondo um conjunto de requisitos para adaptar o usurio em sua soluo, que j existe.

O analista deve ter uma postura ctica na coleta de informaes, pois normalmente o usurio no diz o que ele realmente quer. Naomi Karten (Karten, 1994), oferece algumas sugestes para extrair informaes dos usurios: a. Nunca faa suposies. Repita questes j perguntadas, refaa -as para conseguir diferentes perspectivas. b. Pergunte para esclarecer. Tenha certeza de entender a linguagem utilizada pelo usurio para descrever o problema. No fique com receio de admitir que

11

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb no sabe alguma coisa. Pergunte tudo o que for necessrio para formar um bom entendimento das expectativas do usurio. c. Colete informaes de mltiplas fontes. Ns podemos conseguir um entendimento mais amplo das diversas necessidades apresentando questes similares para pessoas em entrevistas separadas. Pessoas com diferentes responsabilidades ajudam a preencher lacunas que uma determinada fonte criou. d. Procure inconsistncias no dilogo. O usurio est respondendo suas questes com respostas que voc quer ouvir ou de sua prpria perspectiva ? e. Manter o foco das questes no processo melhor do que nos indivduos, pois evita atitudes defensivas. f. Evite questes do tipo sim e no. Envolva o usurio no questionamento do processo, criando um consenso sobre as questes formuladas. g. O aumento no nmero de linhas de comunicao com o usurio em relao as linhas convencionais (entrevistas, observaes, levantamentos) ajudam no processo de definio de requisitos. Atualmente pelo avano tecnolgico disponvel na maioria das empresas, muito comum utilizar-se de recursos tais como: e-mails, chats, vdeo-conferncias, etc. . 7.3 Modelos de representao grfica que buscam interao com o usurio O uso de artefatos no tradicionais para caracterizar o ambiente do usurio, pode ajudar a deixar mais claro os detalhes dos requisitos do usurio, como exemplo: diagramas do ambiente do usurio, hierarquias do problema encontrado, matrizes mostrando os usurios chaves e suas reas, listas de benefcios e capacidades desejadas e story boards dos produtos. O uso de vdeos tem sido uma forma eficiente de documentar as atividades e o ambiente do usurio. Isto se torna possvel aos usurios falar e serem escutados em seus prprios termos, sem intermedirios. Os vdeos podem ser compartilhados facilmente por outras pessoas da equipe de desenvolvimento de forma a criar novos pontos de vistas sobre o entendimento do problema. 12

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb muito mais eficiente e confere maior autoridade um vdeo demonstrando partes do trabalho do usurio do que relatrios resumindo isto. 7.4 Tcnicas de participao do cliente-usurio. Quanto mais cedo o usurio participar da definio de requisitos maior possibilidade de sucesso ter o desenvolvimento do projeto. Existem detalhes do ambiente do trabalho do usurio que esto fora dos padres regulares de fazer as coisas. Estes detalhes conferem um nvel de flexibilidade importante de se levantar, que s a experincia do dia-a-dia pode demonstrar. Uma forma de se conseguir levantar isto o analista se colocar como aprendiz do usurio. Conversar sobre seu trabalho enquanto se est executando garante que detalhes importantes no sero omitidos ou confundidos. 7.5 Etnografia Rpida e Inquisies Contextuais A Etnografia rpida e inquisies contextuais so 2 tcnicas bastante utilizadas para coleta de dados do usurio, seus requisitos e o contexto do sistema em uso. Etnografia consiste na observao das atividades dirias do usurio e suas interaes com o sistema em uso. Inquisies contextuais envolvem a observao e a entrevista dos usurios em seus locais de trabalho para identificar requisitos de tarefa, especificaes de sistema, fatores ambientais e caractersticas do usurio que devem ser suportadas pelo novo sistema. Ambas as tcnicas possuem um forte contedo comunicacional, pois envolvem uma srie de esclarecimentos verbais que o usurio obrigado a passar para o analista. Porm, faz muita diferena se o analista j possui ou no experincia com rea do usurio e suas atividades, para obter um bom resultado no uso destas tcnicas. Quanto menos o analista conhecer, mais possibilidades de interpretaes errneas e subjetividades na sua definio de requisitos.

13

Engenharia de Software Modulo 2 Analise de Requisitos Prof. Tupinamb BIBLIOGRAFIA Compilao do capitulo 5 da apostila do prof. Vitorio Mazzola intitulada Engenharia d e Software e do capitulo 7 da dissertao do prof. Antonio Tupinamb intitulada As contribuies da Cincia da Informao e do conhecimento no processo de analise de requisitos de software

14