ANÁLISE DE NEGÓCIO para a STN – Engenharia de Requisitos

Saudações concurseiras! Com este post, damos sequência à saga do tópico ANÁLISE DE NEGÓCIOS para a STN (https://blog.grancursosonline.com.br/analise-de-negocio-para-a-stn/). Já revisitei com você os tópicos de gerenciamento de processos de negócio – BPM (https://blog.grancursosonline.com.br/analise-de-negocio-para-a-stn-bpm/) e do Guia BABOK (https://blog.grancursosonline.com.br/analise-de-negocio-para-a-stn-babok/). Agora chegou a vez da Engenharia de Requisitos.

Já adianto a você que o tópico de Engenharia de Requisitos é um dos mais cobrados pela FGV. E para tentar perceber alguma tendência da banca, vamos resolver e analisar algumas questões, as mais recentes possíveis. Mas, antes das questões, um pouco de conceitos sobre requisitos, engenharia de requisitos e os tipos de requisitos.

O que são requisitos

First of all, existem diferentes definições de requisitos encontradas na literatura. Como o edital não define um autor ou indica literatura de referência, vale a pena fazer um apanhado das diferentes definições encontradas.

Requisito é uma característica do sistema ou a descrição de algo que o sistema deve ser capaz de realizar para atingir os seus objetivos. As descrições das funções e restrições do sistema são classificadas como os requisitos do sistema. Um requisito é uma propriedade (característica) que o software deve exibir para resolver algum problema no mundo real. Por fim, requisito é uma condição ou uma capacidade que deve ser alcançada ou estar presente em um sistema para satisfazer um contrato, padrão, especificação ou outro documento formalmente imposto.

Engenharia de Requisitos

A disciplina da Engenharia de Requisitos, conforme cobrado no Edital, se encarrega de coletar, analisar e refinar esses requisitos, garantindo que a solução de software seja desenvolvida com precisão, atendendo às necessidades reais dos usuários e alinhada com os objetivos do negócio. A imagem a seguir detalha o diagrama do processo de engenharia de requisitos.

E já lá vamos à primeira questão. Concurso para o cargo de Analista de Sistemas da SES do Mato Grosso. A questão cobra o conhecimento da definição de engenharia de requisitos, das suas etapas (conforme imagem acima e a figura que ilustra a resposta da questão) e da noção de que obviamente trata-se de um processo iterativo, evidenciado pelas setas “que vão e voltam”.

Tipos de Requisitos (com exemplos)

Requisitos funcionais – descrevem o que o sistema deve fazer, detalhando suas funções e processos. Alguns exemplos são: (1) O sistema deve permitir o cadastro de clientes; (2) O sistema deve permitir a geração e extração de relatório mensal de vendas; (3) O sistema deve permitir o pagamento das compras através de meios eletrônicos (cartão de débito e crédito, além de pix).

Requisitos não funcionais – especificam como o sistema deve ser em relação ao desempenho, segurança, usabilidade, e outros aspectos que definem a qualidade do software. Alguns exemplos são: (1) O sistema deve ser compatível com os browsers Chrome e Mozilla; (2) O sistema deve garantir que o tempo de retorno das consultas não seja maior do que 2 segundos.

E isso já nos habilita a resolver mais uma questão. Trata-se da prova para Analista Legislativo da Assembleia Legislativa do Tocantins. O foco da questão está nos requisitos não funcionais. E, pela definição acima, enriquecida pelos exemplos, você é capaz de resolver com sucesso, lembrando dos quesitos de desempenho e usabilidade destacados no enunciado.

Outras tipologias

Além dos requisitos funcionais e não funcionais, ainda temos os requisitos de domínio, os quais já nos aproximam do domain-driven design (DDD), conforme será explicado na sequência.

Requisitos de domínio – são derivados do domínio (contexto) da aplicação e descrevem características do sistema e qualidades que refletem este domínio. Podem ser requisitos funcionais novos, restrições sobre requisitos existentes ou computações específicas. Exemplo: um aplicativo de transporte utilizado por um motorista que transita pelas ruas de Brasília precisa levar em consideração regulamentações locais, tarifas específicas ou até mesmo eventos que possam afetar o trânsito no nosso quadradinho. 

A partir dos requisitos de domínio, nos aproximamos do domain-driven design (DDD). DDD foi “assunto” da prova de Auditor Fiscal da Receita Estadual de MG, conforme a questão a seguir. Na questão, cobra-se de forma adjacente o conceito de domínio de um sistema, com relação à área e ao problema de negócio que ele pretende resolver, que acaba por “criar” uma linguagem compartilhada com os termos técnicos e de negócio daquele domínio.

Well done! Se você chegou até aqui, compartilhou comigo este sobrevoo na Engenharia de Requisitos. Fique esperto, pois “isso é um mundo” A-DO-RA-DO pela FGV. Nossa saga terá sequência no próximo post, no qual vamos “pensar coletivamente” com Design Thinking, um assunto que virou trend topic – mas, sem ansiedade! ☺ 

Agora vai! Rumo à sua aprovação!!

Fernando Escobar

Doutorando em Tecnologias e Sistemas de Informação pela Universidade do Minho, em Portugal, com pesquisas relacionadas a gestão de projetos/processos, transformação digital e blockchain aplicados ao setor público.

Mestre em Computação Aplicada pela Universidade de Brasília (UNB), com linha de pesquisa em Gestão de Riscos. Também possui Especialização em Gestão Pública pela Escola Nacional de Administração Pública (ENAP).

Entre 05/2010 e 07/2016, como Servidor Público Federal, foi Analista em Tecnologia da Informação, vinculado à Secretaria de Logística e Tecnologia da Informação (SLTI), do Ministério do Planejamento, Orçamento e Gestão (MPOG), tendo exercido as funções de chefe de divisão, coordenador, coordenador-geral, assessor técnico e diretor, em alguns órgãos do Executivo Federal em Brasília.

Desde 08/2016, é Servidor da Justiça Federal, do cargo de Analista Judiciário, especialidade Informática, do quadro do Tribunal Regional Federal (TRF) da 1a Região.