22
April

Solid database design for elawyering apps

by Matthew Pitts

If you've been following the development of ABIEE™, you know that I am in the client use development phase. Due to intellectual property concerns, I cannot disclose specific information relating to the design of the database. Generally speaking, the database design portion of an elawyering application should be given a tremendous amount of attention. Any elawyering application worth using is heavily databse dependent. The more features in play, the more complex the database will be. For ABIEE™, I am breaking down the database design process into two separate parts. One part is for the client/user portion of the application and one part is for the bankruptcy professional's portion of the application.

Data Integrity

The databse should be designed to ensure optimal data integrity and performance. Elawyering application databases are especially tricky because of the need to integrate document generation and processing requirements into the database.

Utility Database

One more complexity involved in an elawyering application's internal structure as it relates to database design, is the need for a "utility database" section. This is the term I use to refer to attributes that will not necessarily be a part of the central database. Some examples are profile information, account information, some personalization information, etc.

23
March

ABIEE™ - Client Registration Use Case - Entry 4

by Matthew Pitts

What follows is the client registration use case for the ABIEE™ (Alliance of Bankruptcy Information and Expert Exchange). If you were following the previous related post, you will see that the client registration use case specifically builds upon the global client use case. Before the client can access any major features of the application, he/she must register an account. Although it is possible to allow anonymous browsing and functionality, up front registration makes the most sense.

The Registration Process Overview

Basically, a client will complete a brief and painless registration form. When they click submit, pertinent data will be entered into a database table. Next, the client and the site administrator will receive notification of the event.

Developer's Perspective

The programming portion of the registration use case is fairly straight forward. Once the client enters information on the form and clicks submit, logic will be written to add that information to a database table. Additional code will be written to confirm the registration with the client. Finally, code will be written to notify the site administrator that a new user has in fact registered an account.

Designer's Perspective

The eventual graphic design of this input form will reflect the overall look and feel of the application (the graphic design will come much later in the process). The focus should be on modern design techniques with an emphasis on usability.

Marketing Perspective

At this point, it is important to realize that the client has an open mind and may be interested in additional services/offers. One thing that I will add here is an opportunity to opt-in to marketing  communications such as newsletters and special offers. One more marketing feature that I will add here is an opt-in for a printed information packet of some kind.

Conclusion

Once the client is registered we will have non personally-identifying identity parameters to use for future programming, design, and marketing implementations.

Client_Reg_UseCase.pdf (143.40 kb)

 

 

18
March

Building ABIEE™ - Global Client Use Case - Entry 3

by Matthew Pitts

Today's post builds on the last post regarding the software requirement specs for ABIEE™. In the last post, I outlined a list of the features that would be available for the clients/consumer side of ABIEE™. Next, I want to present you with a visual aide which generically shows the process that a typical client/consumer user ABIEE™ would follow. Keep in mind that I may shift some of the specifics around as development and design of the elawyering application progresses. The image as well as a downloadable .pdf is included with the post.

Client Global Use Case.pdf (133.78 kb)

14
March

ABIEE™ - SRS for the Client/Consumer - Entry 2

by Matthew Pitts

This is part 2 of series on building the elawyering application ABIEE™. You can find all related entries by selecting "ABIEE" in the category list.

Portion 1: The Software Requirement Specification for client/consumer users of ABIEE™

In entry 1, I roughly outlined most of the features that I envisioned ABIEE™ containing. I also mentioned the size and complexity of the task at hand. Finally, I noted the fact that I would break the development and design process down into manageable chunks. I decided to start the development/design process by outlining the Software Requirement Specifications (SRS) for the client/consumer portion of ABIEE™. You can see a preliminary list of the features for the client in entry 1. The following list is more refined and should be considered the official SRS for the client/consumer portion of ABIEE™. of course this list is also subject to change as the elawyering application development/design process progresses.

Official Software Requirement Specification for the Clients/Consumer Portion of ABIEE™

Pre-Filing Stage

 

  1. Unregistered clients can browse library of resources (RL  SRS Pending)
  2. Clients must register and login for additional features
  3. Clients can organize case related documents that the BKP will need for document generation (BKP SRS Pending). Case related documents include scanned (.pdf or .xps) versions of documents such as bills, tax returns, etc.
  4. clients can view the documents they have uploaded
  5. Clients can send documents to BKP when necessary (BKP SRS Pending)
  6. Clients can build a personal library of resources and use standard methods to manage their library such as add, delete, and sort (RL SRS Pending)
  7. Clients can follow a process checklist which will guide them through the appropriate processes to completion of BK case (intermittently updated as development progresses)
  8. Clients can browse information about BKP such as BKP supplied BIO, experience, etc. on public BKP list)(BKP SRS Pending)
  9. Clients can inquiry/message BKP they are interested in hiring (BKP SRS Pending)
  10. Clients can hire a BKP and complete retainer agreement/service agreement (BKP SRS Pending)
  11. Clients can submit payment to BKP (BKP SRS Pending)
  12. Clients must submit case review/means test to hired BKP (BKP SRS Pending)
  13. Clients can receive case review/means test result from BKP ((BKP SRS Pending)
  14. Clients can receive completed document copies from BKP(BKP SRS Pending)
  15. Clients can inquiry/message BKP they have hired (BKP SRS Pending)
  16. Clients can create reviews for BKPs they have hired (BKP SRS Pending)
  17. Clients can complete questionnaires for later use in document generation.

 

Post-Filing Stage

 

  1. Clients can have case-level calendars updated by BKP (BKP SRS Pending)
  2. Clients can receive standard built-in information about upcoming hearings

 

Note: BKP = Bankruptcy Professional -- RL = Resource Library

 

Published in De Novo

Be sure to read my article in the December 2009 edition of the Washington Young Lawyer's Division publication De Novo. You can read it here.

Sponsors

Thanks for Reading

Matthew A.Pitts

About Matthew A. Pitts

 I am a freelance paralegal in Washington State. I have experience in multiple areas of law in both the private and the public sector. Legal Web Development and Marketing

For the past 7 years I have focused on legal marketing and legal web design and development. I have professional level web programming and design skills.

About this Blog

 The legal service delivery landscape is changing rapidly. Despite the number of options available for legal professionals to establish a web presence and begin to engage in some type of "e-lawyering", there are core fundamentals required for success. In this blog I intend to thoroughly cover these fundamentals. Please subscribe today.

Blog Information

Published by Matthew A. Pitts.
Design by Matthew A. Pitts for Internet Paralegal Innovations™.
Powered by BlogEngine.NET   Icons by Dry Icons
© 2010 All Rights Reserved.