Capítulo 2: Aplicação OCI PIZZA

2.2 Da Necessidade à Definição dos Requisitos

2.2.1 Contado do Cliente

Imagine que você é uma empresa ou uma agência de desenvolvimento de software que acaba de receber uma ligação de um potencial cliente, ansioso para discutir suas necessidades e como você pode ajudá-lo a transformar suas ideias em soluções digitais eficazes.

O diálogo a seguir ilustra a interação entre Você, o desenvolvedor, e seu cliente, Fulano:

2.2.2 Engenharia de Requisitos

Com base neste primeiro contato, podemos iniciar a elaboração de uma descrição das funcionalidades do sistema, alinhadas às necessidades do cliente.

Definir "o que um sistema deve fazer", ou seja, suas funcionalidades, refere-se ao que chamamos de Requisitos Funcionais ou Requisitos do Usuário.

Além dos requisitos funcionais, há uma outra categoria de requisitos chamada Requisitos Não-Funcionais ou Requisitos de Sistema. Esses requisitos tratam de aspectos como desempenho, usabilidade, segurança e escalabilidade, entre outros, e são especificados de maneira quantitativa, utilizando métricas para garantir sua mensuração e avaliação.

A definição e a especificação dos requisitos são etapas fundamentais no processo de desenvolvimento de software, abrangendo desde a identificação dos requisitos até os processos relacionados às metodologias de desenvolvimento, documentação e entrega. Nesse contexto, duas abordagens principais se destacam:

• Processos Waterfall (Modelo em cascata)

  • Primeiro a ser proposto e inspirado nos processos das engenharias tradicionais.
  • Esse modelo coleta todas as informações necessárias para o desenvolvimento no início do projeto. Após a elaboração de uma documentação detalhada, o desenvolvimento inicia-se e avança de forma linear e sequencial, seguindo etapas que se sucedem em cascata, sem realizar interações ou coletar feedback do cliente ao longo do processo.

• Práticas Ágeis

  • Modo alternativo ao Waterfall para o desenvolvimento de software que prioriza a construção incremental de sistemas, mantendo uma interação contínua com o cliente.
  • Práticas ágeis focam na coleta constante de feedback, possibilitando entregas regulares e frequentes de pequenas funcionalidades.

Processos no estilo Waterfall exigem um levantamento detalhado dos requisitos, seguido pela elaboração de uma documentação completa antes da implementação do que foi especificado. O sistema é disponibilizado ao cliente para validação somente após a conclusão de todo o desenvolvimento.

O principal problema do modelo Waterfall é que a documentação se torna um requisito obrigatório, muitas vezes mais valorizado do que o próprio software. A espera pela conclusão de toda a documentação antes de iniciar o desenvolvimento pode resultar em um produto que não atende mais às necessidades do cliente, que podem ter mudado desde o início do projeto.

Em fevereiro de 2001, na cidade de Snowbird, no estado de Utah, nos Estados Unidos, um grupo de dezessete Engenheiros de Software propôs um modo alternativo para construção de software, que prioriza a proximidade com o cliente e não documentações extensas antes de todo o desenvolvimento, promovendo interações curtas e constantes ao longo do processo de desenvolvimento. Essa nova forma de trabalho resultou no que é conhecido como "Manifesto do Desenvolvimento Ágil de Software", que prioriza certos princípios e valores em relação a outros, conforme destacados na imagem abaixo:

De certa forma, "Práticas Ágeis" ou "ser ágil" estão mais relacionadas a um estilo de "fazer acontecer" do que à implementação de ferramentas, processos ou qualquer forma de controle. A agilidade está mais relacionada às ações necessárias para alcançar um objetivo acordado, com expectativas alinhadas, especialmente em situações onde não há clareza sobre como atingi-lo. Esse processo, de certa forma, segue um ciclo que se repete da seguinte maneira:

1. Avançar um passo de cada vez.
2. Avaliar os resultados de cada passo.
3. Ajustar o caminho caso os resultados não estejam de acordo com o esperado.
4. Repetir o ciclo.

Além disso, as "Práticas Ágeis" introduziram novas abordagens para a criação de software, incluindo o desenvolvimento guiado por testes (test-driven development), que consiste em escrever os testes antes do código, e a integração contínua (continuous integration), que recomenda que os desenvolvedores integrem o código produzido o quanto antes no repositório principal do projeto, se possível todo dia.

Para o desenvolvimento da aplicação OCI PIZZA, serão adotadas as "Práticas Ágeis". Na definição dos requisitos dentro dessa abordagem, utiliza-se a linguagem natural, empregando o que chamamos de Histórias de Usuários (User Stories), que será explorado a seguir.

Histórias de Usuários

Após o diálogo com o cliente, identificou-se a necessidade de desenvolver uma aplicação web que apresente a pizzaria e inclua seções para o cardápio e cadastro de usuários para realizar pedidos de pizza.

Com base na necessidade apresentada, é possível especificar de forma simples as Histórias de Usuários a seguir:

• Cadastro de Usuário

  • Como um novo cliente, eu quero me cadastrar na aplicação, para que eu possa fazer pedidos de pizzas.

• Cardápio de Pizzas

  • Como um cliente, eu quero navegar pelo cardápio de pizzas, para que eu possa ver as opções disponíveis e escolher a que mais gosto.

• Filtros de Pesquisa

  • Como um cliente, eu quero filtrar as pizzas por categoria (como vegetarianas ou especiais), para que eu possa encontrar rapidamente o que estou procurando.

• Adicionar ao Carrinho

  • Como um cliente, eu quero adicionar pizzas e bebidas ao meu carrinho, para que eu possa revisar antes de finalizar o meu pedido.

• Realizar Pedido

  • Como cliente, desejo fazer o pedido da pizza informando um endereço para a entrega.

• Painel Administrativo

  • Como um funcionário da pizzaria, eu quero que o sistema me permita visualizar e gerenciar os pedidos em andamento, além de gerar relatórios sobre vendas e o desempenho geral da pizzaria

• Suporte ao Cliente

  • Como um cliente, eu quero ter acesso a um chat de suporte, para que eu possa esclarecer dúvidas, obter informações sobre o status do meu pedido e resolver quaisquer problemas relacionados à minha experiência de compra.

É importante mencionar que, no caso desta aplicação, os requisitos são simples. Documentar os requisitos de uma aplicação maior, com mais funcionalidades a serem desenvolvidas, não é uma tarefa fácil, pois é impossível prever todos os aspectos do sistema desde o início.