How to express CRUD permissions within UML?

[Certainty]

Hi,

I'm struggling to express user permissions within my models in a way that feels right and I'm hoping that you UML Sages out there could help shed some light onto this with me ...

I have a fairly complex web application and I'm trying to convey to our developers how different users will be able to interact with the application. Taking the admin system, for example, we have tiered user levels through which user have different page visibilities (some users can see some pages and not others) and within certain pages, component parts can be edited by some users and not others.

If I was to draw a matrix of pages and users, say in Excel, and then add the CRUD symbols to each cell as applicable (Create, Review, Update and Delete), then I get close. However, there are contexts within which this would not be enough - such as session continuation vs new session and module visibility.

I think I'm trying to attach security requirements to specific page usage, which then feels like I should be drawing out use cases. But this seems excessive, especially if I've got a large number of page and actor permutations (e.g. 10 pages x 10 actors = 100 use cases). Yet, use cases would give me the granularity I need.

Should I just knuckle down and get the use cases written, or is there another way? And if I'm writing the use cases, what should the context be?

Thanks in advance.

[Krzysztof Swiatkowski]

I have a strange feeling you are trying to mix application design (tabs) with application requirements (use cases).
It is hard to give very generic answer
Are your actors based on roles or on security access? Several authors advise against mixing that. You may get in trouble if you will have to assign access rights within the same role (e.g. sales person see only their own leads and leads they have been assigned too).
If you are writing use cases in EA you could describe what is seen and what not and under what conditions in Constraints section of a use case.
As for tabs, if they describe some types of information maybe it would be better to address type of information visible instead of tabs (eg. Address data instead of Address Tab)
The discussion about how deep use case should go is as old as use cases them self but I think requirement should not make unnecessary assumptions about structure of the user interface.
Unless of course gui is the requirement itself .

Regards
Kris

[Certainty]

Thanks for taking the time to reply, Kris.

You're right, I have got confused. I'm trying to detail some understanding from a design and, therefore, retro-fit some analysis to support extensive designs (web page wireframes) that we have been given. At the outset of the project, this seemed like an expedient solution, especially since the designer was already underway and we were drafted in to build against the designs. However, the need has arisen to share our understanding with a development partner organisation who hasn't been party to much of the 'enlightenment' that has ocurred during the project lifespan this far.

I'd be interested in reading in supporting explanations as to why not to mix security with roles, since to me at least, they appear synonmous. But I'm open to correction, or at least, enlightenment ...

Thanks for the Constraints clarification.

And as I've illustrated above, the GUI (wireframes) is being regarded as the requirement, so perhaps my approach is flawed?

Hmmm...

[BioformLivesAgain]

I am currently re-engineering the requirements, domain model, and use cases for a financial system that integrates functionality from two legacy systems (NY.. and NA..)

Remember, that the wireframes are a SOLUTION to the set of REQUIREMENTS you are trying to specify.

My approach is to basically create business domain model and the use case catalog (do some business level analysis to understand WHAY the solution solves.)

Then generalize out from the solution WHAT the business features of the system are, research and determine what the business rules are (HARD PART, as the rules can be implemented as constraints on the domain model, UI features, and of course CODE).

Trace the Business Features s and the Business Rules to the UCs, Document the flows, and then abstract out the high level functional requirements (what has to be accomplished), then specify the low level and UI abstracted requirements (e.g., what features the UI has to provide to support the HLFRs), rinse and repeat.

Hope that helps a little. Re-engineering requirements for a system is ALWAYS a battle to specify the requirements in enough detail that they are specific to describe what needs to be built (existing solution) but do NOT contain design choices specfied as requirements.

Example: Instead of saying something about the UI providing check boxes for selecting records, generalize it into something like...

UI will provide the capability for the user to indicate rows selected for printing....