UNIVERSIDADE FEDERAL DE PERNAMBUCO CENTRO DE INFORMTICA PS GRADUAO EM CINCIA DA COMPUTAO

ERTON WAGNER VIEIRA DA SILVA

METODOLOGIAS GEIS, ENGENHARIA DE REQUISITOS E USABILIDADE DE SOFTWARE: ESTADO DA ARTE ENTRE PONTOS DE INTERAO.

RECIPE - PE 2010.2

ERTON WAGNER VIEIRA DA SILVA

METODOLOGIAS GEIS, ENGENHARIA DE REQUISITOS E USABILIDADE DE SOFTWARE: ESTADO DA ARTE ENTRE PONTOS DE INTERAO

Trabalho apresentado ao Curso de Mestrado em Cincia da Computao como requisito parcial avaliao na disciplina de Engenharia de Requisitos ministrada pelo Prof. Jaelson Brelaz de Castro.

RECIPE PE 2009.1

Resumo

Vrias metodologias de desenvolvimento de softwares foram desenvolvidas durante as ltimas dcadas, entre os quais, este trabalho destaca Engenharia de Requisitos, Usabilidade de Software e Metodologias geis. Ambas so bastante impactantes quando utilizadas separadamente em um projeto. Contudo quando so usadaos em conjunto os resultados vo alm das expectativas. Este trabalho expe o estado da arte das pesquisas que prope a mescla destas trs metodologias e como podem influenciar na forma de desenvolver software atualmente.

Palavras-chave: Engenharia de Requisitos, Usabilidade, Metodologias geis.

Sumrio

1. INTRODUO---------------------------------------------------------------------------------------------- 06

2. REQUISITOS ---------------------------------------------------------------------------------------------- 07 2.1. Requisitos No Funcionais ------------------------------------------------------------------------------ 07

3. USABILIDADE ----------------------------------------------------------------------------------------------- 11

4. METODOLOGIAS GEIS ----------------------------------------------------------------------------------- 17

5. ESTADO DA ARTE ------------------------------------------------------------------------------------------- 20 5.1. 5.2. 5.3. Estado da Arte: Engenharia de Requisitos @ Mtodos geis ------------------------------ 20 Estado da Arte: Engenharia de Requisitos @ Usabilidade ------------------------------------ 23 Estado da Arte: Usabilidade @ Mtodos geis ---------------------------------------------- 27

6. CONCLUSO ---------------------------------------------------------------------------------------------31

7. REFERNCIAS --------------------------------------------------------------------------------------------- 32

Lista de Quadros e Figuras

Quadro 1. Requisitos no funcionais da IEEE -------------------------------------------------------------- 08 Quadro 2. 252 tipos de requisitos no funcionais (Mairiza, Zowghi e Nurmuliani, 2010) ------- 10 Quadro 3. Heurstica de Nielsen (Dias, 2003)--------------------------------------------------------------- 12 Quadro 4. Critrios ergonmicos de Bastien & Scapin (Dias, 2003) ---------------------------------- 13 Quadro 5. Regras de Ouro de Shneiderman ( Dias, 2003) ----------------------------------------------- 14 Quadro 6. Princpios abordados na norma ISO 9241-10 (Dias, 2003) -------------------------------- 15 Quadro 7. Comparao entre metodologias geis e convencionais (adaptado de ULLAH e ZAIDI, 2009) ----------------------------------------------------------------------------------------------------------------- 17 Quadro 8. Workflow, regras e responsabilidades dos times de UX trabalhando em metodologia gil. -------------------------------------------------------------------------------------------------------------------- 28

Figura 1. Classificao de Requisitos No Funcionais (Sommerville, 2007) ------------------------ 09 Figura 2. Disciplinas que o IHC abrange (Preece, 1994) ------------------------------------------------- 11 Figura 3. Modelo de interao humano-computador de Mayhew apud Zilse (2004) ----------- 12 Figura 4. Modelo Conceitual de RP -------------------------------------------------------------------------- 22 Figura 5. Exemplo de diagrama TEAM confeccionado pela ferramenta DREAM. ----------------- 25 Figura 6. Tarefas descobertas pelos especialistas em usabilidade mapeada em atividades de RE. --------------------------------------------------------------------------------------------------------------------- 26 Figura 7. Colaborao entre PO UX, PO, Unidade de negcio e Gerente de projeto. ------------ 28

6 1. Introduo

Os requisitos no funcionais parecem ser sempre subestimados quando vamos elicitar todos os requisitos. Gerentes de projetos tendem a negligenciar os requisitos no funcionais, especialmente quando a gesto focada no usurio e seus objetivos, o que contraditrio, pois, exatamente pensando nos usurios finais que os requisitos no funcionais so elicitados. Tal comportamento pode acarretar em grandes problemas no desenvolvimento do projeto, pois, Sommerville (2004) j afirmava que os requisitos no funcionais afetam vrios componentes do sistema e est relacionado intimamente com os requisitos funcionais do projeto. Cada requisito no funcional cumulativo. Os requisitos descobertos durante a pesquisa inicial so importantes em todo o processo de desenvolvimento de software. Impactando diretamente em suas metodologias de desenvolvimento. Atualmente as metodologias mais utilizadas so conhecidas como gil. Soares (2004) explica: A ideia das metodologias geis o enfoque nas pessoas e no em
processos ou algoritmos. Alm disso, existe a preocupao de gastar menos tempo com documentao e mais com a implementao. Uma caracterstica das metodologias geis que elas so adaptativas ao invs de serem preditivas. Com isso, elas se adaptam a novos fatores decorrentes do desenvolvimento do projeto, ao invs de procurar analisar previamente tudo o que pode acontecer no decorrer do desenvolvimento. (SOARES, 2004)

Segundo Sommerville (2001) esses mtodos so uma forma estruturada de se desenvolver software com o objetivo de facilitar a sua produo com alta qualidade e de maneira rentvel. E as metodologias geis vm se destacando por conseguir uma alta produo e qualidade no desenvolvimento de software. Contudo, levando em considerao a rapidez em que se d inicio ao desenvolvimento, grupos de desenvolvedores que utilizam os mtodos geis abdicam de gastar um tempo considervel na elicitao de requisitos. Requisitos funcionais so observados ao mesmo tempo em que o produto de software est sendo desenvolvido. E quando entramos no campo de ao das metodologias geis, os requisitos no funcionais tendem a no ter nenhuma chance. Entre estes requisitos no funcionais que no so observados com a cautela que merecem, destaca-se a Usabilidade, que por tanta importncia, existem linhas de pesquisa que estudam unicamente o impacto da usabilidade na aceitao ou descarte de softwares. Entretanto, existem diversas pesquisas que apontam uma mudana de postura em relao elicitao de requisitos em ambientes de desenvolvimento gil, tanto com requisitos funcionais quanto os no funcionais, adaptando as doutrinas originais do movimento gil de uma forma que tenhamos uma leve, porm eficiente, levantamento de requisitos.

7 2. Requisitos

Requisitos de sistemas, de acordo com Sommerville (2004), definem o que solicitado ao sistema fazer e com quais limitaes ele requisitado a operar. Pode variar de uma declarao abstrata de alto nvel de um servio ou de uma restrio de sistema para uma especificao matemtica funcional. Isto inevitvel quando os requisitos podem servir uma funo dupla. Pode ser a base para uma proposta de um contrato portanto deve ser aberta para interpretao. Pode ser a base para o contrato em si portanto deve ser definido em detalhe. Ambas as declaraes podem ser chamadas requisitos. De acordo com o Sommerville apud Colanzi (2010) requisitos podem ser divididos em dois tipos: Requisitos de usurio - Declaraes em linguagem natural mais diagramas de servios que o sistema fornece e suas restries operacionais. Escritos para os usurios. Requisitos de sistema - Um documento estruturado estabelecendo descries detalhadas das funes, servios e restries operacionais do sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato entre o cliente e o desenvolvedor. De modo geral os requisitos esto divididos em: Requisitos Funcionais So requisitos que expressam funes ou servios que um software deve ou pode ser capaz de executar ou fornecer. As funes ou servios so, em geral, processos que utilizam entradas para produzir sadas. Requisitos No Funcionais So requisitos que declaram restries, ou atributos de qualidade para um software e/ou para o processo de desenvolvimento deste sistema. Segurana, preciso, usabilidade, desempenho e manutenabilidade so exemplos de requisitos no funcionais.

2.1.

Requisitos No Funcionais

Os requisitos no funcionais definem qualidades gerais do sistema, e por estarem diretamente relacionados com a satisfao do usurio um determinante de sucesso para o sistema. Eles so subjetivos, podem ter diferentes interpretaes para cada pessoa; relativos, dependem diretamente do sistema a ser implementado; e so interativos, interagem entre si, podendo afetar negativamente ou positivamente outros requisitos (Leite & Santa Cruz, 2009). A distino entre o que um requisito funcional e o que um no funcional nem sempre clara. Parte da razo advm para o fato de que esto sempre

8 relacionados a um requisito funcional. Partindo desta deficincia pode-se afirmar que um requisito funcional expressa algum tipo de transformao que tem lugar no software, enquanto o no funcional expressa como essa transformao ir se comportar ou que qualidades especficas ela dever possuir. Requisitos no funcionais podem ser mais crticos do que os requisitos funcionais. Se estes no forem atendidos, o sistema intil. Sommerville (2007), Pressman (2004) entre outros autores, apontam as seguintes caractersticas dos Requisitos No Funcionais: - Requisitos no funcionais fixam restries sobre como os requisitos funcionais sero implementados; - A satisfao desses requisitos afetam vrios componentes do sistema; - No so implementados do mesmo modo que os requisitos funcionais; - Raramente so considerados durante o processo de desenvolvimento; - Definem qualidade gerais sobre o sistema; - No possuem mapeamento direto das funcionalidades; - No so fceis de detectar; - Se relacionam diretamente com o produto, suas funes e/ou com o ambiente onde ser implementado; - Desempenham um papel crtico durante o desenvolvimento de sistemas e erros devido a no elicitao ou a elicitao incorreta destes esto entre os mais caros e difceis de corrigir, uma vez que um sistema tenha sido implementado.

No existe uma definio normal de quais e quantos so os requisitos no funcionais. Porm existem vrias propostas de classificar estes requisitos. A IEEE-Std 830 de 1998 lista 13 principais requisitos no funcionais.

Quadro 1. Requisitos no funcionais da IEEE

De acordo com Sommerville (2007) os requisitos no funcionais podem ser divididos em trs categorias: Requisitos de Processo, Requisitos de Produto e Requisitos Externos.

Figura 1. Classificao de Requisitos No Funcionais (Sommerville, 2007)

Requisitos do processo restries aplicadas no processo de desenvolvimento do sistema. Pode ser restries sobre padres e mtodos, sobre ferramentas CASE e relatrios de gerenciamento. So eles: requisitos de entrega, implementao e de padres. Requisitos do produto apontam caractersticas desejadas que o sistema deve oferecer. Alguns podem ser facilmente formulados e quantificados, e outros podem ser mais difceis, sendo assim declarados mais informalmente. Dentre os requisitos esto: confiabilidade, eficincia, performance, capacidade, segurana (safety) e usabilidade (foco deste trabalho, ser detalhado na seo a seguir). Requisitos externos restries que podem ser colocadas tanto no produto como no processo, e relativo ao ambiente onde est sendo desenvolvido o sistema. Podem ser baseados no domnio da aplicao, nas consideraes organizacionais, na interao com outros sistemas e segurana. As restries podem ser legais, econmicas e de interoperabilidade.

Alm destas classificaes apresentadas acima, Mairiza, Zowghi e Nurmuliani (2010) identificaram 252 tipos diferentes de requisitos no funcionais, dos quais 114 so requisitos no funcionais que podem ser discutidos especificamente em relao a qualidade.

10

Quadro 2. 252 tipos de requisitos no funcionais (Mairiza, Zowghi e Nurmuliani, 2010)

11 3. Usabilidade

A usabilidade um importante requisito no funcional, tal que estudada em outras reas de pesquisa, como por exemplo, a linha de pesquisa em Interao Homem-Computador (IHC). Almeida (2007) define a interao homem-computador como o estudo que tem como objetivo uma mudana conceitual do projeto centrado no sistema para o projeto centrado no usurio. Padovani apud Zilse (2004) destaca duas definies para o que a interao humano-computador: Conjunto de processos, dilogos e aes atravs dos quais um usurio humano interage com um determinado sistema computadorizado, e; Uma disciplina que se dedica ao design, avaliao e implementao de sistemas computadorizados interativos para o uso humano, e ao estudo dos principais fenmenos que circundam a interao.

Schnaider (2006) aponta a IHC como sendo uma rea multidisciplinar que abrange reas como: antropologia, cincias da computao, design, engenharia, ergonomia, psicologia cognitiva, sociologia, lingustica, semitica, usabilidade, dentre outras.

Figura 2. Disciplinas que o IHC abrange (Preece, 1994)

Mayhew apud Zilse (2004) traa um modelo de trs fases na interao homemcomputador.

12

Figura 3. Modelo de interao humano-computador de Mayhew apud Zilse (2004)

Existem inmeros estudos realizados no campo da interao humanocomputador por pesquisadores renomados como Morville e Rosenfeld (2002), Farkas e Farkas (2002) e Ribeiro (2007). Contudo alm dos estudos realizados pelos pesquisadores citados, destacam-se os guias de boa interface. Dias (2003) destaca 4 desses guias elaborados por Nielsen (1995), Bastien & Scapin (1993), Shneiderman (1998) e a ISO 9241-10.

Heurstica de Nielsen 1. Visibilidade do estado atual do sistema o sistema deve sempre manter informado os usurios a respeito do que est acontecendo, por meio de feedback apropriado em tempo razovel; 2. Correlao entre sistema e o mundo atual o sistema deve falar a linguagem do usurio, com palavras, frases e conceitos familiares, ao invs de utilizar termos tcnicos. As convenes do mundo real devem ser seguidas, fazendo com que as informaes apaream em uma ordem lgica e natural ao usurio; 3. Controle e liberdade do usurio os usurios costumam escolher, por engano, funes do sistema, e precisam encontrar uma maneira de sair da situao ou estado indesejado, sem maiores problemas. Deve ser possvel ao usurio desfazer ou refazer operaes; 4. Consistncia e padres os usurios no devem ter que adivinhar que palavras, situaes ou aes diferentes significam a mesma coisa; 5. Preveno de erros melhor do que boas mensagens de erro um projeto

13 cuidadoso que previna, em primeiro lugar, a ocorrncia de erros; 6. Reconhecimento ao invs de memorizao objetos, aes e opes devem ser visveis. O usurio no deve ser obrigado a lembrar de informaes ao passar de um dilogo a outro. As instrues de uso do sistema devem estar visveis ou facilmente acessveis quando necessrios; 7. Flexibilidade e eficincia de uso deve ser permitido ao usurio personalizar ou programar aes frequentes. Devem ser implementados aceleradores para usurios mais experientes; 8. Projeto esttico e minimalista os dilogos no devem conter informaes irrelevantes ou raramente necessrias. Cada unidade extra de informao em um dilogo compete com unidades relevantes de informao e diminuem a sua visibilidade relativa; 9. Suporte aos usurios no reconhecimento, diagnstico, e recuperao de erros as mensagens de erro devem ser expressas em linguagem clara, sem cdigos, indicando precisamente o problema e sugerindo solues; 10. Informaes de ajuda e documentao - a documentao do sistema deve sempre estar disponvel ao usurio, mesmo que o sistema seja fcil de usar. A documentao de auxlio ao usurio deve ser fcil de pesquisar, focada nas tarefas que o usurio costuma realizar com o sistema e no muito longa

Quadro 3. Heurstica de Nielsen (Dias, 2003)

Critrios ergonmicos de Bastien & Scapin 1. Conduo refere-se aos dispositivos para aconselhar, orientar, informar, e conduzir o usurio na interao com o computador (mensagens, alarmes, rtulos). Quatro subcritrios participam da conduo: a presteza, o agrupamento/distino entre itens, o feedback imediato e a legibilidade. 2. Carga de trabalho diz respeito a todos os elementos da interface que tm um papel importante na reduo da carga cognitiva e perceptiva do usurio e no aumento da eficincia do dilogo. Esse critrio subdividiu-se em: brevidade (o qual inclui conciso e aes mnimas) e densidade informacional. 3. Controle explcito trata do processamento explcito pelo sistema das aes do usurio, quanto do controle que os usurios tm sobre o processamento de suas aes pelo sistema. Subdivide-se em dois critrios: aes explcitas do usurio e controle do usurio. 4. Adaptabilidade diz respeito capacidade de um sistema de reagir conforme o contexto, necessidades e preferncias do usurio. Dois subcritrios participam da adaptabilidade: a flexibilidade e a considerao da experincia do usurio.

14 5. Gesto de erros trata de todos os mecanismos que permitam evitar ou reduzir a ocorrncia de erros e, quando eles ocorrem, que favoream sua correo. 6. Homogeneidade/consistncia esse critrio refere-se forma como os cdigos, denominaes, formatos, procedimentos e outros elementos da interface foram, em sua concepo, conservados idnticos e contextos idnticos, e diferentes em contextos diferentes. 7. Significado dos cdigos e denominaes relacionam-se com a adequao entre o objeto, a informao apresentada ou pedida e sua referncia. Os cdigos e denominaes significativos possuem uma forte relao semntica com seu referente. Termos pouco expressivos para o usurio podem ocasionar problemas de conduo, levando-o a selecionar uma opo errada. 8. Compatibilidade esse critrio refere-se a concordncia entre as caractersticas do usurio (memria, percepo, hbitos, competncias, idade, expectativas),as caractersticas das tarefas e a organizao das entradas, sadas e o dilogo de uma dada aplicao. Diz respeito tambm ao grau de similaridade entre diferentes ambientes e aplicaes
Quadro 4. Critrios ergonmicos de Bastien & Scapin (Dias, 2003)

Regras do Ouro de Shneiderman 1. Consistncia - sequncias de aes similares para a situao similares, repeties de certo padres. Mesma terminologia em menus e telas de ajuda ao usurio, padres de cores, layout, fontes. 2. Atalhos para usurios mais experientes com a utilizao frequente dos sites e sistemas interativos, os usurios vo se tornando experientes e querem diminuir o nmero de cliques para aumentar a velocidade, eliminando passos desnecessrios. 3. Feedback informativo toda ao do usurio requer uma resposta do sistema, a qual ser mais ou menos detalhada ou informativo. 4. Dilogos com incio, meio e fim sequencias de aes de sistemas devem ser organizadas de tal forma que o usurio seja capaz de identificar quando cada grupo de aes foi completado com sucesso. 5. Preveno de erros o sistema deve ser capaz de recusar os erros humanos. Aes erradas devem fazer o sistema permanecer inalterado. Se o usurio cometer algum erro, o sistema deve oferecer uma forma simples e construtiva de recuperar-se. 6. Reverso de aes tanto quanto possvel, as aes devem ser reversveis, aliviando assim a ansiedade dos usurios e encorajando-os a explorar o sistema. 7. Controle Os usurios mais experientes desejam ter a sensao de que detm o controle sobre o processamento e que os sistemas respondem a suas aes, e no o contrrio. 8. Baixa carga de memorizao a limitao da capacidade de processamento da memria humana deve ser respeitada pelos projetistas de sistemas. As telas do sistema devem ser simples, consistente em relao s outras telas do

15 conjunto e que a frequncia de movimentos em cada tela seja reduzidos.

Quadro 5. Regras de Ouro de Shneiderman ( Dias, 2003)

Princpios abordados na norma ISO 9241-10 1. Adequao tarefa um dilogo adequado para uma tarefa quando auxilia o usurio durante a realizao efetiva da tarefa. 2. Autodescrio um dilogo auto descritivo quando cada passo de dilogo imediatamente compreensvel atravs de feedback do sistema ou explicado aps solicitao do usurio 3. Controle um dilogo controlvel quando o usurio capaz de iniciar a controlar a direo e a velocidade da interao at o ponto em que seu objetivo tenham sido atingido. 4. Conformidade com as expectativas dos usurios um dilogo est de acordo com as expectativas do usurio quando consistente e corresponde s caractersticas do usurio, tais como conhecimento da tarefa, educao e experincia, e convenes geralmente aceitas. 5. Tolerncia a falhas um dilogo tolerante a falhas quando, independentemente dos erros evidentes de entrada de dados, o resultado esperado puder ser atingido com nenhuma ou mnima ao corretiva por parte do usurio. 6. Adequao para personalizao um dilogo capaz de individualizao quando o software de interface pode ser modificado para atender s necessidades, preferncias ou habilidades individuais do usurio. 7. Adequao para o aprendizado um dilogo adequado para o aprendizado quando suporta e guia o usurio em seu aprendizado sobre o sistema.

Quadro 6. Princpios abordados na norma ISO 9241-10 (Dias, 2003)

Com a intensificao do uso dos computadores e com a massificao das informaes em ambiente virtuais, o cuidado com e o como o usurio acessa essa informao de imprescindvel preocupao. Devido a esse fato, vrias reas de pesquisa foram se desenvolvendo junto com o mundo virtual, entre elas a Ergonomia e Usabilidade. Moraes (2003) aponta que o estudo da Ergonomia e Usabilidade passa pelo dilogo humano-mquina, busca econmica de tempo, diminuio da carga cognitiva e rapidez nas decises. A autora afirma que um ergonomista tem que considerar o design informacional, os estilos cognitivos, domnios de conhecimento, estruturao e navegao, orientao/localizao do usurio no ciberespao e a arquitetura da informao. Almeida (2007) resume usabilidade em a preocupao que os desenvolvedores devem ter com o bem estar dos usurios ao desempenharem quaisquer tarefas do produto desenvolvido. Moraes (op cit) ainda explica que:

16 A usabilidade como problema implica o aprendizado de novos mtodos e tcnicas e a nfase na comunicao humana com os sistemas tecnolgicos, a partir da anlise das atividades das tarefas envolvidas nas interaes com o produto, informaes, programas informatizados e com o ambiente. (MORAES, 2003) Diniz (2006) ainda explica que atualmente, faz-se necessrio incorporao do estudo da ergonomia e da usabilidade ainda na fase projetual, para que sejam minimizados os problemas e consequentemente haja uma melhora das interfaces dos sistemas. Muito se fala em usabilidade, porm pesquisadores afirmam que para um sistema conter uma boa usabilidade necessrio que o desenvolvedor conhea o usurio para o qual est projetando. De acordo com Mayhew apud Agner (2009) os desenvolvedores tomam como certas duas proposies erroneamente: primeira, admitir que os usurios so todos iguais e segunda, que todo usurio igual ao prprio desenvolvedor. Agner (op cit) afirma que essas proposies levam a duas concluses: primeiro, que se a interface for fcil de aprender e utilizar pelo desenvolvedor, tambm ser para o usurio, segundo, se a interface for satisfatria para um ou dois usurios sero para todos. Duas afirmaes perigosas e que esto longe da verdade. Os fatores relacionados ao usurio so de naturezas extremamente diversas. Eles incluem tanto diferenas individuais quanto diferenas em estratgias adotadas durante o prprio processo de navegao. O usurio carrega vrios nveis de conhecimento, habilidades, atitudes, caractersticas individuais intrnsecas, que influenciaro na navegao. (PADOVANI e MOURA, 2008) Agner(2009) ainda afirma que a dimenso do conhecimento e da experincia um continuum, existem uma gama enorme de tipos de conhecimento quando falamos de usurios. O autor cita como exemplo destes tipos de conhecimento: o nvel educacional, nvel de leitura, alfabetizao tecnolgica, experincia na tarefa, experincia no sistema, experincia no aplicativo, a linguagem uso de outros sistemas informatizados. Pesquisadores como Bastien, Scapin e Leulier (1998) dizem que usurios experientes e no experientes tm necessidades distintas. Quanto organizao, a interface deve ser projetada para vrios tipos de usurios. Oferecer ao inexperiente um passo a passo, guiando-o atravs de passos progressivos, porm, permitindo aos mais experientes que possam saltar certas partes do hipertexto, para atingir diretamente seu destino. Deve-se descobrir como o usurio alvo do sistema pensa, quer e age, e onde eles querem efetivamente chegar. O conhecimento prvio do usurio possibilita que o desenvolvedor o grau de frustrao que o usurio capaz de aguentar com seu sistema. Se os padres de navegao e usabilidade mudam, ento necessrio que buscar dados e informaes junto as pessoas que esto utilizando o sistema.

17

4. Metodologias geis

O pesquisador Boehm (2003) afirma que desde os anos 2000 estamos em uma tendncia para o desenvolvimento gil de aplicaes de software devido a um ritmo acelerado de mudanas e inovaes na tecnologia da informao e comunicao, em organizaes e no ambiente de negcios. O autor cita que no final dos anos 90 aconteceu o surgimento de vrios mtodos geis (entre eles: Crystal, Dynamic Systems Development, eXtreme Programming (XP) e SCRUM) e todos esses empregavam princpios geis, tais como ciclo iterativos, entrega rpida de software funcionando e simplicidade, como definido no Manifesto para Desenvolvimento gil publicado em 2001. O Manifesto gil tratado como uma filosofia a ser seguida. Exemplos de princpios geis inclui valorizar o seguinte: - Indivduos e interaes sobre processos e ferramentas; - Programar sobre documentar; - Colaborao do cliente sobre negociao de contratos; - Responder a mudanas sobre seguir o plano; A essncia do manifesto a definio de novo enfoque de desenvolvimento de software, apoiada na agilidade, na flexibilidade, nas habilidades de comunicao e na capacidade de oferecer novos produtos e servios de valor ao mercado, em curtos perodos de tempo. (Highsmith, 2004) Quando comparamos metodologias geis com metodologias convencionais, tidas como mais pesadas, percebemos com mais segurana caractersticas essenciais das metodologias geis.

Ambiente de Projeto Categoria Varivel Estilo de Time de Desenvolvimento Comunicao Localizao Tamanho Continuidade na Aprendizagem Cultura de Gesto Participao do Time Planejamento Mecanismos de Feedback

Caractersticas do Projeto gil No-gil Colaborao Somente quando regular necessrio Juntos Distribudos At 50 pessoas Mais de 50 pessoas Estimulado Desencorajado Responsivo Totalmente Desejvel Contnuo Vrios Comando e Controle Indesejvel Comeo No disponvel

Gerenciamento de Projetos

18 Cliente Envolvimento Disponibilidade Processos e Ferramentas Todo o Projeto Facilmente acessvel Apenas o suficiente Pode ser alterado Flexvel Tempo e Material Durante a fase de anlise Difcil acesso

Quantidade Adaptabilidade

Contrato

Requisitos e Datas Custo

Mais do que suficiente No pode ser alterado Fixo Fixo

Quadro 7. Comparao entre metodologias geis e convencionais (adaptado de ULLAH e ZAIDI, 2009)

As metodologias geis mais utilizadas atualmente so: Extreme Programming (XP) A mais conhecida das metodologias geis, o XP uma metodologia para equipes pequenas e mdias e que iro desenvolver software com requisitos vagos e em constante mudana. Para isso, adota a estratgia de constante acompanhamento e realizao de vrios pequenos ajustes durante o desenvolvimento de software. Seus valores fundamentais so a comunicao, simplicidade, feedback e coragem. A metodologia XP prima por seus princpios bsicos, que so: - Feedback rpido; - Presumir simplicidade; - Mudanas incrementais; - Abraar mudanas; - Trabalho de qualidade;

Scrum Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricao de automveis e produtos de consumo. Sua funo primria ser usada para o gerenciamento de projetos de desenvolvimento de software, mas, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessita trabalhar juntas para atingir um objetivo em comum. A caracterstica que diferencia o Scrum das outras metodologias geis a pratica de discusses dirias na qual cada membro da equipe responde s questes: O que fiz ontem?, O que estou planejando fazer at amanh? e Existe algo me impedindo de alcanar minha meta?.

Dynamic System Development Methodology A DSDM foca na interao com o cliente e o usurio final, entrega de prottipos frequentes, equipes de desenvolvimento autnomas, testes massificados durante todo o processo e na definio de prioridades

19 entre a lista de requisitos dada pelo cliente. Possui trs fases: Pr-projeto, Projeto e Ps-Projeto.

Crystal Family Methogology - Existem trs mtodos principais desenvolvidos: Crystal Clear, Crystal Orange e Crystal Orange Web (Crystal Orange acrescido de prticas especficas para web). O Crystal Clear foi desenvolvido para projetos muito pequenos, de at 6 desenvolvedores de curta durao. J o Crystal Orange desenhado para projetos de tamanho mdio, com um total de 10 a 40 desenvolvedores e com durao de 1 a 2 anos. No mtodo Crystal Orange o projeto dividido em muitos grupos com funcionalidades cruzadas.

20 5. Estado da Arte

5.1.

Estado da arte: Engenharia de Requisitos @ Mtodos geis

Manish Kumar, Nirav Ajmeri, Smita Ghaisa. Towards Knowledge Assisted Agile Requirements Evolution. EICS '10 Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing system.

Pesquisadores desenvolveram um quadro chamado K-gileRE que trata de engenharia de requisitos como caso especial de engenharia do conhecimento. Ele integra quatro diferentes contextos do conhecimento (ambiental, requisitos genricos, requisitos geis e de domnio do problema) sob a forma de quatro ontologias, que ajudam em ambientes geis que trabalham de maneira descentralizada, mantendo contato entre os desenvolvedores atravs de ferramentas online. Os pesquisadores afirmam que a necessidade de proporcionar, explcita e perfeitamente integradas, conhecimento de domnio aos requisitos gil evidente. Nenhum mtodo gil, quadro ou a ferramenta atualmente suporta esta importante necessidade. Mtodos e tcnicas para a estrutura de conhecimento e de domnio usados em engenharia de requisitos, existe mas eles no levam muito em conta o contexto gil. Alm disso, eles no incluem os mecanismos de recomendao para alcanar um uso eficaz do conhecimento de domnio. As recomendaes on-line sensvel ao contexto deduzir as bases de conhecimento subjacente na K-gileRE tornar uma "experincia emparelhada", enquanto a definio requisitos, pelo menos parcialmente, substituindo por um especialista do domnio. K-gileRE atinge disseminao de conhecimento essencial para a agilidade facilitando colaboraes semanticamente enriquecidas. Combina benefcios dos aspectos da meritocracia da web semntica e os aspectos democrticos da web 2.0. Todos os mtodos geis insistem na estreita comunicao e colaborao. Usando K-gileRE, as interaes entre os dispersos equipes acontecem informalmente, em consonncia com a cultura gil e doutrinas de confiana e de atendimento s pessoas. A reunio virtual entre equipes geograficamente dispersas podem ser facilmente facilitada.

21 Sandra Kelly. Towards an Evolutionary Framework for Agile Requirements Elicitation. EICS '10 Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing systems.

Devido aos inmeros problemas relatados com problemas de desenvolvimento de requisitos, entre eles: desenvolvedores tem limitado acesso aos interessados, no compreendem inteiramente o problema de domnio e requisitos no so bem entendido. Mesmo com o uso de Mtodos geis, onde o stakeholder encorajado a participar ativamente do desenvolvimento a negociao dos requisitos consideravelmente problemtica. Este artigo apresenta progressos realizados para desenvolver um quadro evolutivo para melhorar e facilitar o levantamento de requisitos em ambientes gil. A questo que o artigo se propicia a responder : Como pode um quadro evolutivo ser desenvolvido para melhorar e facilitar a elicitao de requisitos geis?. Para responder esta questo foram trilhados os seguintes passos: investigar fatores que afetam a comunicao entre os desenvolvedores e stakeholder, investigar abordagens de desenvolvimentos gil com especial relevncia ao papel do cliente, desenvolver uma soluo adequada e avalizar a soluo em ambiente adequado. Uma possvel soluo oferecida pela Open Space Technology, que faz uma ligao com histrias dos usurios atravs de cenrios. OST uma abordagem evolutiva, recomendado para situaes complexas envolvendo diversas participantes, uma complexidade de elementos, a paixo (incluindo conflitos) e necessidade de uma deciso rpida. Fundada em 1985, a OST tem um histrico comprovado de permitir diversas participantes que tm um interesse genuno em resolver alguns questo da importncia de envolver e obter uma soluo em um incrivelmente produtivo, mas simples maneira. Como simples ferramentas, tais como cartazes, canetas e papel so utilizados, h virtualmente nenhuma curva de aprendizagem envolvida e o sucesso tem sido relatado onde grupos de 5 a 2000 pessoas participaram. Um estudo inicial, embora limitado, tem proporcionado um feedback positivo, indicando que a abordagem ligada til para explorar e a clarificao das obrigaes antes de escrever histrias de usurios e que Isto pode ser conseguido de forma gil.

Zornitza Racheva, Maya Daneva, Adrea Herrmann. A Conceptual Model of Clientdriven Agile Requirements Prioritization: Results of a Case Study. ESEM '10 Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement.

22 Modelos conceituais sobre o processo de definio e prioridades de requisitos em ambientes geis so escassos. O que torna difcil para profissionais e pesquisadores a tomada de deciso em uma interao gil. O artigo um estudo de caso mltiplo sobre os mtodos de priorizao de requisitos em ambientes de desenvolvimento gil para produzir um modelo conceitual para a compreenso do processo de priorizao de inter-iterao. O estudo de caso foi realizado nas seguintes etapas: (1) Compor um questionrio, (2) validar o questionrio atravs um investigador experiente, mudanas (3) Aplicar na questionrio baseado no feedback; (4) Faa uma entrevista-piloto para verificar a aplicabilidade do questionrio para o contexto da vida real; (5) Realizao de entrevistas semiestruturadas com profissionais de acordo com o questionrio concludo; (6) da amostra e acompanhamento com os participantes que possuem um conhecimento mais profundo ou uma perspectiva especfica. As vrias iteraes de codificao, a constante comparao das informaes provenientes das entrevistas, e modelagem conceitual do Processo GT produziu o modelo apresentado na Figura XX. Sua finalidade explicar e trazer ideias para a tomada de deciso, que o ncleo do processo de RP. O modelo assume a perspectiva de o cliente, ao contrrio de outros autores de RP, que adotam a perspectiva dos desenvolvedores. Este modelo para ajudar os clientes a mergulharem' no processo de priorizao e ver esses conceitos que so importantes a considerar em RP em tempo de interao, incluindo o contexto. Ele descreve o que acontece em todos os processos do RP sobre os quais temos aprendido com os participantes, no estudo de caso. No modelo quer ter uma viso genrica de RP, ou seja, resumos sobre a utilizao de uma abordagem especfica RP.

Figura 4. Modelo Conceitual de RP

Os resultados do estudo de caso sugerem que h um consenso entre os praticantes que existem cinco aspectos que os clientes consideram na tomada de decises sobre as prioridades requisitos:

23 Valor do negcio, Estimativa de esforo / medio do tamanho, Experincia de aprendizagem, Entrada de desenvolvedores e Mudana externa.

5.2.

Estado da Arte: Engenharia de Requisitos @ Usabilidade

Jaspaljeet Singh, Christof Lutteroth, Burkhard C. Wnsche. Taxonomy of Usability Requirements for Home Telehealth Systems. CHINZ '10 Proceedings of the 11th International Conference of the NZ Chapter of the ACM Special Interest Group on Human-Computer Interaction.

Devido o aumento das aplicaes de tele-sade a preocupao com a interface e usabilidade vem aumentando. Em razo desse fato, o artigo apresenta uma taxonomia de requisitos de usabilidade e conceitos de projetos de tele-sade que permitem um desenvolvimento centrado no usurio. Devido ao pblico que os sistemas de tele-sade atende, foi encontrado, junto aos interessados, um grande nmero de requisitos de sistemas com o qual o desenvolvedor tem que se preocupar, sendo a maioria relacionado a questo da interao homem mquina. Os requisitos foram: - Funcionalidade: Suporte a mltiplas linguagens, lembretes, reduo da ansiedade computacional, customizao; - Compreensibilidade: Modelos mentais e guias de instrues; - Interface: Legibilidade, Mais imagens que palavras, uso de cores apropriadas, Transies com telas limpas; - Servios de suporte operacional: suporte tcnico adequado; - Reduo de complexidade: Fcil entrada de dados, tarefas simples; - Feedback: Feedback do estado de sade, Representao grfica do estado de sade, - Requisitos no funcionais: Confiana no sistema, segurana e confiabilidade.

Os problemas enfrentados pelos usurios foram sistematicamente categorizados em limitaes individuais, as limitaes do sistema e variveis ambientais. Soluo para cada conjunto de problemas foi sugeridos. Os resultados permitem o leitor a melhorar os atuais sistemas, para us-los de forma mais eficaz, e para desenvolver novos mais eficazes e eficientes sistemas de tele-sade.

24

Clia Martinie, Philippe Palanque, Marco Winckler, Stphane Conversy. DREAMER: a Design Rationale Environment for Argumentation, Modeling and Engineering Requirements. SIGDOC '10 Proceedings of the 28th ACM International Conference on Design of Communication.

Este trabalho prope uma ferramenta de notao apoiado para a resoluo de problemas de rastreabilidade e de cobertura dos requisitos que tm de ser cumpridos pelo sistema na sua concepo e opes de projeto durante o processo de desenvolvimento dos sistemas interativos. Estes elementos so adicionalmente integrados dentro de uma ou mais abordagens globais destinadas a fornecer notaes e ferramentas para apoiar um projeto de racionalizao de sistemas interativos na sequncia de uma abordagem baseada em modelos. A contribuio atual, DREAMER, torna possvel relacionar opes de design com ambos os requisitos funcionais e no funcionais. A notao TEAM (Traceability, Exploration and Analysis Method) e a ferramenta case DREAM (Design Ratinale Enviroment for Argumentation and Modeling) foram originalmente propostos para apoiar a explorao sistemtica de opes durante o processo de desenvolvimento de sistemas de segurana crtica. A notao time uma extenso do QOC (Question Option Criteria) que permite a estruturao e a gravao de informao produzida durante as reunies do projeto. Diagramas TEAM compreendem: As questes que foram levantadas; As opes de design que tm sido investigados e os que foram selecionados; A avaliao realizada para as diferentes opes; A coleta dos critrios que foram utilizados para avaliar as opes consideradas; O conjunto de fatores que tm sido tomadas em conta e como se relacionam com os critrios; Os modelos de tarefas correspondentes s opes; Os cenrios extrados dos modelos de tarefas que so usados para computar, para cada opo o valor dos critrios.

Na sua verso original, a notao TEAM no tem uma representao dos requisitos. A necessidade de incluir requisitos em diagramas de desenho racional surgiu em processos de design real, enquanto a tenta determinar se as opes selecionadas em diagramas TEAM atender aos requisitos funcionais e no funcionais. Na verdade, a falta de relao entre o design e os requisitos impede designers de explorar requisitos para a gerao de opes e / ou tomar em considerao requisitos na concepo de uma opo. Embora a

25 integrao dos requisitos represente uma pequena extenso para a notao TEAM, ela tem um enorme impacto sobre o processo de tomada de deciso baseado em diagramas TEAM. Na verdade, tudo o que qualidade, no que diz respeito a critrios e fatores, uma opo de projeto pode ser escolhida apenas pelo seu mrito no que diz respeito cobertura de um determinado requisito essencial. A ferramenta case DREAM, um ambiente de software de suporte, armazenamento, edio e anlise de diagramas TEAM. A ferramenta publicamente disponvel na Internet e de forma gratuita. Poucas horas de treinamento so necessrias para usurios comeando a construir seus prprios diagramas. Ambos, a notao e a ferramenta, podem ser utilizados proveitosamente com outras aspectos do design de sistemas interativos e outras fases do processo de desenvolvimento.

Figura 5. Exemplo de diagrama TEAM confeccionado pela ferramenta DREAM.

Juho Heiskari, Marjo Kauppinen, Mikael Runonen, Tomi Mnnist. Bridging the Gap Between Usability and Requirements Engineering. 2009 17th IEEE International Requirements Engineering Conference.

26 Na prtica, difcil de gerir e controlar design centrado no usurio e processos desenvolvimento de sistemas separadamente. Baseado em um estudo de caso realizado em duas empresas de produtos de software, o estudo tem como alvo compreender o papel de especialistas em usabilidade na engenharia de requisitos (ER). Os resultados indicam que a usabilidade ainda frequentemente visto como design de interface do usurio ao invs de uma caracterstica mais abrangente de um produto de software. Por isso, especialistas em usabilidade tiveram dificuldades em participar de atividades iniciais RE. Para integrar a usabilidade como uma parte natural do processo de RE, as equipes de usabilidade comearam a organizar aes de formao nas suas empresas. Os dados foram recolhidos atravs de seis entrevistas semiestruturadas, 3 grupos de discusso e uma discusso informal nas duas empresas pesquisadas. Todas as entrevistas e discusses foram gravadas. Durante a pesquisa foram abordadas as seguintes atividades: Estudo do usurio, Design de interface do usurio, Reviews de requisitos, Testes de usabilidade, Orientaes para a interface do usurio e Treino da usabilidade. Em cada um destas atividades foram observados descobertas, benefcios e desafios. A partir da anlise das tarefas nas empresas estudadas, os pesquisadores formularam seis lies aprendidas durante a anlise: - A usabilidade mais do que apenas o design da interface do usurio; - Especialistas em usabilidade tm um papel participativo e solidrio; - Tarefas operacionais so difceis de escalar; - A engenharia da usabilidade tem um papel de apoio e equilbrio no processo de desenvolvimento; - Problemas de usabilidade so difceis de reconhecer em reviews de requisitos; - um desafio integrar usabilidade em processos de RE.

Figura 6. Tarefas descobertas pelos especialistas em usabilidade mapeada em atividades de RE.

27 Atravs da pesquisa foi descoberto vrios desafios que impedem a participao de especialistas em usabilidade no processo de engenharia de requisitos. Talvez o mais significativo deles o entendimento enganoso de usabilidade como um simples projeto de interface do usurio. Por conseguinte, como design de interface de usurio considerada a principal tarefa de especialistas em usabilidade, no so ativamente tomada em incio de atividades de engenharia de requisitos. No entanto, especialistas em usabilidade esto dispostos a realizar estudos de usurios com mais frequncia para aumentar a compreenso do usurio e do domnio. Os especialistas em usabilidade percebem que a aquisio desta compreenso foi fundamental para definir os requisitos de usabilidade e as caractersticas de um produto, incluindo uma interface de usurio eficiente e eficaz.

5.3.

Estado da Arte: Usabilidade @ Mtodos geis

Michael Budwing, Soojin Jeong, Kuldeep Kelkar . When User Experience Met Agile: A Case Study. CHI 2009. Experience with Software & System Development and Evaluation April 4-9, 2009 ~ Boston, MA, USA.

A comunidade de desenvolvedores de softwares fala muito sobre o desenvolvimento de programas atravs de metodologias gil, mas a maioria da discusso voltada para desenvolvedores de software. Muito menos se tem dito sobre a forma de integrar usurios de mtodos e prticas dentro de uma experincia gil, ambiente de desenvolvimento e muitos pesquisadores, designers e profissionais de UX tm encontrado dificuldades para se adaptar rapidamente ferramentas UX e prticas de processos geis. Neste artigo, apresentado experincias, exemplos especficos e recomendaes de melhores prticas para integrar as equipes UX nos processos de desenvolvimento gil. A organizao em que foi realizado o estudo est dividida em vrias unidades de negcios (UN). Os autores fazem parte de uma experincia do usurio e organizao do projeto (UED) que suporta todas essas unidades de negcio. A organizao UED tem uma equipe de mais de 100 designers, escritores e pesquisadores, e responsvel por fornecer uma experincia de usurio de classe mundial aos clientes. Inicialmente, foram atribudos oito membros da equipe de experincia do usurio a esses projetos Scrum. Esta foi a primeira experincia da equipe UX real atravs de uma metodologia gil. As mudanas que fizemos para um apoio mais eficaz para o UX Scrum e desenvolvimento de produtos gil so:

28

Quadro 8. Workflow, regras e responsabilidades dos times de UX trabalhando em metodologia gil.

- Agendar as equipes UX para trabalhar um ou dois sprints frente das equipes de desenvolvimento; - incorporar a viso de design sprints trimestrais no ciclo sprint normal; - Organizar a equipe de UX em um time scrum separada, com sua carteira de produtos prprios e proprietrio do produto.

Figura 7. Colaborao entre PO UX, PO, Unidade de negcio e Gerente de projeto.

29

- Trabalha uma a duas sprints a frente das equipes de desenvolvimento Scrum resultou em menor rotatividade e o balano no trabalho melhorou para os membros da equipe UX. - Ter uma viso sprint design trimestrais resultou em vises mais coesas e mais projetos de qualidade. - Um proprietrio do produto UX fornece o primeiro ponto de contato para equipes de cross-funcional e ajuda a coordenar as equipas UX e os resultados. - A product backlog UX separados ajuda a equipe de UX a alocar melhor recursos para projetos e capacidade de equipe. - Uma equipe UX nica pode suportar vrias equipes de desenvolvimento com a rotatividade e melhor coordenao.

Brian David Fox. Agile Methods and User-Centered Design: How These Two Methodologies are Being Integrated in Industry. Thesis Submitted To The Faculty Of Graduate Studies In Partial Fullfillment Of The Requirements For The Degree Of Master Of Science. University Of Calgary, Alberta, Canad. 2010.

Em um primeiro olhar, mtodos geis e ID tm abordagens opostas em termos do trabalho que est sendo feito antes que o desenvolvimento comece. Mtodos geis de projeto de software, eliminam uma grande quantidade de recursos alocados no incio do projeto. Por exemplo, um dos processos gil mais utilizados eXtreme Programming proposta por Kent Beck e Martin Fowler, a abordagem utilizada com XP um iteraes ofshort com conjuntos menores de recursos e, portanto, menos exigncias coletadas antes do incio da implementao.

Abordagens de design, comeam com uma perspectiva de como o software utilizado, passando uma quantidade considervel de tempo pesquisando os usurios, suas necessidades, as tarefas que precisam realizar e, em seguida iterativamente, testando um design de interface. Em seu livro, Alan Cooper sugere que uma boa quantidade de pesquisas iniciais devem ser feita antes de qualquer aplicao ser concebida como uma abordagem para identificao de erro. Sua abordagem tratar o comportamentos e idiossincrasias do usurio, antes do desenvolvimento comear. Apesar de identificao e de abordagens geis so muito diferentes, ambas as metodologias tm o mesmo objetivo em mente, e que o objetivo construir um software melhor. Como resultado disto, houve um aumento no interesse dirigidas como os mtodos geis e ID tanto pode ser empregado em um mesmo projeto para produzir uma metodologia hbrida.

30 O objetivo desta pesquisa determinar como, bem como, quando, metodologias geis esto incorporando ID no mesmo processo de desenvolvimento de software. A fim de explorar como e quando as equipes podem combinar elementos da UCD e mtodos geis de um modo que fornece os benefcios de ambas as abordagens. As seguintes questes de investigao so abordadas na pesquisa: - Como estas duas metodologias podem ser combinadas, uma vez que eles tm muito diferentes tcnicas de alocao de recursos em incios de projeto? - Quais so as funes dos membros da equipe que esto diretamente envolvidos no processo de combinar essas duas metodologias? - Que estratgias diferentes esto sendo usados para incorporar um processo de identificao e mtodos geis para o projeto de software? - Qual o efeito que a integrao dessas duas metodologias tem em suas abordagens originais ou processos?

Muito das respostas encontradas se assemelham a mtodos de combinao propostos por Sy (2002) e Jeff Patton (2002). Sy prope uma Sprint Zero, ou uma interao Zero, em que os especialistas em UCD fazem todas as pesquisas necessrias antes do incio do projeto, e durante o processo de desenvolvimento sprints de UCD e de desenvolvimento correm em paralelo. J Jeff Patton aconselha os membros de equipe UCD a fazer parte dos times de desenvolvimento usando seus conhecimentos junto com os desenvolvedores, alm de j trabalharem em como ir ser a interao seguinte. Ambos os mtodos de combinao das metodologias sobrecarregam o time de UCD, e esse problema j foi identificado em pesquisas posteriores, porm no houve um aprofundamento na questo.

31 6. Concluso

As trs metodologias estudadas esto entre as mais utilizadas quando falamos em desenvolvimento de software. Engenharia de Requisitos no um campo de estudos novo, h anos estudiosos vem pesquisando suas nuances e como ela deve ser aplicada em vrios projetos, no s em softwares. Usabilidade uma preocupao de dcadas, desde quando os pesquisadores perceberam que o alvo de qualquer software seu usurio final e este deve ser respeitado. As metodologias gil so relativamente recentes, elas vm se tornando popular na ltima dcada, por isso ela a principal alvo de estudos com os mais diversos pontos de vista. Como visto nos trabalhos acima relacionados, existe uma preocupao em mesclar metodologias. Estudos sobre Engenharia de Requisitos em Ambientes geis so comuns, e o nmero de trabalhos sobre este campo de pesquisa est sempre aumentando em congresso e revistas especializadas neste campo. Na mesma via de aumento de trabalhos publicados esto pesquisas que visam a trabalho conjunto entre Mtodos geis e Usabilidade, atravs de seus especialistas que trabalham com o Agile UX. E sempre existiu a cautela, por parte dos engenheiros de requisitos, com a usabilidade, requisito no funcional dos mais crticos, que, como foi mostrado, pode ser a diferena entre um software de sucesso e um software sem usurios. Contudo, no foi encontra publicaes ou pesquisas que tratam de como Engenheiros de Requisitos e especialistas em UCD em conjunto, podem trabalhar no desenvolvimento em ambientes geis. Apesar de ter sido observado necessidades, tal que comum encontrar publicaes que pesquisam uma mescla de dois dos trs mtodos.

32 7. Referncias

AGNER, L. (2009) Ergodesign e Arquitetura da Informao: Trabalhando com o usurio. Editora Quartet, 2 Edio. Rio de Janeiro, RJ. ALMEIDA, P. (2007) Otimizao De Websites E Mecanismos De Busca Na Internet: Uma Contribuio Da Ergonomia. Dissertao para obteno do titulo em Mestre em Design PUC-RJ. Rio de Janeiro RJ. BASTIEN, C. SCAPIN, D. (1993) Ergonomic criteria for the evaluation of humancomputer interfaces. Tech. Rep. N.156. Rocquencourt, France: Institut National de Recherche en Informatique et en Automatique. BASTIEN, J.M.C., LEULIER, C., SCAPIN, D.L. (1998) Lergonomie des sites web. In Crer et maintenir un service Web, J.-C. Le Moal & B. Hidoine (eds.), ADBS Edition, 111-173. BOEHM, B. AND TURNER, R., (2003) Balancing Agility and Discipline: A Guide for the Perplexed, AddisonWesley. BRIAN DAVID FOX. (2010) Agile Methods and User-Centered Design: How These Two Methodologies are Being Integrated in Industry. Thesis Submitted To The Faculty Of Graduate Studies In Partial Fullfillment Of The Requirements For The Degree Of Master Of Science. University Of Calgary, Alberta, Canad. BUDWING, M. JEONG, S. KELKAR, K. (2009) When User Experience Met Agile: A Case Study. CHI 2009. Experience with Software & System Development and Evaluation April 4-9, 2009 ~ Boston, MA, USA. COLANZI, T. E. (2010) Engenharia de Requisitos. Departamento de Informtica. Universidade Estadual de Maring. DINIZ, S. (2006) Modelo conceitual de desenvolvimento de sistemas informacional para e-commerce brasileiros. Dissertao para obteno do titulo em Mestre Em Design pela Universidade Federal de Pernambuco UFPE. Recife, PE. FARKAS, D. & FARKAS, J. (2002) Principles of Webdesign. New York: Longman. HEISKARI, J. KAUPPINEN, M. RUNONEN, M. MNNIST, T. (2009) Bridging the Gap Between Usability and Requirements Engineering. 2009 17th IEEE International Requirements Engineering Conference. HIGHSMITH, J.; COCKBURN, A. (2001) Agile Software Development: The Business of Innovation. IEEE Computer, November, p.120-122 ISO 9241 (1997): Ergonomics Requirements for Office Work with Visual Display Terminals (VDTs), International Standards Organization, Geneva.

33 KELLY, S. (2010) Towards an Evolutionary Framework for Agile Requirements Elicitation. EICS '10 Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing systems. LEITE, A. SANTA CRUZ, S. (2009) Requisitos No Funcionais De Usabilidade E Interao Humano Computador. Ps Graduao Em Cincia Da Computao. Centro De Informtica. Universidade Federal De Pernambuco. MAIRIZA, D. ZOWGHI, D. NURMULIANI, N. (2010) An investigation into the notion of non-functional requirements. SAC '10 Proceedings of the 2010 ACM Symposium on Applied Computing. Manifesto for Agile Software Development. (2010) Disponvel em http://www.agilemanifesto.org/. MANISH, K. NIRAV, A. SMITA, G. (2010) Towards Knowledge Assisted Agile Requirements Evolution. EICS '10 Proceedings of the 2nd ACM SIGCHI symposium on Engineering interactive computing system. MARTINIE, C. PALANQUE, P. WINCKLER, M. CONVERSY, S. (2010) DREAMER: a Design Rationale Environment for Argumentation, Modeling and Engineering Requirements. SIGDOC '10 Proceedings of the 28th ACM International Conference on Design of Communication. MORAES, A ., AGNER, L. C. (2003) Navegao e arquitetura de informao na web: a perspectiva do usurio. Boletim tcnico do SENAC, v 29, p. 52 60. Jan. NIELSEN, J. (1995) Navigating Large Information Spaces. In: NILSEN, J. (ed). Multimedia and Hypertext: The Internet and Beyond, Morgan Kaufmann Publishers. PADOVANI, S. MOURA, D. (2008) Navegao em Hipermdia: Uma abordagem centrada no usurio. Rio de Janeiro: Cincia Moderna. PRESSMAN, R. S. (2004) Software Engineering: a practioners approach. 6 ed. Nova York: McGraw-Hill. RACHEVA, Z. DANEVA, M. HERRMANN, A. (2010) A Conceptual Model of Clientdriven Agile Requirements Prioritization: Results of a Case Study. ESEM '10 Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement. RIBEIRO, D. (2007) Personalizao e colaborao na WEB 2.0: novos caminhos para a arquitetura da informao. 2007 Disponvel em http://danielmelo.net/wpcontent/uploads/2007/10/artigo_ebai07.pdf ROSENFELD, Louis; MORVILLE, Peter. (2002) Organization Systems. Information Architecture: for the World Wide Web. USA: Sebastopol. SCHNAIDER, S. (2006) Web + Design = Quebra-Cabea de pixels? Dissertao (Mestrado em Desenho Industrial). Faculdade de Arquitetura, Artes e Comunicao. Universidade Estadual de So Paulo - Campus Bauru. Bauru, SP.

34 SINGH, J. LUTTEROTH, C. WNSCHE, B.C. (2010) Taxonomy of Usability Requirements for Home Telehealth Systems. CHINZ '10 Proceedings of the 11th International Conference of the NZ Chapter of the ACM Special Interest Group on Human-Computer Interaction. SOARES, M. S. (2004) Metodologias geis Extreme Programming e Scrum para o Desenvolvimento de Software. RESI. Revista Eletrnica de Sistemas de Informao, v. 3, p. 1-8, 2004. SOMMERVILLE, I. (2001) Software Engineering. 6 ed. Addison Wesley. SOMMERVILLE, Ian. (2004) Engenharia de software. 6 ed. Pearson. SOMMERVILLE, Ian. (2007) Engenharia de Software, 8 ed. So Paulo: Pearson Addison-Wesley. ULLAH, M., ZAIDI, W. (2009) "Quality Assurance Activities in Agile - Philosophy to Practice". Master Thesis Computer Science, School of Computing Blekinge Institute of Technology Soft Center, Sweden. September. ZILSE, R. (2004) Anlise ergonmica do trabalho dos desenvolvedores versus o modelo dos usurios, tendo como foco a arquitetura da informao em web sites. Dissertao (Mestrado em Design). Rio de Janeiro. PUC-RIO.