Priorização de Requisitos

Olá sejam bem-vindos ao canal engenharia de software com ênfase uml Eu sou professor Janes Gets e eu já atuo na área de modelagem de software há vários anos eu tenho quatro líos publicados sobre o assunto e eu já ministrei diversas palestras e cursos técnicos sobre modelagem de software utilizando a linguagem uml na aula de hoje eu vou falar sobre priorização de requisitos que é uma atividade normalmente executada durante a fase de análise de requisitos então eu vou apresentar algumas técnicas de priorização principalmente a técnica Moscou Então vamos iniciar nossa aula então priorizar requisitos é essencial

por diversos motivos entre os quais determinar o núcleo dos requisitos do produto ou seja os requisitos cruciais os requisitos essenciais para que o produto seja considerado minimamente aceitável então é importante que eu consiga priorizar os requisitos além de descobrir quais são os requisitos essenciais que precisam Obrigatoriamente desenvolvidos eu consigo identificar quais requisitos que podem ser úteis mas ainda assim possam ser Deixados para versões futuras em situações em que o cronograma não seja suficiente para desenvolver o software que o orçamento não seja adequado que ocorra algum problema com a equipe de desenvolvimento alguns dos seus membros

saiam do projeto em situações em que a real complexidade das funcionalidades não foi avaliada corretamente em situações que novos requisitos surjam ao longo do projeto então priorizar requisitos é útil para saber que que requisitos precisam Obrigatoriamente ser desenvolvidos e quais requisitos podem eventualmente ser negociados em situações à Não previstas em situações em que não é possível atender completamente todas as solicitações do cliente então sabendo Quais são os requisitos essenciais eu sei o mínimo que eu tenho que desenvolver para deixar o cliente minimamente satisfeito então uma maneira de priorizar requisitos levando em consideração a sua importância

é determinar se os requisitos eles são essenciais desejáveis ou opcionais então o requisito ele essencial se caso ele não seja atendido o software não será considerado aceitável pelas partes interessadas então requisitos essenciais são aqueles requisitos que precisam Obrigatoriamente ser implementados então eles enfocam as características mais cruciais para o software mais importantes para o software e eles constituem o mínimo que pode ser considerado aceitável para ah a entrega do produto então requisitos essenciais eles recebem sempre o nível de prioridade mais alta e nós temos os requisitos que são considerados desejáveis são requisitos que são bastante importantes

também eles agregam muito valor ao software porém o produto ele continuaria sendo aceitável caso esse tipo de requisito ele não fosse H atendido então em situações como eu falei em que houver atraso no cronograma cortes no orçamento ah alguma diminuição da equipe de desenvolvimento ah situações em que a complexidade é maior do que a prevista situações em que surgem novos requisitos Então os requisitos desejáveis poderiam em uma uma situação extrema ser deixados por uma versão futuro então requisitos desejáveis eles recebem o nível de prioridade intermediário mas seria muito bom requisitos sempre requisitos desejáveis sempre devem

ser implementados na medida do possível mas diferente dos essenciais eles podem ser deixados por uma nova versão em último caso e nós temos requisitos opcionais então o requisito ele é opcional quando o valor que ele agrega ao software é pequeno é pífio é é de pouca monta Então são requisitos que se não fosse implementados o produto ainda assim seria plenamente ou bastante satisfatório sem ele então esse tipo de requisito ele recebe o nível de prioridade mais baixo e vai ser atendido por último e somente Se isso for realmente possível se houver tempo e se o

orçamento permitir e obviamente os requisitos opcionais vão ser sempre os primeiros serem descartados em situações em que é necessário negociar requisitos agora vou falar sobre a técnica Moscou que é uma técnica que é utilizada obviamente para priorizar requisitos e ela classifica os requisitos em eh quatro categorias que são os must have oos Should have os could have e o Will not have os requisitos must have são os que Obrigatoriamente precisam ser implementados ou seja os essenciais os Should have são os que deveriam ser implementados ou seja os requisitos desejáveis e os could have seriam os

requisitos opcionais os requisitos com menos importantes que seria seria bom se fosse possível implementar Mas também se não fosse implementados o impacto seria pequeno para o produto final já os requisitos Will not have ou w have eles são requisitos que não serão implementados pelo menos não na versão atual por não terem prioridade para esse projeto e muitas vezes eles estarem fora do escopo do produto vamos falar sobre isso ao longo dessa aula então essa técnica é chamada de porque ela pega as as iniciais m de must have S de Should have C de could have

e w de Will not have então fica msw que lembra a palavra Moscou ã em inglês ou seja a capital da Rússia então daí que veio o nome da técnica bom então obviamente os requisitos que forem classificados como must have eles são requisitos essenciais Então esse tipo de requisito ele precisa Obrigatoriamente ser desenvolvido E se eles não forem H desenvolvidos o software não vai ser útil para o cliente não vai ser útil para as partes interessadas então Eh os requisitos que recebem esse nível considerado prioritário considerado essencial eles são inegociáveis não é possível negociar esses

requisitos eles precisam ser atendidos eles constituem o mínimo necessário para que o software seja razoavelmente considerado aceitável pelas partes interessadas sem a implementação de requisitos essenciais o software não é útil para o cliente já os requisitos shh são requisitos que são identificados como sendo muito importantes eles agregam um valor alto ao produto e eles deveriam ser desenvolvidos porém em situações extremas Como já falei falhas no cronograma ã problemas no orçamento problemas na equipe de desenvolvimento n problemas complexidade não estimada corretamente solicitação de novos requisitos etc então em situações extremas o seu desenvolvimento poderia ser negociado

e postergado para uma segunda versão em situações extremas o ideal é que eles sejam desenvolvidos também mas em último caso se eles não fossem desenvolvidos o software ainda seria útil mesmo sem a sua implementação e nós temos requisitos do tipo could have Então esse tipo de requisitos são requisitos que poderiam ser desenvolvidos mas que o valor agregado por eles ao software é pequeno Não é não é grande não é então não são requisitos muito muito importantes e caso não fosse desenvolvidos o impacto no projeto seria pequeno então esse tipo de requisito ele só realmente é

implementado se as condições forem favoráveis para isso então são equivalente a requisitos opcionais e nós temos os requisitos Will not have ou want que são requisitos que não vão ser implementados pelo menos não na versão atual em desenvolvimento em geral requisitos un not have eles são requisitos que estão fora da fronteira do software não pertencem realmente ao software estão fora do seu escopo e portanto não devem ser implementados mesmo eh na verdade eles eh acarretariam um esforço desnecessário para o desenvolvimento do software tornariam A Sua Entrega mais demorada e na verdade eles muitas vezes fariam

parte do escopo de outro projeto então eles não devem ser implementados bom vamos falar um pouco sobre como aplicar a técnica Moscou Então antes de iniciar a aplicação propriamente dita da Moscou as partes interessadas que estão envolvidas com o projeto elas devem eh concordar com os objetivos do software com o escopo do software com as fronteiras do sistema e com os critérios de priorização elas devem devem ser informadas a respeito a técnica de priorização que será utilizada como ela é aplicada E no momento que eles estão de acordo com essa técnica Então os requisitos passarão

a ser priorizados Ah ainda antes de aplicar a técnica priamente Dita é preciso eh estabelecer o prazo final para entrega do produto normalmente quanto menor for o cronograma menor deve ser os com prioridade existem Existem duas situações na verdade a priorização de requisitos ajuda na na negociação com cliente então se for identificados requisitos mas que vão exceder o cronograma então ou o cronograma tem que ser estendido ou então o projeto tem que ser abandonado porque a o engenheiro de requisitos tem que dizer com esse prazo que foi dado nós não temos condições de entregar todos

os requisitos must todos os requisitos essenciais então o produto que vai ser entregue Não vai satisfazer a as partes interessadas não será suficiente paraa empresa então ou se estende o cronograma ou o projeto deve ser abandonado Ah também deve-se elaborar planos para solucionar possíveis conflitos que que possam surgir entre os requisitos e possivelmente entre as partes interessadas existem técnicas específicas de negociação que serão ensinadas em outros vídeos ã e somente após isso a equipe Então ela estabelece Qual é a percentagem de recursos que serão que serão atribuídos a cada categoria eh em termos de basicamente

tempo bom Aqui nós temos algumas perguntas para que auxiliam a identificar requisitos com prioridade must então As perguntas são o software será realmente útil sem esse requisito Ah o produto final satisfará o cliente sem sem este requisito o software terá legalidade sem este requisito o software funcionará se esse requisito não for implementado a não implementação desse requisito acarretará prejuízo para a empresa ou a organização não será autorizada a utilizá-lo ou disponibilizá-lo ou comercializá-lo o produt prodo não será seguro sem esse requisito em termos que permitirá invasões não autorizadas ou poderá causar grandes prejuízos ou perdas

de vida ou impactos negativos ambientais Ah então após essas perguntas se se concluir que o software ele seria viável mesmo que o requisito em questão não fosse implementado na atual versão Então esse requisito precisaria ser classificado como shh ou could have caso eh não não se tenha chegado a essa conclusão pelo contrário que o software ele não seria viável se o requisito não fosse implementado então ele deve receber a classificação must have ah falando a sobre os requisitos de com prioridade Should have Então esse tipo de requisito eles são como já foi falado muito importantes

para o projeto eles agregam grande valor ao software são portanto altamente desejáveis e deveriam ser implementados porém ã eles não são absolutamente necessários tá em último caso eles podem não ser implementados na versão atual porque ã o software produzido sem eles ainda seria útil para a organização então eles podem ser negociados em casos extremos de problemas orçamentários de cronograma problemas da equipe etc e ser então implementados em uma nova versão algumas perguntas para identificar requisitos com prioridade Should have quanto valor esse recurso agrega ao projeto Essa não é uma pergunta muito fácil de responder o

software continuaria sendo útil para organização se esse requisito não fosse implementado esse requisito Pode ser implementado na próxima versão do produto ah com relação à primeira pergunta é necessário uma certa experiência do engenheiro de requisitos e ter bastante auxílio de usuário chave usuários com experiência eh na empresa com conhecimento sobre o domínio do problema com conhecimento sobre o setor ou processo onde o software será implementado ã então é sempre importante trazer esse tipo de eh parte interessada para ajudar na priorização dos requisitos com relação a requisito Should have e could have o problema isso é

um isso é uma das desvantagens ou defeitos ou um fator de fraqueza do m mosc é que às vezes pode ser difícil diferenciar um requisito Should have de um requisito could have porque a diferença está no valor que el o produto e como eu falei medir esse valor às vezes é bastante subjetivo às vezes é muito complexo por isso como eu falei é necessário a participação de partes interessadas com experiência com bastante conhecimento sobre o problema sobre o processo que vai ser substituído pelo software O que irá ao ser auxiliado pelo software sobre o departamento

onde ele vai estar sendo eh implantado Ah ainda também eh impacta na classificação de Should have could have eventualmente o número de partes interessadas que serão afetados pelo requisito Então embora Talvez seja um requisito considerado de pouco que agregue pouco valor ser ele impacta eh num número expressivo de partes interessadas Então ele pode ser considerado um Should have os requisitos R eles agregam valor também porém eh é um valor menor de novo isso pode ser um pouco subjetivo às vezes para uma parte interessada pode ser um valor de pouca monta de Pouca importância e para

outro pode ser de um pode ser um valor expressivo é por isso que é necessário às vezes negociação Mas normalmente um requisito crave ele agrega um valor pequeno ao projeto e a sua não implementação causa pouco impacto no projeto então requisitos desse tipo embora também seja desejável que eles possam ser implementados eles são pouco importantes e podem ser postergados e negociados com uma facilidade maior do que os requisitos Should have não implementar requisitos Should have é uma alternativa de em último caso sh rev devem ser implementados mas em último caso eles podem ser negociados já

os skud rev eles nem tanto eles não são tão importantes então eles são os negociados primeiro ah algumas perguntas para identificar requisitos could have é esse requisito é necessário ao escopo principal do projeto Qual o impacto da não implementação desse requisitos Lembrando que escopo Como já foi falado em outras áreas define Ah o que o software deve fazer de uma maneira pragmática ou seja o que é realmente possível implementar considerando as restrições aplicadas ao projeto restrições no caso são cronograma orçamento ferramentas de apoio hardware disponível expertiz da equipe esse tipo de coisa Ah e Finalmente

nós temos requisitos do tipo Will not have ou w have que são requisitos que não possuem prioridade para o projeto e que muitas vezes nem mesmo estão dentro do escopo do projeto eh Então não é não é não não eles não eles não somente eh não serão implementados como não devem ser implementados eles faz muitas vezes fazem parte de outro software de outro sistema então identificar requisitos Will not R ele é útil para auxiliar a estabelecer as fronteiras do sistema auxiliar identificar quais requisitos estão fora do escopo do sistema isso ajuda a diminuir as a

não ajuda a não criar grandes expectativas por parte das interessadas e não causar decepções futuras já Deixa claro o que não vai ser implementado E além disso isso também permite evitar um aumento exponencial de requisitos que podem ser adicionados ao projeto e que na verdade eles não são úteis ao projeto realmente eles podem futuramente ser implementados num software integrado por exemplo Então os requisitos do tipo un eles dificilmente vão ser implementados pelo menos não na versão atual eventualmente alguns deles poderão no futuro ser repriorização futura de serem implementados mas em geral a maioria deles não

vai ser implementados nunca porque não fazem parte do escopo do software pelo menos não serão implementados no projeto desse software de repente eles podem ser implementados num projeto de um software que estará integrado ao software em questão conversará com software extensão mas que não faz parte realmente do escopo do nosso software do software que nós estamos implementando agora que nós estamos desenvolvendo agora algumas perguntas para identificar requisitos com prioridade un rev são esse requisito Tem qualquer importância para o projeto esse requisito Tem qualquer prioridade para o projeto esse requisito está realmente dentro do escopo do

projeto são algumas perguntas que devem ser feitas na verdade essas perguntas todas que foram faladas elas devem ser feitas para todos os requisitos algumas delas servem para identificar se os requisitos são must should could ou que não estão fora estão totalmente fora do escopo do software Então são eh requisitos do tipo un Aqui nós temos um pequeno exemplo de classificação de requisitos utilizando a técnica Moscou ele tá bem resumido H se refere aos requisitos do sistema para controle de encomendas não vai ser possível apresentar todos os requisitos então selecionei dois de cada tipo Então os

primeiros requisitos em vermelho são do tipo must have os em a são Should have os en could have e os em roxo são not have então enviar encomenda e Rastrear encomenda foram considerados must então eles Obrigatoriamente precisam ser desenvolvidos gerir distribuidoras parceiras e encaminhar encomendas para distribuidoras parceiras embora requisitos bastante importantes em último caso poderiam ser deixados como uma segunda versão de repente a empresa pode não trabalhar com com distribuidoras parceiras na primeira versão tá isso pode ser num segunda versão em uma situação extrema em que não é possível implementar todos os requisitos então should

haves em último caso não serão implementados Nós temos dois requisitos good have que são emitir relatório de mesos com mais demanda por filial e emitir relatório de destinos de encomenda mais solicitados por filal Então são se tiver esse relatório ele até ajuda mas não é muito útil não é tão importante assim então eles são classificados como k eles poderão SEME implementado se houver tempo já controlar o estoque de material de consumo e calcular hora extras dos funcionários eles receberam a classificação Wood notra porque na verdade eles estão fora da fronteira do sistema eles não fazem

parte do escopo desse software o escopo desse software é controlar encomendas controlar o estoque de material de consumo está dentro do escopo de outro software isso aí seria um sistema de controle de estoque calcular extras dos funcionários estaria dentro de um outro software seria por exemplo um sistema de folha pagamento ou coisa parecida mas não do Sistema de Controle de encomendas Então são requisitos que não serão atendidos Ahã falar um pouquinho sobre as vantagens da técnica Moscou ela tem várias ela permite uma clareza na prioridade Então ela permite identificar claramente O que é essencial e

o que pode ser eventualmente negociado numa versão futura ou mesmo descartado se não fizer parte do escopo do software então a técnica mosc ela permite identificar um produto mínimo viável ou seja o minimum viable product o MVP que é o essencial que o software deve entregar o mínimo para o cliente considerar o software aceitável Ahã Uma Outra vantagem é facilidade de entendimento priorizar requisitos facilita comunicação ajuda na negociação com os clientes ajuda na na Solução de Conflitos e nas disputas entre as partes interessadas Numa vez que H os requisitos Eles foram priorizados ã se pode

utilizar esse argumento durante as negociações de conflitos que podem eventualmente surgir entre as partes interessados então como eu falei ele facilita a comunicação é uma técnica intuitiva e fácil de compreender tanto pelo pela equipe de desenvolvimento como pelas partes interessadas que embora leigas no tecnologicamente elas conseguem entender a técnica de priorização com mais facilidade e como falei isso ajuda na negociação na solução de conflitos ah Uma Outra vantagem é o alto foco no valor de negócio ele ajuda também ainda relacionado à facilidade comunicação ele ajuda e incentiva que a equipe as partes interessadas Disc sobre

o valor que cada requisito agregará o projeto então ah vai permitir com que a equipe entenda Quais são os requisitos mais importantes e vai focar naquilo que realmente agrega valor ao negócio Ah também permite uma gestão eficaz de expectativas porque já Deixa claro o que será e o que não será desenvolvido e qual nível de prioridade do que será desenvolvido então não gera falsas expectativas já deixa clo para para algumas partes interessadas este requisito não será desenvolvido porque está fora do escopo também permite já deixar claro para as partes interessadas quais requisitos poderão não ser

desenvolvidos se houver problemas ao longo do projeto Uma Outra vantagem é flexibilidade a as prioridades elas podem ser ajustadas ao longo da evolução do do projeto isso permite a uma maior agilidade e capacidade de adaptação do projeto o está dentro da ideia dos métodos ágeis então uma outra vantagem da técnica Moscou é que ela suporta o desenvolvimento ágil ã uma vez que H essas metodologias ágeis elas prezam a entrega contínua de valor então o suporte de desenvolvimento ágil ele ã permite enfocar nos requisitos essenciais que serão os primeiros a a serem implementados nos primeiros nas

primeiras interações também permite a a adaptação às mudanças quando surgirem novos requisitos ou eh os requisitos sejam modificados e a sua priorização mude e dessa forma auxilia na entrega de versões incrementais do produto eh agora falar sobre as desvantagens existe uma pressão pode ocorrer uma pressão para definir muitos requisitos como sendo ã e isso pode diluir a prioridade se eu tiver muitos requisitos must rev eu tenho uma dificuldade de negociação eu tenho que estender muito cronograma isso encarece o orçamento também ã e muitas vezes alguns desses requisitos considerados most RAV na verdade não são tão

essenciais assim talvez eles possam ser classificados como Shut RAV Ah então se eu tiver muitos eh requisitos must have Ah pode ser que eu não consiga entregar o projeto dentro prazo ou que o cronograma e e eventualmente o orçamento precisam ser eh renegociados é mais comum isso acontecer com equipes inexperientes que ainda não estão acostumadas com a técnica Moscou ah como eu falei às vezes ocorre uma certa dificuldade em diferenciar requisitos Should have de requisitos could have uma vez que essa classificação é um pouco subjetiva depende da forma como o valor agregado é estimado E

isso também depende de da Visão da perspectiva de cada parte interessada como eu falei uma parte interessada pode considerar um requisito como Should have e outra pode considerar como could have também pode haver H dificuldade de estabelecer requisitos do tipo w not have por quê porque algumas partes interessadas podem não aceitar que certos requisitos não serão implementados às vezes é preciso ter uma certa uma certa calma um certo Tato para explicar que determinados requisitos não fazem parte do scopo do software eo é parte particularmente difícil quando existem muitas partes interessadas ã de diversos setores diferentes

e com perspectivas diferentes Ah ainda essa a técnica Moscou ela precisa de muita comunicação muita colaboração muito alinhamento é necessário que as partes interessadas trabalhem junto com a equipe na priorização então se não houver muita colaboração se não houver eh comunicação e alinhamento então isso pode requisitar pode pode pode causar mal-entendidos ou gerar expectativas não realistas para as partes interessadas então a priorização pode ser mal feita Ah ainda Moscou ela é embora não seja exclusiva de métodos ágeis ela tem um viés ágil um pouco forte Então ela costuma às vezes ter um foco no curto

prazo então a a essa técnica ela tende a a favorecer que sejam feitas várias entregas em um prazo curto isso pode causar uma visão limitada em que não se identificam ou não se priorizam requisitos de longo prazo ou requisitos que permitam eh uma evolução do produto mais fácil bom então essas foram as vantages e desvantagens da técnica Moscou eu vou falar rapidinho de Ah mais uma forma de priorizar requisitos onde eles podem ser priorizados por estabilidade ah basicamente estabilidade diz respeito ao nível de volatilidade ao nível de mudança ao nível de alteração que um requisito

pode sofrer então nessa técnica os requisitos eles são classificados em instveis ou permanentes voláteis ou transitórios Ah então requisitos estáveis ou permanentes como nome já diz são requisitos que possuem não não não existe uma expectativa que eles mudem ah ao longo do projeto Ou pelo menos que as mudanças sejam pouco pouco frequentes e pouco impactantes Ah já requisitos voláteis são requisitos que T uma probabilidade de sofrer grandes mudanças ou uma grande quantidade de mudanças durante o desenvolvimento do software e esse tipo de requisito ele costuma ser considerado de maior risco e recebe então uma maior

prioridade eles provavelmente serão desenvolvidos primeiro e nós temos requisitos de transição que são sempre requisitos temporários basicamente eles servem para identificar a necessidade de mudança de um estado atual que pode ser por exemplo quando um setor já tem tem um sistema legado já defasado já difícil de manter difícil de evoluir ou ainda quando existe um processo manual que precisa h de um software para eh auxiliá-lo então Eh esse tipo de requisito então identifica essa necessidade de mudança para um novo estado que na maioria das vezes quase sempre vai se caracterizar por pelo desenvolvimento de um

software novo ou ou a automação de um processo que H estava manual Ahã mas mesmo assim apesar de existir esse tipo de de priorização eles muitas vezes eles precisam ser reclassificados repriorização e eventualmente os requisitos ainda podem sofrer uma nova classificação levando em consideração os seus custos de implementação por exemplo Às vezes o custo de implementação pode pesar na priorização do requisito e nós concluímos mais essa aula eu espero que essa aula tenha sido considerada útil espero que vocês tenham gostado dessa aula Se vocês gostaram desse vídeo eu peço que vocês curtam esse vídeo compartilhem

com quem possa ter interesse e se ainda não estão inscritos eu peço que se inscrevam no canal obrigado pela atenção nós nos vemos nas próximas aulas