Entenda o que são requisitos de software e a importância da engenharia de requisitos para o sucesso dos seus projetos.
Tempo de Leitura: 10 minutos
Neste artigo, entenderemos o que são requisitos e suas diferentes classificações. Além disso, exploraremos os processos de engenharia de requisitos para compreender o impacto dessa prática no sucesso dos sistemas de software. A engenharia de requisitos é uma disciplina fundamental na engenharia de software, pois estabelece a base sobre a qual todo o projeto é construído. Sem uma definição clara e precisa dos requisitos, é quase impossível desenvolver um sistema que atenda às expectativas e necessidades dos usuários finais.
Os requisitos desempenham um papel crucial em todas as fases do desenvolvimento de software. Eles servem como um guia para os desenvolvedores, ajudando a garantir que o produto final seja funcional, eficiente e atenda às necessidades dos stakeholders. A falta de requisitos bem definidos pode levar a ambiguidades, retrabalhos e, em última análise, ao fracasso do projeto. Portanto, é essencial que os requisitos sejam cuidadosamente elaborados, analisados e documentados desde o início do projeto. Neste contexto, a engenharia de requisitos não é apenas uma atividade inicial, mas um processo contínuo que envolve a colaboração entre desenvolvedores, clientes e outros stakeholders.
O que são requisitos?
Os requisitos de um sistema são as especificações dos serviços que ele deve fornecer e as restrições operacionais associadas. Eles refletem as necessidades dos clientes e definem o propósito do software. Assim, o processo de identificar, analisar, documentar e verificar esses serviços e restrições é conhecido como engenharia de requisitos.
Contudo, o termo "requisito" na indústria de software não é absoluto nem estático. Ele pode referir-se a uma abstração de alto nível de um serviço que o sistema deve oferecer ou a uma descrição formal, detalhada, técnica e precisa de uma função específica do software. A descrição dos requisitos varia conforme a fase do projeto de software.
Por exemplo, uma empresa que deseja contratar o desenvolvimento de um sistema de geração, assinatura e gestão de contratos digitais precisa descrever os requisitos de forma ampla para que diversos fornecedores possam apresentar suas propostas. Entre os requisitos principais, podem estar: o sistema deve gerar contratos com o timbre da empresa, permitir múltiplos assinantes em um mesmo documento, enviar contratos para assinatura por e-mail, e armazenar contratos por até cinco anos. Após a escolha do fornecedor, este deve elaborar um documento detalhado com as funções do software, seu fluxo de operação e limitações, garantindo que o sistema atenda às expectativas do cliente.
Portanto, distinguimos entre requisitos de usuário e requisitos de sistema. Essa diferença deve estar clara, especialmente para os responsáveis pelo projeto de software, a fim de evitar ambiguidades e confusões durante o desenvolvimento e a implementação.
Requisitos de Usuário
São declarações práticas, em linguagem natural, que descrevem o que o usuário precisa do sistema. Elas podem ser acrescidas de fluxogramas e diagramas para explicar o que o sistema deve fornecer como serviço. Os requisitos de usuários podem variar de declarações mais genéricas, até especificações mais minuciosas. Porém, mantendo sempre a perspectiva de usuário de software.
Requisitos de Sistema
São detalhamentos de perspectiva técnica sobre as funções, serviços, micro serviços e restrições operacionais de um sistema de software. Chamado por vezes de “Especificação Funcional”, o documento de requisitos de sistema define com exatidão o que deve ser implementado, um passo crucial na engenharia de requisitos. Ele também pode ser incluído como parte do contrato entre o adquirente do sistema e os desenvolvedores de software.
São necessários diferentes níveis de descrição porque há distintos tipos de leitores que utilizarão esses dados. É comum que os requisitos de usuários sejam destrinchados em vários requisitos de sistemas, ou seja, várias funções e atividades estarão envolvidas na entrega daquele serviço em específico. Nada melhor que um exemplo para materializar esses conceitos, vamos supor um cenário envolvendo uma possível função para o software Mentcare (um sistema de apoio à gestão clínica de pacientes com doenças mentais):
Exemplo de Requisitos de Usuário e de Sistema
Requisito de Usuário:
1. O sistema deve disponibilizar relatórios de gestão mensal mostrando o custo dos medicamentos prescritos por cada clínica em determinado mês.
Requisitos do Sistema:
1.1 No último dia útil de cada mês, deve ser gerado um resumo dos medicamentos prescritos, seus custos e qual clínica o prescreveu.
1.2. Após às 17h30 do último dia útil do mês, o sistema deve gerar o relatório para impressão.
1.3. Deve ser criado um relatório para cada clínica, listando: nome de cada medicamento, quantidade total de prescrições, quantidade de doses prescritas, valor unitário, custo total de todos os medicamentos prescritos.
1.4. Se os medicamentos estiverem prescritos em dosagens diferentes, deve ser criada uma linha separada no relatório para cada dosagem.
1.5. O acesso aos relatórios devem ser restritos aos usuários autorizados conforme a lista de controle de acessos disponibilizada pela gestão.
Observe que nos requisitos de sistema, há vários fatores que precisam ser implementados para atender apenas aquele requisito de usuário. Além dos usuários diretos do sistema, há outras “partes interessadas” que também são chamadas de stakeholders que podem ser internos e externos. Nesse grupo, podemos incluir gestores, autoridades reguladoras, desenvolvedores de software, outros profissionais e empresas que se relacionam com as atividades do cliente de software, entre outros.
Percebe-se que o ecossistema de software pode ser complexo e exige um gerenciamento eficaz. Por isso, a engenharia de requisitos é colocada como o primeiro estágio do processo de engenharia de software
Requisitos funcionais e não funcionais
É frequente encontrarmos a distinção dos requisitos de sistema em funcionais e não funcionais. O primeiro se refere ao modo que o sistema deve reagir a dadas entradas e como deve se comportar em determinadas situações. Em alguns casos, os requisitos funcionais podem explicitar o que o sistema não deve fazer. Já a segunda classe, se refere aos serviços e funcionalidades disponíveis no sistema. Os requisitos não funcionais incluem restrição de tempo, de processo de desenvolvimento ou padrões e se aplicam, geralmente, ao sistema como um todo e não apenas às características individuais ou serviços.
Apesar de parecer simples, a distinção entre funcional e não funcional pode não ser tão clara e objetiva na prática. Tomaremos como exemplo um requisito de security (segurança da informação): declaração de restrição de acesso aos usuários autorizados. A primeiro momento, parece um requisito não funcional. Porém, quando desenvolvido em mais detalhes, esse requisito irá gerar outros requisitos claramente funcionais - como a necessidade de incluir no sistema recursos de autenticação de usuário. Isso demonstra a interdependência dos requisitos e o impacto deles na garantia de que os serviços e funções do sistema sejam entregues.
Agora, entraremos em mais detalhes sobre cada um dos tipos de requisitos.
Requisitos Funcionais
Já citamos que os requisitos funcionais descrevem o que o sistema deve fazer, mas a grande questão é que eles dependem totalmente do tipo de software que está sendo desenvolvido, dos usuários esperados e da abordagem adotada pela organização ao descrever esses requisitos. Os requisitos de espécie funcional expandem os requisitos de usuário e são escritos para desenvolvedores. Por isso, eles devem conter informações detalhadas das funcionalidades do sistema, suas entradas e saídas, exceções e restrições operacionais. Essas descrições podem ser mais gerais, como o que o sistema deve fazer em objetivos mais amplos, ou mais especificados, refletindo o modo de trabalho local, por exemplo.
Para exemplificar alguns requisitos funcionais, utilizaremos novamente o sistema de saúde mental, Mentcare, com o seguinte requisito de usuário:
- O usuário deve ter permissão para fazer uma busca na lista de consultas de todas as clínicas.
Como o nome sugere, os requisitos funcionais focam na função que o sistema deve ter. Para dar precisão, esses requisitos devem abordar todas as informações necessárias para prestar aquela determinada funcionalidade. Apenas com as descrições de usuário, não é possível ter exatidão do que o sistema deve fazer.
Neste primeiro requisito, não está claro qual entrada o usuário deve inserir e nem as possíveis saídas. Podemos imaginar que um mesmo paciente, eventualmente, pode ser atendido por várias clínicas diferentes e, para garantir que ele compareça no estabelecimento onde agendou, precisa conferir isso no sistema. Sendo assim, um requisito funcional oriundo desse primeiro item pode ser transcrito como:
- O usuário (paciente ou equipe médica) poderá buscar pelo nome ou CPF do paciente quais as agendas já marcadas. Na lista de consultas agendadas, deve constar: dia e hora da consulta, médico responsável, nome da clínica e endereço da clínica.
Essa descrição se faz necessária para garantir que a interpretação dos diferentes envolvidos no projeto coincidam. A coerência dos requisitos é de suma importância para o sucesso de qualquer projeto. Sobretudo em grandes sistemas, há vários stakeholders com distintas formações e expectativas, por isso suas necessidades podem ser inconsistentes umas com as outras. Essas inconsistências podem não ser tão óbvias quando os requisitos são pouco específicos. Para contorná-las, precisamos analisar mais profundamente os requisitos propostos e modificá-los para que se tornem harmônicos.
Requisitos não funcionais
Os requisitos não funcionais, como o nome sugere, são aqueles que não possuem relação direta com os serviços específicos fornecidos pelo sistema. Desta forma eles especificam ou restringem características do sistema como um todo, podendo estar relacionados à propriedades emergentes do sistema - como confiabilidade, tempo de resposta ou uso de memória.
Geralmente, os requisitos não funcionais são mais críticos do que os funcionais se olharmos de maneira individual. Os usuários de sistema normalmente encontram formas de contornar uma função que o sistema não satisfaça. Entretanto, descumprir um requisito não funcional pode gerar a total inutilização do sistema. Imagine um sistema de aeronave que não satisfaça o requisito de confiabilidade, este não será certificado como seguro para operação por oferecer risco a todos os seus usuários e ao uso das próprias aeronaves.
Nota-se que os requisitos não funcionais afetam a arquitetura geral do sistema e não apenas componentes individuais. Ademais, um requisito não funcional pode originar a necessidade de vários requisitos funcionais que definem novos serviços do sistema para conseguir implementá-lo. É possível visualizar essa característica se tratando de um requisito de segurança da informação (security) que exige, exemplificando, limitar o acesso à informação no sistema.
Os usuários do sistema originam os requisitos não funcionais a partir de suas necessidades que estão influenciadas por restrições orçamentárias, políticas organizacionais, necessidade de interoperabilidade com outro sistema de software ou hardware, ou fatores externos como as normas de segurança, legislação tributária ou de privacidade, por exemplo.
Processos de Engenharia de Requisitos
Legenda: O processo de engenharia de requisitos contempla três atividades principais: Elicitação, Especificação e Validação de Requisitos. | Imagem: Freepik
O processo de engenharia de requisitos contempla três atividades principais: Elicitação, Especificação e Validação de Requisitos. Na prática, elas são interativas e intercalam-se entre si.
Elicitação de Requisitos
A primeira delas consiste na descoberta dos requisitos por meio da interação com stakeholders . Para isso é interessante ter contato direto com as partes interessadas para entender como usariam um novo sistema em seu trabalho. Durante a licitação de requisitos, os engenheiros de software trabalham com as partes interessadas para saber mais sobre o domínio da aplicação, as atividades envolvidas, o serviço e as características que o sistema deve ter segundo a necessidade e o desejo dos stakeholders.
Eventualmente, os stakeholders não sabem o que querem do sistema - exceto em aspectos mais gerais, isso dificulta a articulação essencial dos serviços. Portanto, é comum que eles expressem os requisitos em seus próprios termos e com conhecimento implícito do seu trabalho. Por isso, o desafio dos engenheiros de software é compreender essas expressões e traduzi-las em código, em software, isto é, dar vida às ideias das partes interessadas.
Além de conseguir identificar os requisitos de sistema, os desenvolvedores precisam elencar os requisitos e descobrir as possíveis fontes de divergência e convergência. Visando atender a expectativa do cliente com performance, cabe aos responsáveis de desenvolvimento priorizar e negociar os requisitos. Afinal nem sempre o céu é o limite quando se trata de projetar e desenvolver um sistema. A transparência com o potencial e restrições do sistema é crucial para a perpetuação do relacionamento com o cliente.
A elicitação e análise de requisitos é composta por quatro atividades principais:
- Descoberta e compreensão dos requisitos;
- Classificação e organização dos requisitos;
- Priorização e negociação dos requisitos;
- Documentação dos requisitos;
Especificação de Requisitos
A especificação de requisitos é o processo de escrever os requisitos de usuário e de sistema em um documento de requisitos. Idealmente esse documento deve conter descrições claras, inequívocas, fáceis de entender, completas e consistentes de todos os requisitos funcionais e não funcionais. Na prática isso é quase impossível de obter porque os stakeholders interpretam o documento de requisito de maneiras diferentes, gerando conflitos.
Há dois tipos de especificações utilizadas no documento de requisitos: especificação em linguagem natural e especificações estruturais. Em linguagem natural, os requisitos são descritos de maneira expressiva, intuitiva e universal. Se por um lado ela simplifica a compreensão, por outro é potencialmente vaga e ambígua, comprometendo sua interpretação à experiência do leitor. Devido a isso, há muitas propostas de maneiras diferentes para escrever os requisitos. Todavia, nenhuma dessas propostas foi adotada amplamente e a linguagem natural continua sendo a maneira mais utilizada de especificar os requisitos de software.
Para minimizar os desacertos ao escrever os requisitos em linguagem natural recomendam-se algumas diretrizes:
- Padronizar o formato de descrição para diminuir a probabilidade de omissões. Sempre que possível, sugere-se escrever o requisito em uma ou duas frases de linguagem natural.
- Utilizar a linguagem coerentemente para diferenciar entre requisitos obrigatórios e desejáveis. Os obrigatórios são os que o sistema deve apoiar e, normalmente, são escritos usando “deve”. Já os requisitos desejáveis não são essenciais e são escritos usando “pode”.
- Usar realces de texto como negrito, itálico ou cor distinta para destacar informações importantes do requisito.
- Evitar usar jargões, abreviações e acrônimos que possam gerar confusão aos leitores não adeptos a linguagem técnica de engenharia de software.
- Associar um racional a cada requisito de usuário sempre que possível. O racional deve explicar porque o requisito foi incluído e quem o propôs (origem do requisito). Essa orientação permite que saibamos a quem recorrer se o requisito precisar ser alterado.
Quantas especificações estruturadas, elas são uma maneira de escrever os requisitos de sistema num formato padrão ao invés de texto livre. Esse tratamento mantém a maior parte da expressividade e da clareza da linguagem natural, mas garante que algumas uniformidades estejam impostas às especificações. As notações que adotam a linguagem estruturada usam modelos para especificar os requisitos de sistema. Essa especificação pode usar conjuntos de linguagem de programação para mostrar alternativas e interações, podendo destacar os elementos chaves por intermédio de sombreamento ou fontes diferentes.
Em resumo, a abordagem estruturada define um ou mais templates para representar formulários estruturados que contenham as especificações dos requisitos.
Abaixo, listamos informações que devem ser incluídas nesse tipo de template:
- Descrição da função ou entidade que está sendo especificada;
- Descrição das entradas e suas origens;
- Descrição das saídas e sua destinação;
- Informações sobre os dados ou outras entidades necessários para computar;
- Descrição da ação a ser tomada;
- Se for utilizado uma abordagem funcional, incluir uma precondição estabelecendo que deve ser verdadeiro antes da função ser invocada e uma pós-condição especificando o que é verdadeiro após a função ser invocada;
- Descrição dos efeitos colaterais da operação - se houver.
A forma estruturada reduz a variabilidade de especificação por oferecer uma organização mais eficiente do que a linguagem natural. Entretanto, para computações mais complexas, pode ser difícil escrever os requisitos de maneira estruturada. Para resolver esse problema, é possível acrescentar mais informações aos requisitos em linguagem natural usando tabelas ou modelos gráficos do sistema.
Validação de Requisitos
Esse é o processo de averiguar se os requisitos licitados e especificados conferem com que o cliente realmente quer. A validação é voltada para encontrar incoerências e problemas. Uma vez que encontre os problemas durante o desenvolvimento dos requisitos, é possível prevenir a perda de grandes custos com retrabalho. Há uma série de técnicas de validação de requisitos que podem ser utilizadas individual ou conjuntamente:
- Revisão de requisitos: Análise sistemática dos requisitos por uma equipe de revisores que conferem inconsistências;
- Prototipação: Se refere ao desenvolvimento de um modelo executável do sistema e o uso desse modelo com usuários finais para verificar se satisfaz a necessidades e expectativas.
- Geração de casos de testes: Os requisitos devem ser testáveis. Se os testes dos requisitos forem concebidos como parte do processo de validação, frequentemente isso revela problemas nos requisitos. Se um teste for difícil ou impossível de projetar, normalmente, isso aponta que os requisitos serão difíceis de implementar e devem ser reconsiderados. Desenvolver testes a partir dos requisitos de usuários antes de qualquer código ser escrito faz parte do desenvolvimento dirigido por testes.
O processo de validação de requisitos geralmente ocasiona a evolução deles. Primeiro, há a compreensão inicial do problema constatado nos requisitos iniciais, seguida da compreensão modificada do problema, e resultando em requisitos modificados. Considerando que as mudanças no ambiente de negócio, nas organizações e nas tecnologias ocorrem continuamente, é inevitável que haja mudanças nos requisitos de um sistema de software. Em razão disso, o gerenciamento de requisitos é o processo de gerir e controlar essas mudanças visando a máxima eficiência e atendimento das necessidades dos stakeholders.
Conclusão
A Engenharia de Requisitos constrói a base de um sistema de software. Por conseguinte, quanto mais consolidada ela estiver, mais segura e eficiente será a construção do projeto. Como a fundação de um grande edifício, ela deve ser realizada antes de levantar qualquer parede. Esperamos que esse texto tenha contribuído com o seu conhecimento a respeito de requisitos e a importância da Engenharia de Requisitos no desenvolvimento de sistemas.
Para continuar explorando conteúdos sobre desenvolvimento de software, navegue na categoria de Desenvolvimento aqui no blog. Se tiver dúvidas ou quiser compartilhar seus aprendizados, participe do nosso fórum e conecte-se com outros profissionais da área. Estamos aqui para ajudar e aprender juntos!
