Muitas vezes, os softwares não são desenvolvidos, internamente, na empresa, sendo necessário que um terceiro realize esse desenvolvimento. O objetivo desta lição é te fornecer conhecimentos suficientes para que você saiba quais procedimentos devem ser executados por um técnico em desenvolvimento de sistemas durante a requisição de um novo software à organização.

Devemos conhecer as formas como uma requisição de software chega até o setor de Tecnologia da Informação e como os profissionais desse setor tratarão tal requisição, visto que elas podem vir dos mais diferentes setores da organização. Assim, estabelecer critérios para determinar qual ou quais requisições serão atendidas primeiro é muito importante ao gerenciamento adequado do processo de requisição de softwares. 

Portanto, nesta lição, discutiremos procedimentos e documentações para que a requisição de um software seja, adequadamente, atendida pelo profissional técnico em desenvolvimento de sistemas.

Todas as organizações possuem limitações com relação ao quantitativo de pessoas em determinados setores bem como recursos financeiros para contratação de novos funcionários ou aquisição de novos produtos. Assim, a demanda da organização por um novo software deve ser avaliada quanto à possibilidade de esse software ser desenvolvido, internamente, pela própria equipe de desenvolvimento da empresa, caso ela exista; deve ser avaliado se ele poderia ser desenvolvido por outra empresa, especialmente contratada para isso, ou se o software seria adquirido no mercado, ou seja, um programa já pronto e que poderia ser comprado.

Conforme estamos estudando, independentemente da abordagem que se decida seguir, é fundamental saber um detalhe muito importante. Você se lembra o que seria? Se pensou em “quais são os requisitos do novo software”, ou seja, “o que, exatamente, esse novo software deve fazer”, você está com o pensamento correto. O alinhamento dessa demanda por um novo programa com o que já existe na empresa, em termos de recursos de hardware e outros softwares, também é importante. Deve-se ter a clara noção das implicações que o desenvolvimento ou a aquisição de um novo software terá para a organização. 

Imagine, por exemplo, que uma organização peça um novo software para fazer o controle de entrada e saída dos pedidos. Após dias de uso, o gerente lembra que o dono do estabelecimento queria saber quanto tempo levava entre a entrada e a saída do pedido, mas ele esqueceu de falar sobre esse detalhe ao desenvolvedor, e o software não foi feito de forma que esse tempo fosse calculado, automaticamente. O que poderia ser feito, neste caso? 

É muito comum organizações adquirirem um novo software que não atende à necessidade porque elas não sabiam, com antecedência, o que desejavam. Esse tipo de erro pode levar ao comprometimento de recursos financeiros importantes para a empresa, especialmente, se for uma organização de pequeno ou médio porte.

Para evitar situações como as mencionadas, o técnico em desenvolvimento de sistemas deve ser capaz de desenvolver um documento que apresente todos os requisitos demandados pela organização a um novo software. A ideia é desenvolver ou adquirir um software que atenda 100% das demandas da organização. 

Imagine que você é o(a) técnico(a) em desenvolvimento de sistemas de uma organização e recebeu três requisições de desenvolvimento de um software/funcionalidades. A primeira requisição é automatizar determinado processo do setor de vendas, a segunda requisição é automatizar a publicação de conteúdos na página web da organização pelo setor de marketing e a terceira é desenvolver um sistema de Business Intelligence (Inteligência de Negócios) para os gerentes de nível estratégico.

Devido ao reduzido número de funcionários no setor de Tecnologia da Informação, a primeira decisão é definir qual requisição será atendida primeiro. Normalmente, os softwares ou funcionalidades associadas à estratégia da organização terão prioridade. No caso citado, o sistema Inteligência de Negócios terá prioridade sobre os demais devido à sua associação ao nível estratégico.

Definida a prioridade, é o momento de definir se o sistema ou funcionalidade será desenvolvido pela própria equipe da empresa ou se será adquirido no mercado. Nesse momento, pode-se observar que, devido à amplitude do sistema que está sendo solicitado, para adquirir o software no mercado, deve-se a considerar o número de funcionários do setor de TI e, até mesmo, o conhecimento desses profissionais. Contudo, para que seja possível convidar as empresas a apresentarem os seus sistemas e verificar se os sistemas do mercado atendem à necessidade da organização, precisamos desenvolver uma Especificação de Requisitos de Software (ERS). 

A ERS deve apresentar, de forma clara e objetiva, quais são os requisitos do sistema que a organização deseja adquirir, com o intuito de que as empresas vendedoras software possam avaliar a adequação dos seus produtos a essa demanda. Uma ERS de software bem-feita pode levar a organização a adquirir um produto adequado à necessidade dela.

Após criar a ERS, você deve enviar esse documento para os fornecedores de software associados ao objetivo do sistema (ex.: Inteligência de Negócios). O envio do documento deve ser na forma de um convite, para que as empresas avaliem a ERS em relação ao produto que elas ofertam. Caso as empresas considerem que o seu produto atende aos requisitos da ERS, elas te enviam uma proposta comercial. Como responsável pelo recebimento das propostas, você precisa definir critérios para que as propostas sejam analisadas. Por exemplo, você pode definir, junto com a equipe envolvida nesse projeto, um valor comercial base que será considerado (ex.: propostas até R$ 200.000,00 serão avaliadas e, acima disso, desconsideradas). Outro critério a ser adotado é considerar, apenas, as propostas que atendam 100% dos requisitos estabelecidos na ERS. Faço essa observação porque é muito comum surgirem empresas que tentaram vender produtos os quais não atendem 100% do que foi especificado na ERS.

Feita a seleção das propostas, você solicita uma apresentação formal do sistema a cada uma das empresas que tiveram as suas propostas pré-aprovadas. Também é uma boa prática visitar outras empresas que já possuem a solução (software) instalado e em funcionamento por um bom tempo (ex.: mais de um ano). O momento de conhecer os softwares do mercado é fundamental para tomar a melhor decisão e, assim, o produto mais adequado seja adquirido à organização. 

Atente-se ao fato de que não necessariamente a solução mais usada no mercado será a melhor solução à sua organização (ex.: no caso de sistemas de Inteligência de Negócios, é muito usado o Power BI da Microsoft). Cada caso é um caso e deve ser analisado conforme o seu documento de ERS.

Compreender os motivos que podem levar a organização a desenvolver um software são importantes para o conhecimento do técnico em desenvolvimento de sistemas. O profissional técnico precisa perceber as necessidades da organização não só em relação a aspectos internos, mas também em relação a aspectos externos, como: mudanças legais (ex.: alterações na legislação), concorrência (ex.: novos concorrentes que fazem uso mais intenso de tecnologia) ou mudanças tecnológicas (ex.: uso mais amplo de Inteligência Artificial em sistemas corporativos). 

Muitas vezes, o técnico em desenvolvimento de sistemas atua como um profissional que sugere mudanças na organização por meio de novas funcionalidades ou softwares. Este tipo de atuação do profissional é mais comum em pequenas organizações onde o setor de Tecnologia da Informação é bastante próximo ao dono/proprietário da empresa.

Independentemente da origem da solicitação, o processo de atendimento a demandas pode ser apresentada de várias maneiras, tais como: (I) Requisição de proposta (Request for Proposal – RFP) ou Especificação de Requisitos de Software (ERS); (II) solicitação originada da área operacional, de negócios ou de setores estratégicos da organização; (III) avaliação de viabilidade (envolve tanto viabilidade técnica quanto orçamentária e de recursos humanos da organização). A RFP/ERS é um dos principais documentos à especificação dos requisitos de um software e, geralmente, é obrigatória quando o objetivo é adquirir um software no mercado. Discutiremos o desenvolvimento desse documento mais à frente.

Uma realidade bastante comum nas organizações é decidir ou comprar um software no mercado ou o desenvolver, internamente, com a equipe existente. Assim, uma pergunta deve ser do conhecimento do técnico em desenvolvimento de sistemas: como proceder quando a empresa decide contratar outra organização para o desenvolvimento de um sistema? A resposta a essa pergunta pode ser de duas formas, a saber: (I) elaborar uma Especificação de Requisitos de Software (ERS) ou (II) Declaração de trabalho.

A ERS é um documento mais amplo, se comparado com a Declaração de Trabalho, e tende a ser aplicada quando se busca, no mercado, softwares maiores, geralmente, do tipo ERP (Enterprise Resource Planning). A Declaração de Trabalho é utilizada para softwares menores ou quando o software a ser desenvolvido, internamente, possui poucas funcionalidades (requisitos funcionais) (KOTONYA, 1998). De qualquer forma, ambos os documentos possuem estruturas semelhantes, alterando, apenas, a abrangência de cada um em termos de requisitos do software.

A ideia central, ao desenvolver um documento como os mencionados, é fornecer às empresas do mercado condições para que elas elaborem uma proposta comercial (ENGHOLM, 2010). As empresas do mercado só conseguirão passar um orçamento (proposta comercial) caso saibam, exatamente, o que a organização contratante deseja. Por isso a importância de desenvolver uma RFP ou Declaração de Trabalho adequada, pois, caso ela seja mal desenvolvida, implicará a aquisição de um software que não atende às demandas da organização. 

Uma das maiores motivações para desenvolver um documento do tipo RFP é, exatamente, evitar a aquisição de software desalinhado com a demanda ou com a infraestrutura existente na organização. Trata-se de um problema bastante comum, que ocorre com frequência. Na grande maioria das vezes, esse problema ocorre devido a pressões internas para encontrar um software que atenda uma demanda urgente, então, não realizada, adequadamente, a engenharia de requisitos com a consequente criação de uma RFP. 

Tenha em mente que a apresentação de um software é sempre muito maravilhoso, mas este tipo de apresentação foi criada para ser assim: passar uma imagem de que aquele software, além de perfeito, tem plena adequação à necessidade. Não caia nessa! Aplique as técnicas que vimos de levantamento de requisitos, documente os requisitos funcionais e não funcionais do software e cheque, de forma cuidadosa, se um ou outro software atende àqueles requisitos (PRESSMAN, 2016).

Especificação de Requisitos de Software (ERS)

A ERS é um “convite” enviado a um grupo de fornecedores para que eles apresentem propostas de venda de produtos ou serviços. Trata-se de um documento técnico que será a base para intermediar a negociação de aquisição de um produto ou serviço. No nosso caso, a ERS é aplicada na aquisição de um software no mercado, é a forma como uma empresa vendedora de software verificará se o produto o qual ela possui (software) atende ao que a sua organização precisa (PRESSMAN, 2016).

Um processo de aquisição envolvendo vários fornecedores aumenta a capacidade de negociação e o poder de compra das empresas (PAULA FILHO, 2009). Assim, de posse de um documento do tipo ERS, é mais fácil você convidar vários fornecedores de determinado produto ou serviço. Esse documento deve conter o maior número de informações possível, a fim de os fornecedores usarem a criatividade para oferecer a melhor solução à empresa, dessa forma, a elaboração de uma ERS é importante para garantir a eficiência do processo de aquisição. Ela precisa seguir metodologia e linguagem comuns ao gerenciamento de projetos, utilizando princípios da Engenharia de Requisitos.

Existe uma forte relação entre a Engenharia de Requisitos de um projeto e a ERS. Se a engenharia for elaborada, de forma correta, ela pode ser, facilmente, incluída na ERS, economizando tempo e esforço, além de estabelecer uma linguagem comum entre o processo de aquisição e o gerenciamento de projetos.

A seção de requisitos funcionais deve dar preferência à definição das necessidades da organização, o que possibilita aos fornecedores mais flexibilidade na definição do produto ou serviço. A linguagem utilizada no texto da ERS precisa ser clara e conhecida por todos os fornecedores que são qualificados para fornecer a solução. Os requisitos do software não podem ser ambíguos ou conter termos subjetivos e, para completar o quadro de informações técnicas, a ERS deve apresentar os ambientes de negócios e técnico atuais bem como os ambientes propostos. É necessário que a ERS inclua as necessidades de hardware, software e aplicações.

Sugere-se que haja uma equipe para a avaliação das propostas que chegarem à organização. Defina um processo para a solicitação de esclarecimento aos fornecedores e, também, use técnicas de avaliação das soluções e do preço (ex.: a proposta atende 100% dos requisitos funcionais estabelecidos e possui um preço abaixo ou igual ao orçamento da empresa). Após analisar, em detalhes, as características da solução (produto que está sendo adquirido) defina o vencedor da ERS, em seguida, faça a aquisição do produto ou serviço (FAGUNDES, [2022], on-line).

A estrutura de uma ERS

Um documento do tipo ERS deve ter uma estrutura profissional e organizada. A seguir, serão apresentados os elementos, geralmente, sugeridos a aparecer neste tipo de documento (FAGUNDES, [2022], on-line; PRESSMAN, 2016).

1. Capa
   A capa da ERS deve conter o título do projeto (ex.: Sistemas Cosmos – Especificação de Requisitos de Software).

2. Ainda na capa, deve haver a data da última versão e a própria versão daquela ERS. Deve-se apresentar, no rodapé, o nível de confidencialidade daquele documento.

3. Na segunda página, sugere-se uma tabela de versionamento, ou seja, uma tabela que apresente as versões daquele documento (histórico de revisões). 

Veja um exemplo, a seguir, na Tabela 1:

4. A seção de Introdução pode ter os seguintes itens:
- Propósito.
- Escopo.
- Público-alvo.
- Definições, acrônimos e abreviações.
- Referências.
- Organização do documento.

5. Requisitos
- Requisitos funcionais – Lista de requisitos funcionais no formato:
[R1] Gerir usuário
[R2] Gerir vendas
etc.
- Requisitos não funcionais – Apresenta os requisitos não funcionais do sistema conforme os seguintes elementos:
- Usabilidade.
- Confiabilidade.
- Desempenho.
- Reusabilidade.
- Segurança.
- Acessibilidade.
- Requisitos de interface
- Interfaces com o usuário: que tipo de interface com o usuário o sistema deve ter (ex.: interface web com cores neutras e navegação simples).
- Interfaces de hardware.
- Interfaces de software.
- Interfaces de comunicação.
- Requisitos de documentação
- Manual de usuário: o sistema deve apresentar um manual físico para o usuário.
- Ajuda online: o sistema deve ter ajuda online para o usuário.
- Requisitos de licença: que tipo de licença o software deve possuir ou que tipo de licença os softwares associados ao produto que está sendo adquirido deverão ter (ex.: você pode especificar que os softwares associados deverão ser todos opensource – código-fonte aberto).

6. Mapeamento dos requisitos funcionais com casos de uso
Neste item, costuma ser apresentado o diagrama de caso de uso do sistema.

Nesta lição, compreendemos como o técnico em desenvolvimento de sistemas atende à demanda por um novo software na organização e como proceder para adquirir esse software no mercado. Agora, é com você!

Agora, é oportuno que façamos o preenchimento de uma ERS juntos. Assim, disponibilizei para você um documento modelo já preenchido que simula uma ERS. 

Clique aqui para acessar o exemplo de uma ERS.

Atente-se a algumas particularidades que você deve seguir ao criar a sua ERS. Os elementos centrais dela são as listagens de requisitos funcionais e não funcionais do software. Assim, atente-se para o fato de que os requisitos devem ser identificados um a um (ex.: [RF1] - refere-se ao requisito funcional 1). O nome do requisito funcional é definido com base em um substantivo e um verbo no infinitivo. Calma! Vou te explicar como isso pode ser feito. 

No nosso modelo, foi definido o requisito funcional 4 [RF4] com o nome de Gerir vestibular. Perceba que a primeira palavra é um verbo que termina em “IR”. Os verbos os quais terminam em “IR” (ex.: gerir), “AR” (ex.: organizar, informar, relatar etc.) e “ER” (ex.: desenvolver) estão no infinitivo e devem ser usados no nome dos requisitos funcionais porque se referem a uma ação/funcionalidade que o software deve ter. Sempre use verbos no infinitivo para dar nome aos seus requisitos funcionais. A segunda palavra no nome do requisito funcional é um substantivo e precisa estar associado à funcionalidade principal. No nosso exemplo, a palavra é “vestibular”, mas poderia ser “alunos”, “pessoas”, “fornecedores”, “clientes” etc. Sempre o segundo nome será algo associado ao elemento central da funcionalidade.

Também é importante saber definir os requisitos não funcionais do sistema. Para isso coloquei cinco grupos de requisitos funcionais que você pode usar ou não, dependendo do tipo de software:

A usabilidade diz respeito a aspectos na forma como o software será usado pelos usuários (ex.: o software deve atender a pessoas com deficiência visual). A confiabilidade refere-se a aspectos que garantam a recuperação do software contra desastres (ex.: restaurar o que o usuário estava fazendo, caso a máquina desligue, abruptamente). O desempenho está associado a características que podem envolver a capacidade de processamento do software ou mesmo o tempo de resposta a determinadas ações do usuário (ex.: o tempo do cálculo que integra as vendas das 100 filiais de uma organização deve ser inferior a cinco segundos). 

A seção segurança está associada a aspectos envolvendo a segurança da informação. Aspectos de autenticação do usuário no sistema (ex.: biometria) ou uso de criptografia para armazenar os dados ou mesmo trafegar os dados na rede de computadores são alguns exemplos de requisitos não funcionais os quais o software deve atender.

Preenchida a ERS, você está preparado(a) para enviar o documento às empresas desenvolvedoras ou usá-lo como base para iniciar o desenvolvimento na sua própria empresa. A ERS é um dos documentos centrais no desenvolvimento de um software e, se você, como técnico(a) em desenvolvimento de sistemas, dominar a criação desse documento, terá muitas chances de desenvolver softwares com forte aderência à necessidade da organização.