The IBM piece is exactly the kind of stuff I’m looking for
Ummmmmmm. I have just spent nine months working on my MSc Dissertation. The project was about testing the hypothesis that ORM is at least 25% more effective than other approaches such as UML & ER.
My conclusion from that project (and of many years of working with ORM) is not to waste your time with the approach recommended on the IBM website.
I found several research studies that show that if you must use UML, then its best to start by creating "Data only Class models" without bothering with the Use Case stuff.
Now "Data only Class models" are remarkably similar to ER models.
And the best way to create an ER model is by generating it from an object-role model. (by using an ORM Tool).
So once you get your head around ORM, then you can generate and update ER models to your hearts content - with very little extra effort.
Now I think my case might be somewhat exceptional here, since my current focus is less on ORM’s contribution to improving the code or software, and more to the benefits that might be derived for ORM from a project management angle
Welcome to the world of the enlightened few!
That's where I started (many years ago 
)
If you look in the ORM2005 section of the library you will see the "Requirements Engineering with ORM" presentation that I gave in Cyprus.
Your case is "exceptional" only in the sense that not many folks seem to see the connection.
Clarifying – defining the logical structure
ORM enables semantic precision because ORM uses "verbalization" techniques to express ORM diagrams in easy-to-understand sentences. This makes it easy for a non-technical domain expert to understand the precise meaning of an object-role model.
If you look at the following diagram, it gives an example of how to use the "Uniqueness constraint" and the "Mandatory role constraint" to precisely define the fact "Student writes Dissertation".
A uniqueness constraint is represented by a line that spans one or more roles. The line signifies that there may not be any duplicate values in the column(s) that are spanned by the uniqueness constraint line. Thus, in the left hand column of the first row, the line over the left hand role means that the value of Student (.id) may not be duplicated in any of the instances of this fact type. The right hand column shows the verbalized fact. We can immediately see that the sentence "It is possible that more than one Student writes the same Dissertation" is against the University rules so this constraint structure is not correct.
In the second row, we have added a uniqueness constraint over the right hand role. This means that there may not be more than one instance of each Dissertation in the column. However, the verbalization "Each Student writes at most one Dissertation" shows that this fact does not meet University requirements because the term "at most one" allows for a student not to write a Dissertation at all!
In the third row, the dot on the left hand role signifies a "mandatory role constraint". This means that every instance of "Student" must play a role in this fact. By combining the two uniqueness constraints with a mandatory constraint, we get the following verbalization that exactly meets the University requirements:
Each Student writes exactly one Dissertation.
For each Dissertation, at most one Student writes that Dissertation.
ORM is unique in providing an easy to understand conceptual information model that is at the same time, a formal description of the application domain.
