Você está na página 1de 16

Engenharia de Software

CONCEITOS E PRINCPIOS DE ANLISE


A engenharia de requisitos de software um processo de descobrimento, refinamento, modelagem e especificao. Os requisitos do sistema e o papel atribudo ao software - estabelecidos inicialmente pelo engenheiro de sistemas - so refinados em detalhe. Modelos dos dados, informao e fluxo de controle, bem como comportamentos operacionais necessrios, so criados. Solues alternativas so analisadas e um modelo de anlise completo criado. Donald Reifer descreve o processo de engenharia de requisitos de software do seguinte modo: Engenharia de requisitos o uso sistemtico de princpios, tcnicas, linguagens e ferramentas comprovadas para a anlise, documentao, evoluo continuada das necessidades do usurio e especificao do comportamento externo de um sistema para satisfazer as necessidades do usurio, que sejam efetivas em termos de custo. Note que como todas as disciplinas de engenharia, a engenharia de requisitos no conduzida de um modo espordico, aleatrio ou sujeito a azares, mas, ao contrrio, o uso sistemtico de abordagens comprovadas. Tanto o engenheiro de software quanto o cliente assumem um papel ativo na engenharia de requisitos de software - conjunto de atividades que freqentemente referido como anlise. O cliente tenta reformular uma descrio, s vezes nebulosa, em nvel de sistema dos dados, funo e comportamento em detalhes concretos. O desenvolvedor age como inquisidor, consultor, solucionador de problemas e negociador. A anlise e especificao de requisitos pode parecer uma tarefa relativamente simples, mas as aparncias enganam. O contedo da comunicao muito grande. As probabilidades de m interpretao e m informao so grandes. A ambigidade provvel. O dilema que confronta um engenheiro de software pode ser mais bem entendido repetindo a declarao de um cliente annimo (infame?): "Eu sei que voc acredita que entendeu o que pensa que eu disse, mas no estou certo de que voc reconhece que o que voc ouviu no o que eu quis dizer".

ANLISE DE REQUISITOS
Anlise de requisitos uma tarefa de engenharia de software que vence o espao entre a engenharia de requisitos, no nvel de sistemas, e o projeto de software. As atividades de engenharia de requisitos resultam na especificao das caractersticas operacionais do software (funo, dados e comportamento), indicam a interface do software com outros elementos do sistema e estabelecem restries que o software deve satisfazer. A anlise de requisitos permite ao engenheiro de software (algumas vezes chamado de analista, nesse papel) refinar a atribuio do software e construir modelos dos domnios de dados, funcional e comportamental que sero tratados pelo software. A anlise de requisitos fornece ao projetista de software uma representao da informao, funo e comportamento, que podem ser traduzidos para os projetos dos dados, arquitetura, interface e para o nvel de componentes, Finalmente, a especificao de requisitos fornece ao desenvolvedor e ao cliente os meios de avaliar a qualidade quando o software construdo. A anlise de requisitos de software pode ser dividida em cinco reas de esforo: (1) reconhecimento do problema, (2) avaliao e sntese, (3) modelagem, (4) especificao e (5) reviso. Inicialmente, o analista estuda a Especificao do Sistema (se existe alguma) e o Plano do Projeto de Software. importante entender o software no contexto do sistema e revisar o escopo do software que foi usado para gerar as estimativas de planejamento. A seguir, a comunicao para a anlise deve ser estabelecida de modo que seja garantido o reconhecimento do problema. A meta reconhecer os elementos bsicos do problema tal como so percebidos pelos clientes/usurios. A avaliao do problema e sntese da soluo a prxima rea importante de esforo da anlise. O analista deve definir todos os objetos de dados observveis externamente, avaliar o fluxo e o contedo de informao, definir e refinar todas as funes do software, entender o comportamento do software no contexto dos eventos que afetam o sistema, estabelecer as caractersticas das interfaces do sistema e descobrir restries adicionais de projeto. Cada uma dessas tarefas serve para descrever o problema de modo que uma abordagem ou soluo global possa ser sintetizada. Por exemplo, um sistema de controle de estoque necessrio para um fornecedor importante de autopeas. O analista descobre que os problemas com o atual sistema manual incluem (1) incapacidade de obter rapidamente o status de um componente, (2) dois ou trs dias de rotatividade para atualizar um arquivo em cartes, (3) pedidos mltiplos de ressuprimento para o mesmo fornecedor, porque no h como associar fornecedores com componentes, e assim por diante. Uma vez identificados os problemas, o analista determina que informao deve ser produzida pelo novo sistema e quais dados vo ser fornecidos ao sistema. Por exemplo, o cliente deseja um relatrio dirio indicando que peas foram retiradas do

Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

estoque e quantas peas similares restaram. O cliente indica que os funcionrios do almoxarifado vo registrar o nmero de identificao de cada pea quando ela sai da rea do estoque. Aps avaliar os problemas atuais e a informao desejada (entrada e sada), o analista comea a sintetizar uma ou mais solues. Para comear, os objetos de dados, funes de processamento e comportamento do sistema so definidos em detalhe. Uma vez estabelecida essa informao, arquiteturas bsicas para implementao so consideradas. Uma abordagem cliente/servidor parece que seria adequada, mas o software para apoiar essa arquitetura se encaixa no escopo esboado no Plano do Software? Parece que seria necessrio um sistema de gesto de bases de dados, mas a necessidade de associatividade do usurio/cliente justificada? O processo de avaliao e sntese continua at que o analista e o cliente se sintam seguros de que o software pode ser especificado adequadamente para os passos subseqentes de desenvolvimento. Durante a avaliao e sntese de soluo, o principal foco do analista "que", no "como". Que dados o sistema produz e consome, que funes o sistema deve desempenhar, que comportamentos o sistema exibe, que interfaces so definidas e que restries se aplicam. Durante a atividade de avaliao e sntese de soluo, o analista cria modelos do sistema no esforo de entender melhor os dados e o fluxo de controle, o processamento funcional, o comportamento operacional e o contedo da informao. O modelo serve como fundamento para o projeto de software e como base para a criao de especificaes para o software. Especificaes detalhadas podem no ser possveis neste estgio. O cliente pode estar inseguro do que precisamente necessrio. O desenvolvedor pode estar inseguro de que uma abordagem especfica vai conseguir funo e desempenho adequados. Por essas e muitas outras razes, uma abordagem alternativa para a anlise de requisitos, chamada prototipagern, pode ser conduzida.

ELICITAAO DE REQUISITOS PARA O SOFTWARE


Antes que os requisitos possam ser analisados, modelados ou especificados eles precisam ser reunidos usando-se um processo de elicitao. O cliente tem um problema que pode ser adequado para uma soluo baseada em computador. Um desenvolvedor responde ao pedido de ajuda do cliente. A comunicao comeou. Mas, como j mencionamos, o caminho da comunicao para o entendimento freqentemente cheio de buracos.

Incio do processo A tcnica mais comumente usada de elicitao de requisitos conduzir uma reunio ou entrevista. A primeira reunio entre um engenheiro de software (o analista) e o cliente pode ser comparada com a falta de jeito de um primeiro encontro entre dois adolescentes. Nenhuma das pessoas sabe o que dizer ou perguntar; ambas esto preocupadas em serem mal-interpretadas; ambas esto pensando sobre aonde isso iria levar (provavelmente ambas tenham expectativas radicalmente diferentes quanto a isso); ambas desejam acabar logo com o encontro, mas ao mesmo tempo, desejam que ele seja um sucesso. No entanto, a comunicao precisa ser iniciada. Gause e Weinberg sugerem que o analista comece formulando
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

questes livres de contexto. Isto , um conjunto de questes que levem a um entendimento bsico do problema, do pessoal que deseja soluo, da natureza da soluo que desejada e da efetividade do primeiro encontro propriamente dito. O primeiro conjunto de questes livres de contexto focaliza o cliente, os objetivos globais e os benefcios. Por exemplo, o analista poderia perguntar: Quem est por trs da solicitao deste trabalho? Quem vai usar a soluo? Qual vai ser o benefcio econmico de uma soluo bem-sucedida? H outra fonte para a soluo que voc necessita? Essas questes ajudam a identificar todos os envolvidos que tm interesse no software a ser construdo. Alm disso, as perguntas identificam o benefcio mensurvel de uma implementao bem-sucedida e possveis alternativas para o desenvolvimento de software sob encomenda. O conjunto de questes a seguir possibilita ao analista obter um melhor entendimento do problema e ao cliente verbalizar sua percepo de uma soluo: Como voc caracterizaria "boas" sadas, que seriam geradas por uma soluo bem sucedida? Que problema(s) essa soluo enfrentaria? Voc pode me mostrar (ou descrever) o ambiente no qual a soluo ser usada? Tpicos especiais de desempenho ou restries vo afetar o modo pelo qual a soluo abordada?

O conjunto final de questes focaliza a efetividade da reunio. Gause e Weinberg [GAU89] as chamam de metaquestes e propem a seguinte lista (abreviada): Voc a pessoa certa para responder essas questes? Suas respostas so "oficiais"? Minhas questes so relevantes ao problema que voc tem? Estou formulando muitas questes? Algum mais pode fornecer informao adicional? Devo perguntar-lhe mais alguma coisa?

Essas questes (e outras) vo ajudar a "quebrar o gelo" e iniciar a comunicao, que essencial para a anlise bem-sucedida. No entanto, uma reunio na forma de perguntas e respostas no uma abordagem que tem sido extremamente bem-sucedida. De fato, a seo Q&A deve ser usada apenas para o primeiro encontro e depois ser substituda por uma forma de reunio que combine elementos de soluo de problemas, negociao e especificao.

Tcnicas facilitadas de especificao de aplicaes


Muito freqentemente, clientes e engenheiros de software tm inconscientemente um estado de esprito de "ns e eles". Em vez de trabalhar como equipe para identificar e refinar requisitos, cada parte define seu prprio "territrio" e se comunica por intermdio de uma srie de memorandos, declaraes formais de posicionamento, documentos e sesses de perguntas e respostas. A histria tem mostrado que essa abordagem no funciona muito bem. Sobram mal-entendidos, informao importante omitida e nunca estabelecido um relacionamento de trabalho bem-sucedido. com esses problemas em mente que diversos pesquisadores independentes desenvolveram uma abordagem orientada a equipe para elicitao de requisitos que aplicada durante os primeiros estgios da anlise e especificao. Chamada de tcnicas facilitadas de especificao de aplicaes (facilitated application specification techniques, FAST), essa abordagem encoraja a criao de uma equipe conjunta de clientes e desenvolvedores, que trabalham juntos para identificar o problema, propor elementos da soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo. A FAST pode ser usada predominantemente pela comunidade de sistemas de informao, mas a tcnica oferece potencial para comunicao melhorada em aplicaes de todos os tipos. Muitas abordagens diferentes de FAST tm sido propostas. Cada uma faz uso de um cenrio ligeiramente diferente, mas todas aplicam alguma variante das seguintes diretrizes bsicas: Uma reunio conduzida em um local neutro com a participao de engenheiros de software e de clientes So estabelecidas regras para preparao e participao. sugerida uma agenda que suficientemente formal para cobrir todos os pontos importantes, porm suficientemente informal para encorajar o livre fluxo de idias. Um "facilitador" (que pode ser um cliente, um desenvolvedor ou uma pessoa de fora) controla a
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

reunio. usado um "mecanismo de definio" (que podem ser folhas de rascunho, flip charts, ou papel auto-adesivo, ou um quadro de avisos eletrnico, salas de conversa ou forum virtual). A meta identificar o problema, propor elementos da soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo em uma atmosfera que propicie que a meta seja alcanada.

Para entender melhor o fluxo de eventos que ocorre numa reunio tpica de FAST, apresentamos um cenrio resumido que delineia a seqncia de eventos que provocam a reunio, ocorrem durante e aps a reunio. Reunies iniciais entre o cliente e o desenvolvedor ocorrem e perguntas e respostas bsicas ajudam a estabelecer o escopo do problema e a percepo geral de uma soluo. Como resultado dessas reunies iniciais, o desenvolvedor e o cliente redigem uma "solicitao de produto", de uma ou duas pginas. So selecionados um local de reunio, horrio e data para FAST e escolhido um facilitador. Participantes das organizaes, tanto do desenvolvedor quanto do cliente/usurio, so convidados a comparecer. A solicitao de produto distribuda para todos os participantes antes da data da reunio. Enquanto rev a solicitao nos dias que precedem a reunio, solicitado a cada participante que faa uma lista dos objetos que so parte do ambiente que cerca o sistema, outros objetos que devem ser produzidos pelo sistema e objetos que so usados pelo sistema para desempenhar suas funes. Alm disso, solicitado a cada participante que faa outra lista de servios (processos ou funes) que manipulam ou interagem com os objetos. Finalmente, so tambm desenvolvidas listas de restries (p. ex., custo, tamanho, regras de negcio) e critrios de desempenho (p. ex., velocidade, preciso). Os participantes so informados de que no se espera que as listas sejam exaustivas, mas espera-se que elas reflitam a percepo do sistema de cada um. Como exemplo, considere que uma equipe FAST trabalhando para uma empresa de produtos para o consumidor obteve a seguinte descrio de produto: Nossa pesquisa indica que o mercado para sistemas domsticos de segurana est crescendo a uma taxa de 40% ao ano. Gostaramos de entrar nesse mercado construindo um sistema de segurana domstico baseado em microprocessador, que iria proteger contra e/ou reconhecer vrias "situaes" indesejveis tais como entrada ilegal, fogo, inundao e outras. O produto, chamado experimentalmente de SofeHome, usar sensores adequados para detectar cada situao, poder ser programado pelo proprietrio e discar automaticamente para uma agncia de monitorao quando uma situao for detectada. Na verdade, muito mais informao seria fornecida nesse estgio. Mas mesmo com informao adicional, teramos ambigidade, e provavelmente omisses e erros poderiam ocorrer. Por enquanto, a "descrio de produto" precedente vai ser suficiente. A equipe FAST composta de representantes de comercializao, engenharia de software e hardware, e fabricao. Um facilitados externo ser usado. Cada pessoa da equipe FAST desenvolve as listas descritas anteriormente. Os objetos descritos para SafeHome poderiam incluir detectores de fumaa, sensores para janelas e portas, detectores de movimento, um alarme, um evento (um sensor foi ativado), um painel de controle, um mostrador, nmeros de telefone, uma chamada telefnica e assim por diante. A lista de servios poderia incluir ligar o alarme, monitorar os sensores, discar o telefone, programar o painel de controle, ler o mostrador (note que os servios agem sobre os objetos). De modo semelhante, cada participante do FAST vai desenvolver listas de restries (p. ex., o sistema deve ter um custo de fabricao de menos de $80, deve ser amigvel ao uso, deve fazer interface diretamente com uma linha telefnica padro) e de critrios de desempenho (p. ex., um evento de sensoriamento deve ser reconhecido dentro de um segundo, um esquema de prioridade de eventos deve ser implementado). Quando a reunio FAST comea, o primeiro tpico de discusso a necessidade e a justificativa do novo produto - todos devem concordar que o produto justificvel. Uma vez estabelecida a concordncia, cada participante apresenta suas listas para discusso. As listas podem ser penduradas nas paredes da sala usando grandes folhas de papel, grudadas nas paredes usando folhas com adesivo na parte de trs ou escritas num quadro de parede. Alternativamente, as listas podem ter sido colocadas num quadro de avisos eletrnico ou postas num ambiente de bate-papo eletrnico para reviso anterior reunio. O ideal seria que cada entrada em uma lista pudesse ser manipulada separadamente de modo que as listas possam ser combinadas, as entradas possam ser apagadas e possam ser feitas adies. Nesse estgio, criticas e debates so estritamente proibidos. Depois que as listas individuais forem apresentadas sobre um assunto, uma lista combinada criada pelo grupo. A lista combinada elimina entradas redundantes, adiciona qualquer idia nova que surgiu durante a discusso, mas no apaga nada. Depois que listas combinadas para todos os assuntos tiverem sido criadas, a discusso - coordenada pelo facilitados tem incio. A lista combinada reduzida, ampliada ou reescrita para refletir adequadamente o produto/sistema a ser desenvolvido. O objetivo desenvolver uma lista de consenso em cada assunto (objetos, servios, restries e
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

desempenho). As listas so ento postas de lado para ao posterior. Uma vez completadas as listas de consenso, a equipe subdividida em equipes menores; cada uma trabalha para desenvolver miniespecificaes para uma ou mais entradas de cada uma das listas. Cada miniespecificao um detalhamento da palavra ou frase que consta de uma lista. Por exemplo, a miniespecificao para o objeto painel de controle do SaleHome poderia ser

montado em parede tamanho aproximado de 22 x 12 centmetros contm teclado padro de 12 teclas e teclas especiais contm mostrador LCD com a forma mostrada no esboo (no apresentado aqui) toda a interao com o cliente ocorre atravs de teclas usado para ligar e desligar o sistema software fornece diretrizes para a interao, ecos etc. conectado a todos os sensores

Cada subequipe apresenta ento cada uma das suas miniespecificaes a todos os participantes do FAST para discusso. Adies, supresses e mais detalhamentos so feitos. Em alguns casos, o desenvolvimento de miniespecificaes vai descobrir novos objetos, servios, restries ou requisitos de desempenho que sero adicionados s listas originais. Durante as discusses, a equipe pode levantar um assunto que no pode ser resolvido durante a reunio. Uma lista de assuntos mantida de modo que as idias possam ser trabalhadas depois. Depois que as miniespecificaes so completadas, cada participante FAST faz uma lista de critrios de validao para o produto/sistema e apresenta sua lista equipe. Uma lista de consenso dos critrios de validao ento criada. Finalmente, atribui-se a um ou mais participantes (ou pessoa externa) a tarefa de redigir o rascunho completo da especificao, usando todas as entradas produzidas pela reunio FAST. FAST no uma panacia para os problemas encontrados na elicitao inicial de requisitos. Mas a abordagem de equipe fornece os benefcios de muitos pontos de vista, discusso e refinamento instantneos e um passo concreto para o desenvolvimento de uma especificao.

Desdobramento da funo de qualidade


Desdobramento da funo de qualidade (quality function deployment, QFD) uma tcnica de gesto de qualidade que traduz as necessidades do cliente para requisitos tcnicos do software. Originalmente desenvolvida no Japo e usada inicialmente no estaleiro de Kobe, da Mitsubishi Heavy Industries, Ltd., no incio da dcada de 70, o QFD "concentra-se em maximizar a satisfao do cliente a partir do processo de engenharia de software". Para conseguir isso, o QFD enfatiza o entendimento do que tem valor para o cliente e depois desdobra esses valores atravs do processo de engenharia. O QFD identifica trs tipos de requisitos: Requisitos normais. Os objetivos e metas que so estabelecidos para o produto ou sistema durante reunies com o cliente. Se esses requisitos estiverem presentes, o cliente fica satisfeito. Exemplos de requisitos normais poderiam ser os tipos de mostradores grficos requeridos, funes especficas do sistema e nveis de desempenho definidos. Requisitos esperados. Esses requisitos esto implcitos no produto ou sistema e podem ser to fundamentais que o cliente no se refere a eles explicitamente. Sua ausncia seria causa de insatisfao significativa. Exemplos de requisitos esperados so: facilidade de interao homem/mquina, correo e contabilidade operacional global e facilidade de instalao do software. Requisitos excitantes. Essas caractersticas vo alm das expectativas do cliente e mostram ser muito satisfatrias quando presentes. Por exemplo, um software de processamento de texto solicitado com caractersticas padro. O produto entregue dispe de vrias facilidades para leiaute de pgina, que so muito agradveis e inesperadas. Na verdade, o QFD cobre todo o processo de engenharia. No entanto, muitos conceitos QFD so aplicveis
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

atividade de elicitao de requisitos. Apresentamos apenas um panorama desses requisitos (adaptados para software de computadores) nos pargrafos seguintes. Em reunies com o cliente, o desdobramento (deployment) de funes usado para determinar o valor de cada funo necessria ao sistema. O desdobramento da informao identifica tanto os objetos de dados quanto os eventos que o sistema deve consumir e produzir. Eles so ligados s funes. Finalmente, o desdobramento de tarefas examina o comportamento do sistema ou produto dentro do contexto do seu ambiente. A anlise de valor conduzida para determinar a prioridade relativa dos requisitos determinados durante cada um dos trs desdobramentos. O QFD usa entrevistas com o cliente e observao, levantamentos e exame de dados histricos (p. ex., relatrios de problemas) como dados em bruto para a atividade de elicitao de requisitos. Esses dados so ento traduzidos para uma tabela de requisitos - chamada de tabela da voz do cliente - que revisada com o cliente. Uma variedade de diagramas, matrizes e mtodos de avaliao ento usada para elicitar os requisitos esperados e para tentar derivar os requisitos notveis.

Casos de uso
medida que os requisitos so elicitados como parte de reunies informais, FAST ou QFD, o engenheiro de software (analista) pode criar um conjunto de cenrios que identifica uma linha de uso para o sistema a ser construdo. Os cenrios, freqentemente chamados de casos de uso, fornecem uma descrio de como o sistema ser usado. Para criar um caso de uso, o analista deve primeiro identificar os diferentes tipo de pessoas (ou dispositivos) que usam o sistema ou produto. Esses atores, na verdade representam papis que as pessoas (ou dispositivos) desempenham quando o sistema opera. Definido de um modo um tanto mais formal, um ator qualquer coisa que se comunica com o sistema ou produto e que no faz parte dele. importante notar que um ator e um usurio no so a mesma coisa. Um usurio tpico pode desempenhar vrios papis diferentes quando usa o sistema, enquanto um ator representa uma classe de entidades externas (freqentemente, mas nem sempre pessoas) que desempenha apenas um papel. Como exemplo, considere um operador de mquina (um usurio) que interage com o computador de controle de uma clula de fabricao, que contm um certo nmero de robs e mquinas de controle numrico. Aps cuidadosa reviso dos requisitos, o software para o computador de controle requer quatro diferentes modos (papis) de interao: modo de programao, modo de teste, modo de monitorao e modo de reparao. Assim, quatro atores podem ser definidos: programador, testador, monitor e reparador. Em alguns casos, o operador de maquina pode desempenhar os quatro papis. Em outros, diferentes pessoas podem desempenhar o papel de cada ator. Como a elicitao de requisitos uma atividade evolutiva, nem todos os atores so identificados durante a primeira iterao. possvel identificar atores principais, durante a primeira iterao, e atores secundrios, quando se fica sabendo mais a respeito do sistema. Os atores principais interagem para conseguir a funo desejada do sistema e derivam o benefcio pretendido. Trabalham direta e freqentemente com o software. Os atores secundrios do suporte ao sistema, de modo que os atores principais possam fazer seu trabalho. Uma vez identificados os atores, casos de uso podem ser desenvolvidos. O caso de uso descreve o modo pelo qual um ator interage com o sistema. Jacobson sugere algumas questes que devem ser respondidas pelo caso de uso: Que tarefas ou funes principais so desempenhadas pelo ator? Que informao do sistema o ator vai adquirir, produzir ou modificar? O ator vai ter que informar o sistema sobre as alteraes do ambiente externo? Que informao o ator deseja do sistema? O ator deseja ser informado sobre modificaes inesperadas?

Em geral, um caso de uso simplesmente uma narrativa escrita que descreve o papel de um ator medida que ocorre a interao com o sistema. Voltando aos requisitos bsicos do SafeHome, podemos definir trs atores: o proprietrio (usurio), sensores (dispositivos ligados ao sistema) e o subsistema de monitorao e resposta (a estao central que monitora SafeHome). Para a finalidade deste exemplo, consideramos apenas o ator proprietrio. O proprietrio interage com o produto de um certo nmero de modos diferentes: entra com uma senha para permitir todas as outras interaes consulta o estado de uma zona de segurana consulta o estado de um sensor aperta o boto de pnico numa emergncia ativa/desativa o sistema de segurana
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software
Um caso de uso para ativao do sistema o seguinte: 1. O proprietrio observa um prottipo do painel do controle do SafeHome para determinar se o sistema est disponvel para a entrada. Se o sistema no est pronto, o proprietrio tem que fechar fisicamente as janelas/portas de modo que o indicador de pronto se apresente. (Um indicador de no disponvel implica que um sensor est aberto; isto , que uma porta ou janela est aberta.) 2. O proprietrio usa o teclado para teclar uma senha de quatro dgitos. A senha comparada com a senha vlida armazenada no sistema. Se a senha no for correta, o painel de controle vai emitir um bip e preparar-se para uma entrada adicional. Se a senha estiver correta, o painel de controle espera a ao subseqente. 3. O proprietrio seleciona e tecla dentro ou fora para ativar o sistema. Dentro ativa somente os sensores perifricos (os sensores internos de deteco de movimento so desativados). Fora ativa todos os sensores. 4. Quando a ativao ocorre, uma luz de alarme vermelha pode ser observada pelo proprietrio.

Casos de uso para outras interaes do proprietrio seriam desenvolvidos de modo semelhante. importante notar que cada caso de uso deve ser revisado com cuidado. Se algum elemento da interao ambguo, provvel que uma reviso do caso de uso v indicar um problema. Cada caso de uso fornece um cenrio no-ambguo de interao entre um ator e software. Ele pode tambm ser usado para especificar requisitos de tempo ou outra restries do cenrio. Por exemplo, no caso de uso em questo, requisitos indicam que a ativao ocorre 30 segundos depois que a tecla dentro ou fora pressionada. Esta informao pode ser juntada ao caso de uso. Casos de uso descrevem cenrios que sero percebidos de modo diferente por diferentes atores. Wyder sugere que o desdobramento da funo de qualidade pode ser usado para desenvolver um valor ponderado de prioridade para cada caso de uso. Para conseguir isso, os casos de uso so avaliados do ponto de vista de todos os atores definidos para o sistema. Um valor de prioridade atribudo a cada caso de uso (p. ex., um valor de 1 a 10) por cada um dos atores. Uma prioridade mdia ento calculada, indicando a importncia perceptvel de cada um dos casos de uso. Quando usado um modelo de processo iterativo para a engenharia de software, prioridades podem influenciar qual funcionalidade do sistema entregue primeiro. =====================================================================

PRINCPIOS DE ANLISE
Durante as ltimas duas dcadas, um grande nmero de mtodos de modelagem da anlise foi desenvolvido. Pesquisadores identificaram problemas de anlise e suas causas e desenvolveram uma variedade de notaes de modelagem e conjuntos de heursticas correspondentes para resolv-los. Cada mtodo de anlise tem um ponto de vista singular. No entanto, todos os mtodos de anlise esto relacionados por um conjunto de princpios operacionais: 1. O domnio de informao de um problema precisa ser representado e entendido. 2. As funes a serem desenvolvidas pelo software devem ser definidas. 3. O comportamento do software (como conseqncia de eventos externos) precisa ser representado.
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

4. Os modelos que mostram informao, funo e comportamento devem ser particionados de um modo que revele detalhes em forma de camadas (ou hierarquias). 5. O processo de anlise deve ir da informao essencial at o detalhe de implementao. Aplicando esses princpios, o analista aborda um problema sistematicamente. 0 domnio de informao examinado de modo que a funo possa ser entendida mais completamente. Modelos so usados de modo que caractersticas de funo e comportamento possam ser relatadas de forma compacta. O particionamento aplicado para reduzir a complexidade. As vises essencial e de implementao do software so necessrias para acomodar as restries lgicas impostas pelos requisitos de processamento e as restries fsicas impostas por outros elementos do sistema. Alm desses princpios operacionais de anlise, Davis sugere um conjunto de princpios diretivos para a engenharia de requisitos: Entenda o problema antes que voc comece a criar um modelo de anlise. H uma tendncia de correr para uma soluo, mesmo antes do problema ser entendido. Isso freqentemente leva a um software elegante que resolve o problema errado! Desenvolva prottipos que permitam ao usurio entender como a interao homem/ mquina vai ocorrer. Como a percepo da qualidade do software freqentemente baseada na constatao da "amigabilidade" da interface, a prototipagem (e a iterao resultante) altamente recomendvel. Registre a origem e a razo para cada requisito. Esse o primeiro passo para estabelecer a rastreabilidade at o cliente. Use mltiplas vises dos requisitos. Construir modelos de dados, funcional e comportamental d ao engenheiro de software trs diferentes vises. Isso reduz a probabilidade de que algo seja omitido e aumenta a probabilidade de que a inconsistncia seja reconhecida. Ordene os requisitos. Prazos apertados podem impedir a implementao de cada requisito do software. Se um modelo de processo incremental aplicado, os requisitos a serem satisfeitos no primeiro incremento devem ser identificados. Trabalhe para eliminar a ambigidade. Como a maioria dos requisitos so descritos em linguagem natural, a oportunidade de ambigidade grande. O uso de revises tcnicas formais um modo de descobrir e eliminar a ambigidade. mais provvel que um engenheiro de software, que leva a srio esses princpios, desenvolva uma especificao de software que fornea excelente base para o projeto.

O domnio da informao
Todas as aplicaes de software podem ser coletivamente chamadas de processamento de dados. interessante que esse termo contm uma chave para o nosso entendimento de requisitos de software. O software construdo para processar dados, para transformar dados de uma forma para outra; isto , para aceitar entrada, trat-la de algum modo e produzir sada. Essa declarao de objetivo fundamental verdadeira, quer estejamos construindo software com processamento por lotes para um sistema de folha de pagamento, ou software embutido de tempo real para controlar o fluxo de combustvel para um motor de automvel. importante notar, no entanto, que o software tambm processa eventos. Um evento representa algum aspecto do controle do sistema e realmente nada mais do que dados booleanos - ligado ou desligado, verdadeiro ou falso, presente ou ausente. Por exemplo, um sensor de presso detecta que a presso excedeu um valor seguro e manda um sinal de alarme para o software de monitorao. O sinal de alarme um evento que controla o comportamento do sistema. Assim, dados (nmeros, texto, imagens, sons, vdeo etc.) e controle (eventos) residem ambos no domnio de informao de um problema. O primeiro princpio operacional de anlise requer um exame do domnio de informao e a criao de um modelo de dados. O domnio de informao contm trs diferentes vises de dados e controles medida que cada um processado por um programa de computador: (1) contedo da informao e relacionamentos (o modelo de dados), (2) fluxo da informao e (3) estrutura da informao. Para entender completamente o domnio de informao, cada uma dessas vises deve ser considerada. Contedo da informao representa os objetos individuais de dados e controle que constituem alguma grande coleo de informao transformada pelo software. Por exemplo, o objeto de dados cheque de pagamento, uma
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

composio de um certo nmero de peas importantes de dados: o nome de quem vai receber o pagamento, a quantia lquida a ser paga, a quantia bruta, as dedues e etc. Assim, o contedo de cheque de pagamento definido pelos atributos que so necessrios para cri-lo. Analogamente, o contedo de um objeto de controle chamado estado do sistema poderia ser definido como uma cadeia de bits. Cada bit representa um item de informao separado que indica se um certo dispositivo est ou no ligado ou desligado. Objetos de dados e controle podem ser relacionados a outros objetos de dados e controle. Por exemplo, o objeto de dados cheque de pagamento tem uma ou mais relaes com os objetos carto de ponto, empregado, banco e outros. Essas relaes devem ser definidas, durante a anlise do domnio de informao.

O fluxo da informao representa o modo pelo qual dados e controle se modificam medida que cada um se move atravs de um sistema. Objetos de entrada so transformados em informao intermediria (dados e/ou controle), que so subseqentemente transformados em sada. Ao longo desse caminho (ou caminhos) de transformao, informao adicional pode ser introduzida a partir de um depsito de dados existentes (p. ex., arquivo de disco ou buffer de memria). As transformaes aplicadas aos dados so funes ou subfunes que um programa deve realizar. Dados e controle que se movem entre duas transformaes (funes) definem a interface de cada funo. Estrutura da informao representa a organizao interna dos vrios itens de dados e controle. Os itens de dados ou controle devem ser organizados em uma tabela n-dimensional ou como uma estrutura de rvore hierrquica? Dentro do contexto da estrutura, que informao relacionada a outra informao? Toda informao est contida em uma nica estrutura ou estruturas diferentes devem ser usadas? Como a informao de uma estrutura da informao se relaciona informao de outra estrutura? Essas e outras questes so respondidas por uma avaliao da estrutura da informao. Deve-se notar que a estrutura de dados refere-se ao projeto ou implementao da estrutura da informao no software.

Modelagem
Criamos modelos funcionais para obter maior entendimento da entidade real a ser construda. Quando a entidade uma coisa fsica (um edifcio, um avio, uma mquina), podemos construir um modelo que idntico em forma e aspecto, mas menor em escala. No entanto, quando a entidade a ser construda software, nosso modelo deve assumir uma forma diferente. Deve ser capaz de representar a informao, que o software transforma, as funes (e subfunes), que permitem que a transformao ocorra, e o comportamento do sistema, medida que a transformao est sendo efetuada. O segundo e o terceiro princpios operacionais de anlise requerem que construamos modelos de funo e comportamento.

Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

10

Modelos funcionais. Os software transforma a informao, e a fim de conseguir isso precisa realizar pelo menos trs funes genricas: entrada, processamento e sada. Quando modelos funcionais de uma aplicao so criados, o engenheiro de software focaliza funes especficas do problema. Um modelo funcional comea com um nico modelo de contexto (i. e., o nome do software a ser construdo). Durante uma srie de iteraes, mais e mais detalhes funcionais so fornecidos, at que um delineamento preciso de toda a funcionalidade do sistema representado. Modelos de comportamento. A maioria do software responde a eventos do mundo exterior. Essa caracterstica estmulo/resposta forma a base do modelo comportamental. Um programa de computador existe sempre em algum estado - um modo de comportamento externamente observvel (p. ex., esperando, calculando, imprimindo, consultando), que modificado somente quando ocorre algum evento. Por exemplo, o software vai permanecer no estado de espera at que (1) um relgio interno indica que algum intervalo de tempo passou, (2) um evento externo (p. ex., um movimento de mouse) causa uma interrupo, ou (3) um sistema externo sinaliza para o software agir de uma certa maneira. Um modelo de comportamento cria uma representao dos estados do software e dos eventos que causam mudana de estado no software. Modelos criados durante a anlise de requisitos servem a diversos papis importantes: O modelo ajuda o analista no entendimento da informao, funo e comportamento de um sistema, tornando conseqentemente a tarefa de anlise de requisitos mais fcil e mais sistemtica. O modelo toma-se o focal para revises e conseqentemente a chave para detemlinao da completeza, da consistncia e da preciso das especificaes. O modelo torna-se base para o projeto, dando ao projetista uma representao essencial do software que pode ser "mapeada" para um contexto de implementao. A atividade de modelagem fundamental para um bom trabalho de anlise.

Particionamento
Os problemas so freqentemente muito grandes e complexos para serem entendidos como um todo. Por isso tendemos a particionar (dividir) tais problemas em segmentos que podem ser facilmente entendidos e estabelecer interfaces entre os segmentos de modo que a funo global possa ser compreendida. O quarto princpio operacional de anlise sugere que os domnios de software informacional, funcional e comportamental podem ser particionados. Em essncia, o particionamento decompe um problema nos seus segmentos constituintes. Conceitualmente estabelecemos uma representao hierrquica da funo ou da informao e depois particionamos o elemento de cima expondo cada vez mais detalhes, movendo-nos verticalmente na hierarquia ou decompondo funcionalmente o problema, movendo-nos horizontalmente na hierarquia. Para ilustrar essas abordagens de particionamento, vamos considerar novamente o sistema de segurana SafeHome. A atribuio de software para o SafeHome (derivada como conseqncia das atividades de engenharia de sistemas e FAST) pode ser enunciada nos seguintes pargrafos:

Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software
O software do SafeHome permite que o proprietrio configure o sistema de segurana quando instalado, monitora todos os sensores conectados ao sistema de segurana e interage com o proprietrio por intermdio de um teclado e teclas de funo contidas no painel de controle do SafeHome. Durante a instalao, o painel de controle do SafeHome usado para "programar" e configurar o sistema. A cada sensor atribudo um nmero e tipo, uma senha mestra programada para armar e desarmar o sistema e nmeros de telefone so introduzidos para serem discados quando um evento de sensor ocorrer. Quando um evento de sensor reconhecido, o software aciona um alarme sonoro conectado ao sistema. Aps um tempo de espera, que especificado pelo proprietrio durante as atividades de configurao do sistema, o sistema disca o nmero do telefone de um servio de monitoramento, fornece informao sobre o local e informa a natureza do evento que foi detectado. O nmero de telefone ser rediscado a cada 20 segundos at que a conexo telefnica seja conseguida. Toda a interao com o SafeHome gerenciada por um subsistema de interao com o usurio, que l a entrada fornecida pelo teclado e pelas teclas de funo, exibe mensagens de interao no mostrador de LCD, e exibe informao sobre o estado do sistema no mostrador LCD. A interao pelo teclado toma a seguinte forma: Os requisitos para o software do SafeHome podem ser analisados pelo particionamento dos domnios informacional, funcional e comportamental do produto. Para ilustrar, o domnio funcional do problema vai ser particionado. A Figura acima ilustra uma decomposio horizontal do software do SafeHome. O problema particionado pela representao das funes de software que constituem o SafeHome, movendo-se horizontalmente na hierarquia funcional. Trs funes importantes so notadas no primeiro nvel da hierarquia. As subfunes associadas com cada funo importante do SafeHome podem ser examinadas pela exposio dos detalhes verticalmente na hierarquia, como ilustrado na Figura abaixo. Movendo-se para baixo ao longo do nico caminho abaixo da funo monitorar sensores, o particionamento ocorre verticalmente para mostrar nveis crescentes de detalhes funcionais. A abordagem de particionamento aplicada s funes do SafeHome pode ser aplicada tambm ao domnio de informao e ao domnio de comportamento, de igual modo.

11

De fato, o particionamento do fluxo da informao e do comportamento do sistema proporcionar entendimento adicional dos requisitos do software. medida que o problema particionado, as interfaces entre as funes so derivadas. Itens de dados e controle, que se movem atravs de uma interface, devem se restringir s entradas necessrias para realizar a funo declarada e s sadas que so necessrias a outras funes ou elementos do sistema.

Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

12

Vises essencial e de implementao


Uma viso essencial dos requisitos de software apresenta as funes a serem realizadas e a informao a ser processada, sem cuidar dos detalhes de implementao. Por exemplo, a viso essencial da funo ler o estado de sensor, do SafeHome no se preocupa com a forma fsica dos dados ou com o tipo de sensor que usado. De fato, pode-se argumentar que ler estado seria um nome mais adequado para esse funo, de vez que ela no leva em conta detalhes sobre o mecanismo de entrada. Analogamente, um modelo essencial de dados do item de dados nmero de telefone (implcito na funo discar nmero de telefone) pode ser representado nesse estgio sem considerar a estrutura de dados subjacente (se houver alguma) usada para implementar o item de dados. Concentrando a ateno na essncia do problema, nos primeiros estgios da engenharia de requisitos, deixamos nossas opes abertas para especificar detalhes de implementao durante os ltimos estgios da especificao de requisitos e do projeto de software. A viso de implementao dos requisitos de software apresenta a manifestao do mundo real de funes de processamento e estruturas da informao. Em alguns casos, uma representao fsica desenvolvida como primeiro passo do projeto de software. Entretanto, a maioria dos sistemas baseados em computador especificada de um modo que determina a acomodao de certos detalhes de implementao. Um dispositivo de entrada do SafeHome um sensor perimetral (no um co de guarda ou um guarda humano ou uma armadilha). O sensor detecta a entrada ilegal sentindo uma interrupo no circuito eletrnico. As caractersticas gerais do sensor devem ser anotadas como parte da especificao de requisitos do software. O analista deve reconhecer as restries impostas por elementos predefinidos do sistema (o sensor) e considerar a viso de implementao da funo e da informao quando tal viso for apropriada. J mencionamos que a engenharia de requisitos de software deve focalizar o que o software deve realizar, ao invs de como o processamento vai ser implementado. No entanto, a viso de implementao no deve necessariamente ser interpretada como uma representao do como. Ao invs disso, um modelo de implementao representa o modo atual de operao; isto , a alocao existente ou proposta para todos os elementos do sistema. O modelo essencial (de funo ou dados) genrico no sentido de que a realizao da funo no indicada explicitamente. =================================================================

PROTOTIPAGEM DE SOFTWARE

'

A anlise deve ser conduzida independentemente do paradigma de engenharia de software que aplicado. No entanto, a forma que a anlise assume varia. Em alguns casos possvel aplicar princpios operacionais de anlise e derivar um modelo do software a partir do qual o projeto pode ser desenvolvido. Em outras situaes, a elicitao dos requisitos (usando FAST, QFD, casos de uso ou outras tcnicas de brainstorming ) conduzida, os princpios de anlise so aplicados e um modelo do software, chamado de prottipo, construdo para avaliao pelo cliente e pelo desenvolvedor. Finalmente, algumas circunstncias exigem a construo de um prottipo no incio da anlise, tendo em vista que o modelo o nico modo pelo qual os requisitos podem ser efetivamente derivados. O modelo ento evolui para software em produo.

Seleo da abordagem de prototipagem


O paradigma de prototipagem pode ser de finalidade aberta ou de finalidade fechada. A abordagem de finalidade fechada freqentemente chamada de prototipagem para jogar fora. Usando essa abordagem, um prottipo serve apenas como uma demonstrao rstica dos requisitos. Ele ento descartado e o software construdo usando um paradigma diferente. Uma abordagem de finalidade aberta, chamada prototipagem evolutiva, usa o prottipo como primeira parte de uma atividade de anlise que vai ter continuidade no projeto e construo. O prottipo do software a primeira evoluo do sistema acabado. Antes que uma abordagem de finalidade fechada ou de finalidade aberta possa ser escolhida, necessrio determinar se o sistema a ser construdo adequado prototipagem. Diversos fatores de candidatura a prototipagem podem ser definidos: rea da aplicao, complexidade da aplicao, caracterstica do cliente e caractersticas do projeto. Em geral, qualquer aplicao que cria mostradores visuais dinmicos, interage pesadamente com o usurio ou exige algoritmos, ou processamento combinatrio que deve ser desenvolvido de modo evolucionrio, candidata prototipagem. No entanto, essas reas de aplicao devem ser ponderadas em contraposio complexidade da aplicao. Se uma aplicao-candidata (que tem as caractersticas mencionadas) vai exigir o desenvolvimento de dezenas de milhares de linhas de cdigo antes que qualquer funo demonstrvel possa ser realizada, provvel que ela seja complexa demais
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software
para prototipagem. Se, no entanto, a complexidade puder ser particionada, pode ainda ser possvel prototipar partes do software. Como o cliente precisa interagir com o prottipo nos passos finais, essencial que (1) os recursos do cliente sejam empenhados para a avaliao e refinamento do prottipo e (2) que o cliente seja capaz de tomar decises sobre os requisitos no devido tempo. Finalmente, a natureza do projeto de desenvolvimento vai ter uma forte influncia na eficcia da prototipagem. A gerncia do projeto est querendo, e pode, trabalhar com o mtodo de prototipagem? H ferramentas de prototipagem disponveis? Os desenvolvedores tm experincia com mtodos de prototipagem? Andriole sugere seis questes e indica conjuntos tpicos de respostas, e a abordagem de prototipagem correspondente sugerida.

13

Mtodos e ferramentas de prototipagem


Para que a prototipagem de software seja efetiva, um prottipo deve ser desenvolvido rapidamente de modo que o cliente possa avaliar os resultados e recomendar modificaes. Para realizar a prototipagem rpida, trs classes genricas de mtodos e ferramentas esto disponveis:

Tcnicas de quarta gerao. Tcnicas de quarta gerao (fourth generation techniques, 4GT) incluem um amplo conjunto de linguagens de relatrio e de consulta a base de dados, geradores de programa e aplicaes, e outras linguagens no procedimentais de muito alto nvel. Como 4GT permitem ao engenheiro de software gerar cdigo executvel rapidamente, elas so ideais para a prototipagem rpida. Componentes de software reusveis. Outra abordagem para prototipagem rpida montar, em vez de construir, o prottipo usando um conjunto de componentes de software existentes. A combinao de prototipagem e reuso de componentes de programa vai funcionar somente se um sistema de biblioteca for desenvolvido de modo que os componentes que de fato existem possam ser catalogados e depois recuperados. Deve-se notar que um produto de software existente pode ser usado como prottipo para um produto competitivo "novo e aperfeioado". De certo modo, essa uma forma de reusabilidade para a prototipagem de software. Ambientes de especificao formal e prototipagem. Nas ltimas dcadas vrias linguagens e ferramentas de especificao formais foram desenvolvidas para substituir tcnicas de especificao em linguagem natural. Hoje, desenvolvedores dessas linguagens formais esto no processo de desenvolvimento de ambientes interativos que permitem (1) a um analista criar interativamente especificaes baseadas na linguagem de um sistema ou software, (2) aplicar ferramentas automatizadas que traduzem as especificaes baseadas na linguagem para cdigo executvel e (3) ao cliente usar o cdigo executvel do prottipo para refinar os requisitos formais.

Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

14

ESPECIFICAO
No h dvida de que o modo de especificao tem muito a ver com a qualidade da soluo. Engenheiros de software que tenham sido forados a trabalhar com especificaes incompletas, inconsistentes ou confusas experimentaram a frustrao e a confuso, que invariavelmente resulta. A qualidade, pontualidade e completeza do software sofre como conseqncia.

Princpios de especificao
A especificao, independentemente do modo pelo qual ns a realizamos, pode ser vista como um processo de representao. Requisitos so representados de uma forma que, em ltima anlise, leva implementao bem-sucedida do software. Alguns princpios de especificao podem ser propostos: 1. 2. 3. 4. 5. 6. Separe a funcionalidade da implementao. Desenvolva um modelo do comportamento desejado do sistema que abranja os dados e as respostas funcionais a vrios estmulos do ambiente. Estabelea o contexto no qual o software opera, especificando o modo pelo qual outros componentes do sistema interagem com o software. Defina o ambiente no qual o sistema opera e indique como "uma coleo altamente entrelaada de agentes reage a estmulos do ambiente (modificaes em objetos) produzidas por esses agentes" Crie um modelo cognitivo ao invs de um modelo de projeto ou implementao. O modelo cognitivo descreve um sistema como ele percebido pela sua comunidade de usurios. Reconhea que "as especificaes devem ser tolerantes incompleteza e ampliveis". Uma especificao sempre um modelo - uma abstrao - de alguma situao real (ou imaginada), que normalmente bastante complexa. Conseqentemente, ela vai ser incompleta e vai existir em vrios nveis de detalhe. Estabelea o contedo e a estrutura de uma especificao de modo que ela possa ser facilmente modificada.

7.

Essa lista de princpios bsicos de especificao fornece a base para a representao dos requisitos de software. No entanto, os princpios devem ser traduzidos em realizao.

Representao
J vimos que requisitos de software podem ser especificados de diferentes modos. No entanto, se os requisitos sero postos no papel ou em meio eletrnico de apresentao (e eles quase sempre deveriam ser!), vale a pena seguir um conjunto simples de diretrizes: O formato da representao e do contedo deve ser relevante para o problema. Um esboo geral do contedo de uma Especificao de Requisitos de Software pode ser desenvolvido. No entanto, provvel que as formas de representao contidas na especificao variem com a rea da aplicao. Por exemplo, a especificao para um sistema de automao de fabricao poderia usar simbologia e diagramas de linguagem diferentes da especificao, para um compilador de linguagem de programao. A informao contida na especificao deve ser aninhada. As representaes devem revelar camadas de informao de modo que um leitor possa ir para o nvel de detalhes desejado. Os esquemas de numerao de pargrafos e diagramas devem indicar o nvel de detalhes que est sendo apresentado. Algumas vezes vale a pena apresentar a mesma informao em diferentes nveis de abstrao para ajudar no seu entendimento. Diagramas e outras formas de notao devem ser restritos em quantidade e consistentes no uso. Notao confusa ou inconsistente, quer seja grfica ou simblica, degrada o entendimento e conduz a erros. As representaes devem poder ser revisadas. O contedo de uma especificao vai sofrer modificaes. O ideal que ferramentas CASE estivessem disponveis para atualizar todas as representaes que so afetadas por modificao. Pesquisadores conduziram vrios estudos sobre fatores humanos associados com a especificao. Parece haver pouca dvida de que simbologia e disposio afetam o entendimento. No entanto, engenheiros de software parecem ter preferncias individuais por formas simblicas e diagramticas especficas. A familiaridade freqentemente jaz na raiz da preferncia de uma pessoa, mas outros fatores mais concretos como disposio espacial, padres facilmente reconhecveis e grau de formalidade freqentemente determinam uma escolha individual.

Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software

15

A especificao de requisitos do software


A especificao de requisitos de software produzida no auge da tarefa de anlise. A funo e o desempenho alocados ao software como parte da engenharia de sistemas so refinadas pelo estabelecimento de uma descrio completa da informao, de uma descrio funcional detalhada, de uma representao do comportamento do sistema, de uma indicao dos requisitos de desempenho e das restries de projeto, de critrios de validao adequados e de outra informao pertinente aos requisitos. O Nacional Bureau of Standards, o IEEE (Padro Nr 830-1984) e o Departamento de Defesa Norte-Americano propuseram, cada um, candidatos a formatos para a especificao de requisitos de software (bem como para outra documentao de engenharia de software). A introduo da especificao de requisitos de software declara as metas e objetivos do software, descrevendo-os no contexto do sistema baseado em computador. Na verdade, a introduo pode ser nada mais do que o escopo do software do documento de planejamento. A descrio da informao fornece uma descrio detalhada do problema que o software deve resolver. O contedo, fluxo e estrutura da informao so documentados. O hardware, software e interfaces humanas so descritos para elementos externos do sistema e funes internas do software. Uma descrio de cada funo necessria para resolver o problema apresentada na descrio funcional. Uma narrativa de processamento fornecida para cada funo, restries de projetos so declaradas e justificadas, caractersticas de desempenho so declaradas e um ou mais diagramas so includos para representar graficamente a estrutura geral do software e a interao entre as funes do software e outros elementos do sistema. A seo da especificao descrio comportamental examina a operao do software como conseqncia de eventos externos e caractersticas de controle geradas internamente. Critrios de validao provavelmente a seo mais importante e ironicamente com freqncia a mais negligenciada da especificao de requisitos do software. Como reconhecemos uma implementao bem-sucedida? Que classes de testes devem ser conduzidas para validar a funo, o desempenho e as restries? Ns negligenciamos essa seo porque complet-la demanda um profundo entendimento dos requisitos de software - algo que freqentemente no temos nesse estgio. No entanto, a especificao dos critrios de validao age como uma reviso implcita de todos os outros requisitos. essencial que tempo e ateno sejam dedicados a essa seo. Finalmente, a especificao inclui uma bibliografia e apndice. A bibliografia contm referncias a todos os documentos que se relacionam ao software. Eles incluem outra documentao de engenharia de software, referncias tcnicas, literatura de fornecedores e padres. O apndice contm informao que suplementa as especificaes. Tabelas de dados, descrio detalhada de algoritmos, figuras, grficos e outros materiais so apresentados no apndice. Em muitos casos, a especificao de requisitos do software pode ser acompanhada por um prottipo executvel (que em alguns casos pode substituir a especificao), por um prottipo em papel ou por um Manual do Usurio Preliminar. O Manual do Usurio Preliminar apresenta o software como uma caixa-preta. Isto , grande nfase colocada nas entradas do usurio e nas sadas resultantes. O manual pode servir como ferramenta valiosa para descobrir problemas na interface homem/mquina.

REVISO DA ESPECIFICAO
Uma reviso da especificao de requisitos do software (e/ou prottipo) conduzida tanto pelo desenvolvedor do software quanto pelo cliente. Como a especificao forma a base da fase de desenvolvimento, deve ser tomado extremo cuidado na conduo da reviso. A reviso conduzida primeiro macroscopicamente; isto , os revisores tentam garantir que a especificao esteja completa, consistente e precisa quando os domnios globais informacional, funcional e comportamental so considerados. No entanto, para explorar completamente cada um desses domnios, a reviso torna-se mais detalhada, examinando no apenas as descries amplas mas o modo pelo qual os requisitos so redigidos. Por exemplo, quando especificaes contm "termos vagos" (p. ex., alguns, algumas vezes, freqentemente, usualmente, ordinariamente, a maior parte ou a maioria), o revisor deve marcar os trechos para esclarecimento posterior. Uma vez completada a reviso, a especificao de requisitos do software "assinada", tanto pelo cliente quanto pelo desenvolvedor. A especificao torna-se um "contrato" para o desenvolvimento do software.
Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br

Engenharia de Software
Solicitaes de modificao nos requisitos, depois que a especificao completada, no sero eliminadas. Mas o cliente deve perceber que cada modificao posterior uma extenso do escopo do software e conseqentemente pode aumentar o custo e/ou comprometer o cronograma. Mesmo com os melhores procedimentos de reviso em ao, vrios problemas comuns de especificao persistem. A especificao difcil de "testar" de qualquer modo significativo e, conseqentemente, inconsistncias ou omisses podem passar despercebidas. Durante a reviso, podem ser recomendadas modificaes nas especificaes. Pode ser extremamente difcil avaliar o impacto global de uma modificao; isto , como uma modificao e uma funo afeta os requisitos das outras funes. Ambientes modernos de engenharia de software incorporam ferramentas CASE que tm sido desenvolvidas para ajudar a resolver esses problemas. -------------------------------------------------------------------------------------------------------------------------------------

16

BIBLIOGRAFIA Pressman, Roger S. Engenharia de Software MAKRON BOOKS 5 Edio Sommerville, Ian. Engenharia de Software. Addison Wesley, 6 Edio - 2003

Prof Andr Arantes www.andrearantes.eti.br professor@andrearantes.eti.br