TEMA 2 - Leitura PrВvia Fundamentos (Componentes) da Engenharia de Requisitos

Prévia do material em texto

1 
 
Engenharia de Requisitos 
Tema 2 – Fundamentos da Engenharia de Requisitos 
Processo de Desenvolvimento de Software; Contexto do sistema e Limite do sistema; 
Etapas da Engenharia de Requisitos no Processo de Desenvolvimento de Software; 
A Importância da Comunicação na Engenharia de Requisitos – Usos de 
Linguagens;- Tipos de Requisitos - Funcionais, não funcionais e Inversos. Fontes 
de Informação e Técnicas de Elicitação de Requisitos; Sete Habilidades e 
Competências necessárias a um Engenheiro de Requisitos. 
 
Processo de Desenvolvimento de Software 
Um processo de desenvolvimento de software é uma forma sistemática e padronizada de 
produção de software de acordo com abordagens de ciclo de vida. Geralmente é mais 
barato, a longo prazo, usar métodos e técnicas da engenharia de software para sistemas 
de software, em vez de simplesmente escrever os programas como se fossem algum 
projeto pessoal. Para a maioria dos sistemas, a maior parte do custo é mudar o software 
depois que ele começa a ser usado. A abordagem sistemática usada na engenharia de 
software é, às vezes, chamada processo de software. Um processo de software é uma 
sequência de atividades que leva à produção de um produto de software (SUMERVILLE, 
2011). Existem quatro atividades fundamentais comuns a todos os processos de software. 
São elas: 1. Especificação de software, em que clientes e engenheiros definem o software 
a ser produzido e as restrições de sua operação. 2. Desenvolvimento de software, em que 
o software é projetado e programado. 3. Validação de software, em que o software é 
verificado para garantir que é o que o cliente quer. 4. Evolução de software, em que o 
software é modificado para refletir a mudança de requisitos do cliente e do mercado 
(SOMERVILLE, 2011). Todo software tem início a partir dos requisitos como fator 
determinante para sua utilidade. A Engenharia de Requisitos inclui um conjunto de 
atividades que envolvem: Elicitação, Análise, Especificação, Verificação, Validação dos 
Requisitos. Engenharia de Requisitos é disciplina responsável por essa utilidade. Não é 
possível imaginar um sistema que não tenha a sua origem numa necessidade do cliente 
ou mercado. Para tanto utiliza-se de um conjunto de atividades e artefatos vinculados a 
essas atividades. Os Modelos clássicos e desenvolvimento implicam na definição de 
todos os requisitos na fase inicial. Nos Modelos baseados em metodologias ágeis, onde a 
interação com o cliente é uma premissa básica, os requisitos evoluem ao longo do projeto, 
conforme as necessidades derivadas dessa interatividade com as partes interessadas1. 
Diferentes restrições na execução de projetos influenciam a Engenharia de Requisitos. 
Tais restrições podem envolver aspectos que fazem parte do Contexto do sistema e o 
Limite do sistema. 
 
 
 
1 Pessoas que têm qualquer influência direta ou indireta sobre os requisitos: Clientes e usuários; 
Gerentes de projeto; Analistas de sistema; Engenheiros de testes; Mantenedores, etc 
2 
 
Contexto do sistema e Limite do sistema 
Os Modelos clássicos e desenvolvimento implicam na definição de todos os requisitos na 
fase inicial do Desenvolvimento. Nos Modelos baseados em metodologias ágeis os 
requisitos que evoluem ao longo do projeto, conforme a necessidades derivadas da 
interatividade com as partes interessadas. Diferentes restrições na execução de projetos 
influenciam a Engenharia de Requisitos. Tais restrições podem envolver aspectos que 
fazem parte do Contexto do sistema e o Limite do sistema. 
 Quanto ao Contexto do Sistema: Refere-se a tudo que é relevante para definição, 
compreensão e logicalização dos requisitos de um software. Exemplos: Pessoas 
chave na Organização (Partes interessadas ou stakeholders); • Sistemas 
vinculados como entrada ou saída ao projetado; • Processos de negócio 
vinculados como entrada ou saída com o sistema projetado; • Eventos externos 
disparados que mobilizam alguma ação do sistema (Triggers). Você irá precisar 
muito desse conceito quando estiver fazendo as abstrações dos atores que irão 
interagir com o sistema projetado. 
 Quanto ao limite do sistema - Identifica tudo que foi gerado a partir do projeto de 
desenvolvimento do sistema. Exemplos: Funcionalidades envolvendo cadastros; 
; atualizações/inclusões e exclusões; Processos internos em reposta a Sistemas; 
vinculados, Processos de negócio e a eventos; externos disparados a parti de 
atores que mobilizam alguma ação do sistema (Triggers). 
A correta avaliação do contexto e limite do sistema é parte do estudo da viabilidade. 
Nesse ponto devem ser respondidas as perguntas2: como o sistema contribui para os 
objetivos gerais da organização? O sistema pode ser implementado com a tecnologia atual 
dentro das restrições de custo e de prazo? O sistema pode ser integrado a outros sistemas 
já em operação? 
 
Etapas da Engenharia de Requisitos no Processo de Desenvolvimento de Software 
As etapas da Engenharia de Requisitos no Processo de Desenvolvimento de Software 
incluem: 
 Concepção – A concepção tem o objetivo de ter uma visão geral do negócio, 
conhecer entender as expectativas e necessidades do cliente nesse contexto. Os 
Resultados esperados incluem a identificação dos interessados (stakeholders) e 
seus diferentes pontos de vista e uma visão geral do contexto do sistema. Nessa 
fase algumas perguntas precisam ser respondidas3, e a partir delas, preparado um 
relatório de viabilidade que poderá propor mudanças no enfoque, no orçamento 
e/ou no cronograma; sugerir outros requisitos de alto nível para o sistema e no 
pior dos mundos, simplesmente cancelar o projeto de desenvolvimento do 
sistema. 
 Elicitação: Tem como finalidade principal obter, por meio de técnicas e 
ferramentas, os dados e informações necessários à Modelagem das 
funcionalidades que serão desenvolvidas no projeto de sistema. Isso inclui: 
Objetivo, ou seja, entender o que o cliente espera do software; Incertezas do 
 
2 Professor Eduardo Figueiredo - http://www.dcc.ufmg.br/~figueiredo - DCC / ICEx / UFMG 
3 Professor Eduardo Figueiredo - http://www.dcc.ufmg.br/~figueiredo - DCC / ICEx / UFMG 
3 
 
cliente; Volatilidade dos requisitos; Serviços prestados pelo sistema; Restrições 
que devem ser obedecidas; Critérios de desempenho. Os resultados esperados 
são: Narrativa em linguagem natural dos requisitos do sistema pelo cliente e Lista 
de requisitos do sistema elicitados pelo analista. 
 
 Análise de Requisitos: Tem como finalidade principal aferir os atributos de 
qualidade, a viabilidade e logicalização dos requisitos de modo que atendam as 
expectativas do cliente (utilidade e qualidade) e da organização (produtividade e 
custo). 
 Especificação - Tem como finalidade principal especificar os requisitos que 
foram condensados e que se alinham às expectativas e as necessidades das partes 
interessadas. Essa tradução é feita através de modelos formais, baseados em 
linguagem padrão UML, incluindo a interação com o cliente através de diagramas 
Casos de Uso e outros diagramas orientados à abordagem técnica dos 
desenvolvedores, incluindo Classe, Sequência, Estado, objeto, etc). 
 Verificação - Refere-se ao conjunto de atividades necessárias à aferição da 
conformidade da solução projetada e desenvolvida em relação às expectativas e 
resultados esperados pelas partes interessadas. Isso inclui testes baseados em 
comparações e padrões referenciais de qualidade preestabelecidos. 
 Validação – Validação visa mostrar que os requisitos realmente definem o 
sistema que o cliente deseja. Refere-se ao processo de aprovação formal e 
documental das soluções propostas do projeto de software, em temos dos 
requisitos funcionais e não funcionais e inversos. De acordo com Figueiredo4 ( A 
aferição da Validação inclui: Da validade: Quais serviços são necessários? Da 
consistência: Existe conflitos entre requisitos? Da completude: Todos os 
requisitos estão documentados? Da Factibilidade:Os requisitos podem ser 
implementados? Da Testabilidade: como requisito foi implementado? 
A Importância da Comunicação na Engenharia de Requisitos – Usos de Linguagens 
A linguagem natural é rica em gesticulações, tonalidades e expressões que reforçam a 
redundância para a compreensão das mensagens. A comunicação é a expressão do 
conhecimento através da linguagem. A comunicação satisfatória exige um padrão comum 
entre os indivíduos que alternam recepção e transmissão. Na construção de software a 
comunicação é padronizada através de um padrão de linguagem técnica. A figura a seguir 
resume a comunicação nesse processo: 
 
 
4 Professor Eduardo Figueiredo - http://www.dcc.ufmg.br/~figueiredo - DCC / ICEx / UFMG 
4 
 
A linguagem natural carece de um dos atributos mais importantes na qualificação dos 
requisitos: A precisão Com efeito, a comunicação natural depende fortemente de 
redundância, isso significa que a precisão pode ser perdida na forma escrita. O padrão de 
comunicação da Engenharia de Requisitos é a UML. De acordo com Rupp e Pohl (5) 
podem ser utilizados, dependendo do projeto, três tipos de documentação de requisitos; 
linguagem natural, conceituais (modelos e diagramas) e estrutural, funcional e 
comportamental e híbrida ( reúne ambas anteriores). A linguagem unificada de 
modelagem É um padrão conceitual para modelagem orientada a objetos. A UML surgiu 
da fusão de três grandes métodos, do BOOCH, OMT (Rumbaugh) e OOSE (Jacobson). 
Esta linguagem de modelagem não proprietária (não pertence comercialmente a nenhuma 
empresa) e nem tampouco é um método de desenvolvimento. Têm como papel auxiliar a 
visualizar o desenho e a comunicação entre objetos. Ela permite que desenvolvedores 
visualizem os produtos de seu trabalho em diagramas padronizados, e é muito usada para 
criar modelos de sistemas de software. É uma linguagem de modelagem única, comum e 
amplamente utilizável mantida pela OMG. 
 
Tipos de Requisitos - Funcionais, não funcionais e Inversos. 
 
Diversos autores detalham os requisitos em diferentes categorias, para efeito de 
simplificação estamos agregando-os em três macro- categorias: Funcionais, não 
funcionais e Inversos. 
Funcionais - Os requisitos funcionais tratam das funções definidas pelo analistas que têm 
relação direta com o negócio e as soluções para resolver os problemas de informação do 
cliente. Ex; Calcular o faturamento do período mês fechado. RF-1: Uma mensagem de 
status deve ser mostrada na área inferior da página; A mensagem estoque deve ser 
atualizada a cada 60 segundos, com tolerância de 10 segundos para mais ou para menos; 
A mensagem de sistema ativo deve estar sempre visível : Se a mensagem for referente a 
uma tarefa em andamento, o percentual de andamento deve ser mostrado; Se a mensagem 
for referente a uma tarefa já terminada, isso deve ser informado com o texto etc. 
 Requisitos Não Funcionais - São aqueles que derivam de condições do ambiente 
operacional em atender as expectativas de desempenho, segurança, vinculados ao 
atendimento dos níveis de serviço na execução do sistema. Isso inclui: Usabilidade – 
Estética, consistência, facilidade de interação com o usuário etc. Confiabilidade – 
Precisão e gravidade das falhas etc. •Desempenho – Tempo de resposta, tempo de 
processamento, flexibilidade de carga, etc •Suporte – Tipos de suporte técnico 
predefinido. O sistema deve ficar disponível por 99,5% do tempo nos dias úteis, das 6h 
às 22h; Eficiência - Em condições de pico de uso, deve ter uma reserva de 25% de 
capacidade de processamento e memória; O cálculo de interferência deve ser finalizado 
com sucesso em menos de 5 minutos; Processar um pedido de compra com tempo de 
resposta de até 10 milissegundos. Imprimir na tela um relatório composto do cruzamento 
de até 10 tabelas no máximo em 20 milissegundos. Distribuir um informe na rede em até 
milissegundos; Disponibilizar um robô dançarino com boot em até 20 milissegundos; 
restrições derivadas das rotinas de segurança, configuração de servidores, etc; 
 
5 POHL, Klaus; RUPP, Chris. Fundamentos da Engenharia de Requisitos - Um guia para o exame CPRE-
FL em conformidade com o padrão IREB. 
5 
 
Requisitos Inversos - Poucos autores referem-se ao requisitos inversos que são aquelas 
que representam expectativas do cliente que o analista deve deixar claro que não serão 
atendidas pelo sistema. Tais requisitos expressamente não serão implementadas (seja na 
atual versão ou mesmo nunca mantidas as s condições presentes). É importante observar 
que se o analista de requisito não deixar claro, a situação pode levar a conflitos e 
cobranças futuras. São Exemplos de requisitos inversos: Calcular o custo emocional de 
transações; Disponibilidade acima de 100%. Garantir Segurança 100%. Se se isso não 
for esclarecido corre-se o risco de serem assumidos como óbvios e ser parte integrante 
das funcionalidade do sistema, gerando problemas futuros. 
 
Fontes de Informação e Técnicas de Elicitação de Requisitos 
Em geral as fontes de dados e informação para coleta de requisitos incluem: Stakeholders 
(partes interessadas, Documentos, Sistemas preexistentes e Processos de negócio. As 
técnicas de elicitação ou descoberta de requisitos incluem: Entrevista, Questionário, 
Brainstorming, Mudança de perspectiva, Analogia, Documental , Observação 
participante, etc, A maioria pode ser apoiada por ferramentas como mapas mentais, 
workshops, Cartões CRC, vídeo, Protótipos, etc. 
Na realidade não existe uma técnica geral para Elicitação, tudo irá depender do tipo de 
cliente e da natureza do projeto entre outros aspectos psicológicos que incluem: Fatores 
conscientes e Inconscientes: Fatores conscientes - São requisitos explicitamente exigidos 
e, se atendidos, aumentam a satisfação do Cliente e vice versa. Fatores subconscientes 
são aqueles que devem ser atendidos embora não gerem aumento da satisfação. Porém 
são de alto descontentamento em caso de sua falta. Fatores inconscientes, são requisitos, 
cujos valores e o cliente não percebe, e que somente serão reconhecidos com testes na 
prática. A maioria desses fatores tem origem e geram impactos com restrições em termos 
de tempo, orçamento e atenção dos stakeholders. 
 
Sete Habilidades e Competências necessárias a um Engenheiro de Requisitos – 
Assumindo que o conhecimento depende da qualidade da ação, conforme registramos 
anteriormente, um processo de desenvolvimento de software é uma forma sistemática e 
padronizada de produção de software de acordo com abordagens de ciclo de vida. O 
analista deve fazer abstrações conhecido o Contexto do Sistema, ou seja - tudo que é 
relevante para definição, compreensão e logicalização dos requisitos de um software e, 
derivar para concepção do Limite do Sistema: conjunto de funcionalidades projetadas no 
sistema. A solução é traduzida em diagramas através de uma linguagem padronizada 
(UML). No entanto, convenhamos, que todos esses componentes seriam irrelevantes ou 
inúteis se não pudessem contar habilidades e competências do Engenheiro de Requisitos: 
 
 
 
 
 
 
6 
 
O quadro a seguir apresenta uma síntese das prováveis consequência na falta de uma 
dessas habilidades e competências na perspectiva de um engenheiro de requisitos. 
 
 Sete Capacidades necessárias para um Engenheiro de Requisitos 
 
Possui a Capacidade (Habilidade/Competência ) ? 
 
 
Provável 
Consequência 
 
 
1 -Raciocínio 
Analítico 
 
Não 
 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Justificativas 
para Erros 
 
2 - Comunicação 
 
Sim 
 
Não 
 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Gritaria. 
 
3 -Empatia 
 
Sim 
 
Sim 
 
Não 
 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Isolamento 
 
4 -Moderação 
 
Sim 
 
Sim 
 
Sim 
 
Não 
 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Conflito 
 
5-Persuasão 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Não 
 
 
Sim 
 
Sim 
 
Sim 
 
Aceitação 
comprometedora 
 
6 -Resoluçãode 
Conflito 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Não 
 
 
Sim 
 
Sim 
 
Guerrilha ! 
 
7 - Auto - 
Confiança 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Não 
 
Sim 
 
Terapia 
 
8 - Liderança 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Sim 
 
Não 
 
 
Caos 
 
 
Referências Bibliográficas 
POHL, Klaus; RUPP, Chris. Fundamentos da Engenharia de Requisitos - Um guia 
para o exame CPRE-FL em conformidade com o padrão IREB. 
SOMMERVILLE, Ian. Engenharia de Software, 9th Edition. Pearson Brazil.2011