Engenharia de Requisitos

Introdução à engenharia de requisitos

Bem-vindo à videoaula dedicada aos Requisitos de software, abordando os conceitos de Requisitos funcionais e Não funcionais. Esses fundamentos são essenciais para sua prática profissional, pois guiam o desenvolvimento de software, garantindo que as necessidades dos usuários sejam atendidas e que o sistema seja eficiente e confiável. Dominar esses conteúdos é crucial para o sucesso na análise, design e implementação de sistemas de software robustos e eficazes. Prepare-se para fortalecer suas habilidades e se destacar no mercado!

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Um aspecto crucial na elaboração de um projeto de software é a engenharia de requisitos, em que qualquer erro ou omissão pode afetar significativamente o resultado do produto desenvolvido. Esta fase é de extrema importância, pois o sucesso do software depende dela.

O sucesso de um profissional de Tecnologia da Informação (TI) está intimamente ligado à capacidade de compreender as necessidades do cliente (nosso usuário final) e, ainda mais importante, identificar aquilo que o cliente nem mesmo tem consciência de que precisa. Embora possa parecer complexo, existem técnicas que auxiliam na execução dessa etapa fundamental do desenvolvimento de software, capacitando o profissional a compreender e aplicar métodos para especificação, validação e modelagem de requisitos.

O desafio desta aula é aplicar e identificar os processos de engenharia de requisitos, assim como suas técnicas e análises, para atender à demanda de um cliente, que diz respeito ao desenvolvimento de um software para uma empresa que vende produtos e plantas ornamentais. Porém, para realizar essa tarefa, você necessita conhecer os conceitos e as técnicas que serão apresentados.

Para isso, vamos imaginar que você trabalha em uma empresa de desenvolvimento de softwares e, por ser bem detalhista, você ficou encarregado do levantamento de requisitos para a produção de um software para um grande cliente que cultiva e comercializa plantas ornamentais. A fim de conhecer bem as rotinas da empresa, serão necessárias várias visitas, pois, dessa forma, além de conhecer o fluxo de trabalho da companhia, você poderá investigar como funcionam as rotinas de trabalho que, muitas vezes, não são contadas pelos usuários do sistema.

O cliente necessita de um software para atender à crescente demanda por plantas ornamentais, pois todo o processo, com exceção ao realizado pela máquina de cartão de crédito, é feito manualmente e resulta em anotações em muitos cadernos. A empresa possui como meta expandir os negócios através de franquias, mas, para isso, será necessário informatizar todo o processo de compra de plantas ornamentais e realizar um controle das encomendas realizadas por arquitetos e paisagistas. A empresa atende ao público em geral, de modo que consumidores podem comprar (e/ou encomendar) diversos tipos de plantas.

Você, como analista de sistemas, precisa auxiliar o cliente no progresso dessa informatização. Para resolver o problema de falta de conhecimento sobre as rotinas de trabalho da empresa, você foi designado a elaborar uma apresentação com os seguintes questionamentos: o que precisará ser feito? Quais requisitos funcionais podem ser apontados nesta primeira etapa? Determine também requisitos não funcionais que contribuem para atender às expectativas do cliente, classificando-os em “requisitos funcionais” e “não funcionais”.

O primeiro passo para responder as questões acima é estudar esta aula, que contém conhecimentos acerca de procedimentos da engenharia de requisitos, de seus conceitos e tipos.

Vamos Começar!

Conceitos e fundamentos sobre requisitos

Uma das principais dificuldades no desenvolvimento de software é estimar o tempo necessário para sua conclusão. Além disso, garantir que o produto final atenda exatamente às necessidades do cliente é outro desafio crucial. No entanto, esses obstáculos podem ser superados por meio da prática da engenharia de requisitos.

De acordo com Pressman (2021), a engenharia de requisitos engloba um conjunto de atividades que visam produzir e manter um documento, conhecido como documento de requisitos, cujo principal objetivo é especificar o que deve ser implementado antes do início do desenvolvimento do software ou sistema. No entanto, é comum que as empresas comecem a desenvolver partes do software antes mesmo de concluir o levantamento de requisitos.

Sommerville (2018) define a engenharia de requisitos como o processo de descrever todas as funcionalidades que um sistema deve possuir, além de detalhar os serviços e as restrições de funcionamento, refletindo as necessidades dos clientes (usuários do software) e contribuindo para o desenvolvimento de um produto de qualidade. O objetivo principal da engenharia de requisitos é garantir que todas as partes envolvidas no desenvolvimento do sistema tenham uma compreensão compartilhada por escrito do problema. Para isso, são utilizados diversos artefatos que asseguram a qualidade das especificações fornecidas.

Mas, o que é o requisito de um sistema?

Requisito de sistema era definido como uma função que o software deveria ter ou uma qualidade que ele deveria apresentar. Atualmente, além da função e da qualidade, os requisitos de um sistema abrangem especificações dos serviços que ele deve fornecer, restrições que deve possuir, características gerais e restrições que devem ser atendidas no seu processo de desenvolvimento (Pfleeger, 2004).

Dando sequência a nossa tratativa sobre a engenharia de requisitos, suponha que você precise criar um jogo on-line de perguntas e respostas para treinar seus conhecimentos para um concurso. Nessa situação, podemos elencar alguns exemplos de requisitos:

1. O jogador deverá realizar um cadastro antes de jogar, criando um apelido, senha, e-mail e escolher um avatar.
2. O jogo deverá ter várias fases, apresentando graus de dificuldade.
3. O jogador deverá escolher uma ou mais áreas de conhecimento.
4. As questões deverão ser classificadas em vários níveis de dificuldade.

Note que os requisitos são redigidos de forma que tanto o cliente quanto os desenvolvedores possam compreender claramente o que o software deve realizar. É importante evitar enunciados muito extensos ou subjetivos; eles devem ser concisos e consistentes, garantindo que todas as partes envolvidas entendam claramente o que será entregue. O Quadro 1 lista as qualificações que os requisitos devem atender.

QUALIFICAÇÃO	DESCRIÇÃO
Exatidão	Todo requisito precisa ser um requisito do produto a ser desenvolvido.
Precisão	Todo requisito possui apenas uma única interpretação, aceita tanto pelos desenvolvedores quanto pelos clientes (usuários).
Completude	Todo requisito reflete as decisões de especificação que foram acordadas entre as partes envolvidas.
Consistência	Não pode haver conflitos entre os requisitos e qualquer um dos seus subconjuntos.
Priorização	Todo requisito é rotulado de acordo com a sua importância, estabilidade e complexidade.
Verificabilidade	Demonstra a conformidade do produto final com cada requisito elencado.
Modificabilidade	O requisito deve ter estrutura e estilo que permitam mudança de maneira fácil, completa e consistente.
Rastreabilidade	Permite a determinação dos antecedentes e das implicações de todos os requisitos.

Quadro 1 | Qualificação dos requisitos. Fonte: adaptado de Paula Filho (2019, [s. p]).

Destacar um fator no levantamento de um requisito é determinar a sua prioridade, a qual possuirá denominações diferenciadas de acordo com a literatura consultada, podendo cada empresa adotar a sua terminologia. Os requisitos são classificados como: essencial, importante ou desejável, conforme afirma Pfleeger (2004).

Um requisito classificado como essencial é de suma importância para o funcionamento do software, sendo vital para sua completude. Sem esse requisito, o programa ficaria incompleto, impossibilitando sua implantação ou conclusão. Para ilustrar, podemos considerar o exemplo de um aluno que só pode acessar uma disciplina se estiver devidamente matriculado nela. Nesse caso, é evidente que o acesso às disciplinas é restrito e essencial para a funcionalidade do software.

Um requisito classificado como importante é aquele que não é crucial para a implantação do software, podendo ser realizado em segundo plano. Embora desejável, não é indispensável. Por exemplo, a criptografia das senhas dos usuários em um sistema acadêmico é importante, mas, se não for implementada inicialmente, o sistema ainda pode ser implantado e atualizado posteriormente com essa funcionalidade.

Já um requisito classificado como desejável não é essencial para a conclusão do software; é opcional e pode até ser descartado durante o desenvolvimento. Um exemplo seria a contagem de tempo de acesso dos alunos em um sistema acadêmico, utilizado para determinar a duração do uso do sistema por cada usuário durante o semestre. Esse requisito, classificado como desejável, pode ser deixado de lado caso haja atrasos no desenvolvimento e seja necessário priorizar a implantação do software.

As prioridades de cada requisito devem ser determinadas durante a definição do escopo do projeto, entretanto vale ressaltar que essas prioridades podem mudar com a evolução do sistema.

Siga em Frente...

Tipos de Requisitos

Na engenharia de requisitos é importante fazer uma distinção dos diferentes tipos de descrições dos requisitos conforme afirma Sommerville (2018). Eles podem ser classificados como:

• Requisitos do usuário: estes delineiam tanto os requisitos funcionais quanto os não funcionais do sistema, utilizando uma linguagem compreensível para os usuários finais (clientes). Eles destacam as funcionalidades e as restrições que o sistema deve apresentar. O resultado é a criação de um documento que não se aprofunda em detalhes técnicos do sistema, mas sim facilita a comunicação entre os desenvolvedores e os clientes.
• Requisitos do sistema: estes especificam os detalhes do sistema, baseados nos requisitos do usuário, resultando em um documento que pode servir como parte do contrato entre todas as partes envolvidas no desenvolvimento do sistema. Este estágio marca o início do projeto.

Determinar o tipo de requisito em um sistema pode ser uma tarefa extenuante, e um requisito pode ser classificado inicialmente como de um tipo e, no decorrer no projeto, pode sofrer alterações e receber outra classificação, podendo gerar, ainda, uma série de novos requisitos.

De acordo com Sommerville (2018) e Pressman (2021), os requisitos de um sistema podem ser agrupados em três categorias principais: requisitos funcionais, requisitos não funcionais e requisitos de domínio:

• Requisitos funcionais: estes especificam de forma clara e precisa as funcionalidades específicas que o sistema deve executar ou não. Eles descrevem as ações que o sistema deve realizar em resposta a entradas específicas do usuário ou de outros sistemas.
• Requisitos não funcionais: estes impõem restrições sobre as funcionalidades do sistema, definindo padrões específicos de desenvolvimento, plataforma, tempos de resposta e restrições de acesso. Eles estão relacionados às qualidades que o sistema deve apresentar, como desempenho, segurança, usabilidade e escalabilidade.
• Requisitos de domínio: estes determinam as características do domínio do sistema, refletindo as particularidades do ambiente em que o sistema será utilizado. Eles podem impor restrições aos requisitos funcionais ou fornecer cálculos específicos sobre determinados requisitos com base no contexto do domínio do sistema.

Os requisitos funcionais delineiam os objetivos específicos do sistema, ou seja, as características que ele deve possuir ao término de seu desenvolvimento. Esses requisitos devem englobar todas as funcionalidades e informações fornecidas pelo cliente antes da implementação do software. Para identificá-los, utilizamos a sigla RF (requisito funcional) seguida de uma numeração (Sommerville, 2018). Abaixo estão exemplos de requisitos funcionais para um sistema de controle acadêmico fictício:

• [RF0001] - O sistema deve manter os dados pessoais e acadêmicos dos alunos.
• [RF0002] - O sistema deve permitir que o aluno faça a matrícula por disciplina.
• [RF0003] - O sistema deverá manter os dados (pessoais e profissionais) dos professores, especialmente dos seguintes atributos: CPF, RG, nome, endereço (completo), data de nascimento, telefones para contato, e-mail (pessoal e corporativo), nacionalidade, data de admissão, data de demissão, valor da hora-aula, carga horária.
• [RF0004] - O sistema deve permitir a visualização das notas cadastradas.
• [RF0005] - O professor poderá cadastrar as notas no sistema de acordo com o calendário acadêmico (previamente cadastrado na plataforma).

O nível de detalhamento de um requisito desempenha um papel crucial na comunicação com o cliente, ajudando a esclarecer o que precisa ser realizado no sistema. Além disso, facilita a programação da funcionalidade correspondente, pois fornece uma orientação clara ao programador. Portanto, um detalhamento minucioso é essencial para eliminar ambiguidades e garantir que todos compreendam claramente o que está sendo solicitado.

É importante notar que o requisito funcional [RF0003] possui um nível de detalhamento mais elevado em comparação com [RF0001]. Embora o detalhamento seja fundamental nessa fase, cada requisito deve ser específico. Por exemplo, se estamos discutindo informações dos alunos em um requisito, não devemos incluir dados dos professores no mesmo requisito.

Os requisitos não funcionais são identificados pela sigla RFN e estabelecem critérios para qualificar os requisitos funcionais. Esses requisitos abordam aspectos relacionados à qualidade, desempenho, confiabilidade, usabilidade, implementação, entre outros. É importante ressaltar que um único requisito não funcional pode resultar em vários requisitos funcionais. A seguir, apresentamos alguns exemplos de requisitos não funcionais para um sistema acadêmico fictício:

• [RNF0001] - O tempo de espera do aluno para visualizar as notas, não poderá exceder os sete segundos.
• [RNF0002] - O sistema deverá ser implementado utilizando a linguagem de programação JAVA.
• [RNF0003] - As notas só poderão ser lançadas por profissionais da empresa com o perfil de professor.
• [RNF0004] - Todas as cores do sistema deverão obedecer ao padrão de cores da instituição: laranja (RGB: 255,140,0), cinza (RGB: 211,211,211) e branco (RGB: 248,248,255).
• [RNF0005] - Todos os relatórios devem ser gerados com as cores do sistema, logomarca da instituição, com data e hora da geração; devem ser gerados no formato PDF.

Uma recomendação importante para saber se a especificação do requisito é um requisito não funcional é observar se o assunto tratado pode ser mensurado (velocidade, tempo, linguagens, versões); caso seja, possivelmente será um requisito não funcional, conforme Paula Filho (2019). Observe o Quadro 2 com métricas que auxiliam na identificação e especificação de requisitos não funcionais.

PROPRIEDADE	MÉTRICA
Velocidade	Quantidade de transações realizadas por segundo. Tempo de resposta ou atualização do sistema.
Tamanho	Megabytes ou gigabytes ocupados. Quantidade de RAM. Quantidade de espaço em disco ou nuvem.
Usabilidade	Tempo de treinamento (horas necessárias). Quantidade de telas de ajuda.
Confiabilidade	Tempo médio para falhar. Probabilidade de indisponibilidade. Taxa de ocorrência de falhas. Disponibilidade.
Robustez	Percentual de eventos que causam falhas e o tempo necessário para o sistema se reestabelecer. Determinar as possibilidades de que os dados sejam corrompidos.
Portabilidade	Quantidade de adaptações para o sistema funcionar em diferentes plataformas (Sistema Operacional).

Quadro 2 | Métricas de requisitos não funcionais. Fonte: adaptado de Sommerville (2018, p. 94).

Os requisitos não funcionais são categorizados com base em três grandes áreas de requisitos:

1. Requisitos do produto: estes especificam ou restringem o comportamento do sistema e podem incluir determinações sobre a linguagem de programação a ser utilizada.
2. Requisitos organizacionais: estes são derivados das políticas e procedimentos da empresa, do cliente e do desenvolvedor.
3. Requisitos externos: estes englobam todos os fatores externos ao sistema que podem influenciar no seu desenvolvimento, desde que estejam em conformidade com a legislação vigente.

A classificação completa dos requisitos não funcionais pode ser visualizada na Figura 1.

Os requisitos de domínio descrevem características específicas e estabelecem condições adicionais aos requisitos funcionais, indicando, por exemplo, critérios obrigatórios para a validação de um requisito. Eles podem consistir em novos requisitos funcionais ou em complementos que impõem restrições adicionais aos requisitos existentes.

Um exemplo de requisito de domínio seria o seguinte cenário: um aluno será considerado aprovado se alcançar, no mínimo, 3000 pontos nas avaliações semestrais e 4000 pontos nas atividades complementares de cada disciplina. Este requisito estabelece duas condições: a pontuação mínima nas avaliações deve ser de 3000 pontos e a pontuação mínima nas atividades complementares deve ser de 4000 pontos. Ambas as condições devem ser cumpridas para que o aluno seja considerado aprovado no sistema.

Papel da engenharia de requisitos no ciclo de vida do projeto

As atividades do processo da engenharia de requisitos envolvem a coleta de informações sobre o software (sistema) a ser realizado, a análise do problema e, em seguida, a descrição dos requisitos, classificação e priorização, sendo que logo após isso é gerada a especificação desses requisitos (Pressman, 2021). Tais processos podem ser melhor visualizados na Figura 2.

Todas as atividades relacionadas à engenharia de requisitos têm como objetivo principal a elaboração de um documento de requisitos, como destacado por Sommerville (2018) e Pressman (2021). Estas atividades abrangem as seguintes etapas:

1. Concepção: define-se o escopo geral do sistema e identificam-se todos os stakeholders envolvidos.
2. Elicitação: realiza-se a coleta de requisitos funcionais e não funcionais, utilizando técnicas como entrevistas, observação e pesquisa.
3. Elaboração: detalha-se cada requisito inicialmente expresso em linguagem natural, transformando-os em modelos conceituais, muitas vezes utilizando a Linguagem Unificada de Modelagem (UML), com o objetivo de eliminar erros, omissões, duplicações e inconsistências.
4. Negociação: identificam-se e tratam-se requisitos conflitantes, realizando-se negociações entre as partes envolvidas para ajustar e/ou eliminar tais requisitos.
5. Especificação: transformam-se os requisitos em uma visão mais detalhada do sistema, considerando o desenvolvimento da solução.
6. Validação: realiza-se a validação dos requisitos pelos usuários relevantes, verificando se todas as necessidades foram atendidas, sob a perspectiva do cliente.
7. Gerenciamento: consiste na verificação contínua, ao longo do processo, da conformidade dos requisitos com o escopo do projeto, bem como na garantia da rastreabilidade, que envolve o controle de possíveis alterações que os requisitos possam sofrer.

Essa etapa permeia todo o ciclo de vida do produto e consiste em dois aspectos fundamentais. Várias atividades envolvem o processo de engenharia de requisitos. A partir de uma análise inicial do problema do cliente, na qual é realizada a compressão do domínio do problema, realiza-se a fase do levantamento dos requisitos, atividade que dará suporte a todas as etapas da engenharia de requisitos. Após isso, realiza-se a classificação, a priorização e a documentação dos requisitos. A participação do cliente e dos usuários finais do sistema é fundamental para a validação dos requisitos levantados. Deve-se também, inserir atividades de controle de qualidade em todas as etapas para validar os requisitos e garantir a qualidade do que está sendo projetado. E, como tudo é dinâmico em um projeto de software, os requisitos podem sofrer alterações, sendo necessário um processo de gerenciamento para validar as evoluções dos requisitos funcionais e não funcionais a fim de manter o controle dessa evolução.

Resumidamente, os requisitos funcionais delineiam as funcionalidades, os comportamentos e as características de entrada e saída de um sistema, enquanto os requisitos não funcionais se referem aos atributos e qualidades do sistema.

Os requisitos são o cerne de qualquer software. Antes de iniciar o desenvolvimento de um sistema, é crucial criar uma lista de funcionalidades e características que ele deve possuir - esses são os requisitos iniciais. No entanto, o processo não termina aí. Convido você a explorar ainda mais a engenharia de requisitos. 

Vamos Exercitar?

Retomando a situação-problema do início da aula, você foi escolhido para fazer parte da equipe de analistas cuja meta é elencar os requisitos de um software para um cliente, dono de uma empresa de plantas ornamentais que possui como objetivo expandir os negócios através de franquias. Para isso, será necessário informatizar todo o processo de compra de plantas ornamentais dos fornecedores, controlar as encomendas realizadas por arquitetos e paisagistas e, como a empresa também fornece o serviço de decoração paisagista (doméstico e empresarial), é necessário também um controle desses processos. A empresa atende ao público em geral, de modo que consumidores podem comprar (e/ou encomendar) diversos tipos de plantas. Assim sendo, alguns questionamentos foram realizados e precisam ser respondidos.

Para resolver o problema de falta de conhecimento sobre as rotinas de trabalho da empresa, o que você precisará fazer?

Para solucionar este problema, o primeiro passo é visitar o cliente e conversar com os usuários que utilizarão o software. Desta forma, poderemos conhecer a rotina da empresa, conversando com as pessoas, ficando atentos às atividades que elas realizam, sendo curiosos e perguntando sempre que houver dúvidas. Dica: anotar tudo e, se possível, recolher cópias de documentos que são utilizados.

Durante as visitas, foram realizadas várias entrevistas e foram coletados vários documentos, como listas de anotações de pedidos aos fornecedores, encomendas de clientes e a lista de plantas disponíveis para a venda.

Quais requisitos funcionais podem ser apontados nesta primeira etapa?

Aqui é preciso determinar requisitos não funcionais que contribuem para atender às expectativas do cliente, classificando-os em requisitos funcionais e não funcionais.

Após as visitas realizadas, pode-se listar alguns requisitos funcionais:

• [RF0001] - O sistema deverá manter (incluir, consultar, alterar e excluir) os dados dos clientes: nome, endereço, CPF ou CNPJ, e-mail, telefones.
• [RF0002] - O sistema deve gerar um relatório das plantas disponíveis para venda.
• [RF0003] - O sistema deve permitir que sejam cadastrados os pedidos de encomenda de plantas e produtos da empresa.
• [RF0004] - O sistema deve autorizar a inclusão de pedidos de jardinagem, permitindo a escolha das plantas e demais produtos.
• [RF0005] - O sistema deverá manter o cadastro de todos os produtos da empresa.
• [RF0006] - O sistema deverá manter as informações botânicas das plantas.
• [RF0007] - O sistema deverá emitir relatórios sobre as encomendas, situação do estoque, trabalhos paisagísticos em andamento e finalizados.
• [RF0008] - O sistema deverá manter o cadastro de todos os fornecedores.
• [RF0009] - O sistema deverá emitir um relatório das plantas que podem ser plantadas, sendo estas classificadas por época do ano, tipos de terrenos e tipos de construção.
• [RF0010] - O sistema deverá manter um cadastro dos usuários do sistema, classificando-os como: vendedor, administrador e supervisor.

Pode-se elencar os seguintes requisitos não funcionais:

• [RNF0001] - O sistema deverá ser realizado na linguagem de programação JAVA.
• [RNF0002] - O tempo de espera dos relatórios não poderá ultra- passar os seis segundos.
• [RNF0003] - As telas do sistema devem ter cores claras (tom pastel) e ícones grandes.
• [RNF0004] - O sistema deverá utilizar o banco de dados MySQL.
• [RNF0005] - Apenas usuários classificados como supervisor e administrador poderão gerar os relatórios sobre as encomendas.

Observe que os requisitos funcionais sempre aparecem em maior quantidade do que os requisitos não funcionais. Isso é natural, até porque qualquer software deverá ter muitas funcionalidades e todas devem ser descritas de forma individualizada. Foram listados alguns requisitos, mas será que você não consegue identificar mais alguns? 

Saiba Mais

O livro de Pressman oferece insights valiosos sobre a Engenharia de Requisitos, portanto acesse o Capítulo 7.1 do livro Engenharia de Software – Pressman e leia mais sobre o tema:

PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software. Grupo A, 2021.

Para saber mais sobre os requisitos funcionais e não funcionais, leia o Capítulo 4.1 do livro  Engenharia de Software – Sommerville:

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo, SP: Pearson, 2018. 

Acesse o artigo Requisitos de Software: Um Guia Abrangente para o Desenvolvimento de Sistemas de Sucesso para entender mais sobre a que importância de requisitos, os tipos, processos e melhores práticas para o desenvolvimento de sistemas de sucesso.  

ALMEIDA, B. Requisitos de Software: Um Guia Abrangente para o Desenvolvimento de Sistemas de Sucesso. Data Perspective. 2023. 

Referências Bibliográficas

PAULA FILHO, W. P. Engenharia de software: produtos. 4. ed. Rio de Janeiro: LTC, 2019.

PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018. 

Elicitação e análise de requisitos

Bem-vindo à videoaula essencial sobre Identificação, Elicitação e Validação de Requisitos. Estes pilares da Engenharia de Requisitos são importantes para sua prática profissional, fornecendo as bases para entender, coletar e garantir a qualidade dos requisitos de software. Dominar esses conceitos é fundamental para o sucesso na análise e desenvolvimento de sistemas de software que atendam às necessidades dos clientes. Prepare-se para adquirir habilidades valiosas e impulsionar sua carreira na área de desenvolvimento de software.

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

O processo de desenvolvimento de um software é muito dinâmico, tudo pode mudar rapidamente. Um cliente pode mudar de ideia e esperar que o software a ser desenvolvido tenha características diferentes do início do desenvolvimento. Precisamos deixar o cliente satisfeito, porém, nós, como desenvolvedores, precisamos garantir que os requisitos sejam executados conforme o contratado.

Você sendo detalhista em requisitos de software ficou encarregado do levantamento dos requisitos para o desenvolvimento de um software para um cliente que cultiva e comercializa plantas ornamentais. Foram realizadas diversas visitas ao cliente e foram identificados vários requisitos funcionais e não funcionais:

Requisitos funcionais:

• [RF0001] - O sistema deverá manter (incluir, consultar, alterar e excluir) os dados dos clientes: nome, endereço, CPF ou CNPJ, e-mail, telefones.
• [RF0002] - O sistema deve gerar um relatório das Plantas disponíveis para venda.
• [RF0003] - O sistema deve permitir que sejam cadastrados os pedidos de encomenda de plantas e produtos da empresa.
• [RF0004] - O sistema deve permitir a inclusão de pedidos de jardinagem, permitindo a escolha das plantas e demais produtos.
• [RF0005] - O sistema deverá manter o cadastro de todos os produtos da empresa.
• [RF0006] - O sistema deverá manter as informações botânicas das plantas.
• [RF0007] - O sistema deverá emitir relatórios sobre as encomendas, situação do estoque, trabalhos paisagísticos em andamento e finalizados.
• [RF0008] - O sistema deverá manter o cadastro de todos os fornecedores.
• [RF0009] - O sistema deverá emitir um relatório das plantas que podem ser plantadas classificadas por época do ano, tipos de terrenos e tipos de construção.
•  [RF0010] - O sistema deverá manter um cadastro dos usuários do sistema, classificando-os como: Vendedor, Administrador e Supervisor.

Requisitos não funcionais:

• [RNF0001] - O sistema deverá ser realizado na linguagem de programação JAVA.
• [RNF0002] - O tempo de espera dos relatórios não poderá ultrapassar os 6 segundos.
• [RNF0003] – As telas do sistema devem apresentar cores claras (tom pastel) e ícones grandes.
• [RNF0004] - O sistema deverá utilizar o banco de dados MySQL.
• [RNF0005] - Apenas usuários classificados como Supervisor e Administrador poderão gerar os relatórios sobre as encomendas.

Seu desafio é determinar como será feita a coleta de dados para obter o máximo de informações sobre o software a ser desenvolvido para o controle de venda de plantas ornamentais. Quais os passos para realizar a elicitação dos requisitos? De que forma os requisitos elencados (os citados e os novos que você inseriu) podem ser especificados?

Elabore uma tabela com os requisitos encontrados (e supralistados) e adicione novos requisitos funcionais e não funcionais.

Vamos Começar!

Técnicas e abordagens para identificar, coletar e compreender os requisitos junto aos stakeholders

Na engenharia de requisitos, a elicitação de requisitos consiste em obter o máximo de informações, seja por meio de extrair dados de fontes ou de interações com indivíduos relevantes, a fim de estabelecer os requisitos de um sistema específico. Essa etapa é fundamental e uma das primeiras na disciplina de Engenharia de Requisitos, conforme delineado por Pressmann (2021).

O processo de elicitação de requisitos não é realizado isoladamente pelo analista de sistemas; ele envolve a colaboração de várias pessoas, conhecidas como stakeholders, que incluem todos os interessados no projeto. Segundo Pressman (2021), a elicitação de requisitos envolve a combinação de elementos para resolver problemas, requerendo uma abordagem colaborativa dos stakeholders. Sommerville (2018) ressalta que os stakeholders são as partes interessadas no projeto, que podem incluir analistas de sistemas, gerentes de projetos, programadores, clientes (contratantes) e usuários finais do sistema.

No processo de elicitação de requisitos, é crucial ter perspectivas diversas sobre as funcionalidades do sistema, e os stakeholders devem participar da elicitação para garantir a ausência de requisitos contraditórios. Estes, se não forem resolvidos antes do desenvolvimento, podem acarretar problemas durante a entrega do produto final. A partir das questões e necessidades dos stakeholders, a elicitação de requisitos visa realizar as seguintes tarefas (PRESSMANN, 2021):

• Especificar o escopo do problema do sistema.
• Avaliar as oportunidades de reutilização de soluções existentes.
• Identificar os stakeholders diretamente envolvidos com o sistema.
• Elicitar e qualificar os requisitos do sistema.
• Analisar os requisitos elicitados.
• Validar os requisitos elicitados.

A engenharia de requisitos abrange todas as etapas que colaboram para a elaboração de um documento de requisitos e sua subsequente manutenção ao longo do ciclo de vida do projeto. Os procedimentos fundamentais de levantamento e análise de requisitos de um sistema incluem as seguintes atividades (SOMMERVILLE, 2018):

1. Concepção ou entendimento do domínio: consiste em estabelecer uma compreensão básica do problema a ser abordado. É essencial que todos os stakeholders tenham uma compreensão clara do que será realizado, incluindo os limites do que será e do que não será realizado.

2. Coleta e classificação de requisitos (elicitação): envolve todas as atividades destinadas a identificar o máximo de requisitos dos stakeholders. Os requisitos são então classificados em funcionais e não funcionais.

3. Negociação de requisitos: neste estágio, após a lista de requisitos ter sido compilada, é crucial determinar se há conflitos entre eles. Por exemplo:

• RF0025 - O cliente deve ter uma senha para acessar o sistema.
• RF0078 - Não é necessário que um cliente tenha uma senha para acessar o sistema.

Observe que o requisito RF0078 contradiz completamente o requisito RF0025. Como lidar com essa situação? Provavelmente, durante a coleta de requisitos, um stakeholder solicitou acesso com senha para os clientes, enquanto outra pessoa envolvida no projeto indicou que o uso de senha era desnecessário. O procedimento para resolver esse impasse envolve convocar as partes envolvidas para resolver o conflito, realizando as seguintes análises:

• Verificação de requisitos: todos os requisitos são analisados para garantir que estejam alinhados com as necessidades dos stakeholders.
• Definição de prioridades: é feita a determinação dos requisitos mais importantes, que requerem total atenção para o sucesso do projeto.

4. Validação dos requisitos: uma verificação abrangente dos requisitos é realizada, resultando em um "termo de aceitação" no qual todas as partes envolvidas (stakeholders do sistema projetado) concordam e validam os requisitos.

5. Documentação: este é o resultado da Engenharia de Requisitos, no qual é gerado um documento contendo todas as especificações dos requisitos funcionais e não funcionais. Esse documento serve como o principal meio de comunicação entre o analista de sistemas ou engenheiro de software e o cliente.

A Figura 1 ilustra o processo de levantamento e análise de requisitos. É evidente que a partir da compreensão do domínio do que será efetivamente realizado no sistema, ocorre a coleta e classificação de requisitos, com o propósito de determinar o que será implementado no sistema, facilitando sua organização para melhor controle. A negociação entra em cena para estabelecer os ajustes necessários e auxiliar na definição das prioridades durante o desenvolvimento. A especificação marca o início da documentação dos requisitos, enquanto a validação consiste em uma verificação geral de todos os requisitos, com o objetivo final de documentar os requisitos de forma precisa.

O levantamento e a análise de requisitos, proposto por Sommerville (2018), é um processo de validação continuada. A Figura 1 demonstra essa sequência dos processos, entretanto, basta alguma alteração em um requisito para que o ciclo deve ser repetido, de forma iterativa e contínua, até a finalização do projeto

Elicitação de requisitos

O processo de elicitação de requisitos pode variar entre as empresas, pois cada uma possui seus próprios métodos e procedimentos de elicitação. De acordo com Sommerville (2018), as atividades do processo de elicitação de requisitos incluem:

1. Descoberta de requisitos: uma atividade interativa com a participação ativa dos stakeholders, onde os usuários finais do sistema contribuem com sua experiência para auxiliar na coleta dos requisitos do sistema.

2. Classificação e organização de requisitos: consiste em agrupar os requisitos para identificar se há repetições ou se eles pertencem a subsistemas específicos.

3. Priorização e negociação de requisitos: em colaboração com os stakeholders, estabelece-se a prioridade de cada requisito (essencial, importante ou desejável), ajudando a definir as etapas mais críticas do desenvolvimento do sistema.

4. Especificação de requisitos: nesta fase, os requisitos são documentados, podendo ser em formatos formais ou informais.

A elicitação de requisitos tem por objetivo conseguir o máximo de requi- sitos do sistema a ser desenvolvido, destacando as seguintes técnicas:

• Pesquisa: envolve a observação de como funciona a rotina dos processos do sistema e de outros softwares utilizados, visando procurar requisitos que não foram explicitamente solicitados. Envolve também a pesquisa pela tecnologia solicitada.
• Entrevista: tipicamente conduzida com um questionário para identificar as necessidades que o sistema deve atender. Nesta fase, é crucial praticar a escuta ativa e registrar o máximo de informações obtidas.
• Reuniões: utilizando técnicas como o brainstorming para identificar requisitos que ainda não foram determinados e resolver conflitos de requisitos surgidos durante as entrevistas.
• Documentos: coleta de documentos que possam esclarecer as funcionalidades do sistema, tais como relatórios, planilhas, registros em papel, cadernos de anotações, entre outros.
• Etnografia: observação e análise do verdadeiro modo de trabalho dos usuários finais (em contraste com o que eles possam expressar), resultando na identificação de requisitos significativos para o sistema.

A especificação de requisitos consiste na formalização e abstração das funcionalidades que o software deve executar, utilizando descrições claras e objetivas. Esse processo de sistematização busca caracterizar o problema a ser resolvido, resultando na elaboração de um documento de especificação de requisitos. De acordo com Pfleeger (2004), a melhor abordagem para iniciar a especificação de requisitos é adotar uma estrutura hierárquica, começando pelos atributos gerais do sistema e, em seguida, detalhando progressivamente em subníveis até alcançar os atributos mais específicos.

A especificação de requisitos serve como o canal de comunicação entre o analista de sistemas e os programadores responsáveis pelo desenvolvimento do software. É crucial que os requisitos sejam especificados de maneira que não haja margem para interpretações divergentes, uma vez que o programador utilizará essa especificação como base para implementar exatamente o que está descrito. A especificação de requisitos abrange todas as funcionalidades e suas respectivas restrições, tanto funcionais quanto não funcionais, geralmente apresentadas em tabelas ou documentos específicos, podendo também incluir diagramas de casos de uso para facilitar a compreensão ou a utilização de prototipagem.

Os casos de uso são diagramas que compõem a Linguagem Unificada de Modelagem, conhecida como UML (Unified Modeling Language),  são uma técnica fundamental na engenharia de requisitos, usada para capturar os requisitos funcionais de um sistema de forma clara e compreensível. Eles descrevem interações entre atores (usuários ou sistemas externos) e o sistema em questão, apresentando cenários detalhados de como o sistema será utilizado para alcançar determinados objetivos. Esses casos de uso ajudam a definir o escopo do sistema, identificar requisitos específicos e fornecer uma visão geral das principais funcionalidades esperadas. Além disso, são uma ferramenta valiosa para comunicação entre stakeholders, permitindo que todos compreendam e validem os requisitos do sistema de forma eficaz.

De acordo com Paula Filho (2019), a prototipagem consiste na criação de uma versão simplificada do sistema a ser desenvolvido, baseada no princípio da verificação do custo-benefício, em que a experiência do usuário desempenha um papel crucial no processo de prototipagem. Além disso, o mesmo autor destaca várias vantagens associadas à técnica de prototipagem: (i) possibilita a identificação precoce de problemas; (ii) permite verificar se os requisitos do software atendem às necessidades dos clientes; (iii) aprimora a comunicação com o cliente, apresentando o progresso do software; (iv) facilita a realização de testes para avaliar a aceitação do software pelo cliente, juntamente com o feedback fornecido pelo cliente.

Na técnica da prototipagem, é possível antecipar vários problemas, permitindo uma melhor estimativa do tempo necessário para resolvê-los. Pfleeger (2004) categoriza a prototipagem em três abordagens distintas:

• Protótipo descartável: desenvolvido com o propósito de explorar o problema a ser solucionado e avaliar a viabilidade da solução. Este tipo de protótipo não é utilizado posteriormente, sendo descartado após a fase exploratória.
• Protótipo evolutivo: criado quando os clientes têm dúvidas sobre alguma parte do software, geralmente relacionada à interface gráfica. Esse tipo de protótipo é integrado ao software final.
• Prototipagem rápida: construção de partes do software para avaliar a viabilidade dos requisitos. Nesta abordagem, o objetivo é determinar se a implementação do projeto é viável.

A negociação de requisitos tem como finalidade, conforme destacam Pressman (2021), desenvolver um plano de projeto que atenda às demandas dos envolvidos (stakeholders) e, ao mesmo tempo, analisa as restrições no que diz respeito ao orçamento, pessoal, tecnologia e/ou tempo, impostas à equipe de desenvolvimento do software.

Siga em Frente...

Monitoramento e validação de requisitos

O monitoramento de requisitos é um processo essencial para assegurar que o escopo do software desenvolvido seja alcançado. A cada modificação em um ou mais requisitos, é fundamental garantir a rastreabilidade das alterações, utilizando ferramentas de controle adequadas. Por exemplo, é necessário determinar o status de cada requisito (proposto, em progresso, em revisão, adiado, excluído, aprovado, etc.) e criar uma matriz de rastreabilidade para facilitar o gerenciamento dos requisitos. Essa matriz deve incluir todos os requisitos, suas dependências, o status atual, os responsáveis pela modificação e aprovação dos requisitos, e, especialmente, as datas relevantes de cada evento ocorrido.

Toda mudança, por mínima que seja, em um requisito deve ser cuidadosamente gerenciada para evitar duplicações. Na Figura 2, é possível visualizar o processo de gestão de mudanças de requisitos, que visa garantir a rastreabilidade das alterações durante o desenvolvimento do software. Este processo inclui a análise de impacto das mudanças propostas para determinar sua viabilidade técnica e financeira (SOMMERVILLE, 2018). Muitas vezes, a pressa em alterar uma funcionalidade no sistema em desenvolvimento pode comprometer a gestão de mudanças de requisitos, pois a modificação é realizada sem que a documentação dos requisitos seja devidamente atualizada, resultando em inconsistências e tornando a documentação dos requisitos desatualizada.

O processo de validação dos requisitos determina que a especificação é consistente com a definição dos requisitos, assegurando que os requisitos propostos atenderão às necessidades impostas pelo cliente, de acordo com Pfleeger (2004).

Durante o processo de validação de requisitos podem existir diferentes tipos de verificação (SOMMERVILLE, 2018):

• Validade: verificar se os requisitos contemplam os objetivos do projeto.
• Consistência: garantir que um requisito não entre em conflito com outro requisito.
• Completude: deve haver requisitos que garantam as funcionalidades esperadas pelos usuários do sistema.
• Realismo: ter certeza de que a tecnologia utilizada atenda as demandas do sistema projetado.
• Ambiguidade: o requisito não pode ter mais de uma interpretação.
• Verificável: o requisito deve ser passível de verificação através de testes.
• Rastreabilidade: cada requisito deve ter origem clara e bem definida

O propósito da validação de requisitos é identificar falhas nos requisitos documentados. Pressman (2018) ressaltam que erros comuns nos sistemas incluem inconsistências, contradições, duplicações, ambiguidades, omissões e imprecisões. Para validar os requisitos, algumas perguntas fundamentais podem ser feitas:

• Os requisitos estão de acordo com objetivos globais do sistema?
• O requisito foi bem especificado, fornecendo detalhes apropriados de forma clara e concisa?
• O requisito é realmente necessário? Está com a sua classificação correta?
• O requisito não está em conflito com outro requisito?
• O modelo de requisito reflete adequadamente a informação, comportamento e funcionalidade do sistema?

O nível de detalhamento das perguntas pode ser ampliado e aprofundado de acordo com a complexidade do sistema a ser desenvolvido. Em muitos casos, será necessário realizar uma investigação mais aprofundada e formular mais perguntas para determinar a precisão dos requisitos. É importante ressaltar que o principal objetivo da validação de requisitos é a detecção e eliminação de erros que possam resultar em atrasos e aumento de custos, tanto durante a produção do software quanto para o cliente.

Um recurso que pode contribuir para garantir a qualidade da validação de requisitos é o checklist, uma lista de perguntas elaborada para analisar cada requisito do sistema. Essa técnica tem como objetivos: (i) identificar erros em diversos níveis, como função, lógica e implementação; (ii) verificar se o sistema atende aos requisitos especificados; (iii) assegurar que o software desenvolvido foi implementado conforme os padrões previamente estabelecidos. 

Vamos Exercitar?

O desafio desta aula é determinar como será feita a coleta de informações, a fim de obter o máximo de informação sobre o software a ser desenvolvido para o controle de venda de plantas ornamentais. A meta agora é determinar como será realizada a coleta de dados para obter o máximo de informação sobre o software a ser desenvolvido. Quais os passos para realizar a elicitação dos requisitos? De que forma os requisitos elencados (os citados e os novos que você inseriu) podem ser especificados?

1. Como será feita a coleta de dados para obter o máximo de informação sobre o software a ser desenvolvido e conseguir realizar a elicitação dos requisitos?

Para responder essa pergunta, primeiro teremos que analisar os requisitos elencados após as visitas realizadas no cliente e responder:

• Serão somente esses requisitos? Provavelmente não, pode haver uma lista maior de requisitos. Observe que não foi informado nada a respeito dos trabalhos paisagísticos realizados pela empresa. Será necessário guardar informações sobre esse assunto?
• As informações dos requisitos são suficientes? Provavelmente, a resposta também será não. Observe que foram mencionados nos requisitos anteriores: fornecedores, funcionários, plantas, encomendas, porém não há informação que complete o requisito. Procure por mais informações sobre os usuários que utilizarão o software.

A coleta deverá envolver: (i) pesquisa: examinando com os usuários envolvidos para obter mais informações sobre o que falta em cada requisito; (ii) observação: mesmo que algo não é solicitado explicitamente, você deverá observar para que não haja contradições entre o que é feito e o que dito; e (iii) entrevistas: converse informalmente com os futuros usuários procurando saber o que realmente é importante ter no sistema a ser desenvolvido e, caso necessário, providencie entrevistas estruturadas (já com as perguntas pré-realizadas).

2. Como especificar os novos requisitos funcionais e não funcionais elencados?

Você precisará adotar técnicas para especificar os requisitos. Analise as seguintes dicas:

• Estimule a participação dos stakeholders.
• Escreva os requisitos de forma simples e objetiva.
• Evite o excesso de detalhamento nos requisitos, pois isso dificulta a leitura e a compreensão.
• Tenha como foco resolver o problema do cliente.

Exemplo de uma boa especificação: [RF0001] – O sistema deverá manter (incluir, consultar, alterar e excluir) os dados dos clientes: nome, endereço, CPF ou CNPJ, e-mail, telefones.

Mais um exemplo: [RF0001] – O sistema deverá manter (incluir, consultar, alterar e excluir) os dados dos clientes: nome, endereço, CEP, CPF ou CNPJ, Inscrição Estadual, e-mail, telefone residencial, telefone comercial, celular, cidade, data de nascimento.

É uma boa prática criar tabelas separadas com os tipos de requisitos: uma para os requisitos funcionais e outra para os requisitos não funcionais.

Para os requisitos não funcionais é importante estabelecer a classificação do requisito.

Observe uma sugestão de tabela para os requisitos não funcionais:

IDENTIFICADOR	DESCRIÇÃO	CLASSIFICAÇÃO
RNF0001	O sistema deverá ser realizado na linguagem de programação JAVA.	Implementação
RNF0002	O tempo de espera dos relatórios não poderá ultrapassar os 6 segundos.	Desempenho
RNF0003	As telas do sistema devem apresentar cores claras (tom pastel) e ícones grandes.	Usabilidade
RNF0004	O sistema deverá utilizar o banco de dados MySQL.	Implementação
RNF0005	Apenas usuários classificados como Supervisor e Administrador poderão gerar os relatórios sobre as encomendas.	Segurança

Quadro 1 | Requisitos não funcionais. Fonte: Werlich (2020, p. 143).

Saiba Mais

O livro de Pressman oferece insights valiosos sobre o Levantamento de Requisitos, portanto acesse o Capítulo 7.3 do livro Engenharia de Software – Pressman e leia mais sobre o tema:

Pressman, R. S.; MAXIM B. R. Engenharia de software. (9th edição). Grupo A, 2021.

Para saber mais sobre a Elicitação de Requisitos, leia o Capítulo 4.3 de Engenharia de Software - Sommerville:

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo, SP: Pearson, 2018. 

Quer saber quais são as técnicas utilizadas para a Elicitação de Requisitos?! Leia o artigo Técnicas de Elicitação de Requisitos:

ACERT. Técnicas de Elicitação de Requisitos. 2023. 

Referências Bibliográficas

PAULA FILHO, W. P. Engenharia de software: produtos. 4. ed. Rio de Janeiro: LTC, 2019.

PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

WERLICH, C. Análise e modelagem de sistemas. Londrina: Editora e Distribuidora Educacional S.A., 2020.

Modelagem de requisitos

Olá, estudante! Nesta videoaula, você conhecerá a Modelagem e Especificação de Requisitos, com foco em Diagramas. Estes conteúdos são fundamentais para sua prática profissional, capacitando-o a traduzir as necessidades dos clientes em requisitos claros e compreensíveis. Dominar a modelagem e especificação de requisitos, incluindo o uso de diagramas, é essencial para o desenvolvimento de sistemas de software precisos e alinhados às expectativas dos usuários. Prepare-se para adquirir habilidades valiosas que impulsionarão sua carreira na Engenharia de requisitos.

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Você já reparou que estamos cada vez mais atolados com muitas informações? A cada dia aparecem mais informações que devemos administrar. Como esse excesso de informação deve ser administrado em uma empresa de desenvolvimento de software? É necessário um gerenciamento eficaz das informações recolhidas para o desenvolvimento de um software. Em um desenvolvimento de software, tudo precisa ser documentado, organizado e validado com o cliente, para que ambas as partes concordem com o que será desenvolvido.

Pensando nessa documentação, vamos apresentar métodos de documentar os requisitos, seja por meio de linguagem natural ou através de modelos especificados e próprios para essa atividade. Para que você exercite esse seu lado de modelagem de requisitos, vamos imaginar que você está trabalhando como analista de sistemas e faz parte de uma equipe responsável pela engenharia de requisitos do software. Você documentará os seguintes requisitos:

• [RF0008] - O sistema deverá manter o cadastro de todos os fornecedores.
• [RF0009] - O sistema deverá emitir um relatório das plantas que podem ser plantadas classificadas por época do ano, tipos de terrenos e tipos de construção.
• [RF0010] - O sistema deverá manter (incluir, consultar, alterar e excluir) os dados dos clientes: nome, endereço, CPF ou CNPJ, e-mail, telefones.
• [RF0011] - O sistema deve gerar um relatório das Plantas disponíveis para venda.

Agora, o desafio final é criar uma Documentação da especificação de requisitos. Será possível usar uma padronização para documentar os requisitos? Existe alguma vantagem ao utilizar essa técnica? Você consideraria importante documentar a especificação e a elicitação dos requisitos?

Vamos Começar!

Especificação de requisitos funcionais e não funcionais

A modelagem de requisitos tem como principal objetivo concentrar-se no "o que será feito" e não no "como será feito". Conforme afirmado por Pressman (2021), o modelo de requisitos deve alcançar três objetivos fundamentais:

• Primeiro: descrever o que o cliente solicitou.
• Segundo: estabelecer uma base para a criação do Projeto de Software.
• Terceiro: produzir um conjunto de requisitos que possa ser validado assim que o software estiver concluído.

Para compreender completamente os requisitos, é essencial notar que não apenas descrevem o fluxo de informações que entram e saem do sistema, bem como a transformação dos dados dentro do sistema, mas também delineiam todas as restrições relacionadas ao seu comportamento e desempenho, como afirmado por Pfleeger (2004). Os requisitos permitem: (i) explicar, na perspectiva dos desenvolvedores, como os clientes desejam que o sistema funcione; (ii) definir as funcionalidades e atributos que o sistema deve possuir; (iii) informar à equipe de testes o que deve ser validado junto ao cliente.

Observa-se no Quadro 1 uma série de perguntas que devem ser feitas sobre cada requisito, visando promover o entendimento tanto do cliente quanto dos desenvolvedores, garantindo a qualidade dos requisitos levantados.

PERGUNTA	DESCRIÇÃO
Os requisitos estão corretos?	Todos os envolvidos devem verificar se os requisitos estão corretos.
Os requisitos estão consistentes?	Procurar inconsistência de informação (um requisito para uma determinada ação e outro requisito desfaz essa necessidade).
Os requisitos estão completos?	Verificar a existência de lacunas nos requisitos, com o máximo de informação sobre o que será realizado, como será realizado e as alternativas que podem haver.
Os requisitos são realistas?	Verificar se o que está sendo solicitado é realmente possível de ser realizado.
O requisito descreve algo necessário para o cliente?	O requisito deverá focar no que o sistema deverá realizar, evitando funções desnecessárias (e consequentemente perda de tempo no desenvolvimento).

Quadro 1 | Características dos requisitos. Fonte: adaptado de Pfleeger (2004, [s. p.]).

Existem diversas técnicas de modelagem de requisitos, a primeira, conforme Sommerville (2018), é fazer uma separação entre os requisitos funcionais e requisitos não funcionais, determinando um equilíbrio entre ambos (lembre-se que os Requisitos Funcionais dependem dos Requisitos Não Funcionais). O ideal é agrupar os requisitos conforme os seus objetivos, suas prioridades e seus tipos. Após o agrupamento dos requisitos funcionais e não funcionais, devemos agrupar todos os requisitos funcionais com prioridade Essencial (sem esse tipo de requisito, o software não estará apto a funcionar).

A especificação de requisitos envolve a documentação dos requisitos do usuário e do sistema em um documento formal. Em teoria, esses requisitos devem ser claros, inequívocos, facilmente compreensíveis, completos e consistentes, embora seja praticamente impossível alcançar essas condições idealmente. Os stakeholders tendem a interpretar os requisitos de maneiras diversas, frequentemente resultando em conflitos e incoerências. Os requisitos de usuário são geralmente redigidos em linguagem natural e podem ser complementados por diagramas e tabelas apropriados no documento de requisitos. Por outro lado, os requisitos do sistema também podem ser expressos em linguagem natural, mas outras notações, como formulários, gráficos ou modelos matemáticos, podem ser utilizadas. Quadro 2 resume as diferentes notações possíveis para escrever requisitos de sistema.

NOTAÇÃO	DESCRIÇÃO
Sentenças em linguagem natural	Os requisitos são escritos usando frases numeradas em linguagem natural. Cada frase deve expressar um requisito.
Linguagem natural estruturada	Os requisitos são escritos em linguagem natural em um formulário ou template. Cada campo fornece informações sobre um aspecto do requisito.
Notações gráficas	Modelos gráficos, suplementados por anotações em texto, são utilizados para definir os requisitos funcionais do sistema. São utilizados com frequência os diagramas de casos de uso e de sequência da UML.
Especificações matemáticas	Essas notações se baseiam em conceitos matemáticos como as máquinas de estados finitos ou conjuntos. Embora essas especificações inequívocas possam reduzir a ambiguidade em um documento de requisitos, a maioria dos clientes não compreende uma especificação formal.

Quadro 2 | Notações para escrever requisitos do sistema. Fonte: adaptado de Sommerville (2018, p. 104).

Uso de linguagem natural

Desde os anos 1950, a linguagem natural tem sido empregada na redação de requisitos de software. É uma forma expressiva, intuitiva e universal de comunicação. No entanto, também é intrinsecamente vaga e ambígua, sua interpretação variando conforme a experiência do leitor. Apesar das diversas propostas de alternativas para escrever requisitos, nenhuma delas foi amplamente adotada, e a linguagem natural continuará sendo o meio predominante de especificar requisitos de sistema e software.

Para mitigar possíveis mal-entendidos ao redigir requisitos em linguagem natural, é recomendável seguir estas diretrizes simples (SOMMERVILLE, 2018):

1. Estabelecer um formato padrão e garantir sua adoção em todas as definições de requisitos. Padronizar o formato reduz a probabilidade de omissões e facilita a verificação dos requisitos. Sempre que viável, é sugerido expressar o requisito em uma ou duas frases em linguagem natural.
2. Utilizar a linguagem de maneira consistente para distinguir entre requisitos obrigatórios e desejáveis. Os requisitos obrigatórios são aqueles que o sistema deve obrigatoriamente suportar e geralmente são expressos com o termo "deve". Já os requisitos desejáveis não são essenciais e são indicados pelo termo "pode".
3. Destacar partes importantes do requisito usando realces de texto, como negrito, itálico ou cor.
4. Evitar presumir que os leitores tenham conhecimento técnico em engenharia de software. Termos como "arquitetura" e "módulo" podem ser facilmente mal interpretados. Sempre que possível, evitar o uso de jargões, abreviações e acrônimos.
5. Associar um racional a cada requisito de usuário sempre que possível. O racional deve explicar por que o requisito foi incluído e quem o propôs (a origem do requisito), facilitando a identificação de quem contatar caso o requisito precise ser alterado. O racional dos requisitos é particularmente útil em momentos de mudança, ajudando a discernir quais alterações seriam indesejáveis.

A linguagem natural estruturada é uma forma de redigir os requisitos do sistema de maneira padronizada, em oposição ao texto livre. Essa abordagem mantém a expressividade e a clareza da linguagem natural, porém impõe uma certa uniformidade à especificação. As notações que adotam a linguagem estruturada utilizam modelos para descrever os requisitos do sistema. Essa descrição pode fazer uso de construções da linguagem de programação para apresentar alternativas e iterações, possibilitando destacar elementos-chave por meio de sombreamento ou diferentes fontes.

Para adotar uma abordagem estruturada na especificação de requisitos de sistema, é necessário estabelecer um ou mais modelos para os requisitos e representá-los como formulários estruturados. A especificação pode ser organizada em torno dos objetos manipulados pelo sistema, das funções executadas por ele ou dos eventos processados (SOMMERVILLE, 2018).

A adoção de especificações estruturadas remove algumas das dificuldades encontradas na redação de requisitos em linguagem natural. A variabilidade na especificação é minimizada e os requisitos são organizados de maneira mais eficiente. No entanto, em certas situações, pode ser desafiador expressar os requisitos de forma clara e inequívoca (SOMMERVILLE, 2018).

Siga em Frente...

Uso de modelos e diagramas

Uma técnica de modelagem de requisitos empregada na fase de Elicitação de requisitos é a técnica REMO (sigla em inglês de Requirements Elicitation oriented by business process MOdeling). Esta técnica possibilita a integração da modelagem de processos de negócios, utilizando a notação BPMN (Business Process Model and Notation - Modelo e Notação de Processos de Negócio), com a Elicitação de requisitos, conforme mencionado por Vieira (2012).

A técnica REMO possibilita a extração de requisitos a partir dos diagramas de processos de negócios, apoiada por um conjunto de heurísticas. Vieira (2012) descreve que o método de aplicação da técnica REMO compreende duas fases distintas. Na primeira fase, o foco está no entendimento do contexto para explorar o domínio do problema do software que será desenvolvido. Nessa etapa, é elaborado um documento pelo Analista de Sistemas, contendo informações cruciais para compreender o domínio do software, incluindo problemas e necessidades identificados, papéis envolvidos nos processos, recursos necessários e disponíveis, e diagramas de processos de negócios. Já na segunda fase, a atenção se volta para os requisitos, onde ocorre a extração e descrição dos requisitos do sistema.

Observe na Figura 1 como um requisito funcional pode ser gerado a partir da Modelagem de Processos de Negócios. Primeiramente, foi identificada uma atividade (Preencher formulário de matrícula do aluno) e, então, é realizado o seguinte questionamento: “Essa atividade pode ser um requisito?”, caso afirmativo temos um requisito encontrado a partir da Modelagem de Processos de Negócios. No exemplo da Figura 1, o requisito gerado foi o RF0015 – Cadastrar Alunos. O sistema deve manter os dados dos alunos. A palavra “manter” no requisito significa: cadastrar, consultar, alterar e excluir (evitando, assim, a escrita do mesmo requisito mudando os verbos – que representam o objetivo do requisito).

Existem outras técnicas de modelagem de requisitos, como a linguagem de modelagem SysML (Systems Modeling Language), que é open source (código aberto), derivada da linguagem UML e especificada pelo Object Management Group, SysML suporta as seguintes atividades: especificação, análise, design, verificação e validação de sistemas. Nesta modelagem podemos reutilizar vários diagramas da UML, e foi criado o Diagrama de Requisitos, que possui como principal vantagem a demonstração dos requisitos e suas relações. O diagrama de requisitos do SysML é baseado em textos e os relacionamentos entre os requisitos. Na Figura 2 são ilustrados três requisitos (nos retângulos). O requisito “Processo de Matrícula” possui duas dependências, os requisitos: “Entrada de dados” e “Disponibilização das Disciplinas” precisam ser elaborados após a abertura do requisito “Processo de Matrícula”. Importa destacar que o diagrama pode ficar muito grande, dependendo da quantidade de requisitos. Nesse sentido, ainda é usual a utilização de tabelas para descrever os requisitos.

A UML é amplamente empregada na modelagem de requisitos. A Linguagem UML (Linguagem de Modelagem Unificada) oferece uma variedade de diagramas que podem ser utilizados de forma isolada, representando aspectos específicos, ou combinados para compor modelos mais abrangentes. Por exemplo, o caso de uso é um dos diagramas mais utilizados para modelar requisitos, juntamente com o diagrama de sequência e o diagrama de atividades. Cada empresa pode adotar uma ou várias técnicas de modelagem de requisitos para produzir a documentação necessária ao final do processo de modelagem.

O processo de modelagem de requisitos na análise de aistemas pode ser considerado uma conexão entre as fases de elicitação e especificação de requisitos e a fase de modelagem de projetos do sistema. Uma alternativa adicional para especificar requisitos é através de diagramas de caso de uso. Pressman (2021) destaca que um cenário de uso, ou especificação do caso de uso, detalha o caso de uso, auxiliando na modelagem do requisito específico. Este detalhamento serve como principal meio de comunicação entre a equipe de desenvolvimento, ou seja, entre o analista de sistemas responsável pela modelagem e o programador encarregado de implementar o requisito modelado.

O diagrama de caso de uso desempenha um papel fundamental na construção de software orientado a objetos utilizando a UML. Estes diagramas acompanham o software desde sua concepção até sua conclusão. Além disso, eles servem como um meio de comunicação eficaz entre o analista de sistemas e os programadores, pois detalham precisamente o que precisa ser implementado e codificado.

Na Figura 3 é demonstrado um modelo de diagramas de Casos de Uso com dois processos (cada processo ou a elipse é chamada de Caso de Uso): (i) Matricular o Aluno e (ii) Gerar Boletos, e envolve dois atores que “alimentarão” os processos com o fornecimento ou o recebimento de informações.

Cada caso de uso representa uma determinada função ou tarefa do sistema, segundo Sommerville (2018), que envolve a interação externa com o sistema e pode ser um cenário simples que ajuda no entendimento do sistema (ou de parte dele). É na especificação (ou descrição) de cada caso de uso que o processo de modelagem de requisito é ampliado. Observe o Quadro 3, com a especificação do caso de uso Matricular Aluno.

Nome do caso de uso	Matricular Aluno
Ator Principal	Aluno
Atores Secundários	Secretária
Resumo	Este caso de uso tem por objetivo detalhar o processo de matrícula do aluno no sistema.
Pré-condições	1. O aluno deverá estar matriculado no sistema. 2. Não poderá haver nenhuma pendência financeira no sistema.
Fluxo Principal
Ações do Ator	Ações do Sistema
1. O aluno informa a matrícula e senha para se logar no sistema. 4. O aluno poderá escolher a disciplina que cursará num total de 6 disciplinas por semestre. 5. O aluno deverá finalizar a escolha da disciplina apertando o botão FINALIZAR. 6. O aluno poderá escolher entre imprimir ou salvar o comprovante de matrícula.	2. O sistema deverá verificar a matrícula e validar a senha do aluno. 3. Deverão ser apresentadas as disciplinas que o aluno poderá cursar. 6. Um comprovante de matrícula deverá ser gerado em formato PDF.
Fluxos Alternativos
Ações do Ator	Ações do Sistema
1.1 O aluno poderá redefinir a sua senha.	2.1 - Caso o aluno não tenha senha o sistema deverá permitir o cadastramento da senha ou a sua redefinição. 3.1 - Deverá ser verificado o semestre atual do aluno, se for o 1° semestre do aluno, ele deverá escolher todas as disciplinas. 3.2 - Deverá ser verificada a quantidade de disciplinas a serem escolhidas (limite dever ser igual a 6).

Quadro 3 | Especificação do caso de uso: Matricular Aluno. Fonte: adaptado de Werlich (2020, p. 159).

A finalidade da especificação ou descrição de um caso de uso é fornecer informações sobre quais atores (sejam pessoas ou sistemas) interagem com as funcionalidades específicas que estão sendo modeladas no sistema. Não existe um modelo padrão de especificação, pois este é totalmente adaptável às necessidades das empresas. No entanto, é recomendável que seja redigido de forma simplificada para facilitar a compreensão. 

Vamos Exercitar?

Para relembrar, você está trabalhando como analista de sistemas e faz parte de uma equipe responsável pela Engenharia de requisitos do software. Você documentará os requisitos para o sistema da empresa de plantas ornamentais. Após realizar várias visitas, conversado com o cliente e outros usuários do sistema, vários requisitos funcionais e não funcionais do software foram levantados, mas não houve uma documentação apropriada para essas ações.

O desafio é criar uma Documentação da Especificação de Requisitos e, para isso, primeiramente resgataremos os Requisitos Funcionas:

• [RF0008] - O sistema deverá manter o cadastro de todos os fornecedores.
• [RF0009] - O sistema deverá emitir um relatório das plantas que podem ser plantadas classificadas por época do ano, tipos de terrenos e tipos de construção.
• [RF0010] - O sistema deverá manter (incluir, consultar, alterar e excluir) os dados dos clientes: nome, endereço, CPF ou CNPJ, e-mail, telefones.
• [RF0011] - O sistema deve gerar um relatório das Plantas disponíveis para venda.

Será possível usar uma padronização para documentar os requisitos? Existe alguma vantagem ao utilizar essa técnica? Sim, podemos utilizar o padrão de modelagem apresentado a seguir, no Quadro 4 ou utilizar outro apresentado nesta aula.

Identificador:
Nome:
Módulo:
Data de criação:		Autor:
Data última alteração:		Autor:
Versão:		Prioridade:
Descrição:

Quadro 4 | Padrão de modelagem. Fonte: adaptado de Werlich (2020, p. 160).

E como ficaria a documentação do Requisito Funcional: [RF0008] – O sistema deverá manter o cadastro de todos os fornecedores? Observe o quadro 5 que ilustra a documentação básica do requisito RF008.

Identificador:	FR0008
Nome:	O sistema deverá manter o cadastro de todos os fornecedores
Módulo:	N/A
Data de criação:	05/11/2019	Autor:	Claudia W.
Data última alteração:	N/A	Autor:	N/A
Versão:	1.0	Prioridade:	Essencial
Descrição:	Todo fornecedor deverá ser cadastrado antes de ser efetuada uma encomenda ou compra. Todos os dados deverão ser cadastrados pelo usuário do sistema. Os dados que deverão ser informados são: Nome fantasia, Razão social, CNPJ, Inscrição Estadual, Endereço completo, Cidade, Estado, E-mail.

Quadro 5 | Documentação básica do requisito RF008. Fonte: adaptado de Werlich (2020, p. 160).

Utilize o modelo de modelagem usado anteriormente para documentar os demais requisitos do sistema de plantas ornamentais. Cada requisito deverá ter o seu próprio formulário. Não esqueça que a identificação dever ser única. Caso alguma informação não seja preenchida no formulário, insira a sigla N/A (Não se Aplica), não deixe a lacuna em branco. Toda a versão deverá começar do número 1. Procure ser detalhista no item da descrição do requisito. 

Saiba Mais

O livro de Pressman oferece insights valiosos sobre a Modelagem de Requisitos, portanto acesse o Capítulo 8 do livro Engenharia de Software – Pressman e leia mais sobre o tema:

Pressman, R. S.; MAXIM B. R. Engenharia de software. (9th edição). Grupo A, 2021.

Para saber mais sobre a Especificação de Requisitos, leia o Capítulo 4.4 de Engenharia de Software – Sommerville:

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo, SP: Pearson, 2018. 

Para entender mais sobre a Modelagem de Requisitos, utilizando Casos de Uso, leia o Capítulo 5 do livro Engenharia de requisitos – Reinehr:

REINEHR, S. Engenharia de requisitos. Grupo A, 2020.

Referências Bibliográficas

PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.

PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

SOMMERVILLE, Ian. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.

VIEIRA, S. R. C. Remo: uma técnica de elicitação de requisitos orientada pela modelagem de processos de negócios. 2012.

WERLICH, C. Análise e modelagem de sistemas. Londrina: Editora e Distribuidora Educacional S.A., 2020. 

Validação e modificações nos requisitos

Bem-vindo à videoaula dedicada a Validação, Mudanças e Rastreabilidade de Requisitos. Esses conteúdos são fundamentais para sua prática profissional na engenharia de requisitos. A validação assegura que os requisitos atendam às necessidades dos clientes, enquanto o gerenciamento de mudanças garante a adaptabilidade do sistema. Além disso, a rastreabilidade permite acompanhar e verificar a evolução dos requisitos ao longo do ciclo de vida do projeto. Prepare-se para adquirir habilidades essenciais para o sucesso na análise e desenvolvimento de sistemas de software.

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Partida

Nesta aula, iremos abordar três aspectos cruciais no desenvolvimento de software: validação de requisitos, gestão de mudanças nos requisitos e rastreabilidade de requisitos. Primeiramente, nos concentraremos na validação de requisitos, visando garantir que esses requisitos estejam alinhados com as necessidades dos usuários e do negócio. Usaremos técnicas como revisões sistemáticas e prototipagem para identificar e corrigir problemas antes do desenvolvimento do produto final.

Em seguida, exploraremos a gestão de mudanças nos requisitos, aprendendo a lidar com alterações imprevistas durante o processo de desenvolvimento. Implementaremos processos claros para solicitar, analisar e implementar essas mudanças de maneira eficiente, com técnicas para avaliar seu impacto e comunicá-las de forma eficaz. Por último, adentraremos no conceito de rastreabilidade de requisitos, que nos permite rastrear o desenvolvimento dos requisitos desde sua concepção até sua implementação.

Para exercitar esses temas, vamos analisar o seguinte estudo de caso: uma loja está desenvolvendo um novo sistema de comércio eletrônico para substituir seu sistema legado. O objetivo é criar uma plataforma mais robusta e escalável para lidar com o crescimento do negócio e proporcionar uma melhor experiência ao cliente. O projeto envolve uma equipe multidisciplinar de desenvolvedores, designers, testadores e analistas de negócios.

Um dos principais desafios enfrentados pela equipe de desenvolvimento é lidar eficientemente com mudanças nos requisitos do sistema. Como o mercado de comércio eletrônico é altamente dinâmico, novos requisitos e alterações nos requisitos existentes são esperados ao longo do ciclo de vida do projeto. No entanto, a falta de um processo formal para gerenciar essas mudanças pode levar a atrasos, custos adicionais e, em última instância, a um produto final que não atende às expectativas do cliente. Proponha soluções que possam ajudar neste desafio.

Vamos Começar!

Validação de requisitos

A validação de requisitos é um processo crucial para garantir que os requisitos definidos correspondam verdadeiramente ao sistema desejado pelo cliente. Este processo se destaca durante a elicitação e análise, concentrando-se na identificação de possíveis problemas. Sua importância é primordial, pois erros nos requisitos podem resultar em custos significativos de retrabalho, tanto durante o desenvolvimento quanto após a implementação do sistema (PRESSMAN, 2021).

O custo de corrigir problemas nos requisitos, por meio de alterações no sistema, geralmente é consideravelmente maior do que corrigir erros de projeto ou de código. Uma mudança nos requisitos frequentemente implica em ajustes no projeto e na implementação do sistema, muitas vezes exigindo um reinício do processo.

Durante a validação de requisitos, é essencial realizar diferentes tipos de verificações nos requisitos documentados, incluindo (SOMMERVILLE, 2018):

1. Validade: verificar se os requisitos refletem as reais necessidades dos usuários do sistema, considerando possíveis mudanças nas circunstâncias desde a elicitação inicial.
2. Consistência: garantir que os requisitos no documento não entrem em conflito entre si, evitando restrições contraditórias ou descrições diferentes para a mesma função do sistema.
3. Completude: certificar-se de que o documento de requisitos abrange todas as funções e restrições desejadas pelo usuário do sistema.
4. Realismo: avaliar se os requisitos podem ser implementados dentro do orçamento proposto, considerando as tecnologias existentes e o cronograma de desenvolvimento.
5. Verificabilidade: para diminuir o potencial de conflito entre o cliente e o contratante, os requisitos do sistema sempre devem ser escritos de modo que sejam verificáveis. Isso significa ser capaz de escrever um conjunto de testes que possam demonstrar que o sistema entregue satisfaz cada um dos requisitos especificados.

Diversas técnicas de validação de requisitos podem ser empregadas para garantir a qualidade dos requisitos de um sistema:

1. Revisões de requisitos: uma equipe de revisores examina os requisitos em busca de erros e inconsistências de forma sistemática.
2. Prototipação: desenvolvimento de um modelo executável do sistema para que os usuários finais e clientes possam experimentá-lo, fornecendo feedback para possíveis mudanças nos requisitos.
3. Geração de casos de teste: os requisitos devem ser testáveis, e o desenvolvimento de casos de teste revela problemas potenciais nos requisitos. Se um teste é difícil de conceber, pode indicar que os requisitos são complexos e precisam ser reconsiderados.

A validação de requisitos é um desafio, pois é difícil demonstrar que um conjunto de requisitos atende verdadeiramente às necessidades dos usuários. Muitas vezes, problemas nos requisitos só são descobertos após o início da implementação do sistema, exigindo ajustes mesmo após o consenso inicial no documento de requisitos.

Gestão de mudanças nos requisitos

Os requisitos de sistemas de software grandes estão sujeitos a mudanças frequentes devido à natureza dos problemas que esses sistemas abordam, muitas vezes complexos e difíceis de definir completamente. Como esses problemas são intrinsecamente desafiadores, os requisitos de software tendem a ser incompletos, pois não é possível uma definição abrangente. Durante o processo de desenvolvimento de software, a compreensão do problema pelos stakeholders está em constante evolução, o que exige uma adaptação contínua dos requisitos do sistema para refletir essa compreensão em mudança.

Após a instalação do sistema, é comum surgirem novos requisitos devido a erros, mudanças no ambiente de negócios e tecnológico, e às diferentes necessidades dos stakeholders. Os ambientes de negócios e tecnológicos estão em constante evolução, exigindo adaptações no sistema. Os clientes e usuários finais podem impor requisitos conflitantes, e a diversidade de stakeholders pode levar a prioridades divergentes, exigindo uma conciliação. O gerenciamento de requisitos é crucial para acompanhar as mudanças e garantir que os requisitos sejam priorizados e vinculados adequadamente. Enquanto os processos ágeis de desenvolvimento podem lidar com mudanças de requisitos de forma mais flexível, é importante garantir uma abordagem sistemática para gerenciar as alterações e manter a coerência entre os requisitos do sistema.

O gerenciamento mudança de requisitos é fundamental para avaliar a viabilidade e o impacto das mudanças propostas após a aprovação do documento de requisitos de um sistema. Um processo formal de gerenciamento de mudança garante que todas as propostas sejam tratadas de forma consistente e controlada. Este processo envolve três etapas principais, que estão apresentadas na Figura 1.

O detalhamento do processo de gerenciamento de mudanças em requisitos segue três etapas fundamentais (SOMMERVILLE, 2018):

1. Análise do problema e especificação da mudança: inicia-se com a identificação de um problema de requisito ou uma proposta de mudança específica. Durante essa fase, o problema ou proposta é analisado para determinar sua validade, e o requisitante da mudança pode fornecer uma proposta mais específica ou optar por abandonar a solicitação.
2. Análise da mudança e estimativa de custo: o impacto da mudança proposta é avaliado com base na rastreabilidade das informações e no conhecimento geral dos requisitos do sistema. Uma estimativa de custo é feita, considerando as modificações necessárias nos documentos de requisitos, no projeto e na implementação do sistema. Após a análise, uma decisão é tomada sobre a execução da mudança.
3. Implementação da mudança: os documentos de requisitos, e se aplicável, de projeto e implementação do sistema, são ajustados conforme necessário. É importante organizar o documento de requisitos de forma a facilitar futuras mudanças, minimizando referências externas e tornando as seções modulares para permitir alterações sem afetar outras partes do documento.

Quando surge a necessidade de implementar um novo requisito com urgência, há uma tentação de modificar o sistema primeiro e, em seguida, ajustar retrospectivamente o documento de requisitos. No entanto, isso frequentemente resulta em uma discrepância entre a especificação dos requisitos e a implementação do sistema. Após as mudanças serem feitas, é fácil esquecer de atualizar o documento de requisitos para refletir essas alterações. Embora em certas circunstâncias seja necessário realizar mudanças emergenciais no sistema, é crucial atualizar o documento de requisitos o mais rápido possível para incluir os requisitos revisados.

Siga em Frente...

Rastreabilidade de requisitos

Para realizar uma análise de impacto de mudança de maneira eficaz, é crucial estabelecer e compreender as conexões entre os requisitos, bem como entre esses requisitos e outros elementos do sistema. Essas conexões, conhecidas como rastreabilidade de requisitos, são fundamentais para embasar essa análise. A rastreabilidade implica rastrear a origem de um requisito, o que é conhecido como rastreabilidade para trás (backward traceability), bem como acompanhar suas ramificações, denominadas rastreabilidade para frente (forward traceability). Essa rastreabilidade vertical é essencial. Além disso, há a rastreabilidade entre os próprios requisitos, que identifica as interdependências entre eles, denominada rastreabilidade horizontal. Geralmente, a rastreabilidade é implementada por meio de ferramentas de mapeamento de grafos ou matrizes bidimensionais.

Qual é a importância da rastreabilidade? Essa técnica nos permite o identificar os seguintes pontos com relação aos requisitos:

• Identificação de requisitos ausentes: consiste em buscar requisitos de negócios não rastreados até requisitos de usuário e requisitos de usuário não vinculados a nenhum requisito funcional. Essa abordagem permite detectar lacunas que podem ter sido negligenciadas durante o processo de definição dos requisitos.
• Eliminação de requisitos desnecessários: envolve a busca por requisitos funcionais que não possuem rastreabilidade até os requisitos de usuário e de negócios, indicando sua possível desnecessidade.
• Certificação e conformidade: a rastreabilidade fornece informações valiosas durante processos de certificação de produtos críticos para a segurança, permitindo demonstrar a implementação de todos os requisitos, embora não garanta sua correta implementação. Além disso, é útil para demonstrar a inclusão e tratamento de requisitos relacionados à conformidade regulatória, especialmente em setores como saúde e finanças.
• Análise de impacto de mudanças: a ausência de informações de rastreabilidade aumenta o risco de ignorar elementos do sistema que seriam afetados por adições, remoções ou modificações de requisitos específicos.
• Manutenção de software: a rastreabilidade facilita a capacidade de efetuar mudanças de forma precisa e completa durante a manutenção do software. À medida que políticas corporativas ou regulamentações governamentais evoluem, sistemas de software frequentemente precisam ser atualizados. Uma tabela que indica onde cada regra de negócio relevante foi abordada nos requisitos funcionais, nos projetos e no código simplifica a implementação das mudanças necessárias. É possível identificar relações de causa e efeito de falhas, ajudando a determinar quais componentes precisam ser alterados e fornecendo suporte para estimativas de mudança.
• Executar testes: quando um teste falha, as ligações entre os testes, os requisitos e o código apontam os desenvolvedores para as áreas prováveis a serem examinadas para o defeito. A rastreabilidade apoia, portanto, as correções de defeitos encontrados em testes.

Manter a rastreabilidade de todos os elementos de um projeto é desafiador e pode ser dispendioso. É essencial priorizar e manter apenas os relacionamentos críticos para o desenvolvimento e manutenção do software. Isso requer uma decisão consciente por parte do time de desenvolvimento e stakeholders, semelhante à gerência de configuração. Itens como origem dos requisitos, requisitos críticos para o negócio, impacto na arquitetura e testes, bem como código e casos de teste cruciais para o sistema, são candidatos a serem rastreados. Essa abordagem ajuda a minimizar o risco de análises de impacto imprecisas e garante uma visão mais clara sobre a abrangência das mudanças no software.

A representação mais comum da rastreabilidade de requisitos é no formato de matriz, que pode ser implementada usando-se planilha eletrônica ou ferramenta automatizada. Uma implementação eficiente de uma rastreabilidade mais robusta deve ser realizada por meio de ferramentas automatizadas. Existem ferramentas de modelagem UML, por exemplo, que já oferecem formas de registrar e manter a rastreabilidade dos requisitos e dos demais artefatos do ciclo de desenvolvimento de software.

A Figura 2 apresenta um modelo de matriz bidimensional que representa a rastreabilidade de requisitos.

Na primeira coluna, listamos todos os elementos que poderão ser rastreados entre si. Nesse exemplo, listamos os stakeholders, os objetivos estratégicos, os requisitos funcionais, os requisitos não funcionais, os casos de uso, os casos de teste e os módulos de código.

Na primeira linha listamos os mesmos elementos. Note que não foram listados na linha 1 os stakeholders e nem os objetivos estratégicos, pois não temos interesse em rastrear o relacionamento entre eles, mas sim com os requisitos que eles geraram (funcionais e não funcionais) (REINEHR, 2020).

Poderíamos ter mapeado todos os relacionamentos do Gerente de vendas com os elementos que foram desdobrados a partir do RF20, mas isso iria poluir desnecessariamente a planilha. Então assumimos que apenas nos interessa mapear quais foram os requisitos solicitados por cada stakeholder, ou seja, o único mapeamento possível na nossa planilha é entre o stakeholder solicitante e os requisitos funcionais e não funcionais (únicas células com o fundo branco). Raciocínio similar foi utilizado para a representação dos objetivos estratégicos. Note que a interseção dos stakeholders e dos objetivos estratégicos com os elementos Casos de Uso, Casos de Teste e Módulos foram suprimidos (células em cinza). Podemos observar que estão marcados com um “X” todos os relacionamentos entre os elementos. A parte inferior da tabela está em cinza, denotando que são relacionamentos já representados na parte superior (REINEHR, 2020).

Em destaque verde temos a representação dos relacionamentos existentes com o requisito funcional RF20. Vemos que ele foi solicitado pelo Gerente de vendas e que se relaciona com o objetivo estratégico OE3. Esta é a chamada rastreabilidade para trás, ou seja, para a origem do requisito. Logo em seguida temos a rastreabilidade para frente, ou seja, quais foram os artefatos que foram gerados a partir do requisito funcional RF20. Temos então o caso de uso UC12, o caso de teste CT20.1 e o módulo implementado M1. Temos mais um relacionamento representado, que é o relacionamento com o requisito não funcional RNF3. Esta é a rastreabilidade horizontal entre elementos do mesmo tipo (no caso, requisitos) (REINEHR, 2020).

Manter a rastreabilidade é importante para o software, especialmente durante a manutenção. É essencial encontrar um equilíbrio na quantidade de informações rastreadas para garantir sua atualização constante. Pior do que não ter uma informação, nesse caso, é ter uma informação incompleta ou incorreta.

Vamos Exercitar?

A equipe de gerenciamento de projetos de uma loja decidiu implementar um sistema de gerenciamento de mudanças de requisitos e rastreabilidade. Eles optaram por utilizar uma ferramenta de gerenciamento de requisitos que permitisse a captura, documentação e rastreamento de todos os requisitos do sistema, bem como suas interdependências.

Passos implementados:

• Identificação de requisitos: a equipe trabalhou em estreita colaboração com os stakeholders para identificar e documentar todos os requisitos do sistema, incluindo requisitos funcionais, não funcionais e de negócios.
• Priorização de requisitos: os requisitos foram priorizados com base na sua importância para o sucesso do projeto e seu impacto no cronograma e no orçamento.
• Estabelecimento de um processo de mudança: foi definido um processo formal para solicitação, avaliação, aprovação e implementação de mudanças nos requisitos. Isso incluiu a designação de um comitê de controle de mudanças responsável por revisar e aprovar todas as solicitações de mudança.
• Rastreabilidade de requisitos: a ferramenta de gerenciamento de requisitos foi configurada para rastrear as relações entre os requisitos, permitindo à equipe entender como uma mudança em um requisito afeta outros requisitos e componentes do sistema.

Resultados:

A implementação do sistema de gerenciamento de mudanças de requisitos e rastreabilidade teve vários benefícios significativos:

• Redução de atrasos: a equipe conseguiu lidar com mudanças nos requisitos de forma mais eficiente, evitando atrasos no cronograma do projeto.
• Controle de custos: o processo de controle de mudanças ajudou a evitar custos adicionais associados a mudanças de escopo não gerenciadas.
• Maior satisfação do cliente: a capacidade de rastrear requisitos e suas interdependências resultou em um produto final que atendeu melhor às expectativas do cliente.
• Melhoria da qualidade: o sistema de rastreabilidade permitiu à equipe identificar e resolver mais facilmente inconsistências e conflitos nos requisitos, resultando em um produto final de maior qualidade.

Conclusão:

A implementação de um sistema de gerenciamento de mudanças de requisitos e rastreabilidade foi fundamental para o sucesso do projeto de desenvolvimento de software loja. A abordagem estruturada para lidar com mudanças nos requisitos ajudou a equipe a manter o controle sobre o escopo do projeto, evitar atrasos e custos adicionais, e fornecer um produto final que atendeu às expectativas do cliente. Este caso destaca a importância de uma abordagem sistemática para gerenciar mudanças em projetos de desenvolvimento de software. 

Saiba Mais

Quer saber mais sobre o Gerenciamento e controle de mudanças nos requisitos? Acesse o artigo Gerenciamento e controle de mudanças de requisitos e leia mais sobre o tema:

DEVMEDIA. Gerenciamento e controle de mudanças de requisitos. [s. d.].

Para saber mais sobre as Mudanças em requisitos, leia o Capítulo 4.6 do livro Engenharia de Software - Sommerville.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo, SP: Pearson, 2018

Para entender mais sobre a Rastreabilidade de Requisitos, leia o Capítulo 13 do livro Engenharia de requisitos – Reinehr.

REINEHR, S. Engenharia de requisitos. Grupo A, 2020.

Referências Bibliográficas

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

REINEHR, S. Engenharia de requisitos. [Digite o Local da Editora]: Grupo A, 2020.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018. 

Videoaula de Encerramento

Olá, estudante! Nesta videoaula, você conhecerá a Engenharia de requisitos! Nesta aula, vamos explorar os fundamentos dos tipos de requisitos e a importância da modelagem. Esses conteúdos são essenciais para sua prática profissional, pois garantem uma compreensão sólida das necessidades dos clientes e a entrega eficaz de soluções de software. Prepare-se para adquirir habilidades valiosas que impulsionarão sua carreira na área de desenvolvimento de software.

Clique aqui para acessar os slides da sua videoaula.
Bons estudos!

Ponto de Chegada

Olá, estudante! Para desenvolver a competência desta Unidade, que é identificar os tipos de requisitos e a suas características para a modelagem de sistemas, você deverá primeiramente conhecer os fundamentos da Engenharia de requisitos. A engenharia de requisitos abrange a descrição detalhada das funcionalidades, serviços e restrições de um sistema, refletindo as necessidades dos usuários e contribuindo para um produto de qualidade. Os requisitos de um sistema vão além de funções e qualidades, incluindo especificações de serviços, restrições e características gerais. Exemplos concretos de requisitos para um jogo de perguntas e respostas ilustram a importância de redigir requisitos de forma clara e concisa, garantindo compreensão mútua entre cliente e desenvolvedores.

Na elaboração dos requisitos, é essencial determinar suas prioridades, que podem ser classificadas como essencial, importante ou desejável. Requisitos essenciais são vitais para a completude do software, enquanto os importantes são secundários, mas ainda relevantes, e os desejáveis são opcionais. Essa categorização permite priorizar o desenvolvimento e atualização do software de acordo com as necessidades do projeto, embora as prioridades possam mudar ao longo da evolução do sistema.

Na engenharia de requisitos, é crucial distinguir entre os tipos de descrições de requisitos, conforme afirmado por Sommerville (2018). Os requisitos do usuário delineiam as necessidades dos clientes de forma compreensível, abordando tanto os requisitos funcionais quanto os não funcionais do sistema. Por outro lado, os requisitos do sistema especificam os detalhes técnicos do sistema com base nos requisitos do usuário, podendo servir como parte de um contrato entre as partes envolvidas no desenvolvimento.

A categorização dos requisitos em um sistema, conforme descrito por Sommerville (2018) e Pressman (2021), engloba três principais categorias: requisitos funcionais, não funcionais e de domínio. Os requisitos funcionais definem as funcionalidades específicas que o sistema deve executar, enquanto os não funcionais estabelecem restrições e padrões relacionados ao desempenho, segurança e usabilidade. Já os requisitos de domínio descrevem as características específicas do ambiente em que o sistema será utilizado, impondo condições adicionais aos requisitos funcionais.

A elaboração detalhada dos requisitos desempenha um papel crucial na comunicação com o cliente e na orientação do desenvolvimento do sistema. Os requisitos funcionais são identificados por uma sigla específica seguida de uma numeração, enquanto os não funcionais são categorizados e mensurados de acordo com diferentes métricas. Os requisitos de domínio complementam os requisitos funcionais, estabelecendo critérios específicos para validar determinadas funcionalidades do sistema.

Outro ponto fundamental para alcançar a competência da unidade, é entender o conjunto de atividades da engenharia de requisitos, que envolvem desde a coleta inicial de informações sobre o sistema a ser desenvolvido até a validação dos requisitos pelo usuário final. Essas atividades, conforme descritas por Pressman (2021) e Sommerville (2018), incluem concepção, elicitação, elaboração, negociação, especificação, validação e gerenciamento de requisitos. Cada etapa tem como objetivo primordial a elaboração de um documento de requisitos detalhado e preciso, que servirá como base para o desenvolvimento do sistema.

O processo de engenharia de requisitos compreende uma série de etapas interligadas. Desde a definição do escopo geral do sistema até o gerenciamento contínuo dos requisitos ao longo do ciclo de vida do produto, todas as atividades visam garantir a compreensão das necessidades do cliente e a conformidade dos requisitos com o escopo do projeto.

Em suma, os requisitos funcionais delineiam as funcionalidades e características específicas do sistema, enquanto os requisitos não funcionais estabelecem atributos e qualidades do sistema, como desempenho e segurança. Esses requisitos são essenciais para orientar o desenvolvimento de software e garantir a entrega de um produto que atenda às expectativas do cliente e dos usuários finais. O processo de engenharia de requisitos é dinâmico e envolve a participação ativa do cliente e dos usuários ao longo de todo o ciclo de desenvolvimento do sistema.

Na engenharia de requisitos, a elicitação de requisitos desempenha um papel central na definição das necessidades de um sistema específico, envolvendo a coleta e análise de informações a partir de diversas fontes e interações com stakeholders relevantes, conforme destacado por Pressman (2021). Essa fase requer a colaboração de várias partes interessadas, incluindo analistas de sistemas, gerentes de projetos e usuários finais do sistema, como mencionado por Sommerville (2018), visando resolver problemas de forma colaborativa.

A elicitação de requisitos busca estabelecer uma compreensão clara do escopo do sistema, identificar oportunidades de reutilização de soluções existentes e elicitar requisitos funcionais e não funcionais. A partir daí, ocorre a negociação e validação dos requisitos, garantindo que não haja conflitos entre eles e que atendam às necessidades dos stakeholders. O resultado é a documentação detalhada dos requisitos, que serve como principal meio de comunicação entre os desenvolvedores e o cliente.

O processo de levantamento e análise de requisitos é uma sequência contínua e iterativa de atividades que visam validar as necessidades do sistema. A figura apresentada demonstra a progressão desse processo, desde a compreensão do domínio do problema até a documentação final dos requisitos. A validação contínua dos requisitos é essencial, pois qualquer alteração requer revisão e ajustes, garantindo que o sistema atenda efetivamente às expectativas do cliente e usuários finais (SOMMERVILLE, 2018).

O processo de elicitação de requisitos pode variar entre as empresas, envolvendo atividades como descoberta, classificação, priorização e especificação de requisitos. Essa fase é colaborativa e interativa, com a participação ativa dos stakeholders na identificação das necessidades do sistema, utilizando técnicas como pesquisa, entrevistas, reuniões e análise documental para obter uma visão abrangente do problema a ser resolvido.

A especificação de requisitos consiste na formalização das funcionalidades que o sistema deve executar, seguindo uma abordagem hierárquica para detalhar progressivamente os requisitos. Essa etapa é fundamental para criar um documento claro e objetivo que servirá como base para o desenvolvimento do software, garantindo que os requisitos sejam compreendidos de forma unívoca pelos desenvolvedores e stakeholders (PFLEEGER, 2004).

Além disso, a prototipagem é uma técnica valiosa na engenharia de requisitos, permitindo a criação de versões simplificadas do sistema para avaliar sua viabilidade e identificar problemas precocemente. A negociação de requisitos também é essencial para desenvolver um plano de projeto que atenda às demandas dos stakeholders, considerando as restrições de orçamento, pessoal, tecnologia e tempo impostas à equipe de desenvolvimento do software (PAULA FILHO, 2019).

O monitoramento de requisitos é crucial para garantir que o escopo do software seja atendido, exigindo a rastreabilidade das alterações através de ferramentas de controle apropriadas. Ao modificar um requisito, é essencial atribuir um status apropriado e manter uma matriz de rastreabilidade atualizada, incluindo todas as informações relevantes sobre cada requisito. A gestão de mudanças de requisitos visa analisar o impacto das alterações propostas para determinar sua viabilidade técnica e financeira, evitando inconsistências decorrentes de documentação desatualizada.

A validação de requisitos é fundamental para garantir que a especificação seja consistente com as necessidades do cliente. Durante esse processo, diferentes tipos de verificação, como validade, consistência, completude e verificabilidade, são realizados para identificar falhas nos requisitos documentados. O propósito é eliminar erros comuns, como inconsistências, contradições e ambiguidades, visando evitar atrasos e aumentos de custos durante o desenvolvimento do software (PFLEEGER, 2004).

Um recurso útil para a validação de requisitos é o uso de checklists, listas de perguntas elaboradas para analisar cada requisito do sistema. Essa técnica visa identificar erros em vários níveis e garantir que o software desenvolvido atenda aos padrões estabelecidos, contribuindo para a qualidade do processo de validação de requisitos.

Outro ponto importante é a Modelagem de requisitos, que se concentra no "o que será feito" em vez do "como será feito", com o objetivo de descrever as necessidades do cliente, fornecer uma base para o desenvolvimento do software e produzir requisitos validáveis (PRESSMAN, 2021). Para compreender completamente os requisitos, é crucial considerar não apenas o fluxo de informações no sistema, mas também as transformações de dados e todas as restrições de comportamento e desempenho. As técnicas de modelagem de requisitos incluem a separação entre requisitos funcionais e não funcionais, agrupamento dos requisitos por prioridade e a especificação detalhada em documentos formais.

A redação dos requisitos em linguagem natural é uma prática comum, mas pode levar a interpretações diversas e inconsistências. Para mitigar isso, são sugeridas diretrizes como estabelecer um formato padrão, destacar partes importantes e associar um racional a cada requisito, conforme recomendado por Sommerville (2018). Além disso, a linguagem estruturada e o uso de modelos e diagramas, como os fornecidos pela Linguagem de Modelagem Unificada (UML) e SysML, são úteis para organizar os requisitos de forma mais clara e eficiente.

Diversas técnicas de modelagem de requisitos são empregadas, incluindo a técnica REMO para extração de requisitos a partir de diagramas de processos de negócios e a utilização de diagramas de caso de uso na UML para detalhar as interações entre os atores e o sistema. A especificação de cada caso de uso é essencial para comunicar as funcionalidades específicas a serem implementadas, geralmente redigida de forma simplificada para facilitar a compreensão.

A validação de requisitos é um passo importante para garantir a correspondência entre os requisitos definidos e o sistema desejado pelo cliente. Realizada durante a elicitação e análise, visa identificar problemas que poderiam resultar em custos significativos de retrabalho durante o desenvolvimento ou após a implementação do sistema (PRESSMAN, 2021). Durante esse processo, são realizadas diversas verificações nos requisitos documentados, incluindo validade, consistência, completude, realismo e verificabilidade (SOMMERVILLE, 2018).

Para assegurar a qualidade dos requisitos, são empregadas diferentes técnicas de validação. As revisões de requisitos envolvem uma equipe de revisores que examina sistematicamente os requisitos em busca de erros e inconsistências. A prototipagem permite o desenvolvimento de um modelo executável do sistema para que os usuários finais possam fornecer feedback, enquanto a geração de casos de teste revela problemas potenciais nos requisitos ao torná-los testáveis (PRESSMAN, 2021).

No entanto, a validação de requisitos é um desafio, pois é difícil demonstrar que um conjunto de requisitos atende verdadeiramente às necessidades dos usuários. Muitas vezes, problemas só são descobertos após o início da implementação do sistema, exigindo ajustes mesmo após o consenso inicial no documento de requisitos.

Os sistemas de software de grande porte enfrentam desafios recorrentes devido à complexidade inerente dos problemas que abordam, muitas vezes resultando em requisitos incompletos devido à dificuldade em defini-los integralmente. Ao longo do processo de desenvolvimento de software, a compreensão do problema pelos stakeholders está em constante evolução, exigindo uma adaptação contínua dos requisitos do sistema para refletir essa mudança de compreensão. Após a implementação do sistema, novos requisitos podem surgir devido a erros, mudanças no ambiente de negócios e tecnológico, bem como diferentes necessidades dos stakeholders, demandando uma gestão eficaz de requisitos para acompanhar essas mudanças e garantir a coesão entre os requisitos do sistema.

O gerenciamento de mudança de requisitos desempenha um papel crucial na avaliação da viabilidade e do impacto das mudanças propostas após a aprovação do documento de requisitos de um sistema. Esse processo inclui a análise do problema e a especificação da mudança, a avaliação do impacto e a estimativa de custo da mudança, e a subsequente implementação da mudança. É imperativo atualizar o documento de requisitos após as mudanças serem realizadas para manter a coesão entre a especificação dos requisitos e a implementação do sistema.

A rastreabilidade de requisitos é essencial para a análise de impacto das mudanças e para a manutenção do software, permitindo a identificação de requisitos ausentes, a eliminação de requisitos desnecessários, a garantia de certificação e conformidade, a análise do impacto das mudanças, a facilitação da manutenção do software e a execução de testes. Embora manter a rastreabilidade seja desafiador, é fundamental para garantir uma compreensão clara do escopo das mudanças no software. Uma forma comum de representar a rastreabilidade é através de uma matriz bidimensional, que pode ser implementada utilizando uma planilha eletrônica ou uma ferramenta automatizada, assegurando a atualização contínua das informações rastreadas.

Em suma, a engenharia de requisitos é um processo essencial e contínuo durante todo o desenvolvimento de software, assegurando a compreensão e tradução precisa das necessidades dos stakeholders em requisitos claros. Ao fornecer uma estrutura para várias etapas, como elicitação, análise, documentação, validação e gerenciamento de requisitos, ela desempenha um papel fundamental na criação de sistemas de software bem-sucedidos que atendem às metas do cliente e do usuário final. Além disso, destaca-se a importância da adaptação contínua dos requisitos para acompanhar as mudanças no ambiente empresarial e tecnológico, garantindo a pertinência e eficácia do sistema ao longo do tempo. Em resumo, a engenharia de requisitos é uma disciplina dinâmica e crucial que fomenta a colaboração entre todas as partes envolvidas, resultando em soluções de software que agregam valor e satisfazem as necessidades em constante evolução do mercado. 

É Hora de Praticar!

Esta atividade tem como objetivo compreender a diferença entre requisitos funcionais e estruturais (também conhecidos como requisitos não funcionais) em projetos de desenvolvimento de software. Você vai praticar a classificação de requisitos para um projeto de software fictício, aprimorando sua capacidade de identificar e diferenciar esses dois tipos de requisitos.

Projeto de software fictício: Sistema de reservas de hotéis on-line

O sistema permite que os usuários busquem hotéis, vejam detalhes dos quartos, comparem preços, façam reservas e paguem online. Ele também deve oferecer uma interface administrativa para os hotéis cadastrarem e atualizarem informações sobre quartos, preços e disponibilidade.

Lista de requisitos para classificação:

• O sistema deve permitir que os usuários criem uma conta usando seu endereço de e-mail.
• O sistema deve criptografar as senhas dos usuários antes de armazená-las no banco de dados.
• O tempo de resposta para buscas de hotéis não deve exceder 2 segundos.
• O sistema deve permitir que os usuários filtrem hotéis por localização, preço e disponibilidade.
• O sistema deve enviar um e-mail de confirmação após a conclusão de uma reserva.
• O sistema deve ser acessível em dispositivos móveis e desktops.
• O sistema deve manter um registro de todas as reservas feitas, acessível pelos administradores do hotel.
• O sistema deve garantir uma disponibilidade de 99,9%.
• O sistema deve oferecer suporte a múltiplos idiomas.
• O sistema deve permitir que os administradores do hotel gerenciem as informações de seus hotéis.

Tarefa:

• Classificação: você deve classificar os requisitos acima em "Funcionais" ou "Estruturais".
• Discussão: após a classificação, apresente a razão por trás da sua classificação, destacando a importância de cada tipo de requisito para o sucesso do projeto. 

Reflita

• Definir os requisitos de um sistema são fundamentais para o sucesso de um software. Será que existem requisitos que, se não forem prontamente atendidos, podem colocar em risco o sucesso do programa ao ponto de o cliente não utilizar o software desenvolvido?
• Estabelecer uma boa comunicação na elicitação de requisitos é fundamental para se ter sucesso. Como podemos determinar uma boa comunicação entre todas as partes envolvidas, estabelecendo um entendimento comum? Como diminuir os problemas de comunicação entre todos os stakeholders?
• Como a modelagem de software pode influenciar a qualidade e a eficácia dos sistemas desenvolvidos, além de proporcionar uma compreensão mais profunda das necessidades dos usuários e dos requisitos do projeto?

Dê o Play!

Clique aqui para acessar os slides do Dê o play!

Resolução do estudo de caso

Para o projeto de software fictício "Sistema de reservas de hotéis on-line" apresentado na atividade, aqui está o gabarito sugerido para a classificação dos requisitos em funcionais e estruturais:

Requisitos funcionais

1. O sistema deve permitir que os usuários criem uma conta usando seu endereço de e-mail.

• Descreve uma funcionalidade específica relacionada à interação do usuário com o sistema.

2. O sistema deve permitir que os usuários filtrem hotéis por localização, preço e disponibilidade.

• Detalha uma funcionalidade do sistema que permite aos usuários realizar buscas baseadas em critérios específicos.

3. O sistema deve enviar um e-mail de confirmação após a conclusão de uma reserva.

• Especifica o comportamento do sistema de enviar notificações automáticas para os usuários.

4. O sistema deve manter um registro de todas as reservas feitas, acessível pelos administradores do hotel.

•  Indica uma funcionalidade do sistema relacionada à gestão de informações de reservas.

5. O sistema deve permitir que os administradores do hotel gerenciem as informações de seus hotéis.

• Descreve uma funcionalidade administrativa do sistema para os provedores de serviço (hotéis).

Requisitos estruturais (não funcionais)

1. O sistema deve criptografar as senhas dos usuários antes de armazená-las no banco de dados.

• Relacionado à segurança e proteção de dados, não é uma funcionalidade direta do ponto de vista do usuário.

2. O tempo de resposta para buscas de hotéis não deve exceder 2 segundos.

• Especifica um critério de desempenho que o sistema deve cumprir.

3. O sistema deve ser acessível em dispositivos móveis e desktops.

• Define um requisito de compatibilidade e acessibilidade do sistema.

4. O sistema deve garantir uma disponibilidade de 99,9%.

• Estabelece um critério operacional relacionado à disponibilidade do sistema.

5. O sistema deve oferecer suporte a múltiplos idiomas.

• Indica um requisito de internacionalização, relacionado à usabilidade e acessibilidade, mas não é uma funcionalidade específica do ponto de vista da lógica de negócios.

Essa classificação ajuda a destacar a diferença entre o que o sistema faz (requisitos funcionais) e como o sistema deve ser (requisitos estruturais). Os requisitos funcionais estão diretamente relacionados às ações que o sistema deve ser capaz de executar, enquanto os requisitos estruturais descrevem propriedades gerais e critérios que o sistema deve atender para garantir qualidade, segurança, desempenho e usabilidade. 

Dê o play!

Assimile

Este infográfico oferece uma visão sobre a modelagem de requisitos, um processo crucial na Engenharia de Software. Ao longo deste recurso visual, exploramos os diferentes aspectos da modelagem de requisitos, abrangendo as técnicas mais utilizadas, compreendendo a importância da linguagem natural na redação de requisitos e como os diagramas, como o diagrama de casos de uso e a notação SysML, podem ser empregados para visualizar e comunicar eficazmente os requisitos do sistema

Referências

PAULA FILHO, W. P. Engenharia de software: produtos. 4. ed. Rio de Janeiro: LTC, 2019.

PFLEEGER, S. L. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.

PRESSMAN, R S. Engenharia de software: uma abordagem profissional.  9. ed. – Porto Alegre: AMGH, 2021.

SOMMERVILLE, I. Engenharia de software. 10. ed. São Paulo: Pearson, 2018.