#3 Requisitos e Agilidade

Que passos seguir no planejamento de um sistema? E que técnicas utilizar? Nessa postagem trago um pouquinho sobre Requisitos de Sistemas, Histórias de usuários, a técnica MoSCoW, e Metodologias ágeis.

Ao criar um projeto de software é preciso levantar Requisitos do Sistema, que são as características e funções que o sistema deve ter. Essa é a fase inicial, uma comunicação da equipe com o cliente, e ela pode gerar problemas já que não é tão simples entender o que o cliente quer, e ter certeza que tudo que ele pede é necessário.
É possível organizar os Requisitos de Sistemas por meio das Histórias de usuários, que são descrições simples do ponto de vista do usuário. As Histórias capturam o "quem", "o quê", e "por quê" de um requisito de sistema. Devem ser curtas, simples, e claras. E podem ser transmitidas por meio de pequenos cartões, em uma conversa, ou por meio de uma confirmação mais formal. É um desejo de algo que o cliente quer no sistema, ou um problema que o usuário quer que seja solucionado.

Devem seguir o modelo: "Como um [tipo de usuário] eu quero [ação] para [objetivo]."

Um usuário da netflix, por exemplo, pode ter dito: "Como usuário da netflix, quero ter acesso offline ao conteúdo para assistir quando eu estiver sem internet". E dessa forma a netflix buscou trazer esse atributo ao sistema.

As Histórias de usuários geralmente são discussões sobre o pedido, já os Requisitos de Sistemas são registrados e mais detalhados.

Depois de ter realizado o levantamento de requisitos é necessário analisá-los e utilizar um bom método de priorização para categorizar-los. Porém classificar com prioridades tradicionais como "1, 2, e 3" ou "Alta, Média, e Baixa" fica muito vago, elas não são formas muito específicas e acabam não ajudando tanto. Um método de priorização mais detalhado é a técnica MoSCoW, seu nome é a junção das 4 categorias:

• (M) Must have: deve ter. Aqueles requisitos indispensáveis para o sistema, muito importante.
• (S) Should have: deveria ter. Tudo que é importante mas não indispensável.
• (C) Could have: poderia ter. Aquilo que é desejável mas não necessário.
• (W) Won't have for now: não terá por enquanto. Requisitos que podem ser inseridos depois, mais ou menos um extra pro sistema.

Sistemas geram custo, então tudo que tiver maior prioridade é realizado primeiro, e requisitos classificados como "Won't" podem ser deixados de lado, e feitas como atualizações para depois. Por exemplo, o modo offline da netflix é classificado como "Won't".

Após definir e priorizar os requisitos é preciso escolher uma forma de desenvolver o sistema. Uma forma é a de Metodologias Ágeis, que são um conjunto de métodos que enfatizam a comunicação em tempo real. A interação com o cliente e a sua colaboração é fundamental, pois isso gera um feedback contínuo. E o sistema precisa ser adaptável para responder a mudanças facilmente, já que prioridades podem mudar. Além de focar no planejamento e testes.

Enquanto metodologias tradicionais trazem um planejamento rígido e com pouca flexibilidade, as metodologias ágeis permitem maior liberdade no planejamento do projeto, com mais flexibilidade e participação ativa do cliente. Por mais que a tradicional realize o projeto completo de forma mais rápida, a ágil tem muito mais etapas com feedback para garantir um sistema que atende as necessidades dos usuários.