Muito tempo sem publicar nada e as pessoas começam a pensar o que estarei fazendo e porque não escrevo mais… bom, não é porque não queira, nem porque falte assunto, é porque falta tempo. O assunto de hoje me é muito querido e para quem sabe como gosto de scrum pode parecer até meio contraditório – levantamento de requisitos. Em scrum ha levantamento de requisitos ? Bom, não especificamente, tal como não ha práticas de desenvolvimento como repositorio partilhado. Contudo scrum levanta a bandeira da visibilidade bem alto, e requisitos são uma forma de dar visibilidade ao projeto em tempos primários onde o código ainda não é o artefato principal. Por outro lado, o que é o Product Backlog senão uma lista de requisitos ?
Se podessemos colocar apenas em uma frase o que nossa profissão significa, seria algo como “Implementados requisitos em código”. Muitas escolas existem sobre o comportamento, as funcioanlidades, o codigo, mas poucas sobre requisitos. No seu livro Software Requirements, Karl Wiegers apresenta uma visão, quanto a mim especialmente esclarecedora de como existem diferentes tipos de requisitos, e como eles são influenciados por fatores externos. Além disso estabelece três marcos essenciais num produto de software: documento de visão, documento de casos de uso, e documento de especificação de software.
Começamos com a idealização do software. Isto significa dizer: para que servirá, porque as pessoas o usaram, porque devemos investir nele, o que o distingue dos outros o que fará dele um bom produto e o que fará dele um mau produto. Estes pensamentos são concentrados no documento de visão e são o estabelecimento de porque o software deve existir e qual é a sua finalidade a curto, médio e longo prazo. É um documento nada técnico, muito virado para potenciais utilizadores e investidores. Este passo é normalmente esquecido para produtos “pequenos” cuja vida util é menores que 2 anos, mas é interessante para produtos de vida média (2 a 4 anos) e mandatório para produtos de vida long (5 anos ou mais).
Com base neste documento de visão, que é bem sucinto e ao ponto, é possível angariar o interesse de utilizadores, ou patronos que estejam dispostos a investir neste produto em nome de outros utilizadores. Aqui a ideia original é expandida e desenvolvida e evoluída para algo mais próximo ao que seria de esperar para alguém que utilizasse o software. A divisão de atores e o que cada um representa e como cada um interagiria com o software nos dá mais detalhada informação. Esta informação é registrada num documento de casos de uso. Também neste documento são descritas regras de domino. Regras de domino são regras do âmbito do negócio em que o software é usado ou no âmbito do contexto em que é usado. Estas regras são normalmente genéricas e aplicáveis a software que serão utilizados nos mesmos ambientes. Estas regras não são escolhas dos usuários mas imposições que eles devem seguir ou pretendem que o software as ajude a seguir.
Sabido como o software deverá interagir com o seu utilizador, é necessário definir detalhes mais minuciosos. Sabemos o que o software deve fazer e interagir com o usuário, mas não que comportamento deve ter. Ou seja, que tipo de ações o software tomará sozinho, quais ele necessitará da ajuda ou suporte do ser humano, se será passivo ou ativo, se será instrutivo. É claro que a forma como ele se irá comportar basicamente com base numa abstração como a todas as interações descritas nos casos de uso, mas além disso existirão atributos de qualidade que também afetarão o seu comportamento. Desde propriedades de ergonomia, design, facilidade de uso até propriedades como segurança, confiabilidade , resiliência a falhas, robustez e durabilidade. Estas propriedades desejáveis pelo usuário se tornaram depois guias fundamentais para a arquitetura final do software. Algumas regras de dominio que não podem ser forçadas com base em interação, devem ser forçadas com comportamento, como regras de apresentação de informação, formatação, internacionalização, entre outras. Outros fatores que influenciam fortemente o comportamento do software são requisitos de sistema, ou seja, regras que o sistema deve respeitar porque é um software. Regras relacionadas ao uso de memória, processador, placas gráficas, ou ambientes como navegadores e sistemas operacionais. Um software baseado em internet utilizando HTML num browser tem, à partida, um comportamento diferente de um sistema embarcado ou de um sistema desktop pela natruza do ambiente onde funcionará.
Alguns requisitos podem advir do ecossistema onde o software irá funcionar, ou com quem irá compartilhar informações. Documentação das interfaces externas que o software oferece e das que ele necessitam também fazem parte do documentos de especificação de software.
Todos os requisitos de comportamento são colocados num documento de especificação de software, juntamente com todos os atributos de qualidades relevantes. Mas nem tudo são rosas. Muitas vezes, para que o software seja possível, funcione, ou até para que seja comercialmente interessante ele tem que respeitar um serie de “não pode” conhecidos como constrangimentos. Podem ser variados, desde tecnologia, a sistema operativos, ou qualquer outro detalhe técnico, a preocupações com o gasto de energia, a performance ou mesmo em relação à aparência gráfica. Todas estas regras são então compiladas num último documento de especificação.
É de notar que existem fatores que podem modificar o como um documento de visão é transformado num documento de casos de uso, e posteriormente numa especificação. Um único documento de visão, entregue a grupos diferentes de usuários pode promover diferentes interações e casos de uso, e um mesmo documento de casos de uso, entregue a grupos diferentes, com constrangimentos diferentes pode , sem dúvida , levar a especificações diferentes. As possibilidades são inumeráveis. Aliás até o mesmo grupo de pessoas, em momentos diferentes do tempo podem obter resultados diferentes pegando a mesma fonte. É por isto que em produção de software temos sempre a sensação de estarmos desenvolvendo sempre a mesma coisa, mas ligeiramente diferente.
Pode parecer daqui que o levantamento de requisitos segue uma ordem pré-determinada e bem definida. Na realidade não é bem assim. Ao conversar com um pessoas sobre um software que ela quer, ele irá misturar requisições de diferentes tipos, graus de importância, graus de relevância e de especificidade. O papel do Analista é reconhecer quais são quais e colocá-los em seus respectivos “balões”. Depois de ter um conjunto suficiente de informações contidas nos “balões” serão condensadas e depositadas nos respectivos documentos. Portanto, embora exista uma ordem lógica para a leitura destes documentos, na práticas eles podem, e devem, ser redigidos em paralelo.
O levantamento de requisitos é ainda mais uma arte que a produção do próprio software. Pode ser feito por pessoas que não conhecem das tecnologias envolvidas, mas, com certeza, não pode ser feito por pessoas que ignoram as tecnologias envolvidas e/ou que não dominam o plano tecnológico em causa. Não é missão de quem levanta requisitos impedir os interessados em fazer requisições e moldar requisitos mas é missão de quem levanta requisitos não alimentar falsas expectativas ou fazer promessas de realização se entendimento e/ou conhecimento da equipe irá realizar o software. Sim, eu não acredito nesse negócio de uma equipe levantar requisitos e outra implementar.
Existem algumas diretrizes para o levantamento de requisitos que acho importantes. Primeiro a questão da comunicação. É importante que todos tenham bem claro os conceitos e que eles não sejam ambíguos. Um glossário e o uso de uma linguagem de domínio são ferramentas essenciais. Segundo a atenção ao que o cliente está tentando expressar e não ao como está expressando. Nem todos são exímios com as palavras ou eloquentes. Use formas de comunicação que sejam adequadas ao requisitante. Terceiro a analise. Levantar requisitos é um processo analítico e de alto risco para o projeto. Um levantamento mal feito pode ser desastroso para o resto do projeto. Portanto desconfie sempre que o requisitante usar as palavras “sempre” e “nunca”. Tente explorar cenários alternativos com frase do tipo “E se acontecer ?”. Tenha a certeza que não se está enganando a si mesmo por acreditar no requisitante e simplificar. Tente identificar o que são regras e requisitos gerais do tipo de negócio do requisitante e quais são específicos à forma como ele trabalha e ao seu negócio. Sempre tente entender o valor de negocio que o requisito tem e como ele, adicionado ao software, tornará a vida do requisitante melhor. Para o caso em que o requisitante é desconhecido ou não existe uma única pessoa que possas responder pelo processo de analise, utilize grupos de foco.
Levantamento de requisitos é a tarefa mais importante no desenvolvimento de software. É onde existe mais risco de falha e onde se estabelecem os conceitos que irão balizar a implementação.
Muitas pessoas acreditam, hoje em dia, que as metodologias ágeis são contrários ao levantamento de requisitos e/ou que elas ensinam que os requisitos devem ser obtidos on demand ou just-in-time apenas quando são necessários. Nada mais longe da verdade. Todas as metodologias começam com algum tipo de lista de histórias. Estas histórias não nasceram do nada e não nasceram sem um trabalho de analise. A montagem de dita lista ocorre sempre pre-linarmente ao desenvolvimento, mesmo quando ela é alterada durante o desenvolvimento. Scrum, por exemplo, aconselha que se estabeleça um documento de visão e o Product Backlog antes de mais nada. Sendo que os passos seguintes são a estimativa do backlog e o planejamento e só depois a execução.
Espero que as pessoas parem de menosprezar o levantamento de requisitos e o levem a sério. Senão continuaremos a não acertar no que o cliente quer e a produzir software que será abandonado. Com Ágil, ou sem Ágil, o levantamento de requisitos tem que ser feito, e tem que ser bem feito.