[UFMS Digital] Formação Profissional em Computação - Módulo 1 - Unidade 2

[Música] Olá pessoal tudo bem Sou professor Luciano Édipo E hoje nós vamos iniciar nossa aula da nossa disciplina de formação profissional em computação a unidade 2 do módulo 1 trata sobre o início do desenvolvimento de um documento de especificação de requisitos de software é todo aquele conteúdo Inicial que nós vemos sobre o que são os requisitos ele citação é todas essas informações elas são organizadas no que nós chamamos no documento de especificação de requisitos de software nessa nossa unidade 2 do módulo 1 e em seguida lá no módulo 2 também na unidade 2 vai haver

uma continuação do processo de construção desse documento tá só para que vocês percebam que as unidades 2 dos nossos dois módulos vão tratar de um assunto continuado né que tratar sobre a criação desse documento de especificação antes de falar propriamente sobre esse documento de especificação eu gostaria de mostrar é como na prática é são organizados esses requisitos né que são tratados em um documento de especificação de requisitos obviamente que durante a nossa aula eu vou mostrar Quais são esses elementos textuais que vão compor um documento de especificação de requisitos na prática é essa especificação ela

é organizada por meio de diversos softwares de gerenciamento de projetos então eu vou mostrar para vocês antes de iniciarmos a parte teórica desses elementos que compõem o documento eu vou mostrar um exemplo de como é um software de organização desses requisitos então aqui eu trago para vocês um exemplo de um projeto que foi desenvolvido em uma disciplina de produção de desenvolvimento de software da faculdade de computação onde a gente pode onde eu vou mostrar para vocês como que esses elementos de um documento de especificação acaba o impactando né E como que eles são efetivamente organizados

em um gerenciador de projetos no exemplo que eu mostro aqui para vocês eu tô utilizando os meus alunos utilizaram o The Voice hoje da Microsoft em um projeto real né que se chamava um projeto de chamava coleta de vestígios nem todos os elementos são de interesse no nosso caso obviamente que em outras disciplinas relacionadas ao desenvolvimento vocês vão conseguir assimilar alguns esses elementos que estão presentes aqui por exemplo aqui tem um gráfico de bardal um gráfico de bardal ele mostra o quanto ao longo do projeto as histórias de usuário que aquilo que a gente viu

lá na unidade o quanto que essas histórias de usuários foram concluídas dado o processo de desenvolvimento que foi para o projeto então no caso desse projeto que eu mostro para vocês foi escolhido um scrum como um modelo de desenvolvimento então todas as histórias de usuários foram separados em alguns sprints e esses sprints eles vão sendo concluídos na o backlog né que são essas histórias que fazem parte desse grupo de tempo que é o Sprint eles são concluídos e entregues e esse gráfico por exemplo do burdal ele mostra o quanto que esses essas histórias estão sendo

concluído ao longo do tempo a gente pode ver um quadro dentro desse quadro os desenvolvedores os analistas que foram desempenhados pelos alunos matriculados na disciplina eles organizavam todas as histórias é referente ao projeto que estava sendo desenvolvido todos os itens de trabalho em seguida esses itens de trabalhos eles eram Divididos com algo que lembra muito né que é um quadro onde são organizados O que está sendo implementado no momento o que que já foi resolvido o que que já foi fechado o backlog por exemplo ele é composto pelos épicos vocês podem verificar depois estudando aí

sobre scream esses épicos eles são felizes né são requisitos funcionalidades que são entregues e possuem algum valor para os interessados essas funcionalidades elas são entregues por meio de Springs Então os prints também são cadastrados e são mostrados ali são organizados dentro de um de um sistema de gerenciamento de projetos então na prática do desenvolvimento é mesmo nas fases iniciais de definição de projeto de análise e organização dos requisitos isso é realizado por meio de algum sistema informatizado que ele vai tratar do gerenciamento de projetos então é muito comum a utilização hoje em dia do Devotos

alguns projetos mais antigos utilizam é demais até algum tempo atrás O próprio Git é o github também tinha alguma parte de gerenciamento de projetos que se não me engano já foi retirado né ele tá focando mesmo nas questões de repositório e entrega contínuo e tudo mais então só para deixar claro para vocês que nós vamos ver agora essa parte teórica Quais são esses elementos e tudo mais por quê há um uma cultura em torno da nossa área na área de computação que nós somos da área de exatas Então nós não devemos nos preocupar muito com

algumas habilidades que são extremamente importantes na nossa profissão habilidade de comunicação a habilidade de escrita são duas habilidades que são subestimadas na nossa área então por isso eu já vou mostrar aqui para vocês seguindo na apresentação Quais são esses elementos que fazem parte de um documento de especificação de requisitos Ok é só para deixar claro seguindo aquela ideia proposta na unidade nós vamos trabalhar em três níveis né de requisitos existe aquele nível Inicial que trata dos requisitos em Alto Nível que a gente organiza né o requisitos de negócio esses requisitos eles são documentados por meio

de um documento de visão e escopo que não é o que nós vamos focar nessa unidade 2 na segunda no segundo nível quando se trata nos a nível de usuário é que onde é criado o documento de requisitos de usuário e também não vamos focar nesse nível nós vamos focar no nível mais mais baixo né onde nós tratamos ali dos requisitos funcionais dos requisitos de sistema da de como que é as restrições as requisitos não funcionais como que eles impactam nesses requisitos funcionar as interfaces e tudo mais então vamos explicar aí o que que é

esse documento de especificação de requisitos de software que é o nome que a gente vai utilizar a partir de agora tá ele é um documento que é escrito em geral como resultado final da etapa de desenvolvimento de requisitos tá ele é construído por meio de um acordo entre os interessados que nós chamamos de steak holders É sobre aquele produto que vai ser Constru É nesse documento em que são armazenados são descritos onde onde é especificado Quais foram os requisitos funcionais e os não funcionais que ficaram ali para serem fruto né do produto que vai ser

desenvolvido durante o projeto ele descreve Então qual é o comportamento esperado Quais são as características e as restrições que o sistema deve ter esse documento ele leva em consideração aquilo que é realizado por meio da análise de negócio pensando naquele nível Inicial né de alto nível onde a gente trata dos requisitos a nível de negócio ele serve como base para as etapas de projeto né ou design e desenvolvimento que é a implementação do projeto entretanto esse documento de especificação de requisitos de software ele não contém por exemplo detalhes de projetos de desenvolvimento ele mostra quais

são os requisitos o que que é esperado então o foco num documento de especificação de requisitos é descrever o que é o software que vai ser desenvolvido como ele é desenvolvido é quais são os elementos de um nível mais baixo como ele vai ser arquiteturado como ele vai ser desenvolvido Quais os tipos de design de padrões e tudo mais isso é típico de atividades previstas nas fases de projeto e desenvolvimento um outro nome que vocês podem conhecer para esse documento de especificação de requisitos de software é chamado de simplesmente especificação funcional ou simplesmente documento de

requisitos Esse é o nome mais utilizado para esse tipo de documento que a gente vai mostrar E aí é interessante se atentar para as seguintes características existem diferentes interessados diferentes stakeholders relacionados a um projeto de software por exemplo essas diferentes pessoas obviamente que possuem diferentes necessidades e objetivos em torno do projeto que está sendo desenvolvido tá então existe por exemplo pensando lá naquela naquele nível Inicial o nível de visão de objetivos de negócio Ele tá explicitado no documento de visão escopo aqui é trata de armazenar os requisitos de negócio como eu mostrei naquela naquelas três

naqueles três níveis nos slides anteriores pensando depois na Perspectiva do usuário que é aquele nível intermediário onde nós colocamos ali os documentos de requisitos a nível de usuário que são os requisitos de usuário todos os detalhes que foram analisados e vieram tanto dos níveis de requisitos de negócio quantos requisitos de usuários eles estão especificados nesse documento de especificação de requisitos Então os requisitos funcionais e os requisitos não funcionais as restrições e interface e tudo mais ela vai estar ali nesse documento que tem um nível de detalhamento maior quem são esses interessados pensando então que esse

documento ele é possui diversos objetivos Dependendo de quem é o interessado né nesse documento quem vai analisar esse documento esses documentos de especificação de requisitos de software eles não são utilizados somente por pessoas da área de computação é isso é um erro aí que é muito comum existem outras pessoas de outras áreas que são interessadas naquilo que está sendo desenvolvido então por exemplo o cliente né o próprio cliente que Muito provavelmente muitas das vezes não são pessoas da nossa área ou da área de computação ou que tem conhecimento da área de computação é pessoas que

trabalham com marketing por exemplo elas precisam saber porque que eles utilizam esse documento de especificação de requisitos porque eles precisam saber o que é que está sendo entregue Qual é o produto que está sendo entregue gerentes por exemplo eles precisam gerentes de projeto eles precisam por exemplo conhecer esses requisitos para conseguir fazer o seu trabalho que é estimar cronograma fazer Estimativa de esforço alocação de recursos então todo o gerenciamento né de projetos depende daquilo que é esperado para o software que tá sendo pensado os próprios desenvolvedores eles necessitam saber o que é que precisa ser

construído e isso aí é o primeiro documento que vai mostrar justamente o documento especificação de requisitos testadores por exemplo eles precisam desenvolver os testes baseado naquilo que foi especificado dos requisitos possa ser feito com sucesso precisa conhecer Quais são os requisitos a gente precisa conhecer o que que é esperado do software que está sendo devido né Para que o teste possa ser escrito e que o sistema consiga passar nesses testes e aí a gente vai começar nos primeiros elementos caracteristica geral né esperada no documento de especificação de requisitos né das características geral a gente vai

mostrar uma qualidade desejável do sistema que não é encontrada na especificação de requisitos então ela não vai ser implementada efetivamente né Ela Vai representar então um acordo entre esses diversos interessados no sistema que está sendo desenvolvido e assim como de outros artefatos ao longo do desenvolvimento de software ele pode ser desenvolvido de forma incremental então em cada um dos ciclos esse documento de especificação de requisitos e pode ser refinado ele pode ser aprimorado é claro que nas etapas iniciais interações iniciais o foco nas atividades de definição onde se encontra por exemplo documento de especificação é

o foco é muito maior então diversas esse artefato ele ele passa por diversos atividades nesses ciclos iniciais então geralmente dá essa impressão de que após uma certa completude do documento de especificação de requisitos após entrar em um acordo ele não pode mais ser alterado e na verdade não é bem assim ele é um documento dinâmico enquanto o projeto estiver sendo realizado ele pode e deve ser refinado pode ser melhorado uma outra coisa interessante né de deixar bem claro nos elementos que compõem o documento de especificação de requisitos é todos os elementos que compõem o documento

de especificação de requisitos eles precisam ser é identificados encontrados da forma mais rápida possível e fácil possível então a gente tem que construir o documento de forma que é qualquer tipo de mudança histórico ou para manter mesmo que nós chamamos de rastreabilidade né Logo esses elementos que vão compor o documento de especificação de requisitos eles precisam conter um identificador único que é como eu vou mostrar para vocês em seguida essa Esse identificador é único ele facilita essas mudanças histórico e a rastreabilidade Como eu disse anteriormente é um conceito interessante é a rastreabilidade ele vai servir

justamente para a gente conseguir verificar o quanto que aquele elemento seja ele um caso de uso um requisito de negócio uma regra uma interface seja ele qual for né O que ele impacta nos outros artefatos nas outras etapas do desenvolvimento e qualquer tipo de alteração problema mudança que precisa ser realizado a gente consegue identificar Quais são os elementos ligados né Por meio dessa rastreabilidade que é possível isso aí a gente faz utilizando esses identificadores únicos e é claro que durante o processo de desenvolvimento a gente sempre faz o link né dessas desses elementos desses de

qual elemento impacta né interferir em quais outros elementos então por exemplo aqui na apresentação mostra é alguns elementos como o ser um C2 fr2 né então ali o se ele vai estar se referindo a um caso de uso tá a gente usa a sigla em inglês o requisito funcional FR ou nesse caso seria interessante até usar o RF né para se referir ao requisito funcional rnf para requisito não funcional aqui eu trago uma visão geral sobre Quais são esses elementos que nós vemos né num documento de especificação de requisitos nessa unidade 2 o nosso foco

será nas nas sessões iniciais de introdução e na questão de descrição geral Então a primeira parte que a gente vai tratar é o que é que contém né nas sessões de introdução O que é esperado né nesses documentos de especificação de requisitos de software isso é interessante porque sempre que os alunos vão começar a construir durante as aulas durante o ensino na universidade ele sempre se pergunta né Professor o que é que eu escrevo né O que que eu coloco nesse documento então quando você for sentar para começar a escrever um documento de especificação de

requisitos você vai pensar Quais são esses elementos que que eu coloco aqui que eu preciso colocar basicamente isso que a gente vai ver a partir de agora tá então pensando na do primeiro item da introdução que a gente vai falar sobre a finalidade a finalidade como o nome já diz ele vai tentar Identificar qual é a utilização para que que esse produto no caso software está sendo desenvolvido para qual é a finalidade dele né esse produto que os requisitos estejam descritos nos documentos e ele pode ser dividido né separado por níveis de revisão ou realiza

Então ele pode ser separado por versões por exemplo então ele vai descrever os diferentes paros diferentes tipos de leitores a quem o documento é destinado Lembrando que nós temos diferentes tipos de interessados então aqui eu trago um exemplo né do que é que pode conter aí nesse nesse item da introdução se chama finalidade Então aqui tem um exemplo de um sistema de encomenda de almoço que é o exemplo que a gente vai utilizar nessas unidades dos dois módulos finalidade este documento descreve os requisitos funcionais e não funcionais da Elise um do sistema de encomenda de

almoços este documento é destinado aos membros do projeto que irão implementar e verificar o correto funcionamento do sistema então vocês podem ver que é esse esse texto que vai falar sobre a finalidade ele vai explicar o que é que é esperado desse documento que é que esse documento mostra e para quem que é esse documento e caso esse software seja dividido em inversões ou elises ou mesmo módulos especificar Qual é essa versão Qual é esse módulo que está sendo construído o segundo item trata do escopo o escopo vai mostrar de uma descrição bem curta é

do que é esse produto que está sendo especificado e sempre que for necessário fazer a referência a outros documentos que fazem parte do escopo do sistema dos outros artefatos que compõem esse projeto só lembrando que no caso de um sistema de gerenciamento de projetos né a gente consegue limpar esses Artefatos de maneira muito mais mais simples por isso que quando nós estamos escrevendo um documento de escopo Por exemplo essa sessão de escopo é muito útil que cada um desses elementos do documento de especificação contenha esses identificadores únicos porque é a forma da gente conseguir fazer

essa referência tá então aqui vamos tratar de um do Exemplo né do sistema de encomenda de almoço do que é que a gente pode colocar nesse escopo né então Seguindo aqui o sistema de encomenda de almoço permitirá aos funcionários da empresa x pedir almoço online uma descrição detalhada é encontrado no documento de visão e escopo juntamente com todas as funcionalidades planejadas então vocês viram aqui o texto mostrado como exemplo no na sessão de escopo no item de escopo ele já faz alguns links como por exemplo com documento de visão E escopo lembrando que o documento

de visão escopo é o documento que vai especificar os requisitos a nível de negócio então todos esses documentos eles precisam ser interligados principalmente para que a gente não precise não não duplique algum tipo de informação e ao longo do processo de desenvolvimento essas informações elas podem ser corrigidas alteradas modificadas refinadas então é sempre importante referenciar os elementos nos documentos da quais eles são típicos então por exemplo eu não vou colocar nós não vamos colocar a especificação de requisitos a nível de negócio nesse documento que nós estamos falando agora porque o documento que trata da especificação

a nível de negócio é justamente o documento de visão escopo e não de especificação de requisitos de software por exemplo outra coisa importante né que é muito comum nos artigos nos trabalhos na nossa apresentação nos livros e tudo mais são as referências as referências elas servem para listar todos os outros documentos ou recursos que foram referenciados nesse documento de especificação de requisitos por exemplo no item anterior discopo nós fazemos uma referência ao documento de visão e escopo desse sistema de encomendas de almoço que é um outro documento não é esse mesmo documento de especificação de

requisitos né Logo nós precisamos colocar na no item de referência todo e qualquer documento ou recurso que não faça parte do próprio documento isso é extremamente importante para que a gente consiga fazer esses links né E também para que o seu documento de especificação de requisitos de software seja coerente o segundo a segunda sessão que nós vamos mostrar é a sessão de descrição geral essa sessão de descrição geral São separadas em subseções onde nós vamos falar sobre Quais são esses elementos que vão ser utilizados para descrever de forma geral sem uma especificação mais detalhada O

que é esse produto que está sendo desenvolvido então o primeiro subitem que a gente trata é a perspectiva do produto a ideia da perspectiva do produto é descrever o contexto e a origem do produto Então vou tratar aqui um exemplo do que é escrito nesse tipo de subitem perspectiva do produto o sistema de encomenda de almoço é um novo sistema que substitui o atual processo manual e por telefone para pedir almoço e aí segue a história ele serve para o seguinte para identificar Qual é o contexto em torno desse sistema que vai ser desenvolvido é

muito interessante Então mostrar é se falar sobre Qual o processo existente que esse sistema irá substituir Então nesse texto de exemplo do sistema de encomenda de almoço já é dito que é feito por um processo manual por telefone e tudo mais é óbvio que um documento de especificação de requisitos não é Um textinho pequenininho né que a nossa aula a gente tem esse exemplo bem pequenininho porque a gente não vai tratar da do documento todo mas a ideia é escrever todo o contexto em torno desse sistema de onde esse sistema vai ser colocado Então qual

é a perspectiva dele que você espera dele qual é o principalmente Qual é o processo atual que da Qual o sistema substituirá um outro subitem interessante principalmente quem tiver trabalhando com paradigma de orientação objetos é trabalhar com determinar estipular identificar as classes de usuários e as características dessas classes de usuários a ideia das classes de usuários é identificar aí quais são esses utilizadores do produto e descrever as suas principais características né então vou dar um exemplo aqui se um catálogo de usuário estiver disponível para o sistema que vai ser desenvolvido sempre referenciar e não duplicar

aliás essa ideia do referenciar e não duplicar como eu já tinha dito anteriormente ela é extremamente importante no documento de especificação de requisitos de software porque é o seguinte se é já existir catalogado em algum documento do dos stakeholders do cliente da empresa ou em outros níveis como documento de visão geral ou documento de especificação é a nível de usuário geralmente esses usuário já estão descritos já estão identificados Então se isso já estiver sido realizado referencie nessa seção onde nos respectivos documentos nós podemos encontrar essa definição de Quais são as classes de usuários que vão

utilizar Quais são as características ainda assim né caso a gente não referencia e precise definir Quais são as classes de usuários a gente tem que estabelecer e escrever de alguma forma então aqui eu trago um exemplo para vocês de classes de usuários típicos para aquele sistema de encomenda de almoço e as suas características então eu vou ler aqui para vocês é classe de usuário cliente Qual é a característica do usuário cliente funcionário da empresa x que solicitam o almoço a ser entregue existem 600 potenciais clientes das quais 300 devem utilizar o sistema 5 vezes por

semana classe empregados do restaurante característica são empregados do restaurante que vão receber o pedido do sistema classe gerente de menu ele é um empregado do restaurante que cria mantém OS menu Diários dos itens disponíveis para o almoço e define os pratos especiais e dita os menus diariamente entregador funcionário do restaurante responsável pelas entregas do almoço coletas encomendas e as entregas a entrega aos clientes então de maneira geral a gente especifica Quais são as classes né os tipos típicos de utilizadores desse sistema e quais são os objetivos dele para qual para com o sistema o que

é que ele vai realizar utilizando esse sistema então é interessante aí conseguir identificar todos os utilizadores e caracterizados muito bem uma outra a outra subida interessante é o ambiente operacional o ambiente operacional ele vai mostrar vai descrever o ambiente na qual esse software irá operar né e é interessante conter neste sub item Quais são as plataformas de hardware Quais qual o sistema operacional qual as versões né dos softwares que vão que esse sistema vai depender dos Servidores e bancos de dados né então ali para descrever por exemplo o ambiente operacional lembrando do identificador único Como

eu disse deve conter deve estar contido em todos os elementos a gente sempre utiliza ali um identificador então por exemplo no ambiente operacional a sigla ao é com identificador dizendo que quer cada uma desses ambientes operacionais Então vou dar um exemplo aqui para vocês o ambiente operacional o sistema deve operar corretamente nos navegadores Internet Explorer e as versões Firefox e as intervalo de versões Google Chrome e Safari ambiente operacional 2 o sistema deve rodar no Linux e no servidor abaixa http server ambiente operacional 3 o sistema deve permitir o acesso através da Intranet da empresa

x e aplicativos no Android IOS assim todos os elementos que vão nos dizer né Qual é o ambiente na qual este software será inserido em ambiente nesse caso nós somos um ambiente computacional no ambiente tecnológico tá ambiente operacional tudo aquilo que estiver relacionado aos ambientes ao ambiente a qual esse sistema vai estar inserido é interessante Então que a gente é evidencie por meio desses itens que nós chamamos de ambiente operacional um outro subir que faz parte da descrição geral é o subida em que trata das restrições de projeto e de implementação Então como esses nomes

já sugerem a gente tá se estabelecendo é regras referentes ao próprio projeto de desenvolvimento ou a implementação em si só para deixar claro que quando nós escrevemos um documento de especificação de requisitos quando eu disse que nós não estipulamos como ele vai ser desenvolvido obviamente que existem alguns elementos que precisam estar na especificação e que acabam impactando em como ele vai ser desenvolvido então por exemplo nessa parte de restrição de projeto implementação nós podemos estipular o restringir Quais são qual é a linguagem de programação que vai ser utilizada Quais são as bibliotecas Quais são os

padrões de codificação então esses elementos Em um nível é mais alto e que impactam tanto no projeto quanto na implementação eles precisam estar descritos ali na nessa descrição geral na parte de restrições do projeto e quando a gente diz que nós não colocamos como aquele requisito vai ser desenvolvido porque a gente não estabelece né arquitetura a gente não estabelece é regras específicas para o desenvolvimento para o desenvolvedor é qual é o nome das variáveis Qual é o como é a interface em cada um dos das classes que estão sendo desenvolvidas e tudo mais mas de

maneira geral a gente estabelece não um conjunto de restrições E essas restrições elas vão estar ali nessa subseção de recessão geral e implementação então por exemplo restrições relativas a linguagem de programação a biblioteca padrões de codificação e outras que sejam referentes ao próprio projeto e a implementação então aqui é um exemplo do sistema de encomenda de almoço restrições do projeto implementação restrições o documento de projeto codificação e manutenção do sistema deve estar de acordo com o padrão de documentação da empresa e aí a referência restrição 2 todos os códigos HTML devem estar em padrão HTML5

restrições 3 o sistema deve ser implementado na linguagem Java todo tipo de restrição que for é referente ao projeto e a implementação eles devem então estar descritos nessa seção e ela que vai guiar as próximas etapas e que vão seguir utilizando as restrições que foram imputadas aí nesse nessa sessão do documento e aí a gente finaliza essa parte da das sessões iniciais do documento de especificação de requisitos de software a sequência dessa aula vai ser realizada na unidade 2 do módulo 2 onde nós vamos tratar sobre como que os requisitos são especificados dentro desse documento

Quais são as regras especiais como que o requisito não funcional ele é especificado que que se espera então é a parte que vai finalizar esse documento de especificação de requisitos Ok então espero que vocês tenham um bom estudo e a gente se vê a próxima aula [Música]