A contextualização e a interdisciplinaridade aplicadas no Curso de Pós Graduação em Engenharia de Requisitos – um estudo de caso
Angélica Toffano Seidel Calazans, Dra. angelica.calazans@uniceub.br Transformar o conhecimento em conteúdo a ser ensinado, definir o tratamento a ser dado a essas informações, e tomar decisões com o objetivo de construir um ambiente de aprendizagem tem sido um dos desafios na área do ensino. A experiência do Curso de Pós graduação em Engenharia de Requisitos tem demonstrado que isso é possível utilizando principalmente os conceitos de contextualização e interdisciplinaridade.
Segundo Maranhão (2009), a “contextualização do conteúdo traz importância ao cotidiano do aluno, mostra que aquilo que se aprende, em sala de aula, tem aplicação prática em nossas vidas. A contextualização permite ao aluno sentir que o saber não é apenas um acúmulo de conhecimentos técnico-científicos”.
Com relação a interdisciplinaridade, Saviani ( 2003, p. 53 ),afirma que é ‘um processo de co-participação, diálogo, que caracterizam a integração não apenas das disciplinas mas de todos os envolvidos no processo educativo." Para Lenoir (1998) a interdisciplinaridade necessita do envolvimento de três níveis: curricular, didático e pedagógico. Segundo esse mesmo autor, o estabelecimento de ligações de interdependência, de convergência e de complementaridade entre diferentes disciplinas representa o nível curricular. O nível didático envolve o planejamento de estratégias de ação e de intervenção para a implementação desse currículo e sua inserção nas situações de aprendizagem. O nível pedagógico envolve os aspectos ligados à gestão da classe e ao contexto do ato de ensinar. O presente artigo apresenta a aplicação desses três níveis de interdisciplinaridade no curso de Pós Graduação em Engenharia de Requisitos do Uniceub.
Implementação da interdisciplinaridade no nível curricular, didático e pedagógico
Analisando o nível curricular da Pós Graduação em Engenharia de Requisitos verifica-se a preocupação pelo estabelecimento de ligações de interdependência, convergência e complementaridade, que são implementadas também no nível pedagógico e didático. Um exemplo desta interdisciplinaridade a nível curricular pode ser visualizado na figura 1, onde se identificam os relacionamentos de algumas disciplinas no mesmo nível e no nível hierárquico superior.
Qualidade de software Engenharia de requisitos
Especificação de requisitos Processos de produção de requisitos
Modelagem de dados Modelagem de requisitos
Figura 1 – Relacionamento de algumas disciplinas do Curso de Pós Graduação em Engenharia de Requisitos.
Mas, de acordo com Brasil(2002), “o trabalho interdisciplinar, antes de garantir associação temática entre diferentes disciplinas, deve buscar unidade em termos de prática docente” Como exemplo dessa associação curricular, pedagógica e didática, relata-se brevemente o caso relacionado às disciplinas de Engenharia de Requisitos e Modelagem de Dados do Curso de Pós Graduação em Engenharia de Requisitos.
A introdução de vários estudos de casos na disciplina de Engenharia de Requisitos proporcionou aos alunos através da contextualização o desenvolvimento de competências e habilidades para trabalhar de forma sistêmica com requisitos definidos sobre os mais diversos temas e assuntos. A utilização desses mesmos estudos de casos na disciplina de modelagem de dados proporcionou o trabalho conjunto de duas disciplinas possibilitando a utilização e aprofundamento das competências adquiridas em outro contexto. Segundo Brasil (2002) a interdisciplinaridade deve possibilitar a utilização do conhecimento de várias disciplinas para resolver um problema ou compreender um fenômeno.
A seguir, exemplifica-se a implementação da interdisciplinaridade através de um dos estudos de caso aplicados na disciplina de Engenharia de Requisitos. O estudo de caso tinha por objetivo concentrar e organizar todos os requisitos identificados para o sistema de atendimento da empresa Editora ABC S/A no Módulo Publicação e Vendas, fornecendo aos membros da equipe de projeto, as informações necessárias para a implementação, assim como para a realização dos testes e homologação do sistema.
Os alunos, na disciplina de Engenharia de Requisitos, trabalharam em grupo e individualmente identificando regras de negócio, requisitos funcionais e complementares etc. Todos estes dados constam do Documento de Definição de Requisitos – DDR que fazem parte do Método Extreme Requeriments - XR. Todas essas informações foram analisadas e discutidas na disciplina de Modelagem de Dados para a identificação e definição do modelo Entidade e Relacionamento. Os requisitos funcionais (Tabela 1) serviram de insumo para a definição de algumas entidades (Figura 2).
Identificador Requisito Funcional Requisito Complementar
Regra de Negócio
RF01 O sistema deve permitir cadastrar usuário RC01 RNG01
RF02 O sistema deve cadastrar autor RC02
RF03 O sistema deve cadastrar livro RC03 RNG02
Tabela 1 – Exemplo de alguns dos requisitos funcionais
Os requisitos complementares (Tabela 2) serviram de insumo para a definição de atributos para as entidades já criadas e de relacionamentos, conforme apresentados na Figura 3.
Identificador: Requisitos Funcional
RC01 – O sistema deve cadastrar o usuário pelos seguintes atributos. RF01 / RFXX
Nome O S E Descrição Exemplo Tipo
Nome usuário x x Atributo que representa o nome completo do usuário Pedro Silva Motta.
A
Login x x Atributo que representa o login do usuário. Este atributo é utilizado para efetuar o login no sistema.
PedroSM A
Senha x x Atributo que representa a senha do usuário. Este atributo é utilizado para efetuar o login no sistema.
12345678 A
Data de
cadastramento
x Atributo que representa a data do cadastramento do usuário a ser identificado pelo sistema
17/11/2002 D
Status x x Atributo que representa o status do usuário. I ou A -- CPF x x Atributo que representa o número do cadastro da pessoa física do
usuário.
021.058.19 4-08
N
RG x Atributo que representa o número do registro geral do usuário. 1.487.599 N UF do RG x Atributo que representa a unidade da federação de expedição do
RG do usuário. DF, BA, RR. C Órgão expedidor do RG
x Atributo que representa o órgão que expediu o RG do usuário. SSP/DF C
e-mail x Atributo que representa um e-mail do usuário. teste@gmai l.com
A
RC02 – O sistema deve cadastrar o autor pelos seguintes atributos. RF02 / RFXX
Nome O S E Descrição Exemplo
Nome Autor x Atributo que representa o nome completo do autor Pedro Silva Motta. Unidade Federação
- UF
x x Atributo que representa a unidade da federação do autor
DF, BA, RJ, SP
Cidade x x Atributo que representa a cidade do autor São Paulo
Endereço x x Endereço do autor SQN 216 BL V APT 326
Bairro x x Bairro do autor Asa Norte
CEP x x CEP do endereço do autor 70000-000
Telefone residencial x Numero do telefone residencial do autor (61) 3034-8457 Telefone Celular x Numero do telefone celular do autor. (61) 9999-8877
e-mail x e-mail do autor teste@gmail.com
RC03 – O sistema deve cadastrar o livro pelos os seguintes atributos RF03 / RFXX
Nome O S E Descrição Exemplo
Título livro x x Atributo que representa o título do livro do autor. Qualidade de Software Autores
x x Atributo que representa os autores de um mesmo assunto.
Ivan Mecenas e Viviane Oliveira
Figura 3 – DER atualizado após a análise dos Requisitos complementares É importante ressaltar que, nesse primeiro momento, os relacionamentos, cardinalidades e os atributos identificados podem sofrer alterações, considerando o amadurecimento posterior dos requisitos.
A análise das regras de negócio permite uma ratificação ou retificação do entendimento, possibilitando também a inclusão ou alteração de entidades, relacionamentos e cardinalidades. Na tabela 3 apresentam-se algumas regras de negócio e, na Figura 4 demonstra-se como isso foi implementado no DER.
Identificação da regra de negócio Descrição da regra de negócio
Rng01 Quando o livro for cadastrado o sistema deve permitir cadastrar um ou mais autores
Rng08 Quando cadastrar o premio o sistema deve permitir relacionar premio ao autor Tabela 3 – Exemplo de algumas regras de negócio
Na figura 4 foi incluída a entidade prêmio para atender ao Requisito de negócio Rng08. Foi também confirmada a cardinalidade do relacionamento entre autor e livro, através do Requisito de negócio Rng01.
A análise dos requisitos não funcionais também é necessária para complementação do DER. Por exemplo, o Requisito não funcional “RNF_Q01 - O sistema deve garantir que a atualização de dados será feita de forma atômica e imediata, sempre com registro histórico” pode gerar a necessidade da inclusão de algumas outras entidades, de forma a preservar o histórico. O estudo do Quadro de permissões pode gerar modificações do DER. Dependendo do nível de permissões no sistema, talvez sejam necessárias inclusões de relacionamentos da entidade Usuário com outras entidades. Ou seja, a análise de todos os dados obtidos na DDR, permite uma modelagem de dados inicial de forma mais direcionada e eficiente.
É importante ressaltar, porém, que a modelagem de dados tem como objetivo planejar ou projetar a sua base de dados para suportar uma ou mais áreas de negócio e, por esse motivo, é essencial a participação do usuário nesse processo. Mas, conforme foi identificado, as informações contidas na DDR podem ajudar a iniciar esse processo, agregando mais agilidade e qualidade ao mesmo.
