Multiple Requirements Catalogs

[Former Member]

Hi,

Per Michael Fan's suggestion in:

I have been exploring the idea of associating requirements catalogs with programs of study. Generally speaking, it seems to be quite elegant and natural with regards to SLCM's audit capabilities.

However, in our existing paper-based process, the structure of our undergraduate programs is somewhat messy in the sense that undergraduates can have different yearly versions of the catalogs for each major or minor that they sign, plus another different yearly version of the catalog for their overall degree and general education requirements.

Furthermore, in our undergraduate programs catalog, programs of study are named after the various degree programs (B.S., B.A., etc...), and majors and minors (academic specializations) in those degree programs are attached as module groups to their corresponding programs of study. So, unlike some universities, we do not have distinct programs of study for each major (like B.S. in Computer Science, B.S. in Physics, B.A. in Philosophy, etc...).

This seems to imply that we need to derive requirements catalogs from the academic specializations associated with a student's study object (CS - 516 - CG), and not just the program of study (CS - 514 - SC) associated with that study object. If we are to emulate the existing paper process to any reasonable extent, then it seems that we would also need to generate requirements profiles from multiple requirements catalogs (derived as stated above), and I am still not quite sure whether the SLCM audit system was designed to accommodate this.

Any thoughts on whether we should be considering a restructure of our undergraduate format (a potential bureaucratic nightmare), or whether SAP can be made to work well with the notion of more than one requirements catalog (or more than one version of a requirements catalog) contributing to a requirements profile?

Thank you,

Eric

[former_member195888]

Hi Eric,

yes, the audit functionality in SLCM is designed to accomodate this - I'm glad that you need it as it was a lengthly internal discussion whether we would have to support it ;).

The way you achieve that is by assigning different requirement catalogs with different versions to the student. E. g. you can assign the requirement catalog "B. A. program requirements" with version 2005 (defining general B. A. requirements and the requirement pattern) and in addition a requirement catalog "Major Biology Requirements" with version 2006 plus "Minor Requirements" with version 2007. The system can then derive the rule containers according to the defined selections and pick the respective subrequirements according to the defined versions.

One thing you would need to spent some thoughts to is, how the catalog versions are going to be assigned to the student. You can maintain them manually in the student file, but most likely you may have some algorithm to default version for particular students.

Best regards

Joachim

[Former Member]

Hi Joachim,

Thanks for the answer. I'm glad that our pathological case is able to help justify your software design decisions....

We actually have thought some about automatically assigning requirements catalogs to the students, because we began our investigation of the audit functionality by attaching catalogs to students. For existing students, who have already signed majors, I don't think we can be deterministic about their catalog version assignments, since they were free to choose any program of study or major/minor catalog year within a certain window. For new students, we agreed that we might be able to make an automatic assignment.

One thing that still bothers me is this idea of "main catalogs". The help provided by the system only tells how they are used, but not what the rationale behind them is, or what the effect of having more than one is. I assume that we need to mark every catalog, which we wish to include in a requirements profile, as a "main catalog", but do I assume correctly? Or, what is the effect of having a catalog that is not a main catalog?

Thanks.

Eric

[former_member195888]

Hi Eric,

There is one main catalog. The requirement pattern assigned to the main requirement catalog (version) is used as the basis for the requirement profile. Other catalogs are used for the derivation of the appropriate subrequirements.

Example: Main Catalog "Program Catalog", Version 2005 defines the requirement pattern

Program Requirements (derivation from the SC)

Major Requirements (derivation from the selected CG type Major)

Minor Requirements (derivation from the selected CG type Minor)

The Program Requirements are from the Program Catalog Version 2005 e. g. 60 credits total and gpa of at least 2.0.

For the Major Requirements the student is assigned to the catalog version "Major Requirement Catalog" Version 2006 - thus the rules valid in that catalog assigned to the students CG are used.

The Program catalog as main catalog thus does both - define the basic pattern AND provides rules for the program. The major and minor catalogs only supply rules.

Best regards

Joachim

[Former Member]

Thanks for the information, Joachim. The scheme that you suggested works well - almost.

There is now a small detail that is bothering me. If multiple academic specializations are attached to the same study object (i.e., a student has multiple majors in the same program of study), then I notice that the requirement for only one of the specializations determines the catalog at that point in the requirements pattern. The subrequirements of the other specializations get pulled in under the requirement for the one specialization that was chosen by the system.

Is there any way to ensure that the distinct catalog for each major is referenced when the requirements profile is generated, and that the subrequirements are placed under their proper requirements?

Thanks,

Eric

P.S. Based on what I have seen from HRIQ_RFC_AUDPROFILE_GET and HRIQ_RFC_AUDITRUN_GET, I wonder if the underlying data structures can even accommodate the necessary information to disambiguate between multiple catalogs at the same point in a requirements profile....

[former_member195888]

Hi Eric,

A key question is of course how catalogs are used and structured. For example if you set up an own catalog per subject area (e. g. Biology) or even per specialization (e. g. Biology Major for B. S.) you can fairly easily manage multiple majors with different versions.

Another consideration should be done with the requirement pattern. Of course it somehow need to match with the structure imposed by the multiple specialization and provide potentially own nodes for each. Using appropriate selections (e. g. one to select subrequirement rules from the 1st major, and another one for the 2nd major) then allows to derive those subrequirement rules belonging to the respective specialization.

Generally the pattern should be the superset of the possible requirements. SLCM will not show those parts where you can't derive any subrequirements. Thus if you allow two majors or one major and two minors, the pattern may contain two major requirement nodes and two minor requirement nodes. However for the specific students only those parts are used which are relevant according to the selected specializations.

The selection you assign for the subrequirement derivation needs of course always to be appropriate, but you have really a lot of options how to derive them and select them by a multitude of attributes.

I hope that helps. It is not easy to explain at all ...

Regards

Joachim

[Former Member]

Hi Joachim,

I am somewhat concerned that we may be talking about two different things, or that you are saying something deeper than I realize. So, let me give you some more detail about what I am trying to do, and what I have tried so far.

I understand what you told me earlier about being able to merge multiple catalogs into a requirements profile at various nodes in a requirements pattern. This works for me. As an example, I have a test student, who has a SC, "Bachelor of Science, Plan B1" and an academic specialization, "Broadcast & Cinematic Arts". The SC and the CG have different catalogs, and I have a requirements pattern that looks like:

ReqPattern Item RefItem Requirement

=============================

Test1 1 Overall Result

Test1 2 1 Degree Program

Test1 3 1 Major

I have attached the SC catalog to the student as a main catalog, and the CG catalog as an additional catalog. Everything works fine. The SC catalog is used for the "Degree Program" requirement and the CG catalog is used for the "Major" requirement.

So far, so good. Now, I add a second major, "Computer Technology", to the student. This major has its own catalog, which is different than the "Broadcast & Cinematic Arts" catalog. Now after I build the requirements profile, HRIQ_RFC_AUDPROFILE_GET basically shows me the following when displaying ET_SUBREQUIREMENTS:

Node Seq Subreq_I Subr Subreq_Txt

===============================

0002 001 0...06 Sub1 dt-BS-A1-3CRH

0003 001 0...08 Sub1 dt-MJ-BCA-3CRH

0003 002 0...09 Sub1 dt-MJ-COMPTEC-3CRH

And, displaying ET_REQ_PATTERN, I see something like:

Node Elem Ref_ Element_Txt RLCatT RLCatVersT

=====================================================

0001 0001 0000 Overall Re...

0002 0101 0001 Degree Pr... Test-Degree-BS-A1 2007-2008 Fall

0003 0201 0001 Major Test-Major-COMPTEC 2007-2008 Fall

In the above, I note that there is no "Test-Major-BCA", probably because there is no way to disambiguate it from "Test-Major-COMPTEC" - at least no way with the above requirement pattern.

After seeing that, I considered the possibility of making the catalogs for the majors be the main catalogs, and making the program of study catalog be the additional catalog. I still may end up adopting this strategy. However, this is somewhat undesirable since it is more like performing major/minor audits rather than a degree audit. I think it might be confusing to the users.

Today, I tried what you suggested in your most recent reply, and added the following to my requirement pattern:

ReqPattern Item RefItem Requirement

=============================

Test1 4 1 Major

However, this only made the problem worse, because now I get the subrequirements for both "Broadcast & Cinematic Arts" and "Computer Tech" under both nodes 3 and 4. I tried using both an evaluation path (CS - A516 - CG) and requirement selection, "SCG0", and they both produced the double result.

So, I am guessing that by "appropriate selections", you mean that we would have to custom develop ones that would be smart enough to only assign the set of subrequirement rules from one academic specialization (instead of all of them) to a particular specialization node in the pattern. Is this correct, or am I misunderstanding your suggestion?

Thanks again,

Eric

[former_member195888]

Hi Eric,

if the requirement selection is the same for two requirements, the same subrequirements will of course appear. Also if the requirement selection does not differentiate by the type of specialization or by the priority (1st/ 2nd major) again the same rules will be found.

The selection SCG0 gets indeed subrequirements for ALL specializations.

You can indeed implement an own selection (copy HRPIQ00REQSEL to a Z... code for the BADI and add a "DELETE lt_spec where ..." statement after the specialization read function). However I think we added some selection which could be used as well where the parameters are specified in the requirement definition (the table contains CG category and priority). I will let Michael now that he gives you some more details about that.

Regards

Joachim

Message was edited by:

Joachim Plumbaum

[Former Member]

OK, Joachim, thank you for enduring this grueling discussion with me.

Yes, I guessed that "SCG0" wasn't going to be much help, since, as you say, it is documented as selecting subreqs for all specializations. But I had some faint hope that it might be smart enough to allocate one set of subrequirements per identical node in the pattern. (I should have read the code first.) Seeing that it isn't smart enough to do that, I look forward to what information Michael can provide me.

I also think that you may be providing an incentive to upgrade. In 4.72, I do not see fields for either priority or CG category in the requirements definition....

Thanks for all your help.

Best regards,

Eric

Message was edited by:

Eric McDonald

[Former Member · Accepted solution]

Hi,

On page 76 (page 1 of part 2) of the SLCM Audit Handbook, it is mentioned that the "Specialization", "Module Group Category", and "Priority" fields are relevant for requirement profile templates. Does this mean that the standard set of selections available in SLCM 6.0 will not account for these fields if one is generating requirement profiles from requirement patterns rather than from templates?

Thank you,

Eric

[former_member583013]

Eric,

'Priority' is also an available field for the dynamic profile generation. When you define the Abstract Requirement, and you flag is as 'Specialization'-relvant, you then also add the CG Category (such as Major), and the Priority.

So, you can have one Requirement for 'Primary Major' where the Priority is set to 1, and another 'Secondary Major' where the Priority is set to 2. Then, of course, when you assign the majors to the students, you must also assign them with the right Priority!

Michael

[Former Member]

Thanks for the clarification, Michael.

I think this may prove to be unworkable for us, since we really don't have the concept of primary or secondary majors. Any major (or minor) can be assigned as a specialization on a relevant program of study in any order. For example, on a "Bachelor of Science" SC, I could (and, in fact, did) have the following specializations (sorted by priority):

1. Computer Science

2. Physics

3. Mathematics

but a friend could have:

1. Mathematics

2. Philosophy

3. Computer Science

The only way I currently see out of this mess is to create requirement patterns which have one distinct abstract requirement per concrete requirement. So, instead of an undergraduate pattern with "Degree", "Major 1", "Major 2", etc..., we will have one with "Degree", "Accounting Major", "Art Major", ..., "Zoology Major" (a very large pattern). I understand that this an egregious abuse of the whole concept of requirement patterns and abstract requirements, but I think this is the corner I have been painted into. Of course, even this is not really viable without the storage prevention flag in 6.3....

If anyone has a better idea, I am certainly open to suggestions.

Thanks,

Eric

[former_member583013]

Eric,

Actually, I think this approach still works for you. Let me clarify:

The Abstract Requirements of 'Major 1', 'Major 2', and 'Major 3' would all be identical, except for the different Priority settings. They are just created so that you can separate the sub-requirements from the different majors assigned to the students. It does not matter which major is assigned to Priority 1, 2, or 3. It just matters that when you assign each major, the user doesn't assign a duplicate priority to the same student.

Michael

[Former Member]

OK, Michael. I understand your theory of operation.

I guess that implicit to this discussion is the need to create 4 - 509 relationships (if we allow up to 4 majors per CS, which we currently do) between each relevant CG and the RC for its requirement. Each relationship will be identical except for the "Requirement" field in the additional data section of the infotype records. If the abstract requirements are 201 - "Major 1", 202 - "Major 2", etc..., then we would need to create 4 relationship infotype records for the RC, and vary each one by putting in 201, 202, 203, or 204 for the corresponding abstract requirement. Is this correct or am I still missing something?

Thanks,

Eric

[former_member583013]

Eric,

Actually, I am not suggesting something quite as cumbersome as you describe. There is no need to create multiple relationships between the Rule Containers and the Module Groups. You just need one relationship. In that relationship, you can leave the 'Requirement' field blank. During your selection of the sub-requirements for each Abstract Requirement, you would check the Priority for a match.

The system does not automatically select only RCs that are related with a specific Requirement value. That is something you might just choose to do in your selection definition.

Michael

[Former Member]

Excellent, Michael. Thank you.

Ten forum points headed your way,

Eric

[Former Member]

Hi,

On 20 November last year, Joachim wrote in this thread, "However I think we added some selection which could be used as well where the parameters are specified in the requirement definition (the table contains CG category and priority). I will let Michael now that he gives you some more details about that." However, I see that in one of Michael's more recent replies in this thread that phrases like "your selection" and "your selection definition" were used.

Now that I have finally been able to test SLCM 6.0, I can find no new requirement selections that will help with the problem we have been discussing. So, my question (hopefully the last on this topic) is now: is the customer expected to implement the necessary requirement selection or does 6.3 ship with it?

Thank you,

Eric

[former_member583013]

Eric,

Yes, I am afraid you will indeed have to write your own selection Badi for this requirement. Let me know if you need any pointers on that. One simple way would be to incorporate the Priority into the Filter Value.

Michael

[Former Member]

OK, Michael. Thank you for the straightforward answer.

Eric

[former_member583013]

Eric,

You can find everything you need in detail to implement this in the following 'sticky' post:

Michael

Edited by: Michael Fan on Jan 31, 2008 12:21 PM