Especificação de Requisitos - Introdução

Olá sejam bem-vindos ao canal engenharia de software com ênfase um ml Eu sou professor Jes Gets 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 vou abordar a etapa de especificação de requisitos Então vamos iniciar a nossa aula esta vai ser então a nossa primeira aula sobre especificação de requisitos e eu vou introduzir alguns conceitos básicos sobre essa etapa da engenharia de quisitos

eu vou iniciar com uma pequena historinha do Dilbert o Gilbert é esse personagem da esquerda ele começa falando Ah os seus requisitos de usuário incluem quatro ã 400 funcionalidades Ah você percebe que nenhum ser humano seria capaz de usar um produto com tal nível de complexidade E aí o outro personagem fala bem lembrado acho que é melhor adicionar Fácil de usar a lista bom ah vamos começar o nosso conteúdo Então então como já falei a especificação de requisitos é uma das quatro fases principais da engenharia de requisitos de acordo com sboc e o objetivo da

da fase desta fase é documentar os requisitos identificados mas ao mesmo tempo uma especificação de requisitos se traduz em um documento ou um conjunto de documentos que descrevem os requisitos do software e Existem várias formas de especific de especificar requisitos então Eh basicamente o documento de especificação de requisitos consiste numa declaração do que serve do que deve ser implementado então requisitos de alta qualidade Como já foi falado em outros vídeos eles são claros completos não ambíguos ou seja não são passíveis de mais uma interpretação eles são consistentes ou seja não possuem conflitos entre si eles

são implementáveis a um custo razoável e eles são testáveis dentro de um custo e de um tempo razoável se algum requisito não apresentar essas características então ele é problemático ele precisa ser revisto precisa ser renegociado ah Possivelmente eh novas e eh licitações requisitos devem ser feitas novas análises requisitos devem ser feitas para corrigir esses problemas então a a fase de especificação de requisitos ela tenta produzir documentos que identifiquem claramente Qual o problema a ser solucionado e que expressem corretamente os requisitos tanto funcionais como não funcionais necessários a esse problema a esse produto Lembrando que requisitos

funcionais identificam as funcionalidades do software ou seja o que o software deve oferecer quais serviços o software deve oferecer a seus usuários e os requisitos não funcionais identificam características de qualidade gerais do software como desempenho confiabilidade escalabilidade portabilidade proteção segurança esse tipo de coisa Ah então uma especificação de requisitos ela a fase de especificação de requisitos ela deve produzir documentos que expressem corretamente os requisitos que são necessários ao produto de tal forma que seja possível projetar uma solução para o problema eh descrito pela especificação Ah então uma especificação de requisitos ela precisa ser escrita de

uma maneira que ela que permita que ela possa ser revisada validada e aprovada sistematicamente dentro de um tempo e de um custo aceitáveis bom falar um pouquinho sobre alguns tipos de informações que uma especificação de requisitos deve ou pode conter Bom primeiramente ela deve descrever as funcionalidades que o software deverá suportar Como já falei funcionalidades representam requisitos funcionais ou seja serviços funções que o software oferece a seus usos os então a especificação de requisitos ela precisa conter a descrição de cada requisito funcional juntamente com suas restrições consistências e possíveis regras de negócio associadas a eles

também eh uma especificação de requisitos deve conter a as suas interfaces externas que podem ser como o software irá interagirá com os usuários então isso pode ser representado por meio de protótipos como o software interagirá com outros itens de hardware ou seja como vai ser feita como se dará a sua comunicação lógica entre o software e itens de hardware especial que ele precisa interagir quando isso for necessário e como ele Inter interagirá com outros softwares como por exemplo sistemas integrados também quando quando e Se isso for necessário ah outras informações são requisitos não funcionais requisitos

não funcionais são características de identificam características de qualidade do software eh características que muitas vezes devem ser atendidas pelo software como um todo por exemplo desempenho ou se el com relação ao requisito no funcional de desempenho pode-se descrever qual qual a velocidade de processamento esperado pelo software Qual o tempo de resposta ã do software com relação aos pedidos do dos usuários e outros parâmetros de desempenho que podem ser necessários devido à natureza da aplicação Ah então quando se trata de sistemas de tempo real ã que necessitam de um tempo de resposta muito rápido então o

requisito no funcional desempenho ele é muito importante e deve ser descrito com detalhes em Sistemas em que o desempenho talvez não seja tão importante esse requisito funcional não precisa de um nível de detalhamento tão grande outros requisitos não funcionais que pode que uma especificação de requisitos pode atender eh seria proteção ou seja impedir que pessoas não autorizadas utilizem o software portabilidade permitir que o software Rode em múltiplas plataformas manutenibilidade permitir que o software seja alterado modificado evoluído de maneira fácil reusabilidade seria a capacidade de o reutilizar código em novos projetos confiabilidade garantir que o software

sempre estará funcionando e resistirá falhas e mesmo que alguma falha eh ocorra ele Continuará funcionando ainda que eh levemente mais devagar mas que logo eh retornará ao seu funcionamento pleno escalabilidade a capacidade do software eh crescer aumentando a sua capacidade de atender o número maior de usuários oferecer um número maior de recursos esse tipo de coisa e outros requisitos não funcionais também eh ela pode conter restrições impostas ao projeto como um todo como por exemplo H cronograma orçamento linguagem implementação sistema gerenciador de banco de dados ambientes de operação que foram estabelecidos pelos clientes e outras

partes interessadas a lei de padrões de codificação eh e padrões da própria documentação de especificação de requisitos por exemplo ah a especificação de requisitos ela deve ser escrita por membros da equipe de desenvolvimento juntamente com a participação de um ou mais usuários chave usuários chave são pessoas com muito conhecimento sobre um determinado problema ou um determinado departamento ou processo em que o software irá rodar Ah é importante essa participação dos usuários Chaves Porque como eles têm esse conhecimento avançado essa experiência já bastante grande sobre determinado setor ou processo então eles podem colaborar muito na identificação

de requisitos importantes para o sistema Ah então para isso os usuário chave eles precisam ser informados devidamente e treinados sobre os padrões e notações adotadas para a criação da especificação de requisitos é recomend desenvolvedores ou as partes interessadas que elas não escrevam sozinhas a especificação de requisitos por quê Porque as partes interessadas muitas vezes não entendem os processos de desenvolvimento de software então elas não conseguem fazer uma especificação razoavelmente adequada e os desenvolvedores muitas vezes não entendem a área a área de aplicação de forma completa então é necessário uma sinergia uma colaboração entre as partes

interessadas e os desenvolvedores ainda a especificação de requisitos ele é um contrato e uma forma de comunicação entre a equipe e as partes interessadas ele traduz o que as partes interessadas solicitaram eh para a equipe e é uma forma de garantir que o que foi solicitado realmente seja cumprido além de servir também de um apoio paraa equipe caso a a reclamação dos clientes dizendo que algo não foi feito ou que algo não atende o que foi solicitado Então esse é um documento que permite eh contrapor esse tipo de afirmação então a especificação de requisitos ela

auxilia os gerentes a planejarem o processo de desenvolvimento e os testadores a criarem casos de testes baseado nos requisitos que foram H identificados então uma especificação de requisitos é qualquer forma de documentação e ela pode ser mais ou menos formal Então ela pode ir desde documentos textuais simples sem um padrão estabelecido passando por histórias de usuário que apesar de relativamente simples não deixam de ser uma especificação de requisitos descrições de cenários caso de uso indo até documentos formais como os que são prescritos pela i3e e que serão ensinados nesse canal Ah mais adiante Ah falar

um pouco sobre alguns tipos de especificação de requisitos bom o a especificação pode utilizar sentenças de linguagem natural então basicamente seria uma sequência de frases frases numeradas ou em tópicos organizadas em tópicos e cada uma dessas frases representaria um requisito mais provavelmente seriam requisitos de usuário embora possa ser aplicado para requisitos de sistema também requisitos de usuário são requisitos com um nível de detalhamento menor enquanto requisitos de sistema são eh requisitos mais profundos melhor detalhados que são produzidos durante a análise de requisitos Como já foi ensinado em outros vídeos Aqui nós temos o exemplo de

eh requisitos em linguagem natural eh relativos ao sistema de entrega de encomendas que nós estamos utilizando como exemplo ao longo dessas aulas então aqui h o primeiro requisito afirma que a encomenda deve deve atender à política de peso e volume máximos da empresa estar de acordo com a lei dos países de origem e destino não se tratar de armas ou drogas ou qualquer outro item proibido ou não aceito pela empresa e na segunda e o segundo requisito ele afirma que é necessário armazenar informações sobre o objeto como sua descrição dimensões altura largura e comprimento peso

e os responsáveis pelo recebimento além dos nomes e endereços do remetente e do destinatário uma especificação de requisitos ela também pode utilizar uma linguagem natural estruturada em que o documento ele é dividido em vários Campos esses campos eles podem fornecer informações sobre o documento como um todo ou sobre um requisito específico Aqui nós temos exemplo de documentação de aliás S uma especificação de requisitos utilizando um formato estruturado onde foram apresentados diversos capítulos e a descrição de cada um deles claro que isso está incompleto ainda falta descrever os requisitos propriamente ditos então nós teremos o primeiro

capítulo que seria sobre identificação que poderia incluir título e nota de revisão para saber ã unicamente qual é a versão do documento em questão quantas versões anteriores já já existiram ã a informação de revisão ela pode incluir o nome do projeto o número da versão do documento a data de lançamento assinatura de aprovada uma lista de subcláusulas que foram alteradas na versão atual do documento Ah uma lista de números de versões e datas de lançamento de todas as versões anteriores do documento entre outras informações possíveis nós temos um capítulo de prefácio que inclui sumário lista

de figuras lista de tabelas eh um capítulo sobre definições ou glossário que vai conterá definições para todas as palavras ou frases que possuem significado importante dentro do contexto problema ou que possam ser interpretadas de maneira diferente então isso é importante para estabelecer a única definição para cada palavra para cada termo dentro do contexto do projeto temos um capítulo de referências que inclui uma lista completa de todos os documentos referenciados identificando cada documento pelo título número de relatório quando for necessário H data e organização editorial e fontes das referencias temos o capítulo sobre acrônimos e abreviações

que todos os acrônimos e abreviações eh serão definidos todos que foram utilizados no documento de especificação Ah também se pode utilizar a linguagem de descrição de projeto que usa uma linguagem estruturada como por exemplo português estruturado que tenha características abstratas para definir o modelo operacional do sistema pode-se utilizar também notações gráficas como H diagramas apoiados por texto comentários em texto então por exemplo nós podemos utilizar eh diagramas da uml como o diagrama de caso de uso e o diagrama de classes então Aqui nós temos o exemplo de notação gráfica utilizando diagrama de casos de uso

da uml que ele é útil para identificar as funcionalidades do sistema na forma de elipses cada uma dess elips é representa um caso de uso e os atores que poderão utilizar o essas funcionalidades atores são grupos de usuários então Aqui nós temos clientes atendentes entregadores gerentes de filial gerentes de Gerais e assim vai então nós podemos utilizar notações gráficas dentro da especificação de requisitos podemos e devemos nós também podemos utilizar notações matemáticas que representa uma especificação formal dos requisitos de forma não ambígua e bastante verificável Porém esse tipo de especificação ela é pouco utilizada porque

há poucos profissionais do mercado que dominem esse tipo de especificação ah com relação ao nível de detalhamento da especificação de requisitos isso Varia muito dependendo da complexidade e importância do software então no caso de sistemas críticos sejam complexos longos e ou possam impactar vidas humanas então a especificação de requisitos precisa ser muito detalhada para garantir segurança e proteção para as pessoas ã também para determinar se os impactos das mudanças dos requisitos possam ser estimados e Que riscos de falhas no no no projeto sejam eh mitigados sejam diminuídos sistemas terceirizados também precisam de uma especificação de

requisitos com certo nível de detalhe uma vez que são H empresas outras que irão realmente desenvolver o software então há bastante incerteza com relação à comunicação com as empresas terceirizadas que irão eh produzir o software propriamente dito agora quando se trata de sistemas produzidos internamente com que tem um nível eh de complexidade e risco relativamente baixo ou médio que se use processos iterativos incrementais para desenvolvê-lo cujas partes interessadas sejam razoavelmente acessíveis e exista uma forte gerência e controle de riscos e mudanças então a especificação não precisa ter um nível de detalhe Tão Profundo com relação

aos métodos ágeis tem muita gente di que diz que os métodos ágeis não possuem ã não produzem documentação isso não é verdade métodos ágeis produzem documentação também eles apenas são avessos a trabalho desperdiciado e documentação burocrática que não acrescenta nada ã mas basicamente os métodos ágeis eles costumam argumentar Que documentos requisitos extensos e formais são trabalho desperdiçado Isso depende muito da situação se tratando de sistemas críticos eu acredito que isso não seja verdade ã Porém isso não significa que os métodos ágeis não produzam especificação e requisitos Eles produzem também porém normalmente a especificação costuma ser

eh menor e só se documenta aquilo que é realmente útil para a compreensão do problema então normalmente se produzem várias pequenas coleções requisitos que vão ser eh modeladas implementadas a cada ciclo interativo mas as regras de negócio relacionadas às funcionalidades aos requisitos elas precisam estar visíveis durante todo o projeto bom mas eh Resumindo métodos ágeis produzem também documentação documentação é necessária especificação de requisitos é necessário Eles apenas não não aceitam não gostam de produzir eh de produzir documentação inútil que é apenas burocrática mas métodos ágeis Eles produzem também especificação e requisitos ã bom H falar

um pouquinho sobre documentos de especificação requisitos de acordo com o sboc o sboc é uma base de con é a base de conhecimento para é o corpo de engenharia de conhecimento da da engenharia de software ã então Eh de acordo com o sboc quando se tratar de sistemas realmente complexos então devem se produzir três tipos de documentos definição do sistema também chamado de requisitos de usuário ou conceito de operações requisitos de sistema e requisitos de soft agora quando se trata de softwares não tão complexos Então somente terceiro documento será realmente necessário produzir Na verdade o

documento de requisito software n nessa situação na situação de softwares não tão complexos ele iria englobar a definição do sistema bom então a definição do sistema ela procura descrever em nível alto Quais são os requisitos do sistema levando em consideração a perspectiva do domínio do problema então ela deve conter informações básicas sobre os objetivos gerais do sistema a quem o software se destina o ambiente em que ele será executado possíveis restrições possíveis requisitos não funcionais Ah também pode incluir eh as principais entidades de domínio como os atores ou seja grupos de usuários que poderão utilizar

o sistema cenários de uso diversos cenários relacionados a cada funcionalidade cenário principal cenários alternativos cenários de são modelos modelos conceituais representando as classes de entidade eh que são classes relacionadas diretamente ao domino do problema que que é representa os conceitos em que os com que o software irá trabalhar fluxo de trabalho entre outras possibilidades e esse tipo de documento uma vez que ele é escrito em alto nível ele normalmente Pode ser lido por outras partes interessadas que não a equipe de desenvolvimento já os requisitos de sistema eles só são útil úteis para softwares que trabalhem

com muitos componentes que podem ser tanto de software como de não software ou seja normalmente hardware então eles Normalmente eles são utilizados para especificar requisitos eh de sistemas embarcados ou seja eh sistemas eh agregados a um hardware ou sistemas que envolvam muitos componentes de hardware e eles são desnecessários para outros tipos de software em geral então h o processo para a documentação de requisit para gerar o documento de requisito de sistema é inicialmente especificar os requisitos de sistema os requisitos gerais do sistema como um todo depois derivar os requisitos de de software e em seguida

ah os requisitos dos componentes do software que podem ser tanto outros softwares como itens de hardware já correlação ao documento de requisitos de software Esse é o único documento que deve ser realmente feito para todo tipo de software na verdade os outros dois só são produzidos quando o software é muito complexo Como já foi falado no caso o documento de requisito de software ele costuma eh quando não se trata de um software muito complexo Ah englobar o primeiro documento mais Geral das informações ã sobre sobre o software que vai conter as informações básicas sobre o

escopo a visão do software seus objetivos Gerais esse tipo de coisa então Ele estabelece o cursal o que é esperado que o software faça E também o que não se espera que o software faça ou seja ele define o escopo do produto o escopo ele determina o que é factível produzir ele difere da visão a visão estabelece o que se pretende que o software faça o escopo ele estabelece O que é possível fazer levando em consideração as restrições de projeto como cronograma Eh orçamento expertiz da empresa e ferramentas de hardware e software de apoio e

o escopo ele estabelece o que faz parte do software e o que não faz parte do software isso é bom deixar bem claro para não haver falsas expectativas Por parte dos clientes então o esse documento de requisitos de software ele estabelece a concordância sobre o que será construído entre os clientes e os desenvolvedores Como já foi falado a especificação de requisitos é uma forma de comunicação e uma forma de eh de acordo de entre o a equipe de desenvolvimento e as partes interessadas estabelece o que será desenvolvido como será desenv e com certo grau como

será desenvolvido ã então é uma forma de acordo entre os clientes e os desenvolvedores ou entre a equipe de marketing E a equipe de desenvolvimento quando se trata de um software que se destina a uma grande quantidade de usuários um software que será baixado e utilizado através da web por exemplo Ah então H esse documento de requisitos de software e permite que os requisitos sejam avaliados E corrigidos no momento que for encontradas anomalias como ambiguidades conflitos omissões e outras e ainda ele fornece base para estimativas de custos de riscos de cronograma entre outras possibilidades então

eles ajudam a determinar com uma acura mais profunda Qual será o Real custo de desenvolvimento Quais são os principais riscos do desenvolvimento de software e quanto tempo realmente será desenvolvido se demorará para desenvolver o software ele também fornece uma base para estabelecer como verificar e validar o produto ou seja se realmente o software fará o que foi especificado E se ele atende se e E caso ele não consiga eh fazer eh se se ele não conseguir atender o que foi especificado então ele não atende às necessidades do cliente Ah então um documento de especificação correto

ele vai definir o que precisa ser feito de maneira clara e ele permite um projeto correto em que vai se estabelecer com o problema será solucionado então um projeto ele precisa estar baseado no documento de especificação correto porque senão ele estará se baseando em premissas erradas e o projeto então estará igualmente errado e pode-se isso pode pode acontecer de se demorar muito tempo procurando por erros de projeto que na verdade seriam erros de especificação então erros no documento de especificação de requisitos podem acarretar um prejuízo bastante grande para o projeto e nós terminamos essa aula

introdutória sobre especificação de requisitos eu espero que vocês tenham achado essa aula útil se vocês gostaram do vídeo eu peço que vocês curtam esse vídeo compartilhem com que 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