A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Curso de Pós-graduação Lato-Sensu em Análise, Projeto e Gerência de Sistemas de Informação Disciplina: Modelagem de Negócio e Gerência de Requisitos de.

Apresentações semelhantes


Apresentação em tema: "Curso de Pós-graduação Lato-Sensu em Análise, Projeto e Gerência de Sistemas de Informação Disciplina: Modelagem de Negócio e Gerência de Requisitos de."— Transcrição da apresentação:

1 Curso de Pós-graduação Lato-Sensu em Análise, Projeto e Gerência de Sistemas de Informação Disciplina: Modelagem de Negócio e Gerência de Requisitos de Software Professora Giselle Teixeira de Almeida PÓS-GRADUAÇÃO 07/05/2010

2 SUMÁRIO Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Conceitos Gerais Sobre Requisitos; Requisitos de Software; Análise e Especificação de Requisitos; Técnicas para Verificação de Requisitos; Técnicas para Gerência de Requisitos ao Longo do Projeto; Atividades Propostas.

3 REQUISITOS DE SOFTWARE: Definição e Conceitos Gerais Tipos de Requisitos Documentos de Requisitos Levantamento de Requisitos Importância da Especificação de Requisitos Critérios de Qualidade para Especificação de Requisitos Técnicas para Elicitação de Requisitos PARTE I Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

4 Definição e conceitos gerais: Necessidades dos futuros usuários do sistema a ser desenvolvido. Uma condição ou capacidade necessária para um usuário resolver um problema ou alcançar um objetivo. Uma condição ou capacidade que deve ser alcançada ou estar presente em um sistema ou componente deste para satisfazer um contrato, padrão, especificação ou outros documentos formalmente impostos (Maciaszek, 2000). Definem o problema a ser resolvido pelo sistema de software, não descrevem o software que resolve o problema. REQUISITOS DE SOFTWARE

5 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Normalmente são identificados a partir de um domínio (área de conhecimento ou de atividade específica caracterizada por um conjunto de conceitos e de terminologia compreendidos por especialista nessa área denominado especialista do domínio). Um especialista do domínio é uma pessoa que tem familiaridade com o domínio do negócio, mas não necessariamente com o desenvolvimento de software. Frequentemente, esses especialistas são os futuros usuários do software em desenvolvimento. No contexto de software, um domínio corresponde à parte do mundo real que é relevante, quais informações e processos desse domínio precisam ser incluídos no sistema a ser desenvolvido. O domínio também é chamado de domínio do problema ou domínio do negócio. REQUISITOS DE SOFTWARE

6 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Tipos de Requisitos: Os requisitos de software podem ser dos seguintes tipos: funcionais; não-funcionais; normativos. REQUISITOS DE SOFTWARE

7 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Requisitos Funcionais: Definem as funcionalidades do sistema. Devem refletir as necessidades dos usuários. Definem o problema a ser resolvido pelo sistema. Descrevem uma interação entre o sistema e seu ambiente. Funcionalidades do sistema conforme percebidas pelos atores externos (usuários). REQUISITOS DE SOFTWARE

8 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Exemplos: a)O sistema deve permitir que cada professor realize o lançamento de notas das turmas nas quais lecionou. b)O sistema deve permitir que um aluno realize a sua matrícula nas disciplinas oferecidas em um semestre letivo. c)O coordenador deve poder obter o número de aprovações, reprovações, trancamentos em cada disciplina oferecida em um determinado período. REQUISITOS DE SOFTWARE

9 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Requisitos Não-Funcionais (Restrições): Declaram as características de qualidade que o sistema deve possuir e que estão relacionadas às suas funcionalidades. Descrevem uma restrição para o sistema que limita as possíveis escolhas de solução para o problema. Normalmente conhecidos como requisitos de qualidade de uma aplicação. Devem ser detalhados em uma seção da documentação do software. REQUISITOS DE SOFTWARE

10 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Exemplos: a)confiabilidade: medidas quantitativas da confiabilidade do sistema. Ex.: tempo médio entre falhas, recuperação de falhas ou quantidade de erros por milhares de linhas de código-fonte. b)desempenho: requisitos que definem tempos de resposta esperados para as funcionalidades do sistema. c)portabilidade: restrições sobre plataformas de hardware e software nas quais o sistema será implantado e sobre o grau de facilidade de transportar o sistema para outras plataformas. d)segurança: limitações sobre a segurança do sistema em relação a acessos não-autorizados. e)usabilidade: requisitos que se relacionam ou afetam a usabilidade do sistema. Exemplos incluem requisitos sobre a facilidade de uso e a necessidade ou não de treinamento dos usuários. REQUISITOS DE SOFTWARE

11 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Requisitos Normativos: Declaração de restrições impostas sobre o desenvolvimento do sistema. Estas restrições definem, por exemplo, a adequação a custos e prazos, a plataforma tecnológica, aspectos legais (licenciamento), limitações sobre a interface com o usuário, componentes de hardware e software a serem adquiridos, eventuais necessidades de comunicação do novo sistema com sistemas legados, etc. Estas restrições também podem corresponder a regras de negócio (restrições ou normas ou políticas de funcionamento específicas do domínio do problema que influenciarão de um modo ou de outro no desenvolvimento do software). REQUISITOS DE SOFTWARE

12 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Documentos de Requisitos: É o produto do levantamento de requisitos. Declara e descreve todos os requisitos de um software, usualmente escrito em uma notação informal (linguagem natural), em um formato ou linguagem inteligível pelo cliente, é a Descrição de Requisitos. O documento que especifica estes requisitos, utilizando um formato mais apropriado para a implementação, é a Especificação de Requisitos. Geralmente, ambos os documentos (descrição e especificação de requisitos) descrevem o que o software proposto deve fazer sem se preocupar em como deve ser feito. REQUISITOS DE SOFTWARE

13 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Não deve conter informações sobre soluções técnicas que serão adotadas para desenvolver o sistema. Sistemas serão avaliados pelo seu grau de conformidade aos requisitos, não importa quão complexa a solução tecnológica tenha sido. Serve como um termo de consenso inicial entre a equipe técnica (desenvolvedores) e o cliente. Constitui a base para as atividades subsequentes do desenvolvimento do sistema e fornece um ponto de referência para qualquer validação futura do software construído. REQUISITOS DE SOFTWARE

14 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Uma das formas de se medir a qualidade de um sistema de software é pela sua utilidade. Um sistema será útil para seus usuários se atender aos requisitos definidos e se estes, por sua vez, refletirem as necessidades dos usuários. Portanto, no documento, os requisitos devem ser expressos de uma maneira tal que eles possam ser verificados e comunicados a leitores técnicos e não-técnicos. A equipe técnica deve entender o documento de requisitos de tal forma que permita obter soluções técnicas apropriadas. Clientes devem entender o documento de requisitos para que possam priorizar o desenvolvimento dos requisitos, conforme as necessidades das organizações em que trabalham. REQUISITOS DE SOFTWARE

15 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estabelece o escopo do sistema (o que faz parte e o que não faz parte do sistema). O escopo de um sistema muda muitas vezes durante o seu desenvolvimento. A mudança no escopo obriga que clientes e desenvolvedores tenham parâmetros para decidir em que medida os recursos de tempo e financeiros devem mudar. Contudo, o planejamento inicial do projeto deve se basear no escopo inicial. REQUISITOS DE SOFTWARE

16 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Os requisitos são voláteis, podem sofrer modificações durante o desenvolvimento do sistema. Atualmente as organizações precisam se adaptar a mudanças cada vez mais rápidas. Durante o período de desenvolvimento, vários aspectos podem mudar: tecnologias utilizadas, expectativas dos usuários, regras de negócio, etc. A medida que novos requisitos são detectados ou os existentes mudem, os desenvolvedores devem verificar cuidadosamente o impacto destas mudanças no sistema. E os clientes devem decidir se estas devem ser consideradas no desenvolvimento, uma vez que influenciam o cronograma previsto e os recursos financeiros alocados. REQUISITOS DE SOFTWARE

17 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida É praticamente impossível pensar em todos os detalhes a princípio. Além disso, quando o sistema é posto em produção e operação, os usuários descobrirão requisitos nos quais não haviam pensado inicialmente. Resumindo, os requisitos de um sistema complexo inevitavelmente mudarão durante o seu desenvolvimento. No desenvolvimento de software, a existência de requisitos voláteis corresponde mais à regra do que à exceção. REQUISITOS DE SOFTWARE

18 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida É desejável que o documento de requisitos tenha seus requisitos ordenados pelos usuários em função do seu grau de prioridade (que adição de valor a presença deste requisito no sistema traz para o usuário?). As prioridades atribuídos aos requisitos, permitem ao gerente de projeto tomar decisões a respeito do momento no qual cada requisitos deve ser considerado durante o desenvolvimento do sistema. REQUISITOS DE SOFTWARE

19 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Levantamento de requisitos (definição e considerações gerais) Levantamento de requisitos = elicitação de requisitos = análise de requisitos = projeto lógico = fase de definição e compreensão do problema; Etapa de compreensão do problema aplicada ao desenvolvimento de software; Seu principal objetivo é que usuários e desenvolvedores tenham a mesma visão do problema a ser resolvido; Desenvolvedores juntamente com clientes tentam levantar e definir os requisitos do sistema a ser desenvolvido; REQUISITOS DE SOFTWARE

20 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida O envolvimento do cliente desde o início do processo de desenvolvimento ajuda a assegurar que o produto desenvolvido realmente atenda às necessidades identificadas. O enfoque prioritário é responder claramente à questão: o que o usuário necessita do novo sistema? A equipe de desenvolvimento tenta entender o domínio que deve ser automatizado pelo sistema de software; REQUISITOS DE SOFTWARE

21 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Compreende também um estudo exploratório das necessidades dos usuários e da situação do sistema atual (se este existir). Para isto, várias técnicas são empregadas, tais como: leitura de obras de referência e livros-texto, observação do ambiente do usuário, realização de entrevistas com os usuários, entrevistas com especialistas do domínio, reutilização de análises anteriores, comparação com sistemas preexistentes do mesmo domínio de negócio, etc. O artefato resultante é o Documento de Requisitos (Descrição de Requisitos + Especificação de Requisitos). REQUISITOS DE SOFTWARE

22 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida É a etapa mais importante em termos de retorno em investimentos feitos para o projeto de desenvolvimento. Muitos sistemas foram abandonados ou nem chegaram a uso porque os membros da equipe não dispensaram tempo suficiente para compreender as necessidades do cliente em relação ao novo sistema. É fato que, normalmente, um sistema de informações é utilizado para automatizar processos de negócio de uma organização. Portanto, esses processos devem ser bem compreendidos antes da construção do sistema. Um estudo baseado em sistemas feitos em 1997 feito por Carper Jones mostrou que os custos resultantes da má realização dessa etapa de entendimento podem ser 200 vezes maiores que o realmente necessário. REQUISITOS DE SOFTWARE

23 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Importância da Especificação de Requisitos: Quanto mais tarde um erro é detectado, maior é o custo de sua correção: REQUISITOS DE SOFTWARE FASECUSTO RELATIVO Requisitos0,1 Projeto0,2 Codificação1 Testes de Unidades2 Testes de Aceitação5 Manutenção20

24 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Uma Especificação de Requisitos é importante porque: estabelece uma base de concordância entre o cliente e o fornecedor sobre o que o software fará. mapeia o problema. uma especificação de requisitos de alta qualidade é um pré- requisito para um software de alta qualidade. REQUISITOS DE SOFTWARE

25 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Critérios de Qualidade para Especificação de Requisitos: Corretude: reflete fielmente a realidade e necessidades dos usuários e cliente; Consistência: informações em diferentes locais não são contraditórias; Clareza: sem ambigüidades, possibilita sua verificação; Completude: não há nenhuma informação necessária ou importante para os usuários e cliente que esteja omitida; Coesão: descreve exatamente o que é necessário para o cliente, sem acrescentar informações desnecessárias. Evite focar na corretude como o único critério de qualidade!!! REQUISITOS DE SOFTWARE

26 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Técnicas para Elicitação de Requisitos: Entrevistas; Sessões de JAD (ou FAST); Reuniões de Grupo; Brainstorm; Análise de Documentos; Questionário; Observações; Sistemas Legados; Casos de Uso, etc. REQUISITOS DE SOFTWARE

27 ANÁLISE DE REQUISITOS: Definição e Conceitos Gerais Validação dos Modelos Verificação dos Modelos Análise do Domínio X Análise da Aplicação PARTE II Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

28 Definição e Considerações Gerais: O levantamento de requisitos e a análise de requisitos em conjunto recebem o nome de engenharia de requisitos (Wilson de Pádua, 2003). O termo análise significa decompor o sistema em seus componentes e estudar a interação entre estes com o objeto de entender melhor o funcionamento do sistema. No contexto de software, esta é a etapa em que os analistas realizam um estudo detalhado dos requisitos levantados na etapa anterior (levantamento de requisitos) e constroem os modelos que representam o sistema a ser desenvolvido. ANÁLISE DE REQUISITOS

29 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida A análise também não leva em conta o ambiente tecnológico a ser utilizado. O objetivo é construir a melhor estratégia de solução para o problema sem se preocupar com detalhes da tecnologia a ser utilizada. É necessário saber o que o sistema deve fazer para, posteriormente, definir como esse sistema irá fazê-lo. Os modelos construídos na fase de análise devem ser cuidadosamente validados e verificados. ANÁLISE DE REQUISITOS

30 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Validação dos modelos O objetivo da validação é assegurar que as necessidades do cliente estão sendo atendidas pelo sistema. Ex.: será que o software correto está sendo construído? A especificação construída para o software deve ser correta, consistente, completa, realista e sem ambiguidades. Os analistas apresentam os modelos criados para que os usuários façam a validação, isto é, atestem que entenderam os modelos e que estes refletem suas necessidades. Os modelos devem ser bem definidos, erros no levantamento de requisitos implica na construção de modelos errados, ocasionando conflitos e impactos nos custos e prazos. ANÁLISE DE REQUISITOS

31 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Verificação dos modelos O objetivo da verificação é analisar se os modelos construídos estão em conformidade com os requisitos definidos. Ex.: será que o software está sendo construído corretamente? A exatidão de cada modelo em separado é analisada e posteriormente a consistência entre os modelos. Obs.: diferente da validação (atividade de análise), a verificação é uma etapa típica da fase de projeto. ANÁLISE DE REQUISITOS

32 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Análise do Domínio X Análise da Aplicação De acordo com alguns autores, a fase de análise pode ser subdividida em: análise do domínio (ou análise do negócio); análise da aplicação. ANÁLISE DE REQUISITOS

33 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Análise do Domínio ou do Negócio Modela objetos do mundo real que serão processados pela aplicação. Ex.: em um sistema de controle acadêmico: aluno, professor, disciplina, turma, sala de aula, etc. Os analistas devem interagir com especialistas do domínio, pois os objetos identificados correspondem a conceitos com os quais estes profissionais lidam diariamente. Modela as regras de negócio e os processos de negócio realizados pela organização. ANÁLISE DE REQUISITOS

34 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Análise da Aplicação Identifica objetos de análise que normalmente não fazem sentido para os especialistas de domínio, porém necessários para suprir as funcionalidades do sistema. Um objeto de aplicação é qualquer objeto necessário para que o sistema possa se comunicar com seu ambiente. Têm a ver com aspectos computacionais de alto nível. Só têm sentido no contexto de software, diferentemente dos objetos de domínio. Ex.: tela de inscrição em disciplina é um objeto componente de uma aplicação de controle de uma instituição de ensino. Apenas identifica objetos da aplicação, não os detalha, nem está interessada na implementação dos mesmos (fase de projeto). ANÁLISE DE REQUISITOS

35 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Separação do domínio da aplicação Um dos motivos para separação da análise do domínio (objetos do domínio) e análise da aplicação é o reuso. Modelar separadamente o domínio dos aspectos específicos da aplicação permite que os componentes resultantes dessa modelagem tenham maior potencial de reusabilidade no desenvolvimento de aplicação dentro do mesmo domínio de problema. Principais diagramas da UML para análise: diagrama de casos de uso, diagrama de classes, diagrama de atividades, diagrama de estados, diagrama de interação. ANÁLISE DE REQUISITOS

36 ATIVIDADES PROPOSTAS: Elicitação de Requisitos Estudo de Caso – Sistema de Controle Acadêmico Estudo de Caso Particular Pesquisa sobre Ferramentas de Gerência de Requisitos PARTE III Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida

37 Elicitação de Requisitos Baseado em sua experiência, tente escrever um documento de requisitos para um Sistema de Controle Acadêmico - SCA. Esse sistema deve controlar as inscrições de alunos em disciplinas, a distribuição das turmas, salas, professores, etc. Deve permitir também o controle de notas atribuídas aos alunos em diversas disciplinas. Você pode se basear na forma de funcionamento da sua própria universidade. Com base em sua experiência, tente escrever um documento de requisitos para um sistema de software do seu cotidiano (por exemplo, um sistema para automatizar algum processo na empresa em que trabalha, aproveitando o conhecimento do domínio do negócio que você tiver). Durante a elaboração desse documento, resista o máximo possível à tentação de considerar detalhes técnicos e de implementação. ATIVIDADESPROPOSTAS

38 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Descrição da situação: O estudo de caso é sobre uma universidade que precisa de uma aplicação para controlar alguns processos acadêmicos, como inscrições em disciplinas, lançamentos de notas, alocação de recursos para turmas, etc. Após o levantamento de requisitos inicial desse sistema, os analistas chegaram à seguinte lista de requisitos funcionais: RF1. O Sistema deve permitir que alunos visualizem as notas obtidas por semestre letivo. ATIVIDADESPROPOSTAS

39 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA RF2. O Sistema deve permitir o lançamento das notas das disciplinas lecionadas em um semestre letivo e controlar os prazos e atrasos neste lançamento. RF3. O Sistema deve manter informações cadastrais sobre disciplinas no currículo escolar. RF4. O Sistema deve permitir a abertura de turmas para uma disciplina, assim como a definição de salas e laboratórios a serem utilizados e dos horários e dias da semana em que haverá aulas de tal turma. RF5. O Sistema deve permitir que os alunos realizem a inscrição em disciplinas de um semestre letivo. ATIVIDADESPROPOSTAS

40 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA RF6. O Sistema deve permitir o controle do andamento das inscrições em disciplinas feitas por alunos. RF7. O Sistema deve se comunicar com o Sistema de Recursos Humanos para obter dados cadastrais sobre os professores. RF8. O Sistema deve se comunicar com o Sistema de Faturamento para informar as inscrições realizadas pelos alunos. RF9. O Sistema deve manter informações cadastrais sobre os alunos e sobre seus históricos escolares. ATIVIDADESPROPOSTAS

41 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Regras de Negócio Algumas regras iniciais do negócio também foram identificadas para o sistema. Essas regras são descritas a seguir: RN01. Quantidade máxima de inscrições por Semestre letivo: em um semestre letivo, um aluno não pode se inscrever em uma quantidade de disciplinas cuja soma de créditos ultrapasse 20. RN02. Quantidade de alunos possíveis: uma oferta de disciplina em uma turma não pode ter mais de 40 alunos inscritos. ATIVIDADESPROPOSTAS

42 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA RN03. Pré-requisitos para uma disciplina: um aluno não pode se inscrever em uma disciplina para a qual não possua os pré- requisitos necessários. RN04. Habilitação para lecionar uma disciplina: um professor só pode lecionar disciplinas para as quais esteja habilitado. RN05. Cancelamento de matrícula: um aluno deve ter a matrícula cancelada se for reprovado mais de duas vezes na mesma disciplina. ATIVIDADESPROPOSTAS

43 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA RN06. Política de Avaliação de Alunos: a nota de um aluno em uma disciplina (um valor de 0 a 10) é obtida pela média de duas avaliações durante o semestre, A1 e A2, ou pela frequência nas aulas. a)se o aluno obtiver nota maior ou igual a 7,0 (sete), será aprovado; b)se o aluno obtiver nota maior ou igual a 5,0 (cinco) e menor que 7,0 (sete), deverá fazer a avaliação final; c)se o aluno obtiver nota menor que 5,0 (cinco) será reprovado; d)se o aluno tiver uma frequência menor que 75% em uma turma, será automaticamente reprovado. ATIVIDADESPROPOSTAS

44 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Documentação do Modelo de Caso de Uso (Atores) Nesse sistema de controle acadêmico, o analista identificou e documentou os seguintes atores: Aluno: indivíduo que está matriculado na universidade, que tem interesse em se inscrever em disciplinas do curso. Professor: indivíduo que leciona disciplinas na universidade. Coordenador: pessoa interessada em agendar alocações de turmas e professores, e visualizar o andamento de inscrições de alunos. ATIVIDADESPROPOSTAS

45 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Departamento de Registro Escolar (DRE): departamento da universidade interessado em manter informações sobre os alunos matriculados e sobre seu histórico escolar. Sistema de Recursos Humanos: este sistema legado é responsável por fornecer informações cadastrais sobre os professores. Sistema de Faturamento: este sistema legado tem interesse em obter informações sobre inscrições dos alunos para realizar o controle de pagamento de mensalidades. ATIVIDADESPROPOSTAS

46 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Documentação do Modelo de Caso de Uso (Pacotes e seus Respectivos Casos de Uso) O analista também identificou os casos de uso a seguir e os organizou em três pacotes: Gerenciamento de Inscrições; Gerenciamento de Recursos Acadêmicos; Acompanhamento de Semestre Letivo. Os casos de uso que apresentam comentários (entre parênteses e em itálico) são aqueles para os quais não são fornecidas descrições detalhadas. ATIVIDADESPROPOSTAS

47 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Gerenciamento de Inscrições: 1.Realizar Inscrição; 2.Cancelar Inscrição (Aluno cancela inscrições em uma ou mais ofertas de disciplinas em que havia solicitado inscrição); 3.Visualizar Grade Curricular (Aluno visualiza a grade curricular atual); 4.Visualizar Andamento de Inscrições; 5.Abrir Turma (Coordenador abre uma turma); 6.Fechar Turma (Coordenador fecha uma turma); 7.Atender Lista de Espera. ATIVIDADESPROPOSTAS

48 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Gerenciamento de Recursos Acadêmicos: 1.Manter Grade Curricular (Coordenador define informações sobre uma grade curricular); 2.Manter Disciplina; 3.Manter Aluno (DRE mantém informações obre aluno); 4.Fornecer Grade de Disponibilidade; 5.Fornecer Habilitações (Professor informa as disciplinas da grade curricular que está apto a lecionar); 6.Atualizar Informações sobre Professor. ATIVIDADESPROPOSTAS

49 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Acompanhamento de Semestre Letivo: 1.Lançar Avaliações e Frequência; 2.Obter Diário de Classe (Professor obtém diário de classe para determinado mês do semestre letivo corrente); 3.Visualizar Avaliações e Frequências; 4.Solicitar Histórico Escolar (Aluno solicita a produção do seu histórico escolar). ATIVIDADESPROPOSTAS

50 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA A seguir são apresentados o Diagrama de Casos de Uso e as descrições de alguns casos de uso no formato essencial e expandido. A descrição dos demais casos de uso fica como atividade proposta. ATIVIDADESPROPOSTAS

51 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA ATIVIDADESPROPOSTAS Documentação do Modelo de Caso de Uso (Diagrama de Casos de Uso)

52 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Documentação do Modelo de Caso de Uso (Descrição dos Casos de Uso) Realizar Inscrição (CSU01) ATIVIDADESPROPOSTAS Sumário: Aluno usa o sistema para realizar inscrição em disciplinas. Ator Primário: Aluno. Ator Secundário: Sistema de Faturamento. Precondições: O Aluno está identificado pelo sistema. Fluxo Principal: 1.O Aluno solicita a realização de inscrição. 2.O sistema apresenta as disciplinas para as quais o aluno tem pré- requisitos (conforme a RN03), excetuando-se as que já tenha cursado.

53 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Realizar Inscrição (CSU01) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 3.O Aluno define a lista de disciplinas que deseja cursar no próximo semestre letivo e as relaciona para inscrição. 4.Para cada disciplina selecionada, o sistema designa o aluno para uma turma que apresente uma oferta para tal disciplina. 5.O sistema informa as turmas para as quais o Aluno foi designado. Para cada turma, o sistema informa o professor, os horários e os respectivos locais das aulas de cada oferta de disciplina. 6.O Aluno confere as informações fornecidas. Aqui, é possível que o caso de uso retorne ao passo 3, conforme o Aluno queira revisar (inserir ou remover itens) a lista de disciplinas a cursar.

54 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Realizar Inscrição (CSU01) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 7.O sistema registra a inscrição do Aluno, envia os dados sobre a mesma para o Sistema de Faturamento e o caso de uso termina. Fluxo Alternativo (4): Inclusão em lista de espera a)Se não há oferta disponível para alguma disciplina selecionada pelo Aluno (conforme a RN02), o sistema reporta o fato e fornece a possibilidade de inserir o Aluno em uma lista de espera. b)Se o Aluno aceitar, o sistema o insere na lista de espera e apresenta a posição na qual o Aluno foi inserido na lista. O caso de uso retorna ao passo 4. c)Se o Aluno não aceitar, o caso de uso prossegue a partir do passo 4.

55 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Realizar Inscrição (CSU01) - continuação ATIVIDADESPROPOSTAS Fluxo de Exceção (4): Violação de RN01 a)Se o Aluno atingiu a quantidade máxima de inscrições possíveis em um semestre letivo (conforme RN01), o sistema informa ao Aluno a quantidade de disciplinas que ele pode selecionar, e o caso de uso retorna ao passo 2. Pós-condições: O Aluno foi inscrito em uma das turmas de cada uma das disciplinas desejadas, ou foi adicionado a uma ou mais listas de espera. Regras de Negócio: RN01, RN02, RN03.

56 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Avaliações e Frequências (CSU02) ATIVIDADESPROPOSTAS Sumário: Aluno visualiza avaliação que recebeu (notas e frequência) nas turmas de um semestre letivo. Ator Primário: Aluno. Precondições: O Aluno está identificado pelo sistema. Fluxo Principal: 1.O Aluno solicita a visualização das avaliações para as ofertas de disciplina em que participou. 2.O sistema exibe os semestre letivos nos quais o Aluno se inscreveu em pelo menos uma oferta de disciplina. 3.O Aluno seleciona os semestres letivos cujas avaliações deseja visualizar.

57 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Avaliações e Frequências (CSU02) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 4.O sistema exibe uma lista de avaliações agrupadas por semestres letivos selecionados e por turma. 5.O Aluno visualiza as avaliações e o caso de uso termina. Fluxo de Exceção (2): Aluno sem inscrição a)Não há semestre letivo no qual o Aluno tenha participado de alguma oferta de disciplina: o sistema reporta o fato e o caso de uso termina. Pós-condições: O Aluno obteve as avaliações que desejava visualizar.

58 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Fornecer Grade de Disponibilidades (CSU03) ATIVIDADESPROPOSTAS Sumário: Professor fornece a sua grade de disponibilidade (disciplinas que deseja lecionar, juntamente com dias e horários em que está disponível) para o próximo semestre letivo. Ator Primário: Professor. Precondições: O Professor está identificado pelo sistema. Fluxo Principal: 1.O Professor indica o desejo de fornecer sua grade de disponibilidades para o próximo semestre letivo. 2.O sistema apresenta a lista de disciplinas disponíveis (conforme RN04). 3.O Professor preenche a grade com as disciplinas que deseja lecionar no próximo semestre letivo.

59 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Fornecer Grade de Disponibilidades (CSU03) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 4.O sistema apresenta a lista de dias da semana e de horários do semestre letivo seguinte. 5.O Professor preenche a grade com sua disponibilidade de dias da semana e horários para o próximo semestre letivo. 6.O Professor solicita ao sistema que registre sua grade. 7.O sistema registra a grade fornecida pelo professor e o caso de uso termina. Fluxo de Exceção (3): Modificação na grade atual a)O professor solicita que o sistema apresente a mesma grade do semestre atual. b)O sistema apresenta a configuração de grade requisitada.

60 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Fornecer Grade de Disponibilidades (CSU03) - continuação ATIVIDADESPROPOSTAS Fluxo de Exceção (3): Modificação na grade atual (continuação) c)O professor realiza as modificações que deseja na grade e solicita o seu registro. d)O sistema registra a grade alterada e o caso de uso termina. Fluxo de Exceção (3): Disciplinas não fornecidas a)Se o Professor não forneceu disciplina alguma: o sistema reporta o fato e o caso de uso continua a partir do passo 2. Fluxo de Exceção (3): Dias e horários não fornecidos a)Se o Professor não r dia e horário algum: o sistema reporta o fato e o caso de uso continua a partir do passo 4. Pós-condições: o sistema registrou a disponibilidade do Professor para o próximo semestre letivo. Regras de Negócio: RN04.

61 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Lançar Avaliações e Frequências (CSU04) ATIVIDADESPROPOSTAS Sumário: Professor realiza o lançamento de avaliações e frequências para alunos das ofertas de disciplinas lecionadas por ele no semestre corrente. Ator Primário: Professor. Precondições: O Professor está identificado pelo sistema. Fluxo Principal: 1.O Professor solicita o lançamento de notas. 2.O sistema exibe a lista de turmas e disciplinas correspondentes do semestre corrente nas quais o Professor lecionou. 3.O Professor seleciona a turma e, dentro desta, a oferta de disciplina para a qual deseja realizar o lançamento de notas.

62 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Lançar Avaliações e Frequências (CSU04) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 4.O sistema exibe a lista de alunos da oferta de disciplina seleciona e requisitada a primeira nota (A1), a segunda nota (A2) e a quantidade de faltas para cada aluno. 5.O Professor fornece as notas de A1 e de A2 e a quantidade de faltas (frequência) para cada aluno. 6.O sistema exibe o resultado da avaliação de cada aluno (conforme RN06), para verificação pelo Professor. 7.O Professor confere os dados e confirma o lançamento. 8.O sistema registra as avaliações e frequências e o caso de uso termina. Fluxo Alternativo (7): Erro no lançamento a)O professor detecta que lançou uma avaliação ou frequência errada para algum aluno.

63 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Lançar Avaliações e Frequências (CSU04) - continuação ATIVIDADESPROPOSTAS Fluxo Alternativo (7): Erro no lançamento (continuação) b)O professor corrige a informação que foi lançada erroneamente do aluno. c)O sistema aceita a correção e o caso de uso do continua a partir do passo 7. Fluxo de Exceção (4): Avaliação em branco ou errada a)Se o Professor não fornece alguma nota, ou frequência, ou fornece dados inválidos: o sistema reporta o fato e o caso de uso retorna ao passo 4. Pós-condições: as notas de uma ou mais disciplinas ofertadas e lecionadas pelo professor foram lançadas no sistema. Regras de Negócio: RN05, RN06.

64 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) ATIVIDADESPROPOSTAS Sumário: DRE realiza o cadastro (inclusão, remoção, alteração e consulta) dos dados sobre disciplinas. Ator Primário: DRE. Fluxo Principal: 1.DRE requisita a manutenção de disciplinas. 2.O sistema apresenta as operações que podem ser realizadas: a inclusão de uma nova disciplina, a alteração dos dados de uma disciplina, a exclusão de uma disciplina e a consulta de disciplinas. 3.O DRE indica a opção a realizar ou opta por finalizar o caso de uso. 4.O DRE seleciona a opção desejada: inclusão, alteração, exclusão ou consulta. 5.Se o DRE deseja continuar com a manutenção, o caso de uso retorna ao passo 2; caso contrário, o caso de uso termina.

65 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) - continuação ATIVIDADESPROPOSTAS Fluxo Alternativo (4): Inclusão a)O DRE requisita a inclusão de uma disciplina. b)O sistema apresenta um formulário em branco para que os detalhes da disciplina (código, nome e quantidade de créditos) sejam incluídos. c)O DRE fornece os detalhes da nova disciplina. d)O sistema apresenta uma lista de disciplinas para que o DRE selecione as que são pré-requisitos para a disciplina a ser criada. e)O DRE define zero ou mais disciplinas como pré-requisitos. f)O sistema verifica a validade dos dados. Se os dados forem válidos, inclui a nova disciplina; caso contrário, o sistema reporta o fato, solicita novos dados e repete a verificação.

66 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) - continuação ATIVIDADESPROPOSTAS Fluxo Alternativo (4): Remoção a)O DRE seleciona uma disciplina e requisita que o sistema a remova. b)Se a disciplina pode ser removida, o sistema realiza a remoção; caso contrário, o sistema reporta o fato. Fluxo Alternativo (4): Alteração a)O DRE altera um ou mais dos detalhes sobre uma disciplina e requisita sua atualização. b)O sistema verifica a validade dos dados e, se eles forem válidos, altera os dados na lista de disciplinas da universidade. Fluxo Alternativo (4): Consulta a)O DRE solicita a realização de uma consulta sobre uma lista de disciplinas.

67 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Manter Disciplina (CSU05) - continuação ATIVIDADESPROPOSTAS Fluxo Alternativo (4): Consulta a)O sistema apresenta uma lista com os códigos de todas as disciplinas, permitindo que o DRE selecione a disciplina desejada. b)O DRE seleciona uma disciplina. c)O sistema apresenta os detalhes da disciplina e seus pré-requisitos (se existirem) no formulário de disciplina. Pós-condições: uma disciplina foi inserida ou removida, ou seus detalhes foram alterados.

68 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Andamento de Inscrições (CSU06) ATIVIDADESPROPOSTAS Sumário: O Coordenador usa o sistema para visualizar o andamento de inscrições sendo realizadas pelos alunos em disciplinas ofertadas para o próximo semestre letivo. Ator Primário: Coordenador. Precondições: O Coordenador está identificado pelo sistema. Fluxo Principal: 1.O Coordenador solicita a visualização do andamento de inscrições realizadas pelos alunos. 2.O sistema exibe a lista de disciplinas para as quais existe pelo menos uma oferta para o próximo semestre. 3.O coordenador seleciona a disciplina para a qual deseja visualizar o andamento de inscrições.

69 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Visualizar Andamento de Inscrições (CSU06) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 4.O sistema exibe a lista de turmas nas quais existe oferta para a disciplina selecionada, juntamente com as distribuições correspondentes: professor, horários, locais e situação (aberta ou fechada). 5.O Coordenador seleciona uma das turmas. 6.O sistema apresenta a lista de alunos inscritos na turma para a disciplina selecionada, ordenador por data de inscrição. 7.O coordenador visualiza as inscrições. 8.Se o Coordenador deseja continuar a visualização, o caso de uso retorna ao passo 5; é também possível que o caso de uso retorne ao passo 3, de acordo com a ação do Coordenador; caso contrário, o caso de uso termina.

70 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Atualizar Informações Sobre Professor (CSU07) ATIVIDADESPROPOSTAS Sumário: Administrador do sistema usa o sistema para atualizar as informações cadastrais sobre professores a partir do SRH. Ator Primário: Administrador. Ator Secundário: Sistema de Recursos Humanos (SRH). Precondições: O Administrador está identificado pelo sistema. Fluxo Principal: 1.O Administrador solicita ao sistema que obtenha os dados atualizados sobre professores. 2.O sistema se comunica com o SRH e obtém os dados a partir deste. 3.O sistema apresenta os dados obtidos e solicita a confirmação do Administrador para realizar a atualização.

71 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Atualizar Informações Sobre Professor (CSU07) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 4.O Administrador confirma a atualização. 5.O sistema atualiza os dados cadastrais dos professores e o caso de uso termina. Fluxo Alternativo (4): Desistência de atualização a)O Administrador declina da atualização e o caso de uso termina. Fluxo de Exceção (2): Houve uma falha na obtenção de dados a)O sistema não consegue obter os dados a partir do SRH. b)O sistema reporta o fato e o caso de uso termina.

72 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Atender Listas de Espera (CSU08) ATIVIDADESPROPOSTAS Sumário: Coordenador atende ás demandas representadas pelas listas de espera por vagas para uma disciplina. Ator Primário: Coordenador. Ator Secundário: Sistema de Faturamento. Precondições: O Coordenador está identificado pelo sistema. Fluxo Principal: 1.O sistema apresenta as listas de espera existentes para as disciplinas. 2.O Coordenador seleciona uma das listas de espera. 3.O sistema apresenta os detalhes da lista de espera selecionada (data de criação e quantidade de alunos).

73 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Atender Listas de Espera (CSU08) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 4.O Coordenador fornece os dias e respectivos horários da oferta de disciplinas que deseja criar. 5.O sistema apresenta as salas e os professores disponíveis nos dias e horários fornecidos pelo Coordenador. 6.O Coordenador seleciona um professor e uma ou mais salas. 7.O Coordenador fornece a quantidade de alunos a serem alocados na nova oferta de disciplina (conforme RN02). 8.A partir de uma lista fornecida pelo sistema, o Coordenador seleciona a turma na qual deseja alocar a oferta de disciplina. 9.O sistema cria a oferta de disciplina e transfere a quantidade de alunos fornecida no passo 7 da lista de espera para a oferta recém-criada, de acordo com a ordem dos alunos da lista.

74 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Atender Listas de Espera (CSU08) - continuação ATIVIDADESPROPOSTAS Fluxo Principal (continuação): 10.Se o Coordenador deseja continuar o atendimento das listas de espera, o caso de uso retorna ao passo 1; caso contrário, o sistema envia os dados de inscrições de alunos para o sistema de faturamento e o caso de uso termina. Fluxo de Exceção (7): Violação de RN02 a)Se a quantidade de alunos que o Coordenador fornecer for inválida (violar a regra de negócio RN02), o sistema reporta o fato e solicita um novo valor. b)O Coordenador corrige o valor e o caso de uso prossegue a partir do passo 8. Regra de Negócio: RN02.

75 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Diagrama de Classe ATIVIDADESPROPOSTAS

76 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Glossário O glossário contém os termos relevantes do domínio, a maioria deles correspondentes a classes identificadas. A definição do glossário para o Sistema de Controle Acadêmico é apresentada a seguir: 1.Aluno: representa um aluno da universidade. 2.Aula: representa o acontecimento semanal de uma aula de alguma oferta de disciplina. Toda aula acontece em uma sala da universidade. 3.Avaliação: representa uma avaliação atribuída à participação de um aluno em uma turma que oferece alguma disciplina da universidade. 4.Disciplina: uma disciplina componente da grade curricular da universidade. ATIVIDADESPROPOSTAS

77 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA 5.Grade de Disponibilidades: representa a grade de dias da semana e os respectivos horários no semestre letivo seguinte ao atual nos quais um professor está disponível para lecionar na universidade. Representa também as disciplinas que o professor está apto a lecionar nesse mesmo semestre letivo. 6.Grade Curricular: uma grade curricular corresponde a um conjunto de disciplinas, juntamente com os pré-requisitos de cada uma delas. De tempos em tempos, a instituição de ensino atualiza a sua grade curricular. Nessa atualização, novas disciplinas podem ser criadas, assim como disciplinas existentes podem ser removidas da grade. 7.Lista de Espera: representa uma lista dos alunos que estão esperando que uma certa disciplina seja oferecida em alguma turma. 8.Oferta de disciplina: representa a alocação de uma disciplina em alguma turma. ATIVIDADESPROPOSTAS

78 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA 9.Participação: representa a participação de um aluno em alguma disciplina ofertada pela universidade. A participação de um aluno em uma oferta de disciplina possui uma avaliação. 10.Professor: representa o indivíduo que leciona as disciplinas ofertadas pela universidade. 11.Sala: representa um dos locais da universidade que podem ser utilizados para as aulas de uma ou mais disciplinas ofertadas. 12.Turma: representa uma turma aberta em algum semestre letivo da universidade. Um turma possui diversas disciplinas ofertadas. 13.Diário de classe: corresponde a um formulário que contém os nomes dos alunos inscritos em determinada oferta de disciplina. Nesse formulário, o professor lança a quantidade de faltas e as avaliações de cada aluno. ATIVIDADESPROPOSTAS

79 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Diagrama de Atividade ATIVIDADESPROPOSTAS O diagrama de atividade apresentado ao lado aplica-se à descrição da lógica de funcionamento do caso de uso Realizar Inscrição. Note que este diagrama realça as atividades do caso de uso que têm potencial para serem realizadas em paralelo.

80 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Diagrama de Atividade ATIVIDADESPROPOSTAS Outra possibilidade é utilizar o diagrama de atividade para documentar regras de negócio. O diagrama de atividade ao lado representa a lógica de implementação da regra de negócio Política de Avaliação de Alunos (RN06).

81 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso – Sistema Controle Acadêmico - SCA Diagrama de Atividade ATIVIDADESPROPOSTAS Também é possível utilizar o diagrama de atividades para a modelagem e representação de fluxos de processos de negócio principais, como ilustrado ao lado.

82 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Estudo de Caso Particular Baseado no estudo de caso apresentado anteriormente, reúna-se com seus colegas formando grupos de 5 pessoas e, posteriormente, tente elaborar desde o documento de requisitos até o diagrama de atividades (fluxo de processos de negócio) para um sistema de software do seu cotidiano (por exemplo, um sistema para automatizar algum processo na empresa em que trabalha, aproveitando o conhecimento do domínio do negócio que você tiver), cujo domínio do problema e negócio sejam do seu conhecimento, vivência e experiência. Durante a elaboração desse documento, resista o máximo possível à tentação de considerar detalhes técnicos e de implementação. Entrega e apresentação no dia 21/05. Artefatos: documento de requisitos, regras de negócio, modelo completo de casos de uso, diagrama de classes, glossário e diagrama de atividades (fluxo dos processos de negócio). ATIVIDADESPROPOSTAS

83 Modelagem de Negócio e Gerência de Requisitos de Software – Giselle T. de Almeida Pesquisa – Ferramenta de Gerência de Requisitos: Faça uma pesquisa e produza um relatório a respeito das principais ferramentas de gerência de requisitos existentes no mercado. Faça um comparativo entre elas. ATIVIDADESPROPOSTAS


Carregar ppt "Curso de Pós-graduação Lato-Sensu em Análise, Projeto e Gerência de Sistemas de Informação Disciplina: Modelagem de Negócio e Gerência de Requisitos de."

Apresentações semelhantes


Anúncios Google