• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Como especificar requisitos em metodologias ágeis?
 

Como especificar requisitos em metodologias ágeis?

on

  • 1,368 views

Apesar deste artigo ter sido produzido descrevendo técnicas de metodologias ágeis, há tópicos que agregam valor e esclarecem dúvidas na descrição de requisitos independente do processo (ágil ...

Apesar deste artigo ter sido produzido descrevendo técnicas de metodologias ágeis, há tópicos que agregam valor e esclarecem dúvidas na descrição de requisitos independente do processo (ágil ou cascata).

Statistics

Views

Total Views
1,368
Views on SlideShare
1,368
Embed Views
0

Actions

Likes
1
Downloads
29
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

    Como especificar requisitos em metodologias ágeis? Como especificar requisitos em metodologias ágeis? Document Transcript

    • COMO ESPECIFICAR REQUISITOS PARA DESENVOLVIMENTO DE SOFTWARE EM METODOLOGIAS ÁGEIS? Priscilla Gualiberto Aguiar 1 Orientador: Gilmar Luiz de Borba 2 Resumo Os Profissionais de TI muitas vezes buscam por novas competências e qualificações para atender as metodologias e modelos de desenvolvimento de software. Elaborar um requisito que reflita a necessidade de um cliente e ao mesmo tempo seja claro para os desenvolvedores é o objetivo de grande parte dos analistas de requisitos. Porém entender, descrever e gerenciar requisitos em um projeto não é uma tarefa fácil para os analistas e isso afeta diretamente a qualidade na entrega de um software. O manifesto ágil valoriza software funcionando que agregue valor ao cliente, mas isso requer a um mínimo de documentação para o desenvolvimento do software. O objetivo desse artigo é apresentar como os requisitos são especificados em processos de metodologias ágeis. Serão descritos nesse artigo, tópicos como técnicas de elaboração, boas práticas para elaboração e características de um requisito de qualidade. Palavras-chave:Metodologias Ágeis. Especificação de Requisitos. Engenharia de Software.Boas Práticas. 1. Introdução Muitas empresas têm adotado métodos ágeis que propõem, segundo o Manifesto Ágil (2001), “[...] satisfazer o cliente, através da entrega adiantada e contínua de software de valor.”. O desenvolvimento de software é baseado nos requisitos especificados e priorizados no início de um projeto. Normalmente os requisitos expressam as necessidades dos usuários, ou ainda, as funcionalidades do sistema, assim esclarece Dennis et al (2009) e Sommerville (2007): 1 Aluna concluinte do curso de Pós-Graduação em Engenharia de Software Centrada em Metodologias Ágeis, Centro Universitário UNA. E-mail:pricaguiar@gmail.com 2 Mestre em Gestão Social, Educação e Desenvolvimento Local pelo Centro Universitário UNA,especialista (nível Lato Sensu): Educação Tecnológica (CEFET-MG); Engenharia de Software (PUC-MG); Análise de Sistemas (UFMG) e Engenharia de Segurança do trabalho (FUMEC). Professor do Centro Universitário UNA, Belo Horizonte - MG.
    • Os requisitos são as informações do que o sistema fará, ou a funcionalidade que irá conter. Eles precisam ser explicados em um alto nível, para que seja aprovado, e finalmente, a equipe do projeto entenda quais são as expectativas de negócio do produto final. (DENNIS, WIXOM e TEGARDEN 2009, p.43, tradução minha) [...]as definições de requisitos de sistema especificam o que o sistema deve fazer (suas funções) e suas propriedades essenciais e desejáveis. [...]Esses requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema. (SOMMERVILLE 2007,p.18 ;p.79) Estas necessidades e funcionalidades são inseridas em um documento próprio, denominado Documento de Requisitos. MORAIS (2011, p.11) explica que “documentos de requisitos têm como objetivo registrar o que os usuários esperam da aplicação independente da solução técnica. Isso faz com que esses documentos sejam simples e rápidos de serem elaborados.” AMBLER (2004-2007) revela que quando começou a trabalhar com modelagem ágil rapidamente descobriu que deveria considerar a efetividade na criação e manutenção de documentos. DENNIS, WIXOM e TEGARDEN (2009) e MORAES (2009) descrevem sobre a relevância dos requisitos em um ciclo de vida de desenvolvimento e das possíveis consequências vindas de requisitos mal definidos. Em muitos aspectos, a etapa de definição dos requisitos é a única etapa mais crítica de todo ciclo de vida de desenvolvimento de software porque é aqui que os principais elementos do sistema começam a surgir. Durante a definição dos requisitos, o sistema é fácil de mudar porque ainda foi feito pouco trabalho. Como o sistema muda através das outras fases no ciclo de vida de desenvolvimento de software, torna-se mais e mais difícil para retornar à definição dos requisitos e fazer grandes mudanças, porque envolve o retrabalho. Vários estudos têm mostrado que mais da metade de todas as falhas do sistema são devido a problemas com os requisitos. (DENNIS, WIXOM e TEGARDEN 2009, p. 111, tradução minha) Segundo MORAES (2009, p.55), o levantamento de requisitos inadequados pode impossibilitar o rastreamento das causas de problemas, custos maiores que o planejado, prazos acima do estimado e processos fundamentais ao cliente omissos. Visto o fator criticidade, vimos que os requisitos estão relacionados diretamente à qualidade do software: “A qualidade de um software pode ser definida como a conformidade aos requisitos.” (KOSCIANSKI,1992 apud CROSBY, 2007, p.12)
    • O CHAOS report apresentado em 2010 mostrou que 13 por cento das falhas de projetos são devidos a requisitos incompletos e representa a maior causa entre os fracassos. Considerando isso, LEFFINGWELL (2011, p.xxiii) cita que até desenvolvedores experientes sabem que o gerenciamento de requisitos é um desafio maior do que o desenvolvimento. Perante este desafio, como os requisitos devem ser especificados para desenvolvimento de software em metodologias ágeis? Serão analisadas neste artigo os métodos, técnicas e modelos para especificação de requisitos em processo ágeis, e as características que definem a qualidade de um requisito. Como material de pesquisa bibliográfica foram explorados livros e artigos já publicados a respeito de metodologias ágeis e engenharia de requisitos. Para análise da qualidade de software foi consultada a norma IEEE 29148. As informações foram coletadas e avaliadas a fim de responder o problema levantado neste artigo. 2. Manifesto Ágil Em 2001, os criadores de muitas metodologias de desenvolvimento de software ágil reuniram-se com outros que também estavam implementando métodos ágeis e criaram o Manifesto Ágil (LEFFINGWELL 2011, p.12), com o objetivo de identificar os valores que concedem maior benefício para o processo de desenvolvimento de software. (SMITH 2009, p.117) Agile Manifesto (2001) descreve os seguintes valores para o Desenvolvimento de Software Ágil: Indivíduos e interações maisque processos e ferramentas Software em funcionamento maisque documentação abrangente Colaboração com o cliente maisque negociação de contratos Responder a mudanças mais que seguir um plano.
    • Quando as pessoas lêem os valores do manifesto, geralmente tem a percepção equivocada que os itens à direita (processos, ferramentas, documentação, contratos e planejamento) não fazem parte do desenvolvimento ágil. Porém o manifesto está dizendo que os itens à direita adicionam valor ao processo de desenvolvimento e os à esquerda fornecem mais valor ao processo. (SMITH 2009, p.6) 3. Como os requisitos são descritos em metodologias ágeis? AMBLER(2004-2007) descreve os seguintes conselhos aos Analistas de Requisitos em projetos de desenvolvimento de software em um ambiente ágil: 1. No início do projeto, compreenda o escopo e gere requisitos de alto nível. Nesse momento os detalhes não são importantes. Esse levantamento inicial não deve chegar a durar semanas, apenas dias. 2. Idealmente, os detalhes são modelados e/ou analisados durante o tempo (just-in-time), através sessões envolvendo poucas pessoas para esclarecer as questões necessárias para o desenvolvimento. 3. Reconheça que a análise dos requisitos é realizada durante todo o projeto e não há mais a “fase de análise”. 4. O requisito pode mudar a qualquer momento, o que é normal e aceitável. É necessário gerenciá-los conforme suas prioridades. 5. Adote modelagens para que os stakeholders3 estejam aptos a entender, incluindo as modelagens mais técnicas. 6. Analistas de requisitos efetivos sabem aplicar várias técnicas de modelagem em sistemas complexos. 7. O objetivo é entender os requisitos e não gerar documentos de requisitos, mas caso o documento seja escrito mantenha-o atualizado e útil para os envolvidos, tendo uma única fonte de informação. 8. Reconheça que há vários modelos a sua disposição. 9. Modele com os desenvolvedores, para que eles entendam os requisitos e você entenda o que eles estão tentando construir. 3 Stakeholder, de acordo com SMITH (2009); LEFFINGWELL (2011), é todo indivíduo que tem interesse ou influência no projeto. Como por exemplo: usuários que usam o sistema; são impactados pelo desenvolvimento ou operação do sistema; será envolvido na compra, operação, gerenciamento, etc.
    • 10. Os melhores analistas de requisitos são os especialistas generalizados que possuem mais de uma especialidade além da de levantar requisitos. SOMMERVILLE (2007, p. 273) explica que no desenvolvimento iterativo não há especificação detalhada e o documento de requisitos descreve as características mais importantes do sistema. De acordo com SMITH (2009, p.38) uma descrição para requisitos ágil poderia ser apenas o suficiente. “Dê-me apenas os requisitos suficientes para começar um projeto”. SMITH (2009, p.80) descreve que em um processo tradicional de desenvolvimento, você identifica e descreve todos os requisitos. Em um processo ágil, você descreve apenas o suficiente, o suficiente para determinar o que será construído, para posteriormente construir apenas o suficiente para demonstrar os requisitos implementados ao usuário para que ele verifique se o software está no caminho certo. De acordo com a experiência de AMBLER (2004-2007), uma forma de iniciar a modelagem de requisitos e descrever apenas o suficiente é o modelo de uso, como casos de uso e história de usuários. LEFFINGWELL (2011, p. 367) afirma que User Stories tornou-se a forma predominante de se capturar e expressar requisitos, porém, como os métodos ágeis começaram a serem aplicados em sistemas maiores, as user stories se tornaram insuficientes para fazer a análise necessária de sistemas complexos. Para LEFFINGWELL (2011, p. 368) no caso de sistemas complexos, a indicação para capturar e expressar os requisitos são os use cases, que nos ajudam a explorar interações entre usuário, sistemas e sub-sistemas, e a identificar cenários alternativos que são os cenários que normal afetam de forma negativa o nível de qualidade do sistema.
    • SMITH (2009, p.156) cita que independente da metodologia usada para o desenvolvimento, nenhuma dita à documentação necessária para cada recurso: a equipe faz. 3.1. User Stories User story ou história de usuário foi originalmente desenvolvimento na metodologia eXtreme Programming(XP), mas agora está presente em outras implementações ágeis, como o Scrum4. (LEFFINGWELL 2011, p.37) História de usuário é uma substituição ágil dos documentos de requisitos, como o caso de uso, por exemplo, elas possuem breves descrições de algo que o sistema precisa fazer para o usuário. (LEFFINGWELL 2011, p.57) As histórias de usuário são ferramentas para definir o comportamento de um sistema de um jeito que seja compreensível para o desenvolvedor e os usuários e suas descrições focam no valor definido por ele, fornecendo uma abordagem leve e eficaz para o gerenciamento dos requisitos.(LEFFINGWELL 2011, p.100) SMITH (2009, p.161) acredita que as histórias de usuário podem ser definidas como “descrições exatas”, que ajudam a equipe do projeto a interagir com o cliente e entender melhor suas necessidades, além de reunir informações o suficiente para entender o escopo do sistema. Detalhes do comportamento do sistema não são descritos e são discutidos no desenvolvimento entre o time e o analista de requisitos e/ou cliente, citado também como Product Owner. (LEFFINGWELL 2011, p.101) “Comunicação eficaz é a chave, e precisamos de uma linguagem comum. A história de usuário fornece uma linguagem comum para construir o entendimento entre o usuário e a equipe técnica.” (LEFFINGWELL 2011, p.101, tradução minha) 4 Scrum é um método de gerenciamento de projeto ágil que possui uma estrutura leve. (LEFFINGWELL,2011 apud SCHWABER, 2004, tradução minha)
    • JEFFRIES(2001), um dos criadores do XP, explica que as histórias de usuário possuem três aspectos críticos, sendo eles: 1. Cartão: as histórias de usuáriosão escritas em cartões para que o texto seja apenas o suficiente, não sendo a descrição completa de um requisito. Este cartão é usado durante todo o ciclo de projeto e devolvido ao usuário quando for concluída. 2. Conversa: “O requisito em si é comunicado de cliente para programadores através de conversa: uma troca de pensamentos, opiniões e sentimentos.” (JEFFRIES 2001, tradução minha) Essa conversa ocorre principalmente no planejamento da execução e apesar de ser na maioria das vezes verbal, pode ser complementada com documentos. Para LEFFINGWELL (2011, p.103-104) a discussão que ocorre nesse momento é necessária para determinar o comportamento do sistema de forma mais detalhada para o desenvolvimento. 3. Confirmação:LEFFINGWELL (2011, p.103) explica que a confirmação representa o teste de aceitação, uma forma de certificar se a história de usuário satisfaz os stakeholders e/ou cumpre os requisitos. De acordo com COHN (2004, p.67) os testes de aceitação são mais bem visualizados na parte de trás do cartão da história de usuário e podem ser complementadas a qualquer momento quando um novo teste for pensado. LEFFINGWELL (2011, p.103) relata que a forma padronizada para descrição de uma história de usuário é: “Como um <papel>, eu posso <atividade> para que <valor do negócio>” Onde: <papel> representa quem está executando a ação, ou talvez alguém que irá receber o valor da atividade. Pode até ser outro sistema, se isto é o que está iniciando a atividade. <atividade> representa a ação a ser executada pelo sistema. <valor do negócio> representa o valor alcançado pela atividade. (LEFFINGWELL 2011, p.103, tradução minha) Figura 1 – Cartão de história de usuário
    • Fonte: AMBLER, 2004-2007 COHN (1992 apud WAKE, 2003, p.17) relata que precisamos focar em seis atributos para criar boas histórias de usuário, sugerindo a sigla INVEST:  Independent: Crie histórias de usuário independentes umas das outras o quanto for possível. As dependências entre elas levam a problemas na priorização e planejamento.  Negotiable: Os cartões de história de usuário são lembretes, os detalhes são negociados posteriormente entre o cliente e a equipe de desenvolvimento.  Valuable to users or customers: De acordo com LEFFINGWELL (2011, p.107), um dos objetivos de um time ágil é entregar valor ao usuário, tornando este atributo o mais importante no modelo INVEST. LEFFINGWELL (2011) explica o valor que devemos entregar para o usuário através da seguinte metáfora: Acho que de toda a história é como um bolo de camadas múltiplas, por exemplo, uma camada de rede, uma camada de persistência, uma camada de lógica e uma camada de apresentação. Quando dividimos uma história [na horizontal], estamos servindo apenas parte desse bolo. Queremos dar ao cliente a essência de todo o bolo, e a melhor maneira é cortar verticalmente através das camadas. Os desenvolvedores muitas vezes têm uma inclinação para trabalhar em uma camada por vez (e fazer "direito"); mas uma camada de banco de dados completo (por exemplo) tem pouco valor para o cliente, se não houver nenhuma camada de apresentação. (LEFFINGWELL,2011 apud WAKE, s/a, tradução minha) A priorização é realizada de acordo com o valor das histórias de usuário e o sucesso da empresa é medido pelo valor que a equipe consegue entregar. COHN (2003, p.22)ainda ressalta que a melhor maneira de garantir que as histórias de usuário possuam valor é solicitar que os clientes escrevam essas histórias.  Estimatable: Os desenvolvedores dever ser capazes de estimar o tamanho das histórias de usuário ou quanto tempo levariam para desenvolvê-la. Caso
    • os desenvolvedores não entendam uma história, esta deverá ser discutida com quem a escreveu. Lembrando que os detalhes não são importantes nesse momento.  Small: De acordo com LEFFINGWELL (2011, p.109), as histórias de usuário devem ser pequenas o suficiente para serem concluídas em uma interação, caso o contrário podem não agregar valor ao cliente.  Testable: As histórias precisam ser testáveis, caso não sejam, a equipe não consegue confirmar se a história foi desenvolvida com sucesso. As histórias de usuário não testáveis, normalmente são requisitos não funcionais. COHN (2003, p.28) sugere que os testes sejam automatizados sempre que possível. 3.2. Use Case Originalmente popularizados no contexto Rational Unified Process (RUP), o Use Case ou Caso de Uso é a principal forma de representar os requisitos em Unified Modeling Language (UML) e tem sido a escolha para especificação e análise de requisitos. (LEFFINGWELL 2011, p.366-367) “Casos de uso são uma técnica para captar os requisitos funcionais 5 de um sistema. Eles servem para descrever as interaçõestípicas entre os usuários de um sistema e o próprio sistema, fornecendo uma narrativa sobre como o sistema é utilizado.” (FOWLER, 2005, p.101) Estas interações são abordadas a partir das ações, ou sequências de ações que o usuário e, eventualmente, o sistema realiza, assim descreve LEFFINGWELL (2011, p.369, tradução minha): “Um caso de uso descreve uma sequência de ações entre um ator e um sistema queproduz um resultado de valor para o ator.”. 5 Requisitos funcionais são as descrições de interação do usuário com o sistema eseu comportamentoperante as regras de um negócio. Já os requisitos não funcionais descrevem as características técnicas do sistema, as características típicas são: disponibilidade, segurança, desempenho, interoperabilidade, segurança e confiabilidade.
    • Para esclarecer melhor este conceito, LEFFINGWELL (2011, p.369) define ator como um indivíduo, outros sistemas (ou aplicações) ou mecanismo que interagem com o sistema. FOWLER (2005, p.101) explica que não há um padrão para descrever os casos de uso, já que eles possuem diferentes formatos que funcionam em diferentes casos. Porém de acordo com LEFFINGWELL (2011, p.370), na estrutura de um caso de uso há quatro elementos mandatórios:  Nome: O nome descreve o objetivo do caso de uso em poucas palavras.  Breve descrição:Descriçãodo propósito do caso de uso em uma ou duas sentenças.  Ator(es): Lista do(s) autor(es)  Fluxo de eventos: Descrições das interações entre ator(es) e sistema. Pode ser dividido em: o Fluxo Básico: descreve o caminho principal do caso de uso. o Fluxo(s) Alternativo(s): ou cenários alternativos, descrevem os eventos que ocorrem em uma circunstância especifica. É aqui que são descritos os “se” do fluxo principal: “e se o usuário não preencher essa informação”; “e se o usuário não acionar esse comando”. LEFFINGWELL (2011, p.372) explica que além desses elementos, o caso de uso pode possuir os seguintes elementos complementares opcionais:  Pré condições: descreve as condições que devem estar presentes para a execução do caso de uso. Normalmente representa as condições que o sistema deve apresentar.  Condições de saída: descreve as condições em que o sistema se encontrará após a execução do caso de uso. Inclui: o Garantia de Sucesso: estado do sistema após execução bem sucedida do caso de uso. o Garantia Mínima: estado do sistema caso ocorra uma situação inesperada que gere falha na execução do caso de uso.
    •  Sistema ou sub-sistema: Lista de sistemas presentes na execução do caso de uso. Desejável quando há múltiplos sistemas presentes no mesmo caso de uso.  Outros stakeholders: Lista de usuários, que não são atores, afetados pela execução do caso de uso.  Requisitos especiais: Na maioria das vezes são requisitos não funcionais, que descrevem alguns requisitos especiais importantes para a execução do caso de uso em específico. Figura2 – Exemplo de Caso de Uso Fonte: LEFFINGWELL, 2011, p.376
    • AMBLER(2004-2007) alerta que é muito fácil uma modelagem de caso de uso tornase un-agile.Para prevenir este acontecimento, crie artefatos bons o suficiente, eles não precisam ser perfeitos. Lembre-se: faça apenas o que agregue valor. "Ao trabalhar na análise de requisitos, lembre-se de que o mais importante é a comunicação com seus usuários e clientes." (FOWLER, 2005, p.48) 3.3. Linguística de Requisitos Alguns termos vagos ou gerais precisam ser evitados na descrição dos requisitos, caso contrário podem causar múltiplas interpretações ou não poderão ser verificados.(INTERNATIONAL STANDARD, 2011) Abaixo uma lista de tipos de termos vagos ou gerais fornecida pelo INTERNATIONAL STANDARD(2011):  Superlativos, tais como o “melhor”, “mais”;  Linguagem subjetiva, tais como “amigável”, “fácil de usar”, “econômico”;  Pronomes vagos, tais como “ele”, “isto”, “aquilo”;  Ambíguos advérbios e adjetivos, tais como “quase sempre”, “significativa”, “mínimo”;  Em aberto, termos nãoverificáveis, tais como “apoio”, “mas não limitado a”, “no mínimo”;  Frases comparativas, tais como o “melhor”, “melhor qualidade”;  Lacunas, tais como “se possível”, “conforme apropriado”, “como aplicável”;  Referências incompletas, não especificando a referência como sua data e número de versão; não especificando apenas as partes aplicáveis da referência para restringir o trabalho de verificação;  Declarações negativas, como declarações de capacidade do sistema não devem ser fornecidas. 4. Boas práticas de requisitos em metodologias ágeis
    • AMBLER (2004-2007) descreve práticas para auxiliar a modelagem e documentação dos requisitos serem mais ágil: 1. Os stakeholders participam ativamente: é importante que as partes interessadas no projeto tenham disponibilidade para além de fornecer os requisitos, realizar a modelagem junto ao analista. De acordo com a filosofia de AMBLER(2004-2007), caso os stakeholders sejam incapazes de participarem do projeto, existe uma forte indicação dele não ter sucesso. Eles são as pessoas que sabem o que querem e se o analista optar, pode ensiná-los como modelar um requisito. “Isto faz sentido do ponto de vista ágil porque ele distribui o esforço de modelagem para mais pessoas.” AMBLER(2004-2007, tradução minha) 2. Adote modelos abrangentes: para tornar o envolvimento dos stakeholders na modelagem e documentação mais fácil, utilize ferramentas simples, como cartões, post-it, papéis ou quadro branco. Isso incentivará a participação mais efetiva dos stakeholders. 3. Adote uma abordagem ampla: adotando uma abordagem ampla é possível ter a visão geral do sistema que auxilia a compreender os detalhes quando apropriado. O ponto é: invista em requisitos de alto nível que lhe proporcione conhecimento o suficiente para conduzir o projeto. 4. Modele os detalhes Just in Time: “Os requisitos são identificados durante todo o projeto” AMBLER (2004-2007, tradução minha) Modelagem ágil inclui práticas diversas de modelagem, que permite uma modelagem evolutiva. 5. Trate os requisitos como uma pilha de prioridade: Mudanças são aceitas. Alteração de requisitos já implementados podem ser tratados como novos requisitos e a priorização reavaliada. Figura 3 – Processo de Gerenciamento de Mudança de Requisitos Ágeis
    • Fonte: AMBLER, 2004-2007 6. Prefira requisitos executáveis mais do que documentação estática: times ágeis detalham requisitos em forma de especificações executáveis, testes de sistemas ou teste de desenvolvimento. 7. Seu objetivo é efetivamente implementar os requisitos, não documentálos: Documente apenas o suficiente. Mantenha a documentação enxuta e eficaz, concentre-se em criar soluções consumíveis para os stakeholders. 8. Reconheça que você tem um grande número de stakeholders: existem muitas pessoas envolvidas no projeto, que possuem opiniões, visões e definições diferentes em relação ao sistema. Em algumas vezes um não concordará com o outro. O analista de requisitos, citado também como Product Owner, precisa possuir a habilidade de negociação estar preparado para trabalhar com outros analistas de requisitos e saber para quem direcionar a equipe ao especialista apropriado quando houver dúvidas pontuais no projeto. 9. Plataforma Requisitos independentes a um ponto: requisitos deveriam ser tecnologicamente independentes. A especificação tecnológica é realizada na modelagem de arquitetura. 10. Menor é melhor: Requisitos menores são mais fáceis de estimar, priorizar e gerenciar. 11. A questão Rastreabilidade:De acordo com AMBLER(2004-2007) vale a pena investir e manter a matriz de rastreabilidade. O benefício de manter a matriz é a facilidade em realizar a análise de impacto nas mudanças que ocorrem nos requisitos, porém quando a equipe possui um conhecimento
    • familiarizado com o sistema, essa rastreabilidade é feita através da comunicação. 12. Explique as técnicas: Dedique alguns minutos para capacitar os stakeholders do projeto em relação às técnicas de modelagem, caso contrário, eles não conseguiram participar ativamente do projeto. 13. Adote a terminologias dos Stakeholder: use termos que todos sejam capazes de entender, não force o uso de expressões técnicas. Em alguns casos, surge a necessidade de haver um glossário no projeto. 14. Mantenha-o divertido: A modelagem não precisa ser uma tarefa custosa. “Conte umas piadas e manter seus esforços de modelagem leves.” (AMBLER, 2004-2007) 15. Obtenha Apoio da Gestão: A participação ativa dos stakeholders no projeto, muitas vezes, exige uma mudança de cultura da empresa e sem o apoio da alta gerência, você possivelmente não será bem sucedido. 16. Conecte Stakeholders em Desenvolvedores: Durante a modelagem, stakeholders desenvolvem habilidades de desenvolvedores, ajude-os nessa aquisição de novas competências. Isso fará com que a participação deles seja mais frequentes nesse e nos próximos projetos. 5. Qualidade de requisito INTERNATIONAL STANDARD, 2011 descreve algumas características individuais dos requisitos com o objetivo de estabelecer critérios relacionados à boa qualidade, conforme apresentado na tabela 1. Tabela 1 - Características de requisitos. Características Definição Necessário O requisito é atualmente aplicável e não se torna obsoleto com a passagem do tempo. Livre Descreva o requisito sem se preocupar como ele deve ser Implementação implementado. A modelagem de arquitetura deve ser evitada nos requisitos. Não ambíguo Requisitos que possuem interpretação única. Consistente Requisitos que não possuem conflitos com outros requisitos do
    • sistema. Completo Requisitos contêm descrições apenas o suficiente para atender a necessidade dos stakeholders. Único Requisitos são únicos, sem uso que conjunções. Viável Risco aceitável e restrições como custo, cronograma, técnico, legal, regulamentar disponível para o projeto. Rastreável Componentes e artefatos relacionados ao requisito podem ser identificados (rastreados). Verificável É possível validar se o requisito foi atendido após implementação. Fonte: INTERNATIONALSTANDARD, 2011. 6. Considerações finais A entrega de valor se tornou o objetivo mais importante em projetos ágeis e essa entrega inicia-se na definição dos requisitos. Vimos que, nesse processo, os stakeholders participam ativamente durante todo o ciclo de desenvolvimento e os requisitos são tratados a partir de suas prioridades. Embora a documentação estática (do processo tradicional) não seja implementada da mesma maneira, na metodologia ágil, os requisitos são apresentados de maneira executável e implementável, mas de qualquer forma as práticas ágeis sustentam a hipótese de documentar apenas o suficiente, ou seja, é necessário manter uma documentação enxuta e eficaz. Um dos objetivos do analista de requisitos, citado também como Product Owner, é descrever apenas o suficiente. Para auxiliá-los perante este desafio, foram descritos neste artigo os modelos mais utilizados em projetos ágeis, assim como técnicas para serem utilizadas na descrição e boas práticas, que tornam este objetivo possível de ser alcançado. Desta forma conclui-se que, como ressalta SMITH (2009,p.9), nenhuma metodologia é melhor do que outra, tudo depende de qual funciona melhor em seu ambiente e dentro de suas limitações. Sugere-se que o analista utilize a ferramenta principal para este processo: a comunicação.
    • 7. Referências Agile Manifesto.(2001) Manifesto para Desenvolvimento Ágil de Software. Disponível em: < http://agilemanifesto.org/iso/ptbr/>. Acesso em: 18 jul. 2013. AMBLER, S.W. Agile/Lean Documentation: Strategies for Agile Software Development. Agile Modeling. Disponível em: <http://www.agilemodeling.com/essays/agileDocumentation.htm>. Acesso em: 21 out. 2013 AMBLER, S.W. Agile Requirements Best Practices. Agile Modeling. Disponível em: <http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm>. Acesso em: 21 out. 2013 AMBLER, S.W. Agile Requirements Modeling. Agile Modeling. Disponível em: < http://www.agilemodeling.com/essays/agileRequirements.htm>. Acesso em: 21 out. 2013 AMBLER, S.W. Introduction to User Stories. Agile Modeling.Disponível em: <http://www.agilemodeling.com/artifacts/userStory.htm>. Acesso em: 21 out. 2013 AMBLER, S.W. Requirements Envisioning: An Agile Best Practice. Agile Modeling. Disponível em: <http://www.agilemodeling.com/essays/initialRequirementsModeling.htm>. Acesso em: 21 out. 2013 AMBLER, S.W.Where Do I Start?.Agile Modeling.Disponível em: <http://www.agilemodeling.com/essays/whereDoIStart.htm>. Acesso em: 21 out. 2013 COHN, M. User Stories Applied: For Agile Software Development. United States of America: Addison-Wesley Professional, 2004. DENNIS, A.; WIXOM, B.H.; TEGARDEN,D. System Analysis Design UML Version 2.0: An Object-Oriented Approach. United States of America: John Wiley & Sons, Inc., 2009. FOWLER, Martin. UML Essencial, 3ª Edição, Bookman,2005. INTERNATIONALSTANDARD.ISO/IEC/IEEE 29148: Systems and software engineering — Life cycle processes — Requirements engineering. First edition.Switzerland, 2011.95 p. JEFFRIES, R.Essential XP: Card, Conversation, Confirmation. XProgramming: Extreme Programming and Agile Software Development Resources, 2001. Disponível em: http://xprogramming.com/xpmag/expcardconversationconfirmation/. Acesso em: 17 out. 2013.
    • KOSCIANSKI, A.; SOARES, M.S. Qualidade de Software: Aprenda as metodologias e técnicas mais modernaspara o desenvolvimento de software. São Paulo: Novatec, 2007. LEFFINGWELL, D. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, 1st edition. Boston: Addison-Wesley Professional, 2011. MORAES, J.B.D.Introdução a Abordagens de Identificação de Requisitos. Engenharia de Software Magazine. Ano 1, 2 ª Ed. Dev Media, 2009. MORAIS, L. Modelagem em uma Visão Ágil. Engenharia de Software Magazine. Ano 3,32 ª Ed. Dev Media, 2011. SMITH, G.;SIDKI,A. Becoming Agile…in an imperfect world. Greenwich: Manning Publications Co.,2009. SOMMERVILLE, I. Engenharia de Software, 8ª edição. Tradução: Selma Shin Shimizu Melnikoff, Reginaldo Arakaki, Edilson de Andrade Barbosa; São Paulo: Pearson Addison--Wesley, 2007. The Standish Group International, CHAOS Report 2010.