UML: Building an SRS Class Diagram: Too complicated?

Question

I'm taking a UML class at my school, and my teacher wants us to do the basic, bare-minimum of the assignment, and will not answer any questions. That being said, the requirements of the system had use-cases of Registration, Student Record, Log-In, Course Record, and Class Record. All it really needs to do is the following:

• A student will log into the system and the only thing they can do is register. In the register page, it would list courses available, a student would select one or many and then they would list the classes available for each course. The student's records have to be checked to verify that they meet the prerequisites.
• A registrar can log into the system and they can not only register a student but also view and modify course records, class records, and student records.
• Also, the classes can be either online or on-site and I'm wondering if that should be defined...
• I can provide more detail if it's needed to understand.

Well, I think I took it too far, and I supposed I wanted opinions on how to go about determining the basic requirements.

I also have a couple questions:

1. Is a Log-In object required in an SRS? Or should it simply be assumed that the users have logged in?
2. Regarding cardinality and multiplicity, is it the same concept?
3. Looking at what I've made my multiplicities, did I make any remarkably obvious errors?

As far as making it less complex, would it make sense to only have: class-type, course, class, registration, student, and registrar?

Answer 1

A systems requirements specification is by far more complex than a simple diagram. There are many ways to accomplish a SRS, so your question is a candidate for being flagged off-topic as being too broad. Anyhow, here is what I did.

In a first step you need to group the requirements themselves. The first broad division is by separating functional and non-functional requirements. Non-functional are those requirements which can not be pinned to a single function. Eg. performance, legal, safety, security, you name it. Those are the categories you build first and eventually you have a set of them in the course of the SRS creation.

Grouping the functional requirements is a bit more tricky. You do that by synthesizing use cases. Each functional requirement needs to be realized by a single use case. You don't need to put in details for the use cases, but only a rough story. But once you have connected all functional requirements to use cases your SRS will be ready.

Note that the non-functional requirements are not yet related. This is because they have impact on a lot of functions and the system design in later phases. It's only necessary to have them clearly structured.

Another thing to note is, that requirements themselves should be traceable to their origin. That means you need a reference to the paper, meeting, phone call, personal talk, etc. from where you got it.

There are many, many details which make creation and maintenance of a SRS a science of it's own, but the above is your staring point.

A class diagram is not necessarily part of a SRS. It's part of a later design specification.

Now for your additional questions.

1. Log-in is no business object in no case. It is a constraint derived from a requirement "user must be logged in to..."
2. see cardinality vs multiplicity
3. I would simply leave away the .. notation. If left away it means just the same (unspecified). I'd remove the 'Log-in' word from credential manager since it will also handle log-out and much more. So the emphasis is not right. Else the class design is, as said, not really part of a SRS.