Pré-Desenvolvimento: Como definir os requisitos técnicos para projetos de software

Introdução

Como dito no primeiro artigo que descreve o processo de metodologia e desenvolvimento da Olympus, criar um app é uma tarefa complexa. A primeira etapa de R&D nos traz mais clareza sobre o tópico no qual estamos nos inserindo e também traz uma visão mais palpável sobre como o produto vai ser, algumas funcionalidades básicas e elementos que são necessários para atingir o objetivo do produto.

A etapa que precede o início do desenvolvimento do projeto, é a criação do documento de requisitos técnicos. O objetivo desse documento é fazermos uma análise precoce das necessidades de tecnologia que esse projeto vai trazer, a fim de investigarmos a existência de Rabbit Holes e inconsistências que podem ter sido geradas durante a etapa de Shaping como, por exemplo, alguma definição de funcionalidade que não faça sentido ou esteja sendo abordada da maneira errada.

Estrutura do Documento

O documento de requisitos técnicos tem três principais objetivos que devem ser atingidos:

• Definir os requisitos de negócios da aplicação;
• Levantar dependências técnicas;
• Encontrar possíveis Rabbit Holes.

Requisitos de Negócios

O primeiro objetivo do documento é, a partir das funcionalidades idealizadas na etapa de R&D e materializadas em Wireframes no processo de Shaping, definir os requisitos de negócios que implicam nessas funcionalidades.

Os requisitos de negócios da aplicação buscam definir de forma mais concreta o escopo e necessidades das funcionalidades da aplicação. No projeto do Memo, por exemplo, que é uma aplicação Anki (sistema de memorização) mobile focada no tópico de programação, temos como algumas das funcionalidades:

• Listagem de decks;
• Execução de decks;
• Materiais de apoio associados aos decks;
• Progresso do usuário na execução dos decks.

Para essas funcionalidades, ilustradas nos Wireframes abaixo, definimos os requisitos de negócios da aplicação. Alguns exemplos dos requisitos elencados são:

Requisitos de Negócio em aberto:

• Como é calculado o nível de fixação de um deck?
• Quais estatísticas vamos mostrar ao finalizar o deck? Nos Wireframes, existem estatísticas relacionadas a acertos/erros, porém isso não faz sentido no universo Anki, onde não existe certo/errado.
• Nos Wireframes, existem estatísticas relacionadas a acertos/erros, porém isso não faz sentido no universo Anki, onde não existe certo/errado.
• Como os materiais de apoio são associados ao deck?
• Quais categorias de materiais de apoio teremos? (Ex: Video, Artigo, Livro, etc.)
• O usuário consegue navegar entre as perguntas?
• O usuário consegue alterar uma resposta já realizada?
• ....

Dependências Técnicas

A primeira definição técnica a ser feita é a respeito das plataformas onde essa aplicação vai ser executada. Queremos um app mobile? Desktop? Web? Onde essa aplicação vai ser executada? Após isso, quais tecnologias vão ser utilizadas para desenvolver na plataforma escolhida? Por exemplo, na área de aplicativos mobile temos as tecnologias nativas - Swift e Kotlin -, tecnologias híbridas - Flutter, Xamarin, React Native, Ionic, etc.. - ou até mesmo Web Apps.

Para a aplicação do Memo, fica claro a partir dos Wireframes que escolhemos mirar primeiro nas plataformas mobile - iOS & Android. E também, como vocês já puderam acompanhar pelos vídeos no canal do Lucas, escolhemos Flutter como o framework para desenvolver uma aplicação híbrida. Essa discussão sobre a escolha da plataforma e do framework do Flutter, merecem um artigo específico, por isso vamos publicar nas próximas semanas o artigo: Porque escolhemos o Flutter? Nesse artigo vamos abordar essas decisões em maiores detalhes.

Com a plataforma escolhida, a tecnologia a ser utilizada e os requisitos de negócios bem definidos, a próxima etapa visa entender quais dependências técnicas (bibliotecas, frameworks, comportamentos customizados, animações, etc.) o app possui. No exemplo do Memo, algumas dependências técnicas que podemos levantar são:

• Como serão armazenados os dados do usuário sobre a execução dos decks? É necessário criar uma persistência local? Quais são as bibliotecas nativas ou criadas por terceiros de persistência local que temos disponíveis?
• Qual será o formato do conteúdo dos decks? Eles precisam exibir imagens, vídeos, áudio e/ou outros conteúdos de mídia mais complexos? Se sim, qual formato suporta estes conteúdos de mídia? Ao optarmos por esse formato, o que isso implica na estrutura da aplicação? Será necessário lidar com WebViews e outros componentes de renderização mais complexos?

No caso do Memo, temos um contexto de uma aplicação um pouco mais simples, porém outros exemplos de dúvidas relacionadas às dependências técnicas que podem existir são:

• Quais as formas de autenticação a aplicação vai suportar? Será necessária integração com redes sociais? Se sim, quais?
• Existe a necessidade de integração com algum servidor? Se sim, como está estruturado esse servidor? É uma API Rest? Comunicação via WebSockets?
• A aplicação possui algum tipo de monetização (InApp ou Subscription)? Como será feita essa integração com a parte de vendas?

Vale ressaltar que o processo de análise das dependências técnicas, assim como a etapa de encontrar os Rabbit Holes, podem afetar o escopo e até mesmo gerar alterações nos Wireframes idealizados. A partir dessa análise mais técnica, é possível que a equipe chegue à conclusão de alterar alguma funcionalidade da aplicação devido à sua dificuldade, inviabilidade técnica ou escopo. Isso significa que as fases já realizadas de R&D e Wireframes podem ser revisitadas para aplicar alterações com base nas análises aqui realizadas. O processo até então se dá de forma iterativa. Não tem problema voltarmos para realizar ajustes na parte de R&D que havia previamente sido definida como finalizada. A ideia aqui é descobrir os problemas antes de entrarmos na etapa de desenvolvimento do projeto.

Rabbit Holes

Por fim, a última etapa consiste em encontrar os Rabbit Holes do projeto. Um Rabbit Hole é uma funcionalidade da aplicação que consideramos um ponto desconhecido, e que pode potencialmente levar muito tempo para ser executado, devido ao desconhecimento da implementação. Ela tem esse nome, pois segue a analogia da toca de um coelho, que vista da superfície parece um pequeno buraco, porém é muito maior da perspectiva de dentro da toca.

Um exemplo de provável Rabbit Hole no projeto do Memo, é o formato dos decks. O tipo de conteúdo deles impacta diretamente na complexidade com a qual eles precisam ser estruturados e mostrados. Por exemplo, caso os decks possuam somente textos e no máximo imagens, é possível utilizar um Markdown como estrutura dos decks e isso se torna muito mais fácil de traduzir para uma interface. Agora, se os decks possuírem vídeos, áudios ou ainda mais complexo, animações utilizando Javascript + CSS. Nesse cenário, precisaríamos lidar com um conteúdo em HTML, e isso envolve utilizarmos WebView para mostrar esse conteúdo, e então surgem cada vez mais perguntas:

• Como essas Webviews se comportam em diferentes plataformas?
• Como essas Webviews se adaptam aos mais diversos tamanhos de tela? Precisamos levar isso em conta no desenvolvimento do HTML do conteúdo do deck ou as Webviews conseguem redimensionar esse conteúdo de forma simples?
• Qual a complexidade (de processamento e dificuldade) de utilizarmos múltiplas Webviews (uma para cada pergunta/resposta) de forma simultânea durante a execução de uma deck?

Quanto mais perguntas sem resposta, mais incerteza essa funcionalidade traz para o escopo do desenvolvimento da aplicação. Por isso, essa é uma das etapas mais importantes e vem justamente antes de entrarmos no desenvolvimento da aplicação. É nessa etapa onde nós buscamos identificar os problemas antes de dar uma estimativa de prazo e custo para o cliente e, principalmente, antes deles acontecerem. O objetivo é minimizar (e se possível, anular) as surpresas ruins durante a etapa de desenvolvimento.

Para cada Rabbit Hole levantado, fazemos uma investigação levantando hipóteses e possibilidades sobre as possíveis soluções para aquele problema. Dependendo do contexto, nessa etapa pode ser desenvolvidas POC (Provas de Conceito) sobre possíveis soluções para o problema, isto é, tentamos criar a menor solução possível antes da etapa de desenvolvimento. Caso as investigações não tragam mais clareza, tampouco as POCs, deixamos a funcionalidade marcada como escopo aberto, tanto no quesito tempo quanto no quesito prazo, pois não foi possível identificar a sua complexidade.

Nível de Fixação

Um exemplo de Rabbit Hole que tivemos de destrinchar durante o desenvolvimento do documento de requisitos técnicos, foi o seguinte:

Como calculamos o nível de fixação de um deck?

A definição do nível de fixação tem potencial para se tornar uma funcionalidade muito complexa, visto que não existe uma definição concreta de como esse nível é calculado. Para responder essa pergunta, fomos atrás de referências sobre a hipótese da Curva de Esquecimento. A partir das análises de diferentes referências, idealizamos uma primeira fórmula para fazer esse cálculo:

Onde:

• F = Nível de Fixação
• t = Dias passados desde a última execução do deck
• S = Estabilidade da Memória
• R = Número de repetições do deck
• K = Constante de decaimento

Após idearmos essa fórmula, criamos uma POC utilizando um script escrito em Dart para aplicar essa fórmula e analisar os resultados. Geramos diversos gráficos para analisar de forma visual o comportamento da fórmula. Alguns destes gráficos são:

Todo o processo de ideação e análise dessa fórmula está descrito em detalhes no documento de requisitos técnicos.

Conclusão & Próximos Passos

Ao final de todo o processo, é gerado o documento de requisitos técnicos do projeto. O documento permeia todos os tópicos abordados nas seções acima e serve como um guia dos desenvolvedores na hora do processo de desenvolvimento do projeto.

Esse documento finaliza a etapa de pré-desenvolvimento. Isso significa que agora é hora de começar a etapa de desenvolvimento, começando pela estrutura da aplicação, priorização de funcionalidades e, finalmente, botar as mãos no código.

Tem alguma dúvida?

Caso tenha alguma pergunta, feedback ou proposta envie um e-mail para hi@olmps.co.