Engenharia de Software - Aula 06 - Processo de engenharia de requisitos

[Música] o olá sou professor marcelo fantinato esta disciplina de engenharia de software do curso de engenharia da computação da univesp vamos tratar agora ao número 6 com o assunto é o processo de engenharia de requisitos e especificação de requisitos ou seja dentro do processo de engenharia de requisitos vamos ter uma visão geral do processo isso a começar a tratar uma das atividades desse processo que é a especificação de requisitos na próxima aula se trata de outras duas atividades do processo bom a começando com uma visão geral do processo de engenharia de requisitos novamente nós podemos

ter diferentes abordagens diferentes modelos é uma visão em espiral do processo em que nós temos a e licitação de espiral nesse lado ea validação desse lado então a idéia é você e requisitos no nosso dia a dia basicamente significa descoberta levantamento então você levanta e vai conversar com seu cliente usuários que representam o cliente descobre com ele o sistema pode ser de uma forma informal ou mais formal a partir daquele momento então você especifica os requisitos nenhum documento e aí você lida com ele você mostra documento para ele válida para ele dizer o que é

isso mesmo a efeito em várias etapas da você começa e aí você vai sempre sabendo isso você descobre coloca no documento válida aí você descobre um pouco coloca é válida e aí você vai indo até que em algum momento você termina é claro que quanto mais você vai indo pra fora dessa dessa espiral isso significa que você está evoluindo na especificação dos requisitos a tag no final você tem o documento de requisitos de sistema completo a esse documento de requisitos completo muitas vezes é chamado de especificação de requisitos então o nome especificação de requisitos ele

tanto pode se referir a fase de especificação de requisitos dentro desse ciclo enquanto o documento final do processo como um todo então vocês têm que cuidar para saber se vocês estão que estão sempre vocês estão falando sobre um pedaço do processo como um todo em termos de actividade ou como o documento final aqui fazendo dito documento de requisitos de sistema como o produto final mas poderia então ser especificação de requisitos bom então esses documentos e requisitos ou chamado de especificação de requisitos de software ele é uma declaração oficial do que os desenvolvedores devem implementar sem

o documento que de desenvolvedores é isso implementem e ele como já havia adiantado em aulas anteriores ele é considerado essencial empresas que são contratadas para o desenvolvedor e tudo desenvolvimento de software destacando então que métodos ágeis ele não é considerado um documento oficial geralmente ele não é usado esse documento requisitos ele tem que focar no que deve ser desenvolvido e não no como ok então isso quem faz em geral é o que a gente chama de o analista de requisitos analista de requisitos ele deve focar isso é o que tem que ser feito como uma

preocupação para os próximos no processo é claro que talvez ele tenha um perfil um pouquinho mais desenvolver torelli acabe adiantando algumas coisas a mesma analista de requisitos ele é totalmente da área de negócio então ele não adianta nada às vezes ele até tem uma visão tão abstrata aquele dificulta muito a vida do desenvolvedor ou seja essa fronteira eteno etapa quando a gente separa o que do como nunca a divisão a fronteira é uma coisa tão é tão clara alguns ficam muito no que o outro fundo já ultrapassa um pouco do como isso vai depender muito

da organização de como ela se fv esse organismo mas como uma uma heurística isso é o que a gente costuma tratar requisito véu que o projeto e implementação entra no como a bom e esse documento de engenharia de requisitos da lei elaborado para aquele elaborado por que vai ser usado nas próximas etapas ele pode ser usado diferentes formas né o próprio cliente do sistema quem vai que está pedindo o sistema pode usar os gerentes da organização que está desenvolvendo pode usar os engenheiros desenvolvedores podem usar quem vai testar podem usar quem vai depois implantar o

sistema e da manutenção pode usar cada um usa com objetivos diferentes mas ele não é um documento que vai acabar orientando o trabalho de quase todo mundo que vai trabalhar no desenvolvimento do sistema na seqüência esse documento de requisitos ou essa especificação de requisitos pode ter diferentes formatos mais ou menos detalhado aqui é um evento de estrutura que você pode simplificar você pode detalhar mais você pode fazer como a sua organização achar melhor então veja um evento muito básico e chega a sugerir que você faça 13 face que você faz uma introdução que não quer

ser formal dessa forma legal sinto falta de faro vou fazer o lançaria fim aquela idéia às vezes falam já vou começar em 15 propriamente dito que é o que interessa e aí ok e arquitetura do sistema caramba ele disse agora eu disse agora que eu não vou entrar no que no como e aí já tem que definir a arquitetura arquitetura céu como bom aqui tá dizendo que é uma visão geral em alto nível da arquitetura mostrando a distribuição de funções entre os módulos do sistema bom o que acontece às vezes a arquitetura faz parte de

um requisito do cliente o cliente diz olha o meu sistema tem que a arquitetura dessa forma se for o caso tem que aparecer um documento de requisitos se não for o caso se não importa o cliente não importa para o sistema a arquitetura porque tem que entrar mesmo ok mas o sistema tem que necessariamente se integrar com outro sistema então a arquitetura é algo que não pode ficar a decisão completa da equipe de desenvolvimento opa adiantar alguma coisa do documento e aí aqui tinha entrado do usuário em algum momento vai entrar os requisitos do sistema

que vai ser a principal parte desse documento o a modelagem pode adiantar como se o sistema vai ter que ter alguma evolução ou não a vou querer fazer alguma pense o índice enfim pode ser o documento propriamente dito ou atividade já tinha falado lá atrás e aí como eu escrevo essa especificação de requisitos o documento a linguagem natural é a idéia do que eu tinha adiantado os requisitos do usuário geralmente geralmente em linguagem natural eu posso ter uma linguagem natural porém estruturada o que seria uma linguagem natural estruturada é você fazer e em linguagem natural

mais uma forma risada é quase como se vocês estivessem fazendo um algoritmo vocês devem ter obviamente aprendido fazer um algoritmo né a gente chama ele de português e estruturado o inglês procurado então aqui seria muito parecido eu vou mostrar um evento daqui a pouco pode ter um gráfico você fazer através de um desenho um dos eventos que eu vou mostrar depois pra vocês é justamente a anotação gráfica que são os diagramas de casos de uso inclusive o projeto que vocês vão fazer como o trabalho da disciplina vai ser através de casos de uso você pode

ter certificações matemáticas para representar os requisitos do sistema em geral para sistemas críticos não aparece aqui a palavra crítico mas geralmente são sessão especificações formais por exemplo uma máquina do estado finito ou conjuntos teoria dos conjuntos ele é tão crítico você precisa de matemática para especificar o requisito dele ok ok é um requisito usando uma linguagem natural vai provavelmente é um requisito de usuário e não um requisito sistema dever ser bom é basicamente a uma linguagem natural aqui já é uma linguagem natural estruturada perceba que é quase tentei que você segue então veja função calcula

dose de insulina dois pontos nível seguro de açúcar então qual é a entrada ea saída entrada leitura atual de açúcar e duas leituras anteriores a fonte saídas destino a san são pós condições efeitos colaterais nem calcula dose de insulina a ser fornecida na zona percebam que é uma forma de você definir itu usando um template qualquer funcionalidade deveria ser especificada usando esse template então o que entra o que sai é isso aqui é meio caminho para você projetar o fsmt e depois que implementar é isso é muito útil para aquele analista de sistemas que já

tem um perfil de desenvolvimento de software que já teve uma formação em análise e desenvolvimento de sistemas e não é da área de negócio embora alguém da área de negócio e acabe acaba se adaptando muito bem a esse tipo de de guajará também vamos dar uma linguagem um template parecido com esse no projeto da disciplina de vocês podem chegar por exemplo até já na especificação de requisitos alguma coisa como uma tabela desse tipo condição tiver diminuindo então faça tal coisa se o nível de açúcar estiver estável faça as coisas porque o cliente desse jeito ele

começa a folha quando o nível de açúcar está diminuindo então tal coisa tem que ser feito quando a coisa na verdade três situações aqui você mantenha a mesma coisa apenas quando você tem uma outra condição aqui então você vai fazer alguma coisa diferente mas enfim às vezes o cliente fala para vocês numa entrevista de uma forma informal e você com a mente de um uma pessoa da área técnica da área tecnológica da área de computação você já pensa de uma forma estruturada e você monta uma tabela para ele desta forma mostra para ele explica e

ele fala é isso mesmo ou ele pega um erro banal não é isso quando isso acontece na verdade não é isso a saída não é inflação é uma forma mais fácil de perceber que existe um erro do que numa linguagem natural há até porque numa linguagem natural eu vou cobrir um pouco mais pra frente mas já adiantando numa linguagem natural você acaba tendo muito mais ambiguidade e dificuldade e entender o que realmente está sendo passado porque em 20 diferentes interpretações numa linguagem natural que se você tiver pelo menos numa linguagem natural estruturada já facilita você

pegar problemas de dupla interpretação ou seja de amigo da ntu e isso a gente continua então é na próxima videoaula obrigado [Música] ah não [Música] [Música] no mundo [Música]