Hi Joakim,

What you've written doesn't really conform to what a use case is for at least the following reasons:

1. Use cases are initiated by an actor that interacts with your system. Who is your actor? sounds like its the external system sending the file.

2. Use cases should be solution independent. Looks to me like you're in danger of using a use case to design your interface where there are possibly more solution oriented artefacts that might be more appropriate e.g. a sequence diagram.

There is certainly a use case there as you have a conversation going between the initiating actor, the system and what you call the "External partner" and "internal partner". Whether using a use case is the best approach or not is the question. Personally I don't think so. You need to capture the use case as a function that is performed in your system but the detailed design logic and mapping is best defined separately. I'm a BA, so I don't design. Others on the forum can advise on the best way to do it. I suspect that many will disagree with me too.

Kimbo

 Hi Joakim,

I was perhaps a bit harsh in my earlier post cause I was trying to make a point about solution independence. You're just missing a first line or two that specifies the trigger from the external system. The rest is just a question of a bit of a re-write but whatever. 

To answer your specific question

Q: Where would You put this documentation and how would You note it? Can I consider these 80 variants as business rules? Or shall it be placed as UseCase realizations? Or, shall it be noted in testdocumentation only?

I think you need a separate interface specification that will include things like:

1. Data mapping between the information coming in and where it will go to in your system. You also need to specify where the values for fields not coming from the external system in the resulting records are sourced from. e.g. they are defaulted or you look up a table in your system, etc.

2. Perhaps a data model of some kind - class diagram or ERD of your system so the reader can see the resulting data structures

3. The set of 80 rules as validation rules for the data load process

4. Rules for what happens when validation fails (one of the 80 validation rules fails) / error processing. Some may just write to an error log and proceed; some may cause the load to fail completely i.e. there may be classes of failure that have different consequences.

5. Your use case should show error processing that changes the conversation with the other systems (actors).

Plus probably some other things that I haven't thought of. Haven't written one of these for a few years.

I see requirements modelling as three levels - requirements (textual statements); process and functional requirements (I use use cases but dfd's work too); UI, reporting, interface specifications. I'm simplifying but what I'm trying to say is that the interface specification is the next detailed step after you have your use cases.

Kimbo