Requisitos-de-software

O que são requisitos de software, e como facilitam o planejamento do seu projeto de computação.

Você já teve uma ideia de algum software que pudesse melhorar o trabalho e os resultados da sua empresa, mas não sabia como começar a desenvolver esse tipo de solução?

Neste artigo, você vai aprender como o engenheiro pensa nos requisitos de software quando vai iniciar um projeto de desenvolvimento de um sistema. 

A primeira fase do desenvolvimento de qualquer software é a Análise de Requisitos. Nesta fase, o analista se reúne com os clientes e outros stakeholders (pessoas envolvidas no projeto e/ou com o produto final), com o objetivo simples de colher informações que não puderam ser precisamente definidas através do escopo do projeto.

Para explicar de uma maneira lúdica, podemos fazer uma analogia a uma situação corriqueira de nossas vidas como, por exemplo, quando estamos planejando uma viagem de férias.

Buscando a melhor experiência possível, todos nós, no mínimo, pensamos no que não pode faltar nessa viagem. Quais os lugares que eu vou visitar? O que vou comer de diferente? Com quem eu devo me encontrar?

Desta forma nós estabelecemos os Requisitos: o que necessariamente deve ter nesta viagem.

Voltando à nossa situação de Análise de Requisitos de software, podemos pensar nos seguintes requisitos:

O sistema deve permitir o cadastro de funcionários

O sistema deve permitir o login dos funcionários cadastrados

O sistema deve permitir o cadastro de novos produtos

O sistema deve permitir a alteração das informações dos produtos cadastrados

Mas qual o objetivo da Análise de Requisitos?

Existem algumas Boas Práticas no Desenvolvimento de Software que devem ser levadas em consideração em qualquer projeto, mas mais do que uma “Boa Prática”, o bom mapeamento de requisitos de software é essencial para o decorrer do projeto e a solução final.

Em um estudo realizado pelo Standish Group (1995) com 350 empresas americanas e cerca de 8000 projetos: (PFLEEGER, 2004)

– 31% dos projetos foram cancelados sem serem completados;

– Em pequenas companhias, somente 16% dos projetos foram entregues no prazo e no orçamento inicialmente estabelecidos;

– Em grandes companhias, apenas 9% atenderam esses critérios.

E quais foram as causas desses problemas?

requisito-de-software3

(Fonte: “Requisitos de Software”, professor Guilherme H. Travassos, Breno França, Luciana Nascimento e Talita V. Riveiro. COPPE UFRJ, 2016/2)


A Análise de Requisitos é tão importante que é costume assinar um documento contendo todos os requisitos do software para a proteção jurídica do contratante e da empresa desenvolvedora.

Então, afinal, o que é o DEP?

Um documento que podemos usar para fazer esse acordo de alinhamento de expectativas entre o cliente e a empresa contratada é o DEP (Documento de Especificação do Projeto). Como já foi dito anteriormente, o DEP tem o objetivo de alinhar as expectativas do cliente e da empresa que está desenvolvendo o software.

A base do DEP é a especificação dos requisitos de software, como podemos ver no exemplo de requisito que usamos no desenvolvimento de um Banco de Dados para um restaurante:

 

requisito-de-software1


Mas uma das vantagens deste documento é que ele também descreve alguns Casos de Uso, que, resumidamente, são o fluxo de acontecimentos no software. Podemos ver um exemplo na figura acima, onde está escrito:

Ao clicar no botão “ENTRAR”, após preencher corretamente os dados, o usuário será transferido para a tela da Aba Inicial (RF_2).

Esse nível de detalhamento descreve um fluxo de acontecimentos no software. Se o usuário preencher os campos e clicar em “ENTRAR”, uma nova tela será aberta, fazendo referência a outro requisito “(RF 2)”, por definição isso não pode ser considerado um requisito do sistema, mas sim um Caso de Uso.

requisito-de-software2

Vantagens e desvantagens da definição de requisitos de software

Uma desvantagem de se utilizar esta forma de desenvolvimento, detalhando a fundo o que será feito no sistema, é que a flexibilidade no decorrer do projeto é bastante reduzida, pois foram estabelecidas “regras” que não podem ser quebradas sem assinar um novo Documento de Especificação de Projeto.

Muitas vezes as empresas desenvolvedoras tentam “blindar” os requisitos, deixando-os muito rígidos, para não haver nenhum tipo de desentendimento que possa ocasionar um desconforto com o cliente. Isso pode deixar o processo de alteração difícil, causando o efeito inverso. É importante que todos os envolvidos no projeto busquem harmonizar seus interesses em prol do sucesso dele.

Por outro lado, um grande benefício dessa metodologia é o controle de tempo de projeto. Como não há alterações nos requisitos de software, o tempo de desenvolvimento do sistema como um todo pode ser estimado com mais exatidão.

Na Fluxo nós utilizamos essa documentação para soluções de Banco de Dados, uma vez que, nestes casos, as expectativas do cliente em relação ao software tendem a ser bem claras e pouco voláteis, já que a busca dele, normalmente, é por uma otimização de processos específica. Assim, o problema de não poder alterar o que está escrito no DEP muitas vezes não existe, já que o cliente tende a não mudar o que ele deseja do projeto. Um outro tipo de estrutura para gerenciamento de projetos de computação é a Metodologia SCRUM, também muito utilizada na Fluxo em desenvolvimentos de aplicativo.

Gostou deste artigo? Continue acompanhando nossos artigos de automação e gestão da informação para saber mais sobre desenvolvimento de softwares ou entre em contato com um de nossos consultores!

Allan Chyaromont

Graduando em Engenharia Eletrônica, trabalhou na Fluxo Consultoria como Gerente de Projetos e Assessor da Diretoria de Projetos. Gerenciou projeto de Banco de Dados.

This Post Has One Comment

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *