A essência da Engenharia de Requisitos – Parte 1

A etapa de levantamento de requisitos ou engenharia de requisitos de um projeto é tão importante e complexa que existem livros e cursos de graduação e pós-graduação apenas sobre esse tema.

Porém neste post darei uma breve explicação sobre este assunto e mostrarei porque todo o processo de desenvolvimento do sistema depende tanto dessa etapa para o seu entendimento e sucesso do projeto.

Nessa primeira parte irei falar sobre o que são requisitos, os seus tipos, a sua documentação de software e o processo para fazer o seu levantamento.

Mas o que são requisitos de um projeto?

Os requisitos de um sistema são as descrições do que o sistema deve fazer, seus serviços e as restrições para o seu funcionamento.

Tudo isso reflete a necessidade dos clientes para a solução de um problema, ou seja, para um sistema com uma finalidade determinada.

No processo de desenvolvimento de software, a etapa de descoberta, análise, documentação e verificação de serviços e restrições é chamada de Levantamento de Requisitos ou Engenharia de Requisitos.

Em alguns casos, o requisito é apenas uma declaração abstrata em alto nível de um serviço que o sistema deve oferecer ou até uma restrição a um sistema.

Por outro lado , pode ser uma função detalhada e formal de uma função do sistema.

Existem muitos problemas que surgem durante esse processo e um deles se refere as falhas em não fazer uma clara separação entre os diferentes níveis de descrição de cada requisito.

Ian Sommerville em seu livro, Engenharia de Software, faz uma distinção entre esses níveis utilizando o termo “requisitos de usuário” e “requisitos de sistema”.

Requisitos de usuário

Expressam os requisitos abstratos de alto nível e são declarações em uma linguagem natural com diagramas de quais serviços o sistema deverá fornecer a seus usuários e as restrições com as quais este deve operar.

Esses requisitos podem ser expandidos em diversos requisitos de sistema.

Os  leitores desse tipo de requisito não costumam se preocupar com a forma como o sistema será implementado.

Exemplo: “O sistema deve gerar relatórios mensais de custos sobre ocorrências daquele mês”.

Requisitos de sistema

Expressam a descrição detalhada do que o sistema deve fazer.

O documento de requisitos do sistema deve definir exatamente o que deve ser implementado e pode ser parte do contrato entre o comprador do sistema e os desenvolvedores de software.

Os leitores desse tipo de requisito precisam saber mais detalhadamente o que o sistema fará, pois estão interessados em como ele apoiará os processos de negócio ou porque estão envolvidos na implementação do sistema.

Exemplo: “O sistema deve gerar relatórios no formato PDF exatamente às 18:00 horas do quinto dia útil do mês.”

Os requisitos devem ser escritos em diferentes níveis de detalhamento para que diferentes leitores possam usá-los de diversas maneiras.

O resultado dessa etapa é um documento de requisitos, que pode ser parte do contrato de desenvolvimento do sistema.

Durante o desenvolvimento, é certo que haverão mudanças nesses requisitos, e dependendo da etapa em que o projeto se encontra e a natureza da mudança requerida, o impacto pode ser muito grande, seja para o custo do projeto ou para o tempo dele ou em ambos.

Os requisitos não são independentes e muitas vezes geram ou até restringem outros requisitos.

Portanto, os requisitos de sistema não apenas especificam os serviços ou as características do sistema, mas também a funcionalidade necessária para garantir que essas características sejam entregues de maneira correta.

Os requisitos de software são classificados como requisitos funcionais e requisitos não funcionais.

Requisitos funcionais

São informações do que o sistema deve fazer, de como o sistema irá reagir a diferentes entradas e de como o sistema deve se comportar em diferentes situações.

Eles também podem explicar o que o sistema não deve fazer. Eles dependem do tipo de software a ser desenvolvido e de quem serão seus possíveis usuários.

Os requisitos funcionais de usuários são escritos de forma abstrata, para serem compreendidos justamente pelos usuários.

Estes requisitos definem os recursos específicos a serem fornecidos pelo sistema e foram retirados do documento de requisitos de usuário, mostrando que os requisitos funcionais podem ser escritos em diferentes níveis de detalhamento.

Já os requisitos funcionais de sistema descrevem em detalhes as funções do sistema, suas entradas, saídas e exceções.

Esse tipo de requisito descreve de forma clara o que deve ser feito pelo sistema como por exemplo, “o usuário deve ser capaz de consultar todas as tarefas de manutenção preventiva de ativos de um determinado sistema.”

A imprecisão na especificação de requisitos é causa de muitos problemas  no desenvolvimento de software.

Um desenvolvedor de sistemas pode interpretar um requisito ambíguo de uma maneira que simplifique sua implementação.

Muitas vezes essa não é a preferência do cliente, sendo necessário estabelecer novos requisitos e fazer alterações no sistema o que gera atraso de entrega e elevação dos custos.

A especificação dos requisitos funcionais de um sistema deve ser completa e consistente para evitar esta situação.

Todos os serviços requeridos pelo usuário devem ser definidos e não devem, claro, ter definições contraditórias.

Em um sistema grande e complexo é muito difícil conseguir completude e consistência dos requisitos, isso ocorre porque na elaboração de sistema complexos é fácil cometer erros e omissões.

Este problema também pode ocorrer pois em um projeto grande existem muitos stakeholders.

Stakeholder é uma pessoa ou papel que é afetado pelo sistema. São os interessados pelo projeto de alguma maneira.

Eles possuem necessidades diferentes o que acaba por gerar inconsistências na hora do levantamento de requisitos.

Isso é um problema que pode ser constatado até mesmo após a entrega do sistema ao cliente.

Requisitos não funcionais

São restrições aos serviços ou funções oferecidas pelo sistema. Incluem restrições de timing, restrições no processo de desenvolvimento e restrições impostas pelas normas.

Aplicam-se, geralmente, ao sistema como um todo.Eles não estão diretamente relacionados com os serviços específicos oferecidos pelo sistema.

Requisitos não funcionais podem estar relacionados às propriedades emergentes do sistema, como confiabilidade e tempo de resposta.

Normalmente eles são mais críticos que os requisitos funcionais. Os usuários do sistema podem encontrar maneiras de contornar uma função do sistema que realmente não atenda a suas necessidades.

Porém, deixar de atender a um requisito não funcional pode significar a inutilização de todo o sistema.

Requisitos não funcionais podem afetar a arquitetura geral de um sistema em vez de apenas componentes individuais.

Por exemplo, para assegurar que sejam cumpridos os requisitos de desempenho, será necessário organizar o sistema para minimizar a comunicação entre os componentes.

Um único requisito não funcional pode gerar uma série de requisitos funcionais relacionados que definam os serviços necessários no novo sistema e ainda podem gerar requisitos que restrinjam requisitos existentes.

Surgem por meio das necessidades dos usuários, devido a restrições de orçamento, políticas organizacionais, necessidade de comunicação com outros sistemas de software ou hardware, ou a partir de fatores externos como regulamentos ou legislações de privacidade e segurança.

Os requisitos não funcionais podem ser divididos em 3 tipos macro não funcionais. Os requisitos de produto, os requisitos organizacionais e os requisitos externos. Estes, por sua vez podem ser divididos em requisitos menores.

Requisitos de produtos

  • Requisitos de eficiência
  • Requisitos de desempenho
  • Requisitos de espaço
  • Requisitos de usabilidade
  • Requisitos de confiança
  • Requisitos de proteção

Esses requisitos especificam ou restringem o comportamento do software.

Requisitos organizacionais

  • Requisitos ambientais
  • Requisitos operacionais
  • Requisitos de desenvolvimento

Esses são os requisitos gerais de sistemas derivados das políticas e procedimentos da organização do cliente e do desenvolvedor.

Requisitos externos

  • Requisitos reguladores
  • Requisitos éticos
  • Requisitos legais
  • Requisitos contábeis
  • Requisitos de segurança/proteção

Esse tipo abrange todos os requisitos que derivam de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos reguladores, que definem o que deve ser feito para que o sistema seja aprovado para uso.

 

 

Um problema comum com requisitos não funcionais é que costumam ser propostos pelos clientes ou usuários como metas gerais, em virtude da facilidade de uso, da capacidade do sistema de se recuperar de falhas ou da velocidade das respostas do usuário.

Metas estabelecem boas intenções, mas podem causar problemas para os desenvolvedores do sistema, pois deixam margem para interpretações e para disputas para a entrega do sistema.

Sempre que possível, é necessário que os requisitos não funcionais sejam escritos quantitativamente para que possam ser testados.

Métricas podem ser usadas para especificar as propriedades não funcionais do sistema. Essas métricas podem ser medidas quando o sistema está sendo testado para verificar se ele tem cumprido ou não os requisitos não funcionais.

Os clientes de um sistema geralmente acham difícil traduzir suas metas em requisitos mensuráveis. Para algumas metas, como manutenibilidade, não existem métricas que possam ser usadas.

Nem sempre os clientes são capazes de relacionar suas necessidades com essas especificações.

O custo de verificar requisitos objetivamente não funcionais mensuráveis pode ser muito elevado e os clientes que pagam pelo sistema podem não achar que os custos valham a pena.

Os requisitos não funcionais geralmente conflitam e interagem com outros requisitos funcionais ou não funcionais.

Na prática, quando é gerado o documento de requisitos, é difícil separar os requisitos funcionais dos não funcionais. Se eles forem apresentados separadamente, os relacionamentos entre eles podem ficar difíceis de serem entendidos.

Os requisitos relacionados com as propriedades emergentes do sistema, como desempenho ou confiabilidade, sevem ser explicitamente destacados.

Após a elicitação de requisitos funcionais e não funcionais gerado e discutido por todos os stakeholders, é gerado o documento de requisitos de software.

Documento de requisitos de software

O documento de requisitos de software é uma declaração oficial do que os desenvolvedores do sistema devem implementar. Deve incluir os requisitos do usuário e também uma especificação detalhada dos requisitos do sistema.

Em alguns casos, os requisitos de usuário e de  sistema são integrados em uma única descrição.Se houver um grande número de requisitos, os requisitos detalhados do sistema podem ser apresentados em um documento separado.

O documento de requisitos é essencial quando um contratante externo está desenvolvendo o sistema de software. Ele é o resultado da etapa de elicitação de requisitos, aonde será interpretado pelos desenvolvedores do sistema.

Ele tem um conjunto diversificado de usuários, que vão desde a alta administração da organização, até os engenheiros responsáveis pelo desenvolvimento do software.

A diversidade de possíveis usuários é um indicativo de que o documento de requisitos precisa ser um compromisso com a comunicação dos requisitos para os clientes, a definição dos requisitos em detalhes precisos para os desenvolvedores e testadores e a inclusão de informações sobre a possível evolução do sistema.

O documento de requisitos não deve incluir detalhes da arquitetura ou projeto do sistema.

Os requisitos de usuário e de sistema em um documento devem ser claros, inequívocos, de fácil compreensão, completos e consistentes.

Os requisitos de usuários são quase sempre escritos em linguagem natural e suplementados no documento de requisitos por diagramas de fácil compreensão e tabelas.

Estes devem descrever os requisitos funcionais e não funcionais de modo que sejam compreensíveis para os usuários do sistema que não tenham conhecimento técnico.

Informações sobre mudanças previstas podem ajudar os desenvolvedores do projeto a evitar decisões que restrinja de alguma maneira aquela mudança prevista, além de ajudar os engenheiros de manutenção de sistema.

O nível de detalhe que você deve incluir em um documento de requisitos depende do tipo de  sistema a ser desenvolvido.

Os sistemas críticos, por exemplo, precisam ter requisitos mais detalhados pois a segurança e a proteção deve ser analisadas em detalhe.

Sistema crítico pode ser um software para controle de voo, por exemplo.

Quando o software é parte de um projeto de um sistema de grande porte que inclui interações entre sistemas de hardware e software, geralmente é necessário definir os requisitos em um alto nível de detalhamento também.

É importante incluir uma tabela completa, abrangendo conteúdo e índice de documentos, para que os leitores podem encontrar as informações de que necessitam.

Quando você estiver escrevendo os requisitos de usuário no documento de software, não utilize palavras muito técnicas, notações estruturadas ou notações formais.

Você deve escrever os requisitos de usuário em linguagem natural com tabelas, formas e diagramas.

Requisitos de sistema também podem ser escritos em linguagem natural, mas também em outras linguagens com base em formulários, modelos gráficos ou matemáticos de sistema.

Existem algumas formas de se escrever uma especificação de requisitos para o documento de requisitos.

  • Sentenças em linguagem natural
  • Linguagem natural estruturada
  • Linguagem de descrição de projeto
  • Notações gráficas
  • Especificações matemáticas

Sentenças em linguagem natural

Os requisitos são escritos em frases numeradas em linguagem natural. Cada frase deve representar um requisito.

Desde o início da engenharia de software a linguagem natural tem sido usada para escrever os requisitos de software.

Ela é expressiva, intuitiva e universal, porém ela também é vaga em algumas situações.

Linguagem natural estruturada 

Os requisitos são escritos em linguagem natural em um formulário padrão ou template. Cada campo fornece informações sobre um aspecto do requisito.

É uma forma de escrever os requisitos do sistema aonde a liberdade do escritor dos requisitos é limitada e todos os requisitos são escrito em uma forma padrão.

A linguagem natural continua sendo a forma mais usada de especificação de requisitos de software e do sistema.

Para utilizar essa abordagem para especificação de requisitos de sistema, você deve definir um ou mais templates para representar esses requisitos como formulários estruturados.

Usar as especificações estruturadas elimina alguns dos problemas de especificação em linguagem natural. A variabilidade na especificação é reduzida, e os requisitos são organizados de forma mais eficaz.

Algumas vezes ainda é difícil descrever os requisitos de forma clara e inequívoca, principalmente quando processamentos complexos devem ser especificados.

Para resolver isto, você pode adicionar informações extras aos requisitos, usando tabelas ou modelos gráficos do sistema.

As tabelas são bem úteis quando há um número de situações alternativas possíveis e é necessário descrever as ações a serem tomadas para cada uma delas.

Quando um formulário é usado para especificar requisitos funcionais, as seguintes informações devem ser incluídas:

  • A descrição da função a ser especificada
  • Uma descrição de suas entradas e de onde elas vieram
  • Uma descrição de suas saídas e para onde elas irão
  • Dados sobre a informação necessária para o processamento
  • Uma descrição da ação a ser tomada
  • Uma pré-condição que define o que deve ser verdade antes que a função seja chamada
  • Uma descrição dos efeitos colaterais da operação, caso exista algum.

Linguagem de descrição de projeto

Utiliza uma linguagem como de programação, mas com características mais abstratas para especificar os requisitos, definindo um modelo operacional do sistema.

Essa abordagem é pouco utilizada atualmente.

Notações gráficas

Para definição dos requisitos funcionais são usados modelos gráficos, suplementados por notações de texto.

Aqui é muito utilizado o diagrama de caso de usos e o diagrama de sequência da UML (Unified Model Language) e também a modelagem de processos BPM (Business Process Managment).

Especificações matemáticas

Elas são baseadas em conceitos matemáticos, como máquinas de estado finito ou conjuntos.

Embora essa especificação possa reduzir a ambiguidade de um documento, a maioria dos clientes não entendem uma especificação tão formal.

Eles não podem verificar que elas representam o que eles querem.

Processos de levantamento de requisitos

O processo de engenharia de requisitos pode incluir quatro atividades de alto nível, com o estudo da viabilidade que visa avaliar se o sistema será útil para a empresa, com a elicitação e análise de requisitos que é a fase de descoberta de requisitos, com a especificação que converte estes requisitos em forma-padrão e a validação que verifica se os requisitos realmente atende o que o cliente deseja.

A engenharia de requisitos é um processo iterativo em que as atividades são intercaladas. As atividades do levantamento de requisitos geram um documento de requisitos de sistema.

A quantidade de tempo e esforço dedicados a cada atividade em cada iteração depende do estágio do processo como um todo e do tipo de sistema que está sendo desenvolvido.

No início do processo, o esforço maior é a compreensão dos requisitos de negócio e não funcionais em alto nível, assim como os requisitos de usuário para o sistema. Mais tarde, o esforço maior será na elicitação e compreensão dos requisitos do sistema em detalhes.

Algumas pessoas consideram a engenharia de requisitos o processo de aplicação de um método de análise estruturada, como a análise orientada a objetos.

Isso quer dizer que o sistema é analisado em torno dele desenvolvido um conjunto de modelos gráficos de sistema, como os casos de uso.

Os casos de uso servem como uma especificação do sistema e servem muito bem para o entendimento do funcionamento de cada parte do sistema, seja para os clientes ou para pessoas mais técnicas.

O conjunto de modelos de casos de uso descreve o comportamento do sistema e é anotado com informações adicionais, descrevendo várias partes do sistema, como desempenho e confiabilidade.

Na maioria dos sistemas os requisitos mudam. Os stakeholders desenvolvem uma melhor compreensão do que querem para o software, a organização que investe no sistema também muda, modificações são feitas no hardware, no software e no ambiente organizacional do sistema.

O processo de gerenciamento dessas grandes mudanças é chamado de gerenciamento de requisitos, porém irei falar sobre o próximo post sobre levantamento de requisitos.

 

Conclusão

Os requisitos para um sistema estabelecem o que o sistema deve fazer e define as restrições sobre seu funcionamento e implementação.

Vimos que existem dois tipos de requisitos, os funcionais e os não funcionais.

Os requisitos funcionais são declarações dos serviços que o sistema deve fornecer ou descrições de como alguns processamentos devem ser efetuados.

Os requisitos não funcionais costumam restringir o sistema que está sendo desenvolvido e o processo de desenvolvimento utilizado e aplicam-se ao sistema como um todo.

Estes podem ser os requisitos de produto, organizacional ou externos que também podem ser classificados em requisitos menores.

O documento de requisitos de software é uma declaração acordada dos requisitos do sistema e é o resultado palpável do levantamento dos requisitos entre os stakeholders do projeto.

Ele deve ser organizado para que clientes e desenvolvedores possam usar.

 

Gostou do nosso post? Quer saber mais sobre engenharia de requisitos?
Siga nossas redes sociais e fale conosco!


João Felipe Pessanha
Consultor e Arquiteto Java
Trabalha na Clubee Soluções

Certificado Java / Apaixonado por Tecnologia e Pesquisas

 

Deixe uma resposta

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

*