O Big bang de todo Software — A Engenharia de Requisitos

Tudo na vida possui um início, um ponto de partida, um momento onde as coisas começam a acontecer. No mundo dos softwares isto não é diferente. Muitas pessoas podem afirmar que um sistema tem seu início quando a primeira faísca de ideia acende na cabeça do seu criador. De fato, não podemos contrariar isto, porém, do ponto de vista operacional, ou o famoso “Mão na massa”, o ciclo de vida de um software é concebido a partir do processo de Engenharia de Requisitos. Se você está aqui, provavelmente é porque deseja entender melhor como funciona esta área do desenvolvimento de Software, de uma forma descomplicada e simples. Então pegue seu caderno, estoure sua pipoca e se prepare para uma boa leitura.

Um pouquinho de história não mata ninguém, certo?

A Engenharia de Software é uma área que foi criada em 1968, com objetivo de contornar a crise do Software, buscando trazer um processo mais sistemático, controlado e de qualidade mensurável para o desenvolvimento de software. Isso se fez necessário, pois a demanda por sistemas computacionais aumentava na época, porém a qualidade dos projetos não satisfazia os clientes.

Mas Alan, o post é sobre Engenharia de Requisitos, porque você está falando sobre Engenharia de Software?

Calma jovem padawan, o que eu quero que você entenda, é que processos para o desenvolvimento de software já foram criados devido a problemas que JÁ ocorreram e que, infelizmente, ainda ocorrem em muitas empresas (cabe a nós profissionais melhorar isto). Um destes processos, e me arrisco a dizer, o mais importante, é a Engenharia de Requisitos.

Vamos tratar disso logo

Vamos lá, sem termos complicados ou coisa do tipo. A engenharia de Requisitos é o processo do desenvolvimento de software responsável por gerenciar as vontades e expectativas dos clientes em torno de um projeto de software. Estas sensações surgem como requisitos, que devem ser extraídos dos clientes, modelados, analisados e se fizerem sentido (ou o cliente insistir), anexados ao escopo do sistema. O resultado final desse processo é um documento de requisitos.

Ótimo, nível 1 concluído! Agora você já não é um completo leigo na Engenharia de Requisitos (pelo menos eu espero). Caso queira se aprofundar, pegue um pouco mais de pipoca e continue comigo.

Entendendo os processos da ER (Engenharia de Requisitos)

Você já sabe o que é a ER e de onde ela veio, mas se quer se tornar um profissional da área (Ou apenas realizar um trabalho de faculdade), precisa saber por onde começar, certo? Então vamos estilo Jack, o estripador, por partes.

• Elicitação de requisitos

Esta é a fase de comunicação e contato com o cliente, a fim de coletar fatos, informações e acima de tudo, entender o que o cliente deseja em seu sistema. E não se engane se acha que em uma reunião tudo ficará claro como a água cristalina das montanhas do Himalaia, os clientes são muito voláteis, e muitas vezes, os requisitos mudam entre diferentes conversas, cabe ao responsável pela elicitação, gerenciar essas mudanças entre um encontro e outro.

Existem diferentes técnicas que ajudam no processo de elicitação de requisitos, escreverei sobre elas em outro artigo, porém, segue algumas para atiçar a sua curiosidade.

• Entrevistas;
• Prototipagem;
• Levantamento orientado a ponto de vista;
• Etnografia;
• Workshops.
• Análise dos requisitos elicitados

Bom, você já tem os requisitos e teoricamente já sabe o que o cliente quer. Ótimo, agora precisa pensar se aquilo realmente faz sentido no contexto em que o seu cliente está inserido, analisar se aquilo que ele está pedindo é possível dentro dos parâmetros estabelecidos, e se não existem requisitos conflitantes. Afinal, é impossível fazer um foguete que vá para a lua, sem que ele saia do chão, certo? Então, muitas vezes seus clientes vão pedir que faça isto. Cabe a equipe analisar e mostrar a ele pontos cegos e guia-lo da forma correta.

A análise de requisitos envolve três principais partes, assim como acima, irei tratar delas em um próximo artigo, mesmo assim, não ousaria deixar vocês sem um pitada de quais são.

• Identificação de partes
• Validação
• Verificação
• Modelagem dos requisitos

Chegamos até aqui, você já elicitou, validou os requisitos e agora precisa pensar em como eles vão se encaixar em um contexto de desenvolvimento. Deve-se levar em conta alguns questionamentos como:

• O que é necessário para que aquele requisito seja implementado a nível de código?
• Como estes requisitos serão distribuídos para a equipe que irá desenvolver?
• São requisitos funcionais ou não funcionais?

Estas são apenas algumas perguntas (existem outras) que devem ser respondidas para modelar os requisitos e fazer com que seu projeto seja bem estruturado.

Por fim, não galera, eu não esqueci da modelagem de requisitos, também farei um artigo mais direcionado para esta fase, por enquanto, acredito que já foi bastante informação por hoje. Espero que a leitura tenha valido a pena e possa ter esclarecido um pouco da ER. Acreditem, a elicitação de requisitos não é algo fácil, lidar e se comunicar com pessoas é sempre um desafio. Porém, uma boa elicitação de requisitos é meio caminho andado para o sucesso do seu projeto. Se sua empresa ainda não se atenta a estes métodos, considere ser o Cristóvão Colombo de onde trabalha e seja o primeiro. Acredito que tanto vocês quanto a organização só terão a ganhar.