ENGENHARIA DE REQUISITOS PARA APLICAÇÕES WEB

Transcrição

1 0 PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO ENGENHARIA DE REQUISITOS PARA APLICAÇÕES WEB PABLO RODRIGO CAMPELO ALVES UNIVERSIDADE FEDERAL DE PERNAMBUCO RECIFE, JULHO/2009

2 1 UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMÁTICA PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO PABLO RODRIGO CAMPELO ALVES ENGENHARIA DE REQUISITOS PARA APLICAÇÕES WEB Monografia apresentada ao Curso de pós-graduação em Ciência da Computação, Centro de Informática, Universidade Federal de Pernambuco, como requisito parcial para conclusão da disciplina Engenharia de Requisitos. Professor: Prof. Jaelson Brelaz de Castro RECIFE, JULHO/2009

3 2 RESUMO O desenvolvimento de softwares, para que haja uma medida de organização em seu projeto, deve ser feito com base em processos sistemáticos. Os requisitos para este software também precisam ser trabalhados da mesma maneira. O advento da Internet tem feito com que o número de aplicações para a Web cresça. Unindo estes dois fatores, este trabalho tem como objetivo tratar de como os requisitos para aplicações Web podem ser tratados do ponto de vista da Engenharia de Requisitos. Palavras-chave: Engenharia de Requisitos, Aplicações Web.

4 3 ABSTRACT The software development, to be a measure of organization in the project, should be based on systematic processes. The requirements for the software also need to be worked the same way. The Internet advent has done the number of applications for Web grows. Uniting these two factors, the purpose of this paper is to address how the requirements for Web applications can be treated in the terms of Requirements Engineering. Keywords: Requirements Engineering, Web Applications.

5 4 LISTA DE QUADROS Quadro 1: Desenvolvimento de Aplicações Desktop e Aplicações Web...13 Quadro 2: Categorias de Aplicações Web...15 Quadro 3: Comparação da adequação das notações a aplicações Web...22

6 5 LISTA DE ABREVIATURAS E SIGLAS RE Requirements Engineering SEI-CMM Software Engineering Institute Capability Maturity Model UML Unified Modeling Language

7 6 Sumário 1 INTRODUÇÃO FUNDAMENTAÇÃO TEÓRICA ENGENHARIA DE REQUISITOS REQUISITOS ATIVIDADES DA ENGENHARIA DE REQUISITOS ELICITAÇÃO/NEGOCIAÇÃO DE REQUISITOS DOCUMENTAÇÃO VERIFICAÇÃO/VALIDAÇÃO DE REQUISITOS GERENCIAMENTO DE REQUISITOS APLICAÇÕES WEB CATEGORIAS DE APLICAÇÕES WEB ENGENHARIA DE REQUISITOS PARA APLICAÇÕES WEB CARACTERÍSTICAS DA ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DE APLICAÇÕES WEB ENTENDIMENTO DO CONTEXTO DO SISTEMA ENVOLVIMENTO DOS STAKELHOLDERS FORMA ITERATIVA DE DEFINIÇÃO DOS REQUISITOS PARA O SISTEMA ARQUITETURA DO SISTEMA PREOCUPAÇÃO COM OS RISCOS DO PROJETO ENGENHARIA DE REQUISITOS EM APLICAÇÕES WEB REQUISITOS NOTAÇÕES ATIVIDADES DE ENGENHARIA DE REQUISITOS ELICITAÇÃO DE REQUISITOS VALIDAÇÃO DE REQUISITOS GERENCIAMENTO DE REQUISITOS CONCLUSÃO...25 REFERÊNCIAS...26

8 7 1 INTRODUÇÃO Em torno de 1950, quando o software despontou para o mundo, ninguém poderia pensar que este promoveria muitas mudanças, sejam estas no comércio, na indústria, na cultura das pessoas, ou seja, em nossas vidas, mesmo mais de 50 anos depois (SOMMERVILLE, 2006). A Engenharia de Software, que surgiu em meados da década de 70, veio como uma maneira de contornar a crise do software que existia, mas principalmente com o intuito de criar um modo de trabalho sistemático e controlado de desenvolver sistemas (LEITE, 2009). Com o uso de métodos sistemáticos, disciplinados e quantificáveis no projeto como um todo de desenvolvimento de um sistema, viu-se mais tarde que era necessário tratar os requisitos para o novo sistema da mesma forma controlada que estava sendo feito em todo o ciclo de vida do software. Dessa necessidade de se trabalhar os requisitos seguindo processos bem definidos, passa a surgir a engenharia de requisitos. No início, havia apenas sistemas tradicionais (aplicações desktop), e tudo o que aparecia de novo na literatura em si tratando de métodos e processos de Engenharia de Requisitos era destinado a este tipo de aplicação. Mas com o advento da Internet, as aplicações voltadas para a Rede Mundial de Computadores se multiplicou e a demanda por aplicações deste tipo também acompanhou este crescimento. Sendo assim, os desenvolvedores também viram que o tratamento de requisitos para estas aplicações também poderia ser feito como uma engenharia. Logo, começou também a surgir na literatura modelos para se trabalhar a Engenharia de Requisitos para aplicações Web. Este trabalho tem como objetivo tratar de aspectos relacionados à Engenharia de Requisitos para Aplicações Web, trazendo à tona como a Engenharia de Requisitos para aplicações tradicionais pode ser adaptada para aplicações voltadas à Internet. A contar do capítulo 2, o trabalho se inicia com uma base teórica que explana alguns tópicos relacionados a assuntos que envolvem a Engenharia de Requisitos e, no capítulo seguinte, trata mais especificamente do tema proposto. O último capítulo traz as considerações finais acerca do trabalho.

9 8 2 FUNDAMENTAÇÃO TEÓRICA Antes de avançar no estudo propriamente dito da Engenharia de Requisitos para Aplicações Web, é interessante esclarecer alguns tópicos essenciais para o entendimento do assunto. Este capítulo tem por objetivo introduzir alguns conceitos fundamentos para uma melhor compreensão do capítulo posterior. Aqui são abordados alguns conceitos sobre a Engenharia de Requisitos e sobre Aplicações Web. 2.1 ENGENHARIA DE REQUISITOS O desenvolvimento de produtos de software, para que se tenha ao final um resultado de qualidade e satisfatório, deve ser regido por um planejamento bem feito, um projeto bem elaborado, ferramentas úteis ao caso e por processos que melhor se adéqüem ao cenário existente para esta tarefa, ou seja, todo o trabalho deve ser pautado em cima de uma verdadeira engenharia. E, de acordo com Kappel et al.(2006, p. 3), a engenharia em geral significa a aplicação prática da ciência para o comércio ou indústria com o objetivo de projetar aplicações ou solicitações feitas, da melhor, isto é, mais rápida, mais barata, mais segura, etc., maneira. E é seguindo fundamentos da engenharia, que a Engenharia de Software se baseia. Esta pode então ser definida como a aplicação ou o estudo de abordagens sistemáticas, disciplinadas e quantificáveis para o desenvolvimento, operação e manutenção do software, isto é, a aplicação da engenharia ao software (IEEE, 1993, apud PRESSMAN, 2006). Esta área é um campo de estudo que vem crescendo e se aprimorando com o passar do tempo, mas não é o foco deste trabalho. Entretanto, antes de tratar dos outros tópicos relevantes a monografia, foi necessário trazer a tona o seu conceito. Os responsáveis pelo processo de desenvolvimento de um sistema, os engenheiros de software, precisam, no inicio deste, identificar com os interessados na aplicação quais são as expectativas para o novo sistema e quais as restrições que definirão o seu desenvolvimento, ou

10 9 seja, é preciso fazer um levantamento dos requisitos para a nova aplicação. As atividades envolvidas na descoberta, documentação e manutenção de um conjunto de requisitos para um sistema baseado em computador 1 caracterizam-se como a Engenharia de Requisitos (KOTONYA; SOMMERVILLE, 1998). Percebe-se que a Engenharia de Requisitos é como uma parte da atividade de Engenharia de Software, e tal como esta, precisa ser adaptada às necessidades do processo, do projeto, do produto e da equipe de desenvolvimento. Dentro da perspectiva de todo o processo de software e, ao encontro das palavras de Pressman (2006, p. 117), [...] a engenharia de requisitos [...] é uma ação de engenharia de software que começa durante a atividade de comunicação e continua durante a atividade de modelagem Requisitos Os requisitos que envolvem um sistema classificam-se usualmente em 3 (três) tipos (KAPPEL et al., 2006): Requisitos Funcionais: requisitos que definem as capacidades que o sistema terá e os serviços que serão por ele oferecidos. São declarações de funções que o sistema deve fornecer, como o sistema deve reagir a entradas específicas e como deve se comportar em determinadas situações. Requisitos Não-funcionais: requisitos que descrevem níveis desejados de qualidade no sistema, ou seja, quão seguro o sistema será, o seu nível de usabilidade, etc. Acabam por delimitar os serviços ou funções que serão oferecidos pelo sistema. Restrições: tão importante quanto os outros dois tipos de requisitos, restrições são condições não-negociáveis que afetam o projeto. Para exemplificar algumas restrições 1 Um sistema baseado em computador é aquele que automatiza ou apóia a realização de atividades humanas através do processamento de informação.

11 10 comuns durante o desenvolvimento de sistemas, pode-se citar os nível de habilidade ou competência da equipe de desenvolvimento, o orçamento disponível para o projeto, a data de entrega, e a infra-estrutura computacional existente no ambiente de implantação do sistema Atividades da Engenharia de Requisitos De uma forma geral, a Engenharia de Requisitos cobre as atividades de elicitação/negociação, documentação, verificação/validação e gerenciamento dos requisitos durante todo o processo de desenvolvimento de um sistema (KAPPEL et al., 2006) Elicitação/Negociação de Requisitos O primeiro passo a ser dado em um processo de Engenharia de Requisitos é o da elicitação. Elicitar requisitos significa descobrir ou levantar com os interessados no sistema, os clientes e futuros usuários finais, quais serão as suas funcionalidades, o que ele deve oferecer, como o sistema deve se comportar, etc. Parece se uma tarefa fácil, mas na realidade, não é. Os clientes, por vezes, não sabem o que realmente querem para o software e em muitos dos casos é difícil para os engenheiros de requisitos ou sistemas interpretar as reais necessidades daqueles. Existem técnicas diferentes de se elicitar requisitos, cada uma com vantagens e desvantagens em relação à outra, mas todas são boas maneiras de desvendar necessidades do cliente. Dentre algumas destas técnicas estão, por exemplo, entrevistas, observações e questionários. A elicitação é uma atividade que caminha de mãos dadas com a atividade de negociação de requisitos. É necessário que haja uma negociação dos requisitos coletados durante a fase de elicitação porque não é difícil ocorrer de clientes e usuários finais pedirem mais do que pode ser conseguido, considerando o fato de que os recursos são limitados em qualquer projeto

12 11 (PRESSMAN, 2006). Além disto, acontece muitas vezes dos requisitos conflitarem ou não coincidirem nas visões dos clientes do projeto. Por fora, também é preciso que os engenheiros do sistema acordem com estes clientes qual será o grau de prioridade das funções do software Documentação Quando os stakeholders 2 em um projeto de software chegam a um consenso sobre os requisitos para o sistema, o que foi acordado entre eles deve ser refinado e descrito em um documento de requisitos. Esta atividade recebe o nome de documentação de requisitos. O documento que é elaborado tem como característica um certo grau de formalidade e detalhamento o qual irá depender de dois fatores: dos riscos identificados para o projeto do sistema e do nível de experiência e habilidade dos seus prováveis leitores (KAPPEL et al., 2006). O documento servirá como uma fonte de consulta ao longo de todo o desenvolvimento do sistema Verificação/Validação de Requisitos Este é o estágio final da engenharia de requisitos pois é nele que os produtos de trabalho resultantes desta engenharia são avaliados no que diz respeito à qualidade. Segundo Kotonya e Sommerville (1998, p. 87), como o próprio nome implica, o alvo da validação é validar os requisitos, ou seja, é verificar os requisitos para se certificar de que eles representam uma descrição aceitável do sistema que será implementado. A técnica de validação mais comum é a revisão de requisitos, que consiste em um grupo de stakeholders unidos para examinar ou verificar o documento de requisitos elaborado no

13 12 estágio de documentação. Este grupo de stakeholders envolvidos na atividade geralmente é composto pelos engenheiros de software, clientes e usuários, todos com o foco em encontrar, no documento, inconsistências, irregularidades ou informações omissas nos requisitos para o novo sistema Gerenciamento de Requisitos A não ser que um projeto de sistema seja constituído por uma equipe de desenvolvimento muito pequena, como uma ou duas pessoas, e um conjunto de requisitos que não ultrapassa uma dúzia de funcionalidades, os outros projetos normalmente têm como característica a ação de gestão dos seus requisitos. Após uma atividade inicial de descoberta dos requisitos para o sistema e depois destes terem sido organizados e documentados de maneira formal, haverá um monitoramento comum dos requisitos para o caso deles mudarem, o que é algo muito previsível em projetos de software. O gerenciamento de requisitos pode ser definido como uma abordagem sistemática para a elicitação, organização e documentação dos requisitos do sistema, e um processo que estabelece e mantém um acordo entre o cliente e a equipe do projeto em mudanças nos requisitos do sistema (LEFFINGWELL e WIDRIG, 2000). Existem tipos de processos para o gerenciamento de requisitos em um projeto de software, e o SEI-CMM (Software Engineering Institute s Capablility Maturity Model) e o ISO 9000 Quality Management Standards são os mais representativos no mercado. 2 Stakeholders de um sistema são pessoas ou organizações que serão afetados pelo sistema e quem tem influência direta ou indireta nos requisitos para o sistema.

14 APLICAÇÕES WEB Quando uma aplicação vai ser desenvolvida, é interessante notar que tipo de aplicação ela será. Esta diferenciação deve ser feita porque, dependendo da aplicação, além de outros fatores que circundam um projeto de sistema, um ou outro processo de engenharia será utilizado durante o trabalho. Considerando-se o desenvolvimento de uma aplicação tradicional ou desktop e o desenvolvimento de uma aplicação para a Web, podem-se observar entre eles algumas diferenças, como é demonstrado no Quadro 1: IMEDIATISMO SEGURANÇA DESENVOLVIMENTO DE APLICAÇÕES WEB O tempo em que uma aplicação para a Web precisa para ficar pronta pode ser de apenas alguns poucos dias ou semanas. Aplicações Web estão mais susceptíveis a falhas de segurança pois estão disponíveis na rede. É difícil e chega até mesmo a ser impossível limitar a quantidade de pessoas que irá acessar a aplicação. DESENVOLVIMENTO DE APLICAÇÕES DESKTOP O tempo gasto no desenvolvimento de uma aplicação desktop geralmente leva meses. O desenvolvimento de aplicações desktop está mais despreocupado com fatores de segurança, levando-se em conta que este tipo de aplicação é utilizado normalmente por um grupo específico de usuários.

15 14 ESTÉTICA O desenvolvimento é fortemente moldado pelo lado estético ou visual que a aplicação terá. Aqui, o lado funcional do sistema a ser desenvolvido é muito mais predominante. Quadro 1 - Desenvolvimento de Aplicações Desktop e Aplicações Web Fonte: SANDRA et al. (2002) Uma aplicação Web pode ser definida como um sistema de informática projetado para a utilização através de um navegador, na internet ou em redes privadas, e o seu desenvolvimento tem muito haver com a necessidade de simplificar a utilização e manutenção, mantendo o código fonte em um mesmo local, de onde é acessado pelos diferentes usuários (ANICETO, 2009, p. 2) Categorias de Aplicações Web As aplicações Web podem ser divididas basicamente em 6 (seis) categorias, apesar de dadas aplicações pertencerem a mais de um grupo. No Quadro 2 é apresentada as 6 (seis) categorias e exemplos de respectivas aplicações Web.

16 15 Quadro 2: Categorias de Aplicações Web Fonte: SUH (2005, p. 5) A seguir é apresentada uma breve explicação sobre cada uma das categorias de aplicações Web citadas no Quadro 1 (KAPPEL et al., 2006): Informacional: Os sistemas informacionais são aquelas aplicações Web que, como o próprio nome diz, tem por objetivo informar os seus usuários. Interativo: Na categoria dos interativos, estão aquelas aplicações que tem como característica marcante o fato de oferecerem uma forma de interatividade por meio de formulários, botões e menus de seleção. Transacional: O caso dos sistemas transacionais também é muito parecido com o dos interativos, porém aqui a interatividade do usuário com a aplicação é muito maior, dando a ele possibilidades como a de realizar alterações nos conteúdos do sistema. Orientada a workflow: Aplicações orientadas a workflow consistem naquelas que permitem movimentação de trabalho dentro ou entre diferentes companhias, entidades públicas e usuários privados por meio da rede mundial de computadores. As aplicações Web que possibilitam planejamento e montagem de cronogramas online são grandes exemplos desta categoria.

17 16 Ambiente de trabalho colaborativo: Na categoria de ambientes de trabalho colaborativo, estão sistemas que foram desenvolvidos especialmente para a cooperação de objetivos em operações não estruturadas, os chamados groupwares, onde a necessidade de comunicação entre os usuários é alta. Comunidades online / Marketplace: Nesta categoria estão aplicações que, assim como na categoria de ambiente de trabalho colaborativo, permitem partilha de informações entre um grande número de usuários, mas em um ambiente muito mais informal.

18 17 3 ENGENHARIA DE REQUISITOS PARA APLICAÇÕES WEB A engenharia de requisitos responde por cerca de 15% dos custos totais de um projeto de software, e esta parte do processo, não sendo bem desenvolvida, pode levar a alguns insucessos ou até ao fracasso total do projeto (KOTONYA; SOMMERVILLE, 1998). Por isso mesmo é tão importante que se siga de forma bem conduzida um processo de engenharia de requisitos pra o sistema a ser implementado. No caso do desenvolvimento de sistemas para a Internet, aplicações estas que surgiram após as aplicações desktop, é preciso fazer adaptações e ajustes em atividades comuns do processo tradicional de engenharia de requisitos. Neste capítulo é mostrado como se pode realizar uma engenharia de requisitos que se adéqüe aos tipos de aplicação voltados para a Web. 3.1 CARACTERÍSTICAS DA ENGENHARIA DE REQUISITOS NO DESENVOLVIMENTO DE APLICAÇÕES WEB No entorno de projetos de software existem características que lhes são peculiares, e no desenvolvimento de aplicações Web, particularmente, algumas características são comuns a esse tipo de sistema e que se tornam especiais em se tratando da atividade de engenharia de requisitos. Aspectos naturais ao processo de RE, em conformidade com Kappel et al.(2006), são vistos nas próximas seções Entendimento do Contexto do Sistema Saber no que o sistema será útil, ou seja, o negócio na qual o sistema que será desenvolvido irá atuar é um fator chave para se obter sucesso na implementação de aplicações Web. Entender o contexto no qual o sistema estará inserido é uma ótima prática, visto que só tem

19 18 a ajudar desenvolvedores e demais stakeholders no processo de identificação de requisitos para o novo sistema Envolvimento dos Stakelholders Os gestores de projetos de aplicações Web devem saber administrar bem a falta do cliente e/ou usuários durante o desenvolvimento do sistema. A pouca participação e envolvimento de stakeholders na fase de RE de aplicações Web é comum, e é algo que pode atrasar o cronograma estabelecido para o projeto Forma Iterativa de Definição dos Requisitos para o Sistema Em ambientes dinâmicos, como é o caso de um ambiente para o desenvolvimento de aplicações Web, o modelo cascata de desenvolvimento não é o mais indicado. O ideal de se trabalhar em projetos de sistemas para a Internet é seguindo um modelo iterativo de desenvolvimento, o que também se aplica à RE no que diz respeito á captura de requisitos para o sistema. A implementação começa com um conjunto que se pode dizer abstrato, de requisitos, e evolui à medida que o sistema for tomando contornos mais fortes para requisitos que melhor descrevem a aplicação desejada Arquitetura do Sistema Os requisitos para um sistema voltado à Internet nunca podem ser elicitados de forma independente à arquitetura que irá definir a aplicação. Realizar as atividades de RE em um

20 19 projeto de aplicação Web sem nunca perder o foco da arquitetura que o sistema terá é algo primordial para evitar, por exemplo, situações como a de descobrir a não viabilidade do projeto por problemas com tecnologias existentes e outras questões associadas Preocupação com os Riscos do Projeto Os projetos de software, sejam estes tradicionais ou voltados para a Internet, são acompanhados muitas vezes de riscos de falhar em algum aspecto. Entre os riscos mais comuns em projetos de sistemas Web estão a falta de experiência dos desenvolvedores ou riscos associados a tecnologias existentes e o risco que envolvem a integração do sistema a ser desenvolvido com um outro já existente. No âmbito das atividades de RE, é válido, durante a elicitação de requisitos, a construção de protótipos do sistema a fim de evitar surpresas futuras quanto a requisitos mal entendidos ou mal interpretados. 3.2 ENGENHARIA DE REQUISITOS EM APLICAÇÕES WEB Os modelos de desenvolvimento de software existentes na literatura não são, normalmente, seguidos à risca em um projeto de sistema, até porque cada um deles é, como o próprio nome diz, modelos que servem para nortear um projeto, e que podem muito bem ser complementados com boas técnicas de um ou mais modelos e podem ser adaptados para melhor atenderem às necessidades do projeto em questão. Adaptação esta que também pode ser usada para se chegar a uma RE cabível a projetos de aplicações Web. As aplicações baseadas na Web têm uma forte ênfase em navegabilidade e design, no visual da aplicação (ESCALONA; KOCH, 2009). Por isto mesmo elas irão diferir das aplicações tradicionais em alguns aspectos, e de início estão os requisitos, os quais irão modificar um pouco

21 20 a forma tradicional de RE para softwares. Estas mudanças, que são aqui divididas em 3 (três) partes (requisitos, notações e ferramentas), apoiando-se em Kappel et al.(2006), são vistas nos próximos tópicos Requisitos Foi visto no capítulo anterior que os requisitos são normalmente divididos em requisitos funcionais e não-funcionais, além de restrições. Acontece que em sistemas para a Internet a classificação dos requisitos pode ser muito mais ampla e abrangente, haja vista a diversidade de requisitos que caracteriza uma aplicação Web. Pode-se ter os seguintes tipos de requisitos para estas aplicações: Requisitos Funcionais Como foi visto, os requisitos funcionais especificam as capacidades e serviços que o sistema deve oferecer; Requisitos de Sumário ou Conteúdo Estes são requisitos que especificam o conteúdo da Web que a aplicação deve representar; Requisitos de Qualidade Os requisitos de qualidade dizem respeito à características mensuráveis do sistema e que agregam ou não valor a ele (WIEGERS, 1999). Podese citar os níveis de confiabilidade, usabilidade e portabilidade da aplicação; Requisitos de Ambiente de Sistema Estes requisitos descrevem como uma aplicação Web está inserida em um ambiente. Isto inclui os sistemas aos quais ela possa estar ligada, a outros sistemas já existentes, componentes e hardwares; Requisitos de Interface do Usuário Requisitos associados à interface que será apresentada pela aplicação ao usuário. Sabendo-se que uma aplicação Web terá um público usuário diversificado e com diferentes conhecimentos e níveis de instrução, geralmente requisitos relacionados a este tipo prezam por aplicações auto-explicativas e intuitivas, visando uma fácil aceitação por parte do usuário; Requisitos de Evolução Os softwares, de maneira geral, e de forma mais intensa as aplicações Web, evoluem com o passar do tempo. Os requisitos de evolução são

22 21 aqueles que identificam mudanças na qualidade do software que deverá ocorrer em um certo espaço de tempo a frente. Mudanças estéticas na aplicação (visual) que deverão ocorrer após dois anos a partir da conclusão do sistema é um exemplo; Restrições Assim como visto no capítulo anterior, as restrições são condições nãonegociáveis que afetam o projeto, tais como orçamento e cronograma Notações Existem muitas notações variadas, todas com o objetivo de especificar requisitos em diferentes graus de detalhe e formalidade. As notações mais comuns para aplicações voltadas à Internet são: Estória: Estórias são descrições escritas pelos usuários de cenários com situações de utilização que os envolvidos gostariam que o sistema em desenvolvimento viesse a oferecer. Uma estória é um texto escrito com aproximadamente 3 (três) sentenças (LEITE, 2007); Requisitos Detalhados: Um requisito discriminado é uma simples especificação em linguagem natural com um identificador único; Especificações Formatadas: As especificações utilizam uma sintaxe definida com precisão, mas também permitem descrições em linguagem natural. Um exemplo bastante conhecido são as descrições de casos de uso da Unified Modeling Language (UML). Outros tipos de linguagem incluem o RDD-100 Requirements Specification e o MBASE SSRD Guidelines. Especificações Formais: Dificilmente usadas para especificar aplicações Web, estas especificações são escritas em uma linguagem que utiliza uma sintaxe e semântica formalmente definidas. Entre os tipos de notação descritos acima, e numa comparação entre eles considerando atributos como precisão, facilidade de validação, custo-benefício, adequação a não-especialistas e

23 22 escalabilidade da aplicação, verifica-se que especificações formatadas são mais apropriadas para o caso dos sistemas para Internet. O Quadro 3 (três) apresenta um comparativo entre as notações de acordo com sua adequação a aplicações Web. Quadro 3: Comparação da adequação das notações a aplicações Web Fonte: Kappel et al.(2006, p. 35) Atividades de Engenharia de Requisitos Nas próximas seções é discutido como se pode realizar as principais atividades da engenharia de requisitos na perspectiva de aplicações Web, baseando-se no estudo de Kappel et al.(2006) Elicitação de Requisitos A elicitação de requisitos é a atividade inicial de RE em desenvolvimento de sistemas, e para as aplicações Web não é diferente. Já foi dito neste trabalho que os requisitos inevitavelmente irão mudar no decorrer de qualquer projeto de software, e nos projetos de sistemas para Internet, isto ocorrerá com maior intensidade. A diferença entre a elicitação de requisitos que pode ser feita durante o desenvolvimento de aplicações tradicionais para as

24 23 aplicações Web é que técnicas de elicitação que são comumente praticadas naquela, nesta já não têm o mesmo valor. Técnicas de elicitação de requisitos como a observação/análise social, por exemplo, não é tão eficaz para se levantar funções do novo sistema Web quanto é para aplicações desktop. Um método ou ferramenta para coletar e, em especial, negociar requisitos coletados, é o EasyWinWin, que é uma abordagem baseada em groupware, na qual um moderador orienta e dirige stakeholders em um processo para, conjuntamente, levantar e negociar requisitos para a nova aplicação Validação de Requisitos Após os requisitos terem sido documentados em um processo que não apresenta diferenças para a forma como é feita a documentação de requisitos na RE de aplicações tradicionais, é o momento da atividade de validação. O adicional aqui é que, por a Internet promover uma nova forma de comunicação e contato entre as pessoas, uma forma de validação online pode ser usada em adição a forma usual de reunião física com os clientes do sistema, e até mesmo substituir este modo. A grande vantagem aí é que o sistema poderá receber as sugestões e avaliações não só dos seus clientes em potencial, mas também feedbacks dos usuários da rede, os quais podem dar um parecer bem útil à equipe de desenvolvimento Gerenciamento de Requisitos O gerenciamento de requisitos dentro da RE de aplicações Web é feito da mesma maneira como em aplicações tradicionais. Considerando que a gestão de requisitos é apenas uma forma de gerir os requisitos coletados no projeto através de um repositório central, existem várias

25 24 ferramentas para auxiliar neste processo de gestão, ficando a cargo da equipe do projeto escolher aquela que melhor irá se adequar ao seu projeto, visando sempre uma melhor administração e rastreabilidade dos requisitos mutantes.

26 25 4 CONCLUSÃO Como tudo que surge para facilitar ou organizar a vida do homem de alguma forma, e a tecnologia é assim, a Engenharia de Requisitos tem por função-fim apenas organizar a maneira como é realizada atividades concernentes a esta área, tais como a elicitação ou coleta de requisitos, a sua negociação, a documentação, a verificação e validação dos mesmos e o seu futuro gerenciamento. Ou seja, trazer uma forma elaborada e sistemática de realizar um trabalho, para que este não seja feito de maneira desestruturada ou ad-hoc, como eram desenvolvidos os softwares antigamente. O estudo da Engenharia de Requisitos para aplicações do tipo Web ainda não está totalmente avançada, haja vista que ainda não há muito na literatura desta ciência sobre o assunto. Todavia, com o avanço rápido de novas tecnologias para o desenvolvimento de aplicações Web pelo mundo e a crescente demanda no mercado e nos negócios por aplicações deste patamar, há um ambiente favorável para o surgimento de novos métodos, processos e mais tecnologias que visem tratar e aprofundar a evolução da Engenharia de Requisitos. Seguir padrões, modelos, métodos ou processos em atividades comuns do dia-a-dia só contribuem para um melhor resultado desta e ajuda a manter um melhor controle e gerenciamento sobre o que é feito ou o que falta ser. Por isso, as aplicações Web, assim como as aplicações tradicionais, precisam ter seus requisitos trabalhados seguindo uma engenharia, pois os requisitos, além de serem algo de difícil entendimento por parte dos desenvolvedores quanto aos interesses dos clientes, é algo que irá sempre mudar em qualquer projeto.

27 26 REFERÊNCIAS ANICETO, Jefferson. Aplicações Web. Apostila ASP.net. Escola Técnica da Univale (ETEIT) ESCALONA, José ; KOCH, Nora. Requirements Engineering for Web Applications. Journal of Web Engineering. V. 2, n. 3, p , KAPPEL, Gerti; PR OLL, Birgit; REICH, Siegfried; RETSCHITZEGGER, Werner. Web Engineering The Discipline of Systematic Development of Web Applications. John Wiley & Sons Ltd., KOTONYA, Gerald; SOMMERVILLE, Ian. Requirements Engineering Processes and Techniques. John Wiley & Sons Ltd., LEFFINGWELL, Dean; WIDRIG, Don. Managing Software Requirements A Unified Approach. Addison Wesley Longman LEITE, Jair. Programação Extrema (XP). Artigo. Engenharia de Softaware. Blog pessoal do autor Disponível em: < Acesso em 10/07/2009. LEITE, Jair Cavalvanti. Engenharia de Software Disponível em: < Acesso em: 08/07/2009. PRESSMAN, Roger. Engenharia de Software. 6. ed. São Paulo: McGraw-Hill, 2006.

28 27 SANDRA; ROSÂNGELA; JÚNIA; SÍLVIA. Engenharia para Web. Universidade Federal de São Carlos (UFSCar). Projeto e Gerência de Sistemas de Software. Interface Homem Máquina SUH, Woojong. Web Engineering Principles and Techniques. IGI Publishing, WIEGERS, Karl. Software Requirements. Paperback, 1999.