Comments (2)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 Walter Farias commented Permalink

Por que será que gerenciar requisitos não é uma tarefa fácil? Como vamos saber se um requisito é de boa qualidade? <br /> Segundo o RUP gerencia de requisitos é uma abordagem sistemática para elicitar, organizar e documentar os requisitos de software além de manter o acordo entre o usuário/cliente e o time de desenvolvimento sobre as mudanças nos requisitos. Muito simples, não acham? <br /> Segundo a norma IEEE 830-1993 um requisito com qualidade deve ter as seguintes características: correto, completo, consistente, não ambíguo, verificável, classificado de acordo com a importância e estabilidade, modificável, rastreável e compreensível. Também é muito fácil escrever um requisito com todas estas características, vocês não acham? <br /> Mais como fazer tudo isso apenas usando texto? Todo mundo já ouviu falar que um desenho vale mais do que 1000 palavras, isso também se aplica na prática de gestão de requisitos. Os diagramas de casos de uso ajudam a entender e a delimitar o escopo do que será implementado, diagramas de atividade ajudam a entender o fluxo de um requisito complexo, então porque não usamos mais estas técnicas? Será que é porque é difícil de manter tudo isso atualizado? Texto, diagramas, protótipos. E se isso fosse tudo Vivo? Se todos estes elementos fossem partes, e eu pudesse juntar estas partes em um documento e mostrar para meu usuário? Facilitaria? <br /> O IBM Rational Requirements Composer procurou fazer tudo isso de forma colaborativa, ou seja, eu tenho Protótipo, diagramas, texto tudo em um só lugar, e eu posso relacionar estes elementos da melhor forma possível visando diminuir a ambigüidade. <br />

2 calazans@br.ibm.com commented Permalink

Muito se discute acerca do alinhamento de TI com Negócios mas pouco se fez nas organizações além das iniciativas de gestão de portifólios. <div>&nbsp;</div> Estamos diante de um produto que atende diretamente a esta necessidade! <div>&nbsp;</div> É justamente na fase de definição dos requisitos que acontecem as principais interações entre a área de TI e as áreas de negócios. <div>&nbsp;</div> Tipicamente quando um projeto inicia, um analista de negócios chega e marca uma série de reuniões com os stakeholders, realiza estas reuniões, coleta o que ele entende ser os requisitos e escreve um documento de requisitos que será usado pelo resto do time. <div>&nbsp;</div> Alguns problemas inerentes a esta fase, são: <div>&nbsp;</div> 1) Os executivos, pessoas responsáveis pelo negócio e pela estratégia, normalmente dispõem de pouco tempo para a realização de reuniões. <div>&nbsp;</div> 2) Times de TI, para não incomodar, acreditam que são capazes de entender no pouco tempo que lhes é destinado, ou através de uma breve explicação, toda a necessidade do negócio. Resumindo... na maioria das vezes inferem! <div>&nbsp;</div> 3) Palavras e jargões tem diferentes sentidos dependendo do contexto organizacional ou de negócio. Imaginem por exemplo quantos significados a palavra "oil" pode ter dentro de uma organização como a Petrobras. <div>&nbsp;</div> 4) Vocês podem até não acreditar mas mudanças acontecem! <div>&nbsp;</div> 5) Diferentes pessoas têm diferentes visões e expectativas (vide artigo publicado pelo Roberto Argento) neste blog. E por sua vez, o produto esperado é um somatório de comunicação interpessoal, experiências anteriores e necessidades pessoais. <div>&nbsp;</div> 6) Os times de projeto acreditam que ter um documento de definição de requisitos assinado pelos clientes internos ou externos, garante que estes tenham, lido, entendido e concordado com tudo que está escrito. <div>&nbsp;</div> 7) Falta de garantia que os requisitos são divulgados e entendidos pelo resto do time <div>&nbsp;</div> 8) A existência de barreiras geográficas entre os stakeholders do projeto <div>&nbsp;</div> e por aí vai! <div>&nbsp;</div> O Rational Requirements Composer (RRC) ajuda exatamente as juntar as pessoas para definir os requisitos, ou seja, serve para ajudar as pessoas de TI a entender aqueles requisitos que precisam ser desenvolvidos, e também, a fazer com que o grupo de negócios seja capaz comunicá-los claramente, usando técnicas que lhes ajude a expressar, precisamente, seus desejos. <div>&nbsp;</div> O RRC traz os stakeholders para o projeto de desenvolvimento,promovendo uma maior chance de sucesso do mesmo, uma vez que garantirá que os requisitos foram corretamente entendidos. <div>&nbsp;</div> Através do RRC, os desenvolvedores podem interagir e ter feedbacks sobre os requisistos se precisarem. <div>&nbsp;</div> Os analistas por sua vez, tem varias formas de expressar os requisitos, ao invés de simplesmente usar uma especificação de software que leve ao time "o entendimento do projeto", dando-lhe margem a interpretações; <div>&nbsp;</div> O CIO e o Patrocinador do projeto poderão participar do projeto, certificado-se que seus investimentos estao fazendo sentido e o projeto está no caminho certo. <div>&nbsp;</div> Assim, vemos que o Rational Requirements Composer que não se trata de mais uma ferramenta que deva ficar restrita ao time de desenvolvimento ou de requisitos mas algo a ser amplamente difundido entre as áreas de negócios envolvidas com o projeto. Pois, através dela, o time poderá discutir, revisar, aprovar, redefinir, repriorizar, colaborativamente e eficazmente as decisões do projeto, usando técnicas tais como modelagem ou protipação, até que estas se tornem efetivamente requisitos a serem gerenciados. <div>&nbsp;</div> A boa comunicação é um fator preponderante a obtenção do tão sonhado alinhamento de TI com as Áreas de Negócios e para o sucesso dos projetos de desenvolvimento. <div>&nbsp;</div> Como dizia o Velho guerreiro: "Quem não se comunica, se trumbica!"