Nível: Intermediário Sandra Sergi Santos, Especialista em Engenharia de Software para Rational, IBM
20/Ago/2009
Introdução
O principal objetivo deste artigo é apresentar a nova solução para definição de
Requisitos
Rational Requirements Composer
e demonstrar como ela suporta o desenvolvimento Orientado ao Negócio.
Primeiramente é importante a apresentação do conceito de
Desenvolvimento Orientado ao Negócio
também chamado de BDD (Business Driven Development).
Está se tornando cada vez mais difícil para as empresas considerar a área de TI como
apenas uma área de apoio ou suporte. Segundo o CIO da Ameritrade, atualmente uma das
maiores corretoras on-line do mercado
“TI não suporta mais o negócio, na maioria dos casos TI é o negócio.”
Vocês conhecem alguma empresa de Telecomunicações ou uma instituição financeira que
sobrevive sem tecnologia? Cada vez mais notamos que TI tem se tornado mais um
processo de negócio core dentro das empresas e para isso temos que adaptar nossa
maneira de desenvolver e manter software a essa nova realidade.
É por essa razão que é necessário uma abordagem única e eficiente para suportarmos os
processos de negócio alinhados com a entrega de software.
Um simples checklist poderá nos ajudar a saber se sua empresa está alinhada a uma
abordagem BDD:
- Estamos constantemente alinhando nossos investimentos de software e tecnologia
com os objetivos estratégicos e negócio da minha empresa?
- TI consegue responder às demandas de negócio de uma maneira eficiente e
eficaz?
- Entendemos o verdadeiro custo e benefício do desenvolvimento e entrega de uma
demanda?
- As demandas atendidas por TI estão alinhadas aos objetivos de crescimento e
desenvolvimento da empresa?
- A entrega e gestão de uma demanda está aderente aos requisitos de
compliance?
- Consigo rapidamente estender meus processos de negócio e incluir novas
soluções de terceiros ou novos desenvolvimentos?
A importância de Requisitos no Desenvolvimento Orientado ao Negócio
Todos nós sabemos que na maioria dos casos o principal vilão das falhas em projetos
são os requisitos que muitas vezes são de má qualidade, ambíguos e
inconsistentes.
Standish Group classifica no relatório “Chaos Ten” os principais fatores relacionados
a falhas de projetos, dentre eles podemos citar:
- Falta de envolvimento do usuário
- Falta de clareza nos requisitos de negócio
- Escopo incompleto, ambíguo ou mal definido
- Falta de envolvimento executivo
Podemos destacar dois fatores da lista acima: Falta de envolvimento de usuário e
falta de clareza nos requisitos de negócio.
Atualmente encontramos um Gap grande entre as áreas de negócio e TI. Ainda temos
empresas em que as áreas de negócio encaram TI como uma “caixa preta de surpresas”.
Para isso temos que adotar soluções e técnicas que nos permitam quebrar esse
paradigma , permitindo uma comunicação clara entre negócio e TI.
Jim Johnson, do Standish Group, afirma que
"quando um projeto falha, raramente a causa está relacionada a
tecnologia"
.
Espero que os leitores não se identifiquem com algumas dessas frases, mas
infelizmente ainda são realidade em algumas empresas:
- Gerente falando para sua equipe de desenvolvimento: “Pessoal, podem começar a
codificar que enquanto isso vou lá falar com o usuário para descobrir o que ele
precisa..não temos tempo para esperar”
- Depoimento de usuário no final do projeto: “Muito bem, você desenvolveu
exatamente o que especificamos, mas não era exatamente isso que eu
precisava”
- Desenvolvedor ou fornecedor de sistemas: “O que será que ele quis dizer com
isso? Bom, não temos tempo, acho que é isso ...vamos em frente”
- Forncedor contratado conversando com o contratante: “Mas você deveria ter
especificado melhor essa demanda , por isso teremos que refazer o trabalho e
cobrar um adicional para isso”
Especificações incompletas
Como já mencionamos anteriormente , especificações incompletas constituem um dos
fatores que pode contribuir para falhas de projeto em alguma dimensão (custo, tempo
ou escopo).
Percebo que grande parte das empresas acreditam que se tiverem um “template” para
documentar os requisitos funcionais e não funcionais , nunca terão problemas
relacionados à requisitos. Concordo que a forma textual acaba sendo 60 a 80% de uma
especificação, mas ela deve obrigatoriamente ser complementada com especificações
gráficas e utilizações de técnicas.
Uma das técnicas para especificar software mais recomendadas e utilizadas pelo
mercado é a técnica de Casos de Uso onde é possível descrever todos os cenários de
uso de um sistema de forma textual e gráfica através de diagramas que nos mostram
claramente as fronteiras e interações de determinado cenário funcional.
Mas essa técnica pode e deve ser complementada para melhorar a qualidade das
especificações e garantir que faremos o certo a primeira vez, sem novas iterações e
voltas de retrabalho.
Definição de Requisitos com Rational Requirements Composer
Uma vez que estamos mencionando técnicas e especificações gráficas, é de extrema
importância termos uma ferramenta que nos apóie na definição.
Requirements Composer é uma ferramenta que automatiza a definição de requisitos de um
sistema desde a área de negócio até o desenvolvimento através de um ambiente
colaborativo , integrado e rastreável.
Apresentaremos em seguida as cinco principais características da ferramenta que
suporta o processo de definição dos requisitos auxiliando na redução do Gap
existente entre TI e as áreas de negócio:
Modelagem de Negócio Integrada à Requisitos de Sistemas
Para garantir aderência das soluções de TI às demandas do Negócio, é necessário
iniciar a concepção de uma solução com o entendimento do problema e, muitas vezes,
desenho dos processos de negócio envolvidos com a nova demanda ou projeto. Para isso
a ferramenta apresenta um subset da notação BPMN versão 1.1 (Business Process
Modeling Notation) para modelagem de processos.
As tarefas de negócio e pontos de decisão podem ser linkados com casos de uso,
desenhos de interface e requisitos fornecendo uma rastreabilidade completa de
requisitos.
Figura 1: Diagramas de Processos de
Negócio - BPMN
Especificação textual e gráfica de casos de Uso
A ferramenta contém um editor de texto próprio (Rich Text Editor) onde podemos
através de templates pré-definidos documentar os Casos de Uso de um sistema com base
nos processos de negócio definidos. A ferramenta também suporta a utilização de
documentos Microsoft Word.
Os elementos podem ser facilmente organizados através de tipos de requisitos, pastas
e identificados através de tags e atributos para categorização e futuras consultas.
É possível a criação de filtros que podem ser criados por pastas, tags ou tipos de
artefatos.
A modelagem de Casos de Uso também é feita na mesma interface através de
drag-and-drop de interface e reutilização de elementos entre diagramas (atores e
casos de uso).
Figura 2: Diagramas de Casos de
Uso
Ambiente colaborativo
A comunicação é o principal fator de sucesso para os projetos, para isso, a
ferramenta possue um ambiente altamente colaborativo através de integrações com
email, compartilhamento instantâneo de artefatos entre times, comentários e
revisões.
O repositório do servidor é baseado em tecnologia Jazz que é um ambiente altamente
colaborativo.
A ferramenta apresenta dois tipos de interface: cliente e web. Através da interface
cliente é possível criar e modificar os elementos e a interface web pode ser
utilizada para consulta, revisão e aprovação de requisitos.
Figura 3: Requirements Composer Sidebar
– ambiente colaborativo
Auxilio ao usuário visualizar o sistema a ser construído através de Storyboards e
Sketches
Primeiramente essa funcionalidade é de extremo valor para auxiliar o usuário ter uma
visão do que será construído. Como já dizia nosso amigo Jacobson, o usuário muitas
vezes somente sabe o que realmente necessita após visualizar o sistema já construído
- efeito IKIWISI (I Kow It When I See It).
A ferramenta permite documentar cenários de casos de uso através de storyboards
textuais e associá-los á sketches de interface que podem ser construídos através de
um editor de paginas web contido na ferramenta.
Além dos storyboards que são de grande valor para o usuário, podemos graficamente
desenhar e sequenciar fluxos de telas permitindo uma validação do que realmente será
construído. Esses elementos podem ser associados a outros elementos, como por
exemplo casos de uso ou processos de negócio.
Figura 4: Requirements Composer UI
Sketches , Storyboards e Screen Flows
Glossários
Tão importante quanto às demais características da ferramenta, o uso de um glossário
é praticamente obrigatório na disciplina de Requisitos. O glossário integrado às
especificações funcionais podem evitar problemas de ambigüidades e garantir o
correto entendimento de termos de negócio e técnicos.
O Glossário está integrado ao editor de texto da ferramenta, onde é possível
visualizar a definição de um termo dentro do próprio editor. Os termos de glossário
no Requirements Composer podem ser compartilhados entre glossários de outros
projetos ou corporativos.
Figura 5: Editor de Textos Rich Text
integrado a termos do glossário
Integração com Rational RequisitPro 7.1
Importante não deixarmos de mencionar que um requisito além de ser bem definido tem
que ser bem gerenciado. A gestão das mudanças de requisitos , extração de métricas,
análise de impacto e cobertura através de matrizes de rastreabilidade e integração
com o restante do ciclo de desenvolvimento são executadas na ferramenta Rational
RequisitPro que já conhecemos.
A versão 7.1 do RequisitPro além da integração com o Requirements Composer, também
apresenta novas funcionalidades como criação de novos relatórios utilizando a
ferramenta BIRT, melhorias na interface Web, pesquisa rápida e suporte a editor Rich
Text através da interface Web.
Conclusão
Apresentamos neste artigo a solução IBM para a definição e gerenciamento de
Requisitos em um ambiente orientado ao negócio onde cada vez mais temos que
considerar o usuário e as áreas de negócio como parte integrante ao time de TI e
comprometida com a entrega de uma demanda e redução dos índices de retrabalho.
Importante ressaltar que a disciplina de requisitos acaba sendo uma das mais
importantes do ciclo de vida de um desenvolvimento pois um requisito bem elaborado e
definido pode reduzir os riscos de falhas relacionados à mal entendimento, testes
mal elaborados e arquitetura mal definida.
Para concluir , podemos mencionar que um bom requisito segundo Leffingwell &
Widrig - IEEE é aquele que podemos considerar correto, completo, consistente, não
ambiguo, verificável, ranqueável, modificável, rastreável e compreensível pelos
usuários e desenvolvedores.
Terminologia
Artefato:
Um artefato no Requirement Composer refere-se a um documento ou outro recurso
armazenado no Servidor. Documentos Rich Text, Desenhos de interface de tela de
usuário, Diagramas de casos de uso são exemplos de artefatos.
Storyboards:
Também chamados de encenações de caso de uso são utilizadas para ajudar a
compreender os requisitos da interface do usuário, incluindo os requisitos de
usabilidade. Elas representam uma compreensão de alto nível da interface do usuário
e são muito mais rápidas de desenvolver do que a interface real do usuário.
Grupo de Atributos:
Um artefato pode ter um ou mais grupos de atributos associados. Um grupo é uma
coleção de atributos (nome e valor) que pode ser associado a um artefato como um
metadata suplementar.
Elementos:
Um elemento é um subcomponente de um artefato. Como exemplo, podemos citar:
termos de glossários, tarefas em desenho de processos, etc.
Link:
Um elemento pode ser referenciado a outro elemento ou artefato externo através
de um link. O conceito está baseado em hyperlinks HTML e implementados de maneira
similar.
Repositório:
Chamamos de repositório o ambiente servidor de colaboração que permite aos
usuários compartilharem trabalho e possue mecanismos de segurança e
autenticação.
Referências:
IBM Rational – Business Driven Development
Rational Requirements Composer Open Beta
Datasheet Business Driven Development
Rational Requirements Composer DEMO
Sobre o autor  | | | Formada pela Universidade Mackenzie e Pós-graduada pela FAAP, atua na área de desenvolvimento de sistemas a 15 anos . Certificada em RUP (Rational Unified Process) , PMP (Project Management Professional), Scrum Master, Gerência de Requisitos e Gerência de Configuração de Mudanças (IBM Clearcase e Clearquest). Atualmente trabalha como Especialista em Engenharia de Software na brand Rational da IBM Brasil. |
Avalie esta página
| 
