DSRP: Um Caso de Uso

No artigo anterior prometi um exemplo de uso do DSRP, modelo que propõe uma atualização do Pensamento Sistêmico. Fiz opção por um tema caro e comum para quase todos que por aqui passeiam: o desenvolvimento de requisitos.

Apresentei o DSRP (Distinções Sistemas Relacionamentos Perspectivas) de forma muito breve e quase irresponsável alguns meses atrás. Abstração é o luxo do expert? Não sou expert. Foi relaxo de aprendiz mesmo. Acontece que ele é tão simples, mas tão simples, que chega a levantar suspeitas. 

Os objetos de estudo podem ser complicados e complexos, bagunçados e imprevisíveis. Modelos e métodos que apoiam o estudo não precisam – aliás, não podem ser assim. Veja a simplicidade desconcertante de propostas como Scrum e Kanban, por exemplo. O DSRP vem na mesma linha. Mas, claro, tem um propósito bem mais ambicioso: nos ajudar a pensar melhor. Ao exemplo.

Distinções

O que é conhecido está definido – tem identidade e fronteiras. Não fosse assim, não conseguiríamos nem nos expressar. Nomeamos as coisas, comparamos e escolhemos ideias. Determinamos o que está dentro e o que está fora do escopo de um projeto. Pronto, agora podemos aplicar a regra das Distinções aos requisitos.

Antes, porém, uma definição básica: requisitos são condições para alcançar determinado fim. Ponto. Projetos têm fins – nada a ver com as datas em um cronograma nem com a grana que se pretende torrar. Há pelo menos um objetivo de negócio ali, seja qual for. Requisitos são condições que, quando e se plenamente satisfeitas, aumentam as chances de realização daquele objetivo.

Todo requisito é único. Ele merece um nome, número e etiquetas. Pede por informações que demarquem suas fronteiras. E a primeira distinção que realizamos refere-se ao seu tipo: É uma função (algo que o sistema deve fazer ou ajudar a fazer) ou um atributo (uma característica do produto/sistema)? 

Cada requisito é diferente, assim como sua margem de contribuição (valor) para a realização do objetivo maior. Aquilo que é fundamental deve ser entregue e não se fala mais nisso. Requisitos importantes serão satisfeitos, um dia. Os opcionais não comprometem a busca pelo objetivo. Mas podem agradar alguém cujo humor e motivação sejam fatores críticos de sucesso.

A régua utilizada é simples: Fundamental, Importante, Opcional. Podemos fazer uma distinção mais sofisticada, utilizando a sequência de Fibonacci, por exemplo. Não importa. Desde que tal diferenciação aconteça tão logo um requisito seja apresentado.

Se não diferenciamos os requisitos não podemos compará-los. Se a comparação é impossível, qual tomada de decisão faria sentido?

Sistemas¹

Todo requisito pode ser visto como o todo ou parte de algo maior. Se o próprio projeto pode e deve ser visto como “uma condição para alcançar determinado fim”, temos que um projeto é também um requisito. Depende do ponto de vista. Ou, melhor dizendo, depende do ponto de corte: da definição daquilo que se pretende estudar.

Um projeto é um conjunto de requisitos. E requisitos podem ser estruturados em partes menores. Uma função, por exemplo, pode ser descrita na forma de casos de uso. Assim sendo, ator, objetivos, pré e pós-condições, fluxos principal e alternativos e os passos desses fluxos são partes do todo chamado requisito funcional (ou simplesmente Função).

Requisitos podem ser distribuídos em módulos, versões, plataformas etc. Requisitos podem ser descobertos e explicados através de casos de uso, histórias de usuários, protótipos etc. O importante aqui é a estrutura e as idas e vindas entre o todo e as partes – análise e síntese.

Vale a pena recuperar um alerta que faço: “O diabo mora nos detalhes. Em projetos, cada requisito é um conjunto de detalhes. O dito cujo faz a festa.”

Relacionamentos

Se fazem parte de um todo – o projeto – é natural que os requisitos tenham inúmeras e fortes relações entre si. Não é possível compreender um requisito se não sabemos como ele se relaciona com os demais.

Um requisito pode depender de outro, por exemplo. Sua realização não é possível até que o outro seja satisfeito. Relações de complementaridade também são comuns: o requisito B enriquece o requisito A, mas não há dependência. 

Requisitos podem ser redundantes. Neste caso, um deles deve sair do escopo. Assim como um daqueles em relação conflituosa: quando a realização de um impede a satisfação do outro. Infelizmente, muitos conflitos só são descobertos quando é tarde demais: na bancada de testes ou, pior ainda, em produção.

Por fim, mas não menos importante: um requisito pode substituir outro. Quando as relações de substituição são bem registradas, temos boa parte da história de um projeto e dos diversos rumos que ele tomou.

Ops!, não era o fim. Requisitos também se relacionam com outras coisas. Com testes, por exemplo, numa típica relação de muitos para muitos. Explico: todo requisito merece vários testes (unitários, de integração etc); E alguns testes validam vários requisitos numa pancada só. Muitos para muitos. Há mais relacionamentos, mas você já pegou a ideia. Hora da última peça do tabuleiro DSRP.

Perspectivas

Como fixado na definição original, qualquer coisa ou ideia pode ser o ponto de vista ou aquilo que é visto. Vale para tudo, e é particularmente importante quando falamos de requisitos. Um mesmo requisito pode ser interpretado de formas diferentes ou mesmo ter valores distintos dependendo da perspectiva – de quem ou o que o observa. Ao desenvolver requisitos, o bom analista se preocupa em capturar todos os pontos de vista relevantes. Ele promove o debate e ajuda a dissolver os inevitáveis conflitos.

Coincidência?

Nossa Paulo, com exceção das figurinhas, não tem nada diferente do que você apresenta desde a primeira edição do FAN.

Para falar a verdade, é praticamente a mesma ideia que utilizo desde 2000 e que apresentei numa palestra em 2004. Aqui no finito, ela apareceu pela última vez há quatro anos. Coincidência? Sorte? Isso importa?

Conclusão

Usar o DSRP significa aplicar 4 regras simples. Espero ter demonstrado isso acima. Pretendo elaborar novos exemplos, utilizando casos do dia a dia. Porque também preciso mostrar como o DSRP é extensível e acomoda de forma natural outras vertentes e ferramentas do pensamento sistêmico.