Como é que implementamos a análise de requisitos?

Como é o processo de planeamento?

A análise de requisitos está incluída no processo de planeamento, que, por sua vez, deve ser o seguinte

1. A projeto que descreve a visão final produto a ser criado.
2. Um plano de ação geral ou uma ideia que define o que é necessário fazer para atingir os nossos objectivos.
3. Lista de tarefas básicas que determinam as fases de trabalho do projeto.
4. Planeamento do tempo, no qual definimos o que e quando deve ser entregue.
5. Planeamento pormenorizado das tarefas individuais criadas durante a terceira fase.

A análise das necessidades abrange os três primeiros pontos do processo de planeamento.

Visão do projeto

Nesta fase, devemos colocar-nos algumas questões básicas:

1. O que é que queremos fazer?

É certo que, nesta altura, já temos consciência do que pretendemos alcançar e a ideia do projeto já foi apresentada e pensada há muito tempo, mas vale a pena refletir mais profundamente. Talvez descubramos novas questões que valha a pena explicar. As seguintes questões podem ser úteis neste contexto:

• Que problema deve este projeto resolver?
• Quem será o seu utilizador final?
• Estamos a criar uma interface para os utilizadores? Está prevista a sua criação no futuro? Foi determinado o tipo de interface que vamos criar (desktop ou móvel)? Preocupamo-nos com o RWD?
• Existem aplicações semelhantes? Quais são os seus prós e contras?
• Já foram criados alguns desenhos ou maquetas iniciais sobre o projeto?
• O projeto dependerá de aplicações externas? Estas têm ou conhecemos as suas limitações?
• Sabemos alguma coisa sobre o desempenho esperado e o nível de segurança?

2. Quais são os requisitos?

Agora, chegou o momento de estabelecer uma lista de requisitos para o projeto. Para além dos requisitos funcionais, especificamos os que não estão relacionados com as funcionalidades: usabilidade, capacidade de resposta, velocidade, desempenho e segurança.

Deixar nós verificar se cada um dos requisitos preenche os seguintes critérios:

• está completo - temos a sua imagem completa,
• é correto - verdadeiro e esperado,
• é exequível - exequível e outros requisitos não o invalidam,
• é necessário - é necessário para o funcionamento do sistema ou é exigido pelo cliente,
• não seja ambíguo - legível e impossível de interpretar incorretamente,
• é verificável - após a implementação, através de observação e testes, é possível determinar se este requisito foi ou não cumprido.

3. Qual é o objetivo final?

Vale a pena criar aqui uma visualização simples do funcionamento do projeto. Nada ajuda a compreender melhor a ideia do projeto do que desenhar um fluxo básico ou simplesmente escrever no quadro, por pontos, o que vai acontecer sucessivamente. No caso de uma aplicação com uma interface de utilizador, o ideal é ter mesmo as maquetes mais simples.

4. Quais são as prioridades?

Tal como quando se constrói uma casa, os projectos de TI devem começar do zero no início e, em seguida, voltar-se para o que é mais necessário. Por conseguinte, no início, com base na lista de requisitos, é necessário especificar uma lista de todas as funções possíveis que um determinado projeto irá realizar e, em seguida, chegar a acordo sobre quais delas têm a prioridade mais elevada e devem ser realizadas o mais rapidamente possível e quais são do tipo "agradável de ter".

O resultado de toda a fase de visualização do projeto deve ser uma imagem geral de como o projeto deve funcionar, seja através de maquetes ou do fluxo de actividades desenhado. Também devemos receber uma lista de todas as funções possíveis que um determinado projeto deve cumprir e também saber qual a prioridade de cada uma delas.

A visualização do projeto é um momento-chave durante a análise dos requisitos. Ajuda a compreender em profundidade a essência do problema, e quanto melhores forem os materiais que ilustram o problema, mais eficientes serão as fases seguintes do planeamento.

Plano de ação

Nesta fase, já determinamos como imaginamos o funcionamento do projeto como um todo. É bom ter algumas ideias para a implementação, pensar e discutir cada uma delas, e destacar os seus pontos fracos e fortes. Também vale a pena desenhar aqui em pormenor uma ideia escolhida, se não todas.

Esta fase é também o momento de considerar questões puramente tecnológicas, não só em que língua ou estrutura será escrito o projeto, mas também de que ferramentas adicionais necessitaremos, por exemplo, se decidimos utilizar o AWS ou talvez outra coisa qualquer. Se estivermos a hesitar entre algumas tecnologias ou não tivermos ideia do que utilizar, vale a pena deslocar essa decisão no tempo e delegá-la numa tarefa de investigação. É claro que só podemos fazer isto se o planeamento posterior não for bloqueado por essa investigação. Caso contrário, podemos anexá-las com segurança às tarefas do correr.

Principais tarefas

Uma vez estabelecido o plano do projeto, procede-se à definição das tarefas principais, que serão depois discutidas em pormenor e divididas em tarefas mais pequenas pelos equipa de desenvolvimento ao planear um novo sprint. É importante descrever cada tarefa com a maior exatidão possível.

Resumo

Como já foi referido, o processo de análise de requisitos varia em função da complexidade do projeto. Há problemas mais fáceis e mais difíceis, e há também aqueles que já foram resolvidos por alguém e outros completamente novos que precisam de ser resolvidos durante mais tempo. Independentemente disso, há algumas dicas importantes a ter em conta:

• Comunicação. Esta é a componente mais importante de cada ciclo de vida do projeto; tudo deve ser claramente definido e explicado.
• Compreender rapidamente o problema. É ótimo ter a documentação do projeto escrita, mas lembremo-nos de que deve ser tão concisa quanto possível e não ocupar mil páginas. Cada membro da equipa de desenvolvimento equipa devem ter acesso a ele e devem ser capazes de compreender rapidamente a visão do projeto.
• A simplicidade acima de tudo. Tentemos simplificar o mais possível o que planeamos, escolher soluções mais simples que possam ser facilmente desenvolvidas no futuro ou renunciar a elas quando for necessário.
• Não vai precisar dele. Tendo em conta que na programação nos guiamos pelo princípio YAGNI, aqui, temo-lo na parte de trás da cabeça e não aceleramos demasiado.
• Mudanças. Não tenhamos medo delas; mais cedo ou mais tarde, todos os projectos precisam delas. Além disso, não tenhamos a ilusão de que o que planeamos hoje funcionará para sempre. Ao mesmo tempo, não devemos tratar as mudanças como algo mau e indesejável. As mudanças devem ser sinónimo de melhoria, e é isso que queremos: que o projeto seja o melhor.
• O tempo. Não deixemos que o planeamento demore demasiado tempo e se arraste para sempre. Se temos um problema que nos bloqueia, então procuremos soluções no exterior ou escolhamos a opção mais fácil.

Vale sempre a pena recordar os aspectos acima referidos ao analisar os requisitos, para que tudo corra bem e seja a base de um projeto bem planeado.

Ler mais:

• Qual é a melhor abordagem de gestão de projectos para o desenvolvimento de software?
• As boas práticas da Codest para a construção de software. A nossa abordagem ao percurso do cliente
• Um guia rápido para criar e desenvolver o seu próprio mercado. O que vale a pena saber?