Shane's Comments for Eric

[Shane.Durham@lexisnexis.com]

I have given some feedback to Eric regarding the approach to the use cases, and some comments on the content.  I want to summarize my suggestions here and get any feedback you guys care to offer.

 

Of course, we have the comments from last Tuesday's conference call to incorporate. 

 

These include:

- less component-oriented language

 

- clarification of 'method of payment' so that it is understood the filing review clerk decides that the filings fees will be, or have been, paid, in some manner acceptable to the court.

 

- clarification that interactions with the "court record" (or any component) might occur during the Filing Assembly process and FilingReview process, in order to review the court record and to pre-populate or validate a filing's data. 

 

 

Eric and I chatted this morning, and here are some directions I gave him:

 

1. In general, strike the use of 'This-n-That Component' in our user-oriented use cases.  Instead, refer to the users' interaction with the 'System'.    I think the results will be a better story.

 

2. Rather than creating component-oriented use cases, we should document the component interactions with UML 'collaboration diagrams' and/or, my favorite, 'sequence diagrams'.  The UML diagrams will provide a better picture of how the underlying parts-and-pieces are intended (by LegalXML) to fit together. (and, of course, how these parts fit together can be the subject of much debate.  So be it.  Still, UML will be a structured way to express our opinions and proposals)

 

Here, I might have stepped on toes or overstepped my bounds.  My apologies if I have.  Still, my suggestion stands and I would like to hear if anyone disagrees.

 

 

3. Where a user's actions with the System is likely/capable of being facilitated by specific component interactions, the user-oriented use cases will make a reference to the documentation of the component interaction.  So, for example, if the use cases states "Filer Transmits Filing to Court'...then the use cases should have a reference to documentation concerning HOW the 'Filing Review Component' and its 'ReceiveFiling' (aka SubmitFiling, ReviewFiling, DoMyFiling) interface are intended to operate 

 

4.The functional definition of what data needs to be transmitted, managed, or transformed during a user's process should be defined in the user-oriented use cases.  In contrast, the component documentation will concern itself with the technical representation of the data and actions.  For example:

Our 'submit a filing' use case, should document what SPECIFIC functional data needs to be transmitted to the court. 

 

For us to say 'filer transmits filing' and then hope that the DOJ's schema documentation has defined 'filing' well enough for us, is not going to cut the mustard  Why? The DOJ filing is probably overkill in most places, and underkill in others.  We'll never know what we should use, or can't use, until we clearly list our functional requirements for our LegalXML data-things.

 

The use cases need to say that the filing, with respect to THIS process, specifically includes 'timestamp-this, and person-that, and lists-of-these-and-those-things'.

 

Then, the component documentation can define how to technically express those functional things that have been listed in the use cases. 

 

That's the gist of the directions I have given Eric for the next draft of the use cases.

If you have serious disagreements with what I have suggested, speak them soon - Eric is working on this stuff right away (as we speak).  But, also keep in mind, it's JUST another draft, and there will be time for further comment after it is posted. (i.e. you might want to see what it looks like before you poo-poo it?)

 

- Shane

Lexis Nexis