Olá aqui é o professor Ricardo ginton Ramos sejam bem-vindos ao primeira aula do segundo módulo do da disciplina de engenharia de software nessa disciplina agora a gente vai ver a parte da engenharia de requisitos a engenharia de requisitos que a gente viu um pouquinho nos modelos dos de desenvolvimento de software que é a primeira etapa que onde você tem um contato com o cliente ou então o contato com a documentação onde você descobre o que vai ser o sistema que você vai fazer então você você vai descobrir o que será feito Tá bom então n
gerente de requisitos que você utiliza técnicas pode ser de entrevista a gente vai ver várias técnicas que estão disponíveis para que você faça elicitação de requisitos Não nessa aula na próxima aula nessa aula de hoje a gente vai entender o que que é engenheria de requisitos e e o que que é é documento de requisitos Tá bom então os objetivos dessa aula vai ser introduzir a noção de requisitos de sistema e o processo de engenharia de requisitos eh existem mestrado doutorado só nessa área de engenharia de requisitos explicar como a engenharia de requisitos se encaixa
no processo mais abrangente da engenharia de sistemas e explicar a importância do documento de requisitos que vai ser a última parte dessa aula Tá bom então espero que vocês aproveitem Lembrando que você vai para pausar o vídeo se você eh achar necessário tem também bastante coisa na nossa apostila a apostila tá lá numa pasta que eu separei escrita Nossa biblioteca procurem lá no no ambiente Ava e espero que vocês aproveitem anotem também para que a gente possa tirar as dúvidas nas nossas aulas síncronas aulas ao vivos Vamos então à definição simples do que seria requisitos
do sistema então eles definem o que é solicitado ao sistema a fazer e com quais limitações ele é requisitado a operar tá a gente vai ver outras definições no decorrer dessa aula mas essa definição é bastante abrangente e dá para entender um pouco o que o que será vamos ver um exemplo de um sistema de biblioteca como poderiam ser os requisitos Por enquanto eu tô falando de requisitos no geral eh não tô falando de requisitos específicos a gente vai ver que depois tem uma divisão de requisitos funcionais e não funcionais e outros tipos de requisitos
Tá bom então por enquanto Eh vamos vamos entender o exemplo o o sistema deve manter um registro de todos os materiais da biblioteca incluindo livros séries jornais e revistas fitas de vídeo e áudio relatórios coleções de transparências discos de computadores e CD Rooms o sistema deve permitir os usuários pesquisarem Um item através do título autor do isbn a interface de usuários do sistema deve ser implementado utilizando o browser eh de www o sistema deve suportar pelo menos 20 transações por segundo as facilidades do sistema e que estão disponíveis para o público devem ser demonstradas em
10 minutos ou menos Pois é então aqui a gente viu um exemplo Onde você consegue ver algumas restrições e consegue ver também algumas funcionalidades de um sistema de biblioteca se vocês lembrarem da aula passada eu também passei um pouquinho de um de exemplo de requisitos né quando tava dando o exemplo do scrum quando o po criava o backlog do produto se você não lembra direito o contexto dá uma voltada na terceira aula do módulo um que você vai lembrar mais ou menos disso mas eh eu acabei de dar um exemplo no slide anterior de requisitos
de uma biblioteca agora vocês estão vendo os requisitos do restaurante o formato é diferente de um para outro esse formato aqui que a gente tá vendo que a gente já viu lá do scrum que monta o backlog é um formato eh específico para scrum tá bom onde você coloca como a a determinada pessoa o ponto de vista que você quer ver e o que que você necessita daquele ponto de vista então só pra gente relembrar a gente pode escrever requisitos de várias maneiras a gente vai ver no decorrer dessa aula alguns formatos diferentes de você
escrever requisitos tá bom que tem aí nos livros de engenharia de software agora que a gente viu alguns exemplos de requisitos né na literatura são diversos os tipos de requisitos tá bom Alguns são mais complexos como a gente vai ver já já Mas pode você pode definir requisitos bem Gerais com alto nível de administração voltando ao exemplo lá da biblioteca por exemplo a biblioteca deverá ajudar os alunos nas em consultas em trabalhos escolares e por aí vai então são requisitos bem Gerais requisitos funcionais a gente viu alguns requisitos funcionais por exemplo a a os livros
devem ser armazenados e devem as consultas podem ser através do seu nome ou do isbn e requisitos de implementação por exemplo o sistema deve ser implementado em linguagem Java utilizando o banco de dados MySQL E por aí vai requisitos de performance a performance mínima e aceitável que o que um software deve funcionar por exemplo Ah ele deve funcionar pela internet e quando tiver na internet ele tem que aceitar no mínimo 50 requisições ao mesmo tempo requisitos de uso habilidade que V mostrar os recursos e que devem estar disponíveis para os usuários conseguir utilizá-lo como por
exemplo a o deve haverá um botão eh para voltar à página inicial em todas as telas do sistema e por aí vai a gente vai focar em dois requisitos mais e complexos que são os funcionais e os requisitos não funcionais que são requisitos não funcionários a gente vai ver um pouco que tá dividido aqui nesse nessa tela que eu tô te mostrando de modo geral Nós temos dois tipos de requisitos três se a gente falar dos requisitos organizacionais requisitos funcionais como eu já dei exemplo no slide passado eles definem parte da funcionalidade do sistema a
gente viu por exemplo e seria um requisito funcional armazenar um livro pelo isbn dele tá bom então é um requisito funcional faz partir da funcionalidade do sistema de biblioteca um requisito não funcional diz respeito à restrições aspectos de desempenho por exemplo interface com usuário em alguns casos confiabilidade segurança manutenabilidade portabilidade eh padrões Bom exemplo eh eu quero que o meu sistema ele seja criptografado então essa parte por exemplo pode ser um sistema de de biblioteca mas se eu quero criptografia não faz parte das regras de negócio de um sistema de biblioteca por isso são chamados
de requisitos não funcionais ele são meio que a parte das regras de negócio do sistema em si eh mas eles são tão importantes quant os requisitos funcionais Tá bom é só pra gente conseguir uma classificação se a gente for trabalhar na área de engenharia de requisitos os requisitos não funcionais também tem grande importância existem frameworks que trabalha somente com os requisitos não funcionais eh e ele e geralmente determinam a qualidade do software que tá sendo desenvolvido os requisitos que a gente pode citar aqui são os requisitos organizacionais que dizem respeito à metas da empresa eh
se tem alguma empresa que tem alguma meta por exemplo todo mundo que eh no sistema de biblioteca todo mundo que conseguir emprestar mais de 50 livros vai ganhar um livro gratuitamente por exemplo seria uma meta eh da empresa que quer promover a leitura e por aí vai alguns exemplos rápidos de requisitos funcionais por por exemplo o usuário pode pesquisar todo ou um subconjunto do banco de dados você tá dando informações Claras sobre as regras de negócio do sistema o sistema deve oferecer telas apropriadas para que o usuário possa ler os documentos armazenados cada pedido deve
ser associado ao identificador único pid o qual o usuário pode copiar para a área de armazenamento permanente da conta fica claro que são que faz parte das regras de negócio eh de um sistema o outro exemplo aqui um usuário deve ser capaz de pesquisar as listas de agendamentos para todas as clínicas por exemplo no sistema de agendamento para clínicas e médic por exemplo o sistema deve girar a cada dia para cada Clínica a lista de pacientes para as consultas daquele dia mais um outro exemplo de um requisito funcional de uma clínica médica cada membro da
equipe que usa o sistema deve ser identificado apenas por o seu número de oito dígitos de novo é uma restrição de eh funcional da funcionalidade ou seja da regra de negócio daquele sistema que a gente tá trabalhando aqui mais uma charge do Dilbert só pra gente entrar agora no tema de requisitos não funcionais ele tá o dbt tá lá falando com o cliente e o cliente tá pedindo lá ó seu eh requisitos de usuários incluem 400 características Você tem noção que nenhum humano será capaz de usar um produto com nesse nível de complexidade aí o
cliente fala para ele ótimo ponto é melhor você adicionar facilidade de uso à lista dos requisitos ou seja eh então facilidade de uso é um requisito não funcional tá bom eh então eles definem os requisitos não funcionais definem propriedades e restrições do sistema um exemplo seria segurança já falei um exemplo um pouquinho né de você por exemplo criptografar os dados desempenho Ah o sistema tem que funcionar 7 dias por semana 24 horas por dia espaço em disco quanto que ele vai ocupar supor que a gente tá fazendo não se em disco mas pode ser por
exemplo em memória a gente tá fazendo um software um aplicativo para celular e a gente precisa delimitar o tamanho da memória O quanto que esse software vai utilizar da memória desse celular seria um requisito não funcional poem ser do sistema todo o parte do sistema requisitos não funcionais podem ser mais críticos do que requisitos funcionais perceba que às vezes por exemplo se eu tiver trabalhando com algo precisa ser criptografado talvez eu precisa aprender novas técnicas novas tecnologias para para conseguir implementar não é tão simples se não satisfaz o sistema inútil pois é então faz parte
apesar de não fazer parte das regras de negócio do software que você tá desenvolvendo ele é uma das características principais do software que tá sendo desenvolvido só um exemplo aqui para que a gente veja uma uma árvore né de tipos de requisitos não funcionais isso aqui eu retirei de um livro eh mas a gente pode ver por exemplo ó requisitos éticos que faz parte ali de requisitos externos né então por exemplo vamos supor que eu tenho um banco e nesse meu no meu sistema de banco eu tenho a senha um eu posso colocar como requisito
ético seja que o funcionário desse banco não tem acesso à senha não possa saber qual é a senha então todo todo o campo de senha será criptografado ou será de alguma maneira eh não possível de ser vista por outros funcionários a não ser pelo usuário que criou essa senha então isso aí seria por exemplo um requisito ético um requisito não funcional deu uma olhada deu um pause aqui no vídeo falei que vocês consigam perceber outros requisitos não funcionais agora aqui alguns exemplos de requisitos não funcionais já falei para vocês alguns mas só pra gente deixar
fixado né né Por exemplo requisito de produto o sistema MHC PMs deve estar disponível para todas as clínicas durante as horas normais de trabalho de segunda a sexta das 8:30 às 17:30 períodos de não operação dentro do horário normal de trabalho não podem exceder 5 segundos em um dia requisitos organizacionais usuário os do sistema MHC PMs devem se autentificar com seus cartões de identificação da autoridade da Saúde requisito externo o requisito deve implementar as disposições de privacidade dos pacientes tal como estabelecido no Regimento xyz ali bom a gente viu que requisitos não funcionais a gente
tá vendo que requisitos não funcionais apesar de não fazerem parte da regra de negócio eles complementam o sistema e sem eles o sistema se torna inútil já foi falado isso a uma as etapas da engenharia de requisitos que a gente tá vai falar agora né é o estudo de viabilidade o estudo da viabilidade é quando você se reúne com o cliente após você ter uma primeira leva de requisitos e você discute com ele você visualiza se o software é realmente viável e a partir desse ponto dessa decisão se o software é viável ou não você
vai começar a construção e começar realmente a elicitação dos requisitos de maneira mana mais complexa de maneira mais completa também por exemplo algumas perguntas eh o sistema contribuiu para os objetivos gerais da organização será que esse sistema é útil né para contribuir aos objetivos gerais da organização o sistema pode ser implementado com tecnologia atual e dentro das restrições definidas um prazo e e o custo que foi pedido será que tá um prazo muito curto para eu construir esse software será que eu consigo com as tecnologias Será que eu vou ter treinamento na minha equipe Então
tudo isso eu tenho que analisar é será que o quanto eu cobrei do software vai ser suficiente para eu entregar o software que eu tô prometendo Tá bom então nesse estudo de viabilidade a gente faz essa análise mais completa o sistema pode ser integrado a outros sistemas já implantados né senão você vai fazer um sistema que não seja integrável com outros sistemas já da da organização eh talvez não seja tão viável Tá bom então todo esse estudo é feito Antes de eu começar a etapa de elicitação de requisitos que seria você fazer os requisitos colher
os requisitos de maneira mais completa um dos principais problemas dos requisitos que você pode encontrar com documentação de requisitos ou então com o processo de iné de requisitos é que os requisitos não refletirem as reais necessidades do cliente do sistema tanto pode ser o cliente não conseguiu falar o que ele queria como pode ser que o engenheiro de requisitos não conseguiu obter a informação de maneira correta requisitos podem ser inconsistente ou incompletos talvez pela mesmo problema do anterior custo alto para para fazer mudança de requisitos depois de terem sido concordados você colhe os requisitos faz
eles de maneira completa só que depois quando você já tá construindo o software já acordou isso já começou o desenvolvimento do software o cliente pode querer mudar ou então você pode ter encontrado algum problema que você não pensou antes e terá que mudar o custo é bem alto quando esse caso existem mau entendimento entre clientes aqueles que desenvolvem os requisitos do do sistema e os engenheiros de software que desenvolveram ou mantém os o sistema bom e é preciso que seja Às vezes a equipe de desenvolvimento de software é muito grande ou então Os clientes são
espalhados e muito grande a empresa Isso dificulta esse entendimento entre as partes então é preciso que seja eh feito uma engenharia de requisitos bastante conciso bastante porque é uma das partes mais importantes do desenvolvimento do software de acordo com as pesquisas só pra gente ter uma noção do quanto que é prejudicial se você não pensar bem nos requisitos do sistema 40% do percentual de erros detectados nos sistemas deve-se a especificação de requisitos mal feitos Então a gente tem esse gráfico aí 40% 30% no projeto e 30% na codificação Olha o custo aí chegando só para
que a gente consiga fixar né questões mais frequentes perguntadas sobre requisitos O que são requisitos então você pode falar que é uma descrição de um serviço ou de uma limitação lembra lá o que é engenharia de requisitos engenharia de requisitos é todo o processo envolvido no desenvolvimento de requisitos do sistema Quanto custa engenheria de requisitos se você colocar no dentro de um projeto total de desenvolvimento de software seria 15% por exemplo dos custos O que é o processo de engenharia de requisitos seria um conjunto estruturado de atividades desenvolvidas no desenvolvimento dos requisitos do sistema desde
aquela parte de você eh fazer entrevistas é procurar o que o que você quer desenvolver o que será desenvolvido até a parte lá da viabilidade de verificar se é viável o software até a parte de você eh saber os custos de tempo o que acontece quando os requisitos estão errados os sistemas atrasam ficam não confiáveis e não satisfazem as necessidades dos clientes existe um processo de engenharia de requisitos ideal seria perfeito né mas não os processos precisam ser adaptados às necessidades organizacionais então para cada organização que você vai desenvolver um software você tem que adaptar
aí o seu processo de Engenharia requisitos O que é um documento de requisitos é uma descrição formal dos requisitos do sistema a gente vai ver também algumas definições que o documento de requisitos é como se fosse o contrato do desenvolvedor de software com eh o cliente que tá comprando aquele software uma palavrinha que a gente vai ouvir falar bastante são stakeholders né O que são stakeholders do sistema seria qualquer pessoa afetada de alguma forma pelo sistema desde os desenvolvedores do software do sistema até os entes e outras partes que podem estar envolvida aí então quando
eu falar de os stakeholders do sistema são qualquer parte Envolvida com esse sistema O que é o relacionamento entre requisitos e projeto bom Lembrando que requisitos de software é o que o software vai ter tá então eu pergunto com o qu e projeto de software É como esse software vai ser desenvolvido então eu descobri o que nos requisitos e como o que para o como é é o pulo do gato é onde o engenheiro de software vai aplicar soluções para que esse requisito que foi descoberto do do do sistema será implementado de alguma maneira eh
que seja mais viável que seja cabível ou combinável entre os desenvolvedores de sistema e o cliente então requisitos de projetos são interligados idealmente eles deveriam ser separados mas na prática isso é impossível eh é essa parte do o que e do como eh O que o software faz e como ele faz quando a gente eh seria o interessante seria ser bem separadinho o que e o como só que geralmente são tudo junto Porque quando você faz a pesquisa do o que será os requisitos você já tenta pensar de como você vai implementar esses requisitos O
que é o gerenciamento dos requisitos é o processo envolvido no gerenciamento das mudanças dos requisitos Então vamos supor que eu tenho um software já completo ten os requisitos do meu software e quando eu preciso fazer alguma mudança se essa mudança envolve alguma funcionalidade então a mudança tem que ser também no código do do do software que tá sendo desenvolvido e eu tenho que refletir essa mudança no código da funcionalidade nos requisitos E vice-versa se eu mudar algo nos requisitos eu tenho que refletir isso no no código isso aí é o gerenciamento de requisitos Existe alguma
técnica para que eu consiga garantir a qualidade do requisito para que eu possa seguir em frente Bom a validação de requisitos Exatamente Essa a preocupação que tem em garantir que o requisito que foi for gerado ele tem qualidade ou seja ele é completo ele possui pequenos poucos erros ou quase nada de erros né Não dá para garantir que o requisito não tenha erros a validação de requisitos objetivo é mostrar que os requisitos realmente definem o sistema que o usuário deseja bom então é algo bastante complexo não é simples isso né procura problemas com os requisitos
através de algumas técnicas que a gente vai falar daqui a pouco se encontrar erros e um documento de requisitos devem ser corrigidos já que esses erros podem acarretar outros erros aí outros custos porque se Lembrando que os requisitos é a primeira etapa do desenvolvimento de software no processo de desenvolvimento bom algumas técnicas que você pode utilizar a gente vai ver eh no último módulo da nossa disciplina prototipação que eh Talvez seja a principal técnica para que você consiga realmente produzir os requisitos de acordo com o que o cliente quer Eh Ou você pode também fazer
a revisão de requisitos é a leitura de documento através de um checklist por exemplo para você verificar se ele tá completo Se ele contém algum erro eh e geração de caso de testes a partir do documento de requisitos você pode gerar um caso de teste que quando o sistema tiver funcionando você Testa o o sistema de acordo com o caso de teste que foi gerado Eu já falei já que um documento de requisitos é como se fosse o contrato daquilo que o o cliente pediu para que fosse feito a ideia do que o o desenvolvedor
de software tenho para saber também quais são os procedimentos quais são os passos A seguirem para construir o o software então é um documento formal usado para comunicar os requisitos aos clientes aos Engenheiros e gerentes o documento de requisitos descreve serviços e funções que o sistema deve prover a gente já viu mais ou menos isso eh quando a gente consegue separar requisitos funcionais e não funcionais as limitações sobre as quais o sistema deve operar propriedades gerais do sistema Isto é eh limitações das propriedades emergentes definições de outros sistemas com qual sistema deve se integrar então
é mais ou menos um documento bastante completo é existe um formato para isso é que onde você é definido pela i3e que é um órgão que define padrões de como você escrever documentos de requisitos por exemplo define vários outros padrões a gente vai dar uma olhada eh mais um pouco sobre como escrever um documento de requisitos a gente vai ver também alguns exemplos que eu posso escrever de com a linguagem mais formal com uma linguagem eh menos formal a gente vai ver isso daqui a pouco continuando o que que faz o que que é feito
no documento de requisitos informações sobre o domínio da aplicação do sistema exemplo Como calcular um certo tipo de computação e se tiver algum cálculo específico alguma fórmula que deve ser utilizada Então tem que ter lá no documento de requisitos limitações dos processos usados para desenvolver o sistema descrições sobre o hardware no qual o sistema irá Executar a gente vê bastante isso quando tá trabalhando com desenvolvimento de aplicativos para celulares então Eh como muda toda hora os os hardw dos celulares ou os próprios softwares que dos sistemas operacionais dos celulares Então a gente tem que colocar
Qual a limitação sobre qual sistema operacional que esse software vai conseguir Qual que é a capacidade dele Ah qual que é a partir de qual versão de sistema operacional Tá bom então isso vai fazer parte do documento de requisito você ainda pode adicionar um capítulo introdutório que prê um resumo sobre o que que o software o sistema todo completo ele faz necessidades de de negócio suportadas pelo sistema e o glossário esse glossário é importante para que às vezes você tá trabalhando com um sistema que ele é mais eh complexo que ele é mais fechado que
a população em geral não conhece e ele serve como comunicação tanto pro engenheiro de software que vai ter que ler o documento de requisitos compreendê-lo eh como também pro próprio cliente poder se comunicar de maneira mais eh eficaz e quem são eh os usuários quem que precisa utilizar um documento de requisitos dentro da engenharia de requisitos né bom são os clientes do sistema que eles vão tanto especificarem os próprios requisitos e eles vão lerem também esse requisito eh para verificar se satisfazem realmente suas necessidades para verificar se é aquilo mesmo que eles queriam né as
clientes especificam as alterações dos requisitos também os gerentes que usam documento de requisitos para planejar uma proposta para o sistema e para planejar o processo e desenvolvimento do sistema então é a partir dos dos requisitos que os gerentes vão conseguir eh planejar o projeto eh por completo todas as etapas lá do do processo de desenvolvimento de software Engenheiros de sistema que usam os requisitos para entender o sistema que será desenvolvido Engenheiros de manutenção do sistema que depois de desenvolvido o sistema Ele precisa saber por exemplo se mudou alguma alguma funcionalidade se é o requisito que
tá com problema então usa os requisitos para entender o sistema e os relacionamentos entre suas partes então por isso que o requisito de software ele não é só feito no começo do software ele deve ser utilizado sempre sempre deve estar atualizado e os engenheiros de teste do sistema que utiliza os requisitos do do que foram eh escritos para poderem fazer testes de funcionalidade daquele sistema para ver se o o sistema tá de acordo com aquilo que o cliente pediu aqui agora no primeiro exemplo de como escrever um documento de requisitos eh Lembrando que eh linguagem
natural eh é a maioria dos documentos requisitos estão escrito assim embora é dependendo da empresa que você tiver trabalhando depend Você pode ter algum padrão que a empresa adotou para que você escreva por exemplo você pode escrever um documento de requisitos e no formato de quase de um algoritmo dando um passo a passo Tá bom mas aqui é um exemplo dei uma olhada aqui esse exemplo é bem famoso ele tá lá no livro eh do do summerville que é um livro bastante importante da engenharia de software ele tem esse livro você pode dar uma olhada
lá na na biblioteca da Bass outro exemplo aqui retirado também do livro do summerville eh você pode ver aqui agora que é uma maneira estruturada você colocando passo a passo então algumas empresas por exemplo ela já pode ter alguns templates alguns modelos de como você escrever os requisitos é dependendo da onde que você vai trabalhar dependendo da onde você vai estruturar você tem uma maneira de estruturar diferente os requisitos aqui também Você pode utilizar uma tabela eh dependendo de cada tipo de requisito eh você pode expressar melhor por exemplo nesse caso aqui ó você a
gente pode ver que tem várias regrinhas para que você coloque eh no no sistema então e você pode mesclar também eh utilizando linguagem natural ou uma linguagem mais tabular para que você consiga expressar melhor os requisitos não precisa ser somente uma regra existe um padrão que define o que que deve ter um documento de requisitos geralmente alguma empresa que precisa é de certificação de qualidade ela geralmente ela segue eh esse padrão tá bom Um exemplo seria um sei lá uma empresa de aviação Onde tem um software que vai controlar aviões vai controlar é um motor
alguma coisa desse tipo Então os requisitos ele tem que seguir exatamente uma padronização para que essa padronização seja possível seja passível de ser medida a qualidade tá uma das normas mais conhecidas um dos padrões mais conhecidos é esse daí 3E 830 de 1993 já tem versões mais atuais mas esse é um dos primeiros exemplos lá vai ter uma introdução é como se fosse eh você já não sei se vocês já viram um artigo científico ou então um um trabalho de conclusão de curso você tem lá eh a estruturação de tudo o que que tem ter
no documento por exemplo o propósito do documento de requisitos o escopo do produto definições acrônimos abreviações referências resumo do resto do documento e por aí vai é bastante complexo eh São Regras bastante restritas aqui também só mais um exemplo do que que deve ter em cada capítulo desse documento de requisitos mais uma vez é algo bastante bu OC crático você não vai utilizar Isso é óbvio num software pequeno Isso aí são softwares que necessitam de um documento de requisitos que seja e avaliada a sua qualidade de maneira mais é precisa Como eu disse então a
i3e que a gente viu Agora tem um padrão de o que você deve conter o que deve conter no documento de requisitos mas a a isso não é seguido a risco né geralmente a a empresa que tá trabalhando o desenvolvimento de software ele vai adaptar esse padrão de acordo com a necessidade tá bom às vezes col coloca todos os documentos eh todas as partes do documento mas geralmente é algo mais simplificado eh dependendo muito do da empresa que tá trabalhando dos detalhes que você quer que esteja nesse documento de requisitos Geralmente os requisitos quando são
escritos eles são em linguagem natural como a gente já viu ali e complementado com alguns diagramas com equações com tabelas né a gente viu também isso ou com alguma estrutura definida pela própria organização bom alguns problemas frequentes que a gente pode encontrar aí nos requisitos são uso de cláusulas condicionais complexas que podem confundir Às vezes a pessoa começa a estruturar bastante eh o documento de requisitos parecendo quase um algoritmo de programação e vai ficando cada vez mais complexo e Essa não é a ideia a ideia do documento de requisitos é que seja fácil tanto pro
desenvolvedor entender o que vai Ele vai construir como pro cliente entender também o que ele pediu terminologia inconsistente você utilizar uma terminologia que não seja eh a mesma que o cliente tá utilizando Tá bom então por isso é importante lá o glossário os Escritores assumem que os leitores possuem conhecimento do domínio muitas vezes eh usam termos técnicos que eh o cliente não consegue não é capaz eh de entender o que tá sendo feito e a ideia documento de requisitos mais uma vez é um protocolo de comunicação entre o cliente e também o desenvolvedor algumas dicas
essenciais para que se escrevam um documento de requisitos requisitos são lidos mais frequentemente do que são escritos eh Invista um tempo lendo e entendendo os requisitos e não Assuma que o é quem vai ler o seu o seu documento de requisitos tem o mesmo background que você tem ou seja tem a mesma base de conhecimento que você tenha então Eh em alguns casos né use palavras que sejam mais fáceis de entender e permita um tempo para revisão e refeito documento de requisitos ou ainda eh faço documento de requisitos junto com o cliente né existem eh
metodologia de desenvolvimento de software que é feita junto com o cliente Qual é essa mais algumas diretrizes eh A ideia é que você define alguns templates alguns modelos para que você consiga seguir sempre nessa padronização se tiver mais de alguma pessoa eh trabalhando no desenvolvimento dos requisitos Vai facilitar quando você tem esses modelos utilize a linguagem de forma simples consistente e concisa e utilize diagramas de forma apropriada né não não enche de diagramas coloa diagramas ente quando for necessário complemente a linguagem natural com outras descrições de requisitos como a gente viu pode ser de forma
tabular ou então colocando alguma fórmula que for necessário e especifique requisitos de forma quantitativa é é um grande problema isso por exemplo quando você coloca no plural E não coloca a quantidade que que seja necessário por exemplo eh os livros eh o o sistema deve permitir que se armazene em livros ao mesmo tempo e e em em transações concorrentes é mas quantos livros né quantas transações concorrentes são permitidas então o o correto seria o sistema deve permitir 10 transações concorrentes para que os livros sejam armazenados ao mesmo tempo bom algo mais ou menos do tipo
eh quando você utiliza plural Você não dá quantitativamente esse número e você não dá para saber talvez dois é o plural né alguns pontos principais dessa aula de hoje requisitos define o que o sistema deve prover e define os limites do sistema tem que ficar bem claro né O que que são os requisitos eh do software problema dos requisitos causam a entrega tardia dos sistemas e solicitações de mudanças depois que o sistema estiver em uso e a gente viu que isso é 40% do custo de todo o projeto se você eh não conseguir resolver não
definir bem os requisitos do sistema e a g de requisitos diz respeito à elicitação análise e documentação dos requisitos do sistema a gente vai ter uma aula sobre licitação que são os processos de como você eh faz a captura dos requisitos você tem a obtenção dos requisitos outra coisa que precisa ficar bastante Clara é que o documento de requisitos é a especificação definitiva para os clientes Engenheiros e gerentes né então é aquele protocolo de comunicação entre o cliente e o desenvolvedor de software o documento de requisitos deve incluir um resumo um glossário definição de requisitos
funcionais e limitação operacionais que seriam os requisitos não funcionais Lembrando que nós temos uma apostila que tem o conteúdo que foi passado aqui para vocês tá bom vocês também podem ter acesso à biblioteca da univasf que tem os livros que eu citei para vocês o livro do do summerville que é um livro que é bastante utilizado na engenharia de software eh mas na unidade três da apostila as seguintes sessões a introdução requisitos e sub de viabilidade ão aí as páginas especificação de requisitos validação de requisitos documentos de requisitos da página 40 página 43 Nossa apostila
está aqui no nosso ambiente e você pode encontrar na nossa biblioteca
