Engenharia de Requisitos - Parte I - Introdução

Olá sejam bem-vindos ao canal engenharia de software com ênfase o ML Eu sou professor Janes GS e eu já atuo na área de modelagem de software há vários anos eu tenho quatro livros publicados sobre o assunto e eu já ministrei diversas palestras de cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu pretendo introduzir alguns fundamentos sobre engenharia de requisitos Então vamos iniciar a nossa aula então este é o primeiro vídeo que eu pretendo gravar sobre engenharia de requisitos ele vai ser dividido em várias partes porque é uma um tema

bastante extenso Mas vamos iniciar eh esse tema introduzindo alguns conceitos básicos então a engenharia de requisitos ela busca identificar compreender e detalhar claro e precisamente os problemas que precisam ser solucionados por um determinado software em essência a engenharia de requisitos ela tenta determinar o que precisa ser feito Isso inclui estabelecer as necessidades das entidades que irão utilizar um software e as possíveis restrições que deverão ser impostas a estas necessidades essas restrições podem ser por exemplo regras de negócio consistências validações ou mesmo definição de atributos de qualidade como nível de desempenho ou confiabilidade necessários ao software

a partir dessas informações a engenheria de requisitos ela tenta garantir que se irá desenvolver o produto certo da maneira certa então um processo de inaria de requisitos ele costuma ser composto por diversas etapas as principais delas as mais importantes são elicitação de requisitos onde busca-se levantar os requisitos necessários análise de requisitos onde os requisitos levantados serão como o nome já diz analisados especificação de requisitos que irá documentar esses requisitos e validação de requisitos e que se irá procurar por anomalias erros falhas e inconsistências na especificação de requisitos falar um pouquinho sobre elicitação de requisitos então

como eu já falei a elicitação de requisitos ela identifica as necessidades das partes interessadas relacionadas a um problema específico partes interessadas são todas as pessoas que têm interesse no desenvolvimento do software ou serão de alguma forma afetadas por ele então a engenharia de requisitos como o nome já disse a Aliás a elicitação de requisitos ela busca determinar quais requisitos um software deve satisfazer existe uma série de técnicas de licitação de requisitos que vão desde as clássicas porque podem ser entrevistas ou questionários aplicados aos usuários passando por eh tempestades cerebrais grupos focais indo até ah análise

de documentos ou eh investigação observação de como os usuários trabalham na realidade no seu ambiente existem uma série de técnicas mais de 20 Não não nós não vamos ver essas técnicas Neste vídeo por enquanto Ah bom então já falei os requisitos eles podem ser obtidos ah por meio de diretamente a partir das partes interessadas por meio de avaliação de documentos pela observação como os usuários trabalham pela compreensão Doo do problema solucionado entre outras possibilidades Fala um pouquinho sobre análise requisitos na análise requisitos o nome já diz os requisitos são analisados eles são examinados e melhor

detalhados então H basicamente durante a licitação de requisitos se identificam principalmente requisitos de negócio e de usuário requisitos de negócio e de usuário são requisitos de um nível mais alto então durante a análise esses requisitos eles são inclusive melhor identificados novos requisitos de negócio de usuários podem surgir e esses requisitos eles são transformados em requisitos de sistema que são requisitos com uma profundidade maior com detalhamento maior em relação aos requisitos de usuário e muitas vezes se descobre novos requisitos no momento em que os requisitos que foram elicitados previamente passam a ser melhor examinados além disso

a análise requisitos ela também tenta determinar se os requisitos foram bem compreendidos se eles não possuem conflitos ou ambiguidades inconsistências e outras outras anomalias ambiguidades é quando o requisito ele é passível de mais de uma interpretação O que é um problema grave para engenheiria de requisitos e também eh para garantir que os requisitos refletem realmente os recursos e funcionalidades que o produto deve suportar uma funcionalidade é uma função serviço que o software deve oferecer aos seus usuários e também as restrições condições regras de negócio que precisam ser obedecidas eh durante a análise requisitos também eh

se consolida a visão do produto a a visão do produto ela determina Qual o problema se quer resolver a qual público o software se destina Qual o propósito final do software que se que se pretende desenvolver ã então basicamente estabelece o motivo básico para que o software seja desenvolvido e nós temos o escopo do software o escopo do software e a visão do produto estão interrelacionados mas não são exatamente a mesma coisa a visão ela determina o que o produto deverá fazer para satisfazer as necessidades dos clientes e seus usuários finais já o Esopo determina

o que pode ser realmente feito ele também define as fronteiras do software O que é muito importante para determinar quais requisitos fazem realmente parte do escopo que realmente são pertencentes à aquele produto e os que estão fora do seu propósito isso é muito útil para primeiro Diminuir a quantidade de trabalho a ser eh desenvolvido e também para já Logo no início não deixar eh os clientes as partes interessadas com falsas expectativas já deixar bem claro o que faz parte do produto e o que não faz parte do produto ã falando um pouquinho sobre especificação e

requisitos a basicamente a especificação de requisitos ela produz documentos esses documentos eles identificam claramente o problema a ser solucionado Ah e eles devem expressar corretamente os requisitos que são necessários ao produto de maneira que seja possível na fase de projeto projetar uma solução correta para o problema em questão então uma especificação de requisitos ela deve ser escrita de tal forma que ela possa ser avaliada inspecionada e aprovada de maneira sistemática falando um pouquinho sobre validação de requisitos a validação de requisitos ela procura examinar o documento de especificação de requisitos para garantir que ele não possua

falhas anomalias para garantir que eh os requisitos estão definidos de maneira correta seguindo padrões atendendo as qualidades de um bom requisito e que estão de acordo com o cliente e as outras partes interessadas solicitaram e necessitam eh bom mas isso não é somente isso pode não ser suficiente ah determinar se os requisitos foram especificados de maneira correta garante somente que se está desenvolvendo certo o produto isso na verdade é uma verificação não garante que se está desenvolvendo o produto certo ou seja se o software realmente irá satisfazer as necessidades do cliente Isso sim é validação

e é bem mais complexo Ah um exemplo clássico é o do fabricante rolhas se Um fabricante rolhas ele recebe uma determinada encomenda de rolhas e quando as rolhas estiverem prontas ele verifica se elas têm as medidas que foram solicitadas ele está fazendo uma verificação Agora se ele realmente pega uma garrafa do cliente dele e tenta fechar com a rolha para ver se realmente a rolha fecha aquela garrafa então está fazendo uma validação bom falar brevemente sobre gerenciamento de requisitos ã que é uma uma fase Extra da engenharia de quisitos ou uma atividade extra além das

quatro que eu citei mas bastante importante eh ela é muito importante porque os requisitos eh podem eh ser modificados isso é bastante frequente os requisitos podem mudar ao longo do projeto também pode acontecer que requisitos surjam ao longo do desenvolvimento software ou mesmo que quisitos sejam abandonados e substituídos por outros eles podem em um determinado fase do projeto se perceber que na verdade eles não são mais necessários então isso pode acontecer então é necessário uma forma de poder gerenciar as modificações as mudanças dos requisitos bom vamos continuar falando sobre alguns conceitos básicos da engenharia de

requisitos a iner de requisitos ela é a primeira tarefa a ser executada ah na verdade o som defensor da engenharia de requisitos na minha opinião a engenharia de requisitos é a fase mais importante da engenharia de software uma vez que ela define o problema a a palavra chave aqui é o qu o que precisa ser feito o problema deve ser compreendido claramente se não não importa com quão bem o software seja desenvolvido ele não irá atender as necessidades do usuário então a engenheria de quisitos ela precisa ser executada com muita seriedade de maneira a evitar

grandes prejuízos erros de requisitos causam tem um custo muito alto normalmente evitar atrasos evitar retrabalho durante a construção do produto então como eu falei saber corretamente o que precisa ser feito é essencial para que o projeto seja bem sucedido uma vez que nós nos basearmos em uma compreensão errada do problema durante o desenvolvimento software é um os fatores mais comuns para que o projeto fracasse e quanto mais tarde Se descobre uma falha nos requisitos maior é o custo para corrigi-los ah falando um pouquinho sobre as fases de engenharia de requisitos que eu falei há pouco

é importante destacar que elas não precisam ser executadas completamente para se passar para outra fase não é necessário fazer uma licitação completa uma análise completa uma especificação completa mesmo porque muitas vezes é algumas dessas fases elas podem ocorrer em paralelo análise e especificação pode muitas vezes pode não em geral ocorre em paralelo e Então nada impede que as fases da engenharia de quisitos elas sejam executadas de forma iterativa e incremental ou seja um grupo de requisitos vai ser analisado especificado por vez e também muitas vezes o final de uma fase ela se confunde com o

início de outra e como eu falei pode ocorrer paralelismo a fase de licitação já gera uma certa especificação de requisitos a fase de análise produz muita especificação de requisitos e assim por diante Ah então os requisitos Eles foram a base de todo o projeto a partir do qual o produto será construído e ele é a medida básica para determinar a qualidade de um software se um software não atende aos requisitos solicitados ele não tem qualidade não importa o que faça então já que os requisitos eles são o alicerce a partir do qual o projeto ser

será construído eles precisam ser muito bem compreendidos muito bem especificados eles precisam ser compreendidos corretamente senão Muito provavelmente o projeto fracassará Então os requisitos eles representam basicamente as necessidades dos clientes e das outras partes interessadas com relação a um problema específico então estas necessidades com o software ser desenvolvido precisa satisfazer Então os requisitos eles representam as funções que o software deverá oferecer a seus usuários quando ele tiver concluído ou seja suas funcionalidades e as possíveis restrições aplicadas a elas consistências validações regras de negócio etc agora por que os requisitos eles são tão importantes Bom eu

acho que já falei um pouco sobre isso mas vamos deixar mais claro por definem o que o software deverá fazer então eles são essenciais é preciso compreender o que o software deverá fazer é preciso compreender corretamente as necessidades das partes interessadas de tal forma que o projeto de software seja bem sucedido se os requisitos foram mal compreendidos ou foram mal definidos então Muito provavelmente o projeto fracassará Ah falar um pouquinho sobre alguns autores que reitera o que eu estou falando então nós temos por exemplo beren Bach que ele afirma que estudos indicam que cerca de

Metade dos fatores Associados com o sucesso de projetos estão relacionados aos requisitos e que o sucesso de um projeto de software está diretamente ligado à qualidade desses requisitos o hull ele corrobora essa afirmação eh e juntamente com presma em que eles afirmam que a definição incorreta dos requisitos do sistema é um dos principais fatores para fala de um projeto e o regnal ele afirma que a licitação análise e documentação ou seja especificação de requisitos em Sistemas complexos é uma tarefa crucial e não trivial ou seja não é fácil o hull ele acrescenta que os requisitos

eles são a base de Todo projeto eles definem o que as partes interessadas necessitam do sistema e o que o sistema deve fazer de forma a satisfazer essas estas necessidades bom então os requisitos eles formam base para o planejamento do projeto para o gerenciamento de riscos riscos são qualquer possibilidade de falha de erro de problema que possa ocorrer ao longo do projeto para os testes os testes n testes mas por exemplo os testes de aceitação é a comparação do que foi pedido com que o software faz ah para tradeoff Escolha entre opções Anes e para

o controle de mudança então definir os requisitos e basicamente é compreender as necessidades dos clientes e das partes interessadas Então o que se deve inquirir durante a identificação dos requisitos Qual o problema ser resolvido quais funcionalidades o software precisa suportar quem poderá usar estas funcionalidades como os usuários interagiram com elas além de outras informações agora falar um pouquinho sobre o custo de erros nos requisitos então quanto mais cedo os erros em requisitos forem encontrados então o custo de reparo desses erros Será menor se for encontrado um erro na fase requisitos na fase de engenharia de

requisitos então o o custo é de c a 10 vezes menor do que se for encontrado um erro na fase de codificação ah e o custo detectar um erro durante a fase de manutenção é 20 vezes maior do que na fase de engenharia de requisitos ah com relação aos erros cometidos na fase de projeto projeto Ela já trabalha com a solução do problema eles podem ser divididos em duas categorias principais erros reais de projeto e erros que poderiam ter sido detectados como erros de requisitos erros de projeto eles são cometidos tomando como base um conjunto

de requisitos uma especificação de requisitos correta então são erros da equipe de projeto erros que a equipe cometeu e não a equipe de engenharia de requisitos já erros que deveriam ter sido detectados durante a fase de engia requisitos mas que foram aceitos pela equipe de projeto então eles eh por melhor que o projeto tenha sido feito o projeto se encontra errado em sua origem uma vez que os requisitos foram mal elaborados foram mal identificados foram mal especificados foram mal analisados então quando isso ocorre com relação a essa segunda categoria essa esse tipo de erro ele

é costuma ser muito mais caro por duas razões Quando os erros requisitos foram descobertos já se já se investiu muito tempo e esforço em construir um projeto a partir de requisitos errados então o projeto terá que ser descartado Ou pelo menos sofrer grande refatoração e a verdadeira natureza do erro pode estar disfarçada porque a equipe de projeto assume que eles estão procurando por erros do projeto no durante as atividades de inspeção ou atividades e teste então vai se gastar um tempo esforço bastante grande procurando erros que na verdade não eram erros de projeto e sim

de de erros da engenharia de requisitos então o custo é muito maior vou falar um pouquinho sobre os diversos tipos de partes interessadas para isso Eu me basei principalmente no sboc eh então grande parte dos requisitos costuma ser identificada a partir de interação com as partes interessadas as partes interessadas também são conhecidas como stakeholders ou usuários Chaves e São pessoas que eh TM interesse no desenvolvimento do software ou serão afetadas por ele então Eh as partes interessadas elas podem formar podem ser formadas Então por qualquer pessoa como falei qualquer pessoa que tem interesse no desenvolvimento

software qualquer pessoa que fé ven a ser afetada por ele Então as partes interessadas elas podem ser divididas em usuários clientes analista de mercado reguladores Engenheiros de software entre outros vamos falar um pouquinho desses cinco então usuários basicamente são as pessoas que irão utilizar o software eles vão assumir diversos papéis ah a utilizar esse software e cada papel terá acesso a requisitos diferentes Ah o grupo de usuários ele pode ser dividido em primários secundários E terciários então usuários primários são os usuários que realmente irão utilizar o software ou seja os usuários finais os eh usuários

secundários são as pessoas que eventualmente pode utilizar o software e os terciários são pessoas ou entidades que irão ser afetados de alguma maneira pelo software esse a a a forma como ele será afetado Eles serão afetados pode ser Econômica ou profissionalmente E essas pessoas H esse tipo de usuário terciário muitas vezes Eles tomam decisões sobre o produto Ah então muitas vezes ah os clientes podem ser considerados os vários terciários também que são eles que pagam eles que tomam a grande parte das decisões finais ah com relação ainda aos usuários alguns desses usuários eles são profissionais

que possuem um conhecimento avançado Sobre o domínio do problema que se pretende resolver com o usuário com o software Ah e como determinado processo ou Setor funciona então os esse tipo de usuário chamado usuário chave ele é essencial para a engenharia de requisitos uma vez que ele possui conhecimento sobre um determinado processo o setor ou tem bastante conhecimento sobre o problema que se está tentando solucionar que está tentando eh resolver então eles são usuários que precisam muitas vezes ser consultados para eh levantar para identificar os requisitos do sistema Normalmente eles fornecem muitos requisitos importantes e

muitas vezes eles tê mais conhecimento sobre determinados ã setores da empresa do que o próprio cliente às vezes ele sabe melhor sobre o problem sobre domí do problema problema sai melhor como determinado processo funciona do que do que o cliente pagador Ah então como eu falei a participação D tipo de usuário é em geral essencial uma vez que ele tem conhecimento profundo sobre as áreas que eu falei então ele é muito útil na concepção e identificação de requisitos considerados importantes e necessários ao software porém esses requisitos esses usuários essenciais para engenharia de quisitos eles também

são essenciais para entidade solicitant então o tempo e dedicação que eles podem ã doar ao projeto doar a equipe de engenheiria de requisitos e ao projeto e ao ciclo de desenvolvimento como um todo eh costuma ser exíguo e caro porque eles são essenciais para a empresa também a empresa não pode prescindir deles durante muito tempo agora vou falar sobre outro tipo de parte interessada que são os clientes que são basicamente quem solicita e paga pelo software ou ainda que representam o mercado para o qual o software se destina ah muitas vezes esses clientes podem ser

considerados também como usuários terciários ah apesar de serem eles que pagam pelo produto às vezes eles não têm um conhecimento Tão Profundo sobre uma determinada característica do problema ou sobre um determinado setor ou processo onde o software será eh implantado ou usufruído então pode haver usuários Chaves que tenham mais familiaridade mais conhecimento sobre o problema ou sobre determinados setores da empresa a qual o software se destina eh falar um pouquinho sobre os analistas de mercado que eles são bastante úteis quando o software se destina a um grande público não a uma empresa específica Então esse

tipo de parte interessada os analistas de mercado eles são responsáveis por determinar o que o mercado quer e o que o mercado necessita e nós temos os reguladores que eles são as autoridades reguladoras que se baseiam em leis externas ou normas internas e que estabelecem eh requisitos e restrições que precisam ser obedecidos pelo software então eles podem influenciar fortemente as regras de negócio dos requisitos regras de negócio são como o nome diz normas que precisam ser obedecidas por determinadas funcionalidades e nós temos o engenheiro de software que são os responsáveis pelo projeto como um todo

eles têm interesse em compreender o problema solucionado uma vez que a responsabilidade deles desenvolver o software e eles querem que o projeto seja bem sucedido e é isso nós terminamos essa primeira parte essa introdução sobre engenharia de requisitos em outras aulas posteriores nós iremos aprofundar um pouco mais no tema eu agradeço a atenção de todos Espero que esse conteúdo tenha sido útil se vocês gostaram do vídeo eu peço que vocês curtam esse vídeo compartilhem com quem possa se interessar e se vocês ainda não estão inscritos Eu gostaria que você se inscrevesse no canal obrigado pela

atenção nós nos vemos em outras aulas