8

We have to create a web application that will be used as an application form for multiple insurance products (15 in total). This application form will be similar to a form wizard, it will span across multiple pages, depending on what product between 4 and 10.

The grand total of all different elements (inputs, select boxes) that the form will be rendering is around 250, but even the most complex product will not use more than 170 of them. The least complex one still requires around 80 elements.

We do not want to create 15 different application forms, one per product, we want to have a single application form which will be used by all products.

Now as you can imagine, the elements have a lot of dependencies between them. A value entered in a field can make another field or set of field appear or disappear (on the current page or a following page(s)). Some other dependencies based on entered values:

  • value of an element is required or not
  • possible values for select boxes will be changed
  • the validation constraints will be changed

As you can imagine, modeling this is very complex. The question is, what tool would you recommend for modeling (and documenting) all these elements, the dependencies between them and the validation constraints? How would you do the modeling? Not talking about the data model at all in this case. This model will be part of the specifications of what needs to be done and as a reference after the completion of the project. By changing the model the application forms will not be automatically changed.

Some of the things we would like to be able to do easily:

  • see what elements a certain element depends on
  • see all elements included in the form for certain product
  • see required elements for a certain product
  • define validation rules for each element
  • define various attributes for each element

Limitation: our product managers and product owners are the ones who will do the modelling.

Marius Burz
  • 139
  • 6
  • Not sure what do you mean by "what" in "what would you recommend", but probably it would make sense to define some kind of ontology first to simplify matters for the modellers. Concrete cases will be driven by inference rules then. As a bonus, you will have meaningful groupings of input widgets. – Roman Susi Dec 19 '14 at 20:15
  • @RomanSusi thanks for pointing that out, just updated the question – Marius Burz Dec 19 '14 at 21:12
  • 1
    Ah, as I recently learned, tool recommendation is offtopic here, see Help Center http://programmers.stackexchange.com/help/on-topic . Also, noticed now, it is not clear from your question whether your system should allow editing products or is it done just once at requirements gathering stage. – Roman Susi Dec 20 '14 at 08:05
  • @RomanSusi it's only part of specifications and as a reference. I wouldn't say that it is only during the requirements gathering stage, with such complexity this will be used as a reference as well. Not really asking for the tool alone, more like how would you do it and what would you use in order to do it. – Marius Burz Dec 20 '14 at 09:55
  • Have you tried/studied LimeSurvey? Any other online surveying tool would work as well. Bonus points for you if you can simply use it directly rather than roll your own tool... –  Dec 20 '14 at 22:49

3 Answers3

1

For a similar complex project we implemented an interpreter in the business-layerer with formulas for "isValid" and "isVisible" for every form-element

For the interpreter we used UML-s Object Constraint Language which was once designed for that purpose.

Unfortunately nearly nobody speaks "uml-ocl" so finding somebody to maintain the rules is difficuilt.

If we had to do that again we would choose a more common language like js/vb-script for the interpreter

k3b
  • 7,488
  • 1
  • 18
  • 31
  • This is already part of implementation if I understand it correctly. I'm not saying that to use the code for documentation is wrong, most of the times it is the thing that really tells the story as it is, but to write the code you already need to have the specifications and have everything well documented. That is the context of the question. – Marius Burz Dec 22 '14 at 09:15
  • I would dispute the notion that you require everything documented and specified before you can write the code. This is exactly the kind of project that can be easily undertaken with an iterative approach, with the customer examining progress and feeding back changes on a regular basis. Describing what needs to be done when there's a partially implemented form in front of you is a lot easier than trying to determine what all the requirements will be in advance. – Jules Dec 23 '14 at 19:05
  • @jules: I totally agree, especially that non-trivial validaion/visibility-rules cannot be specified in advance. They have to be adopted over time. However a [Domain-specific_language](http://en.wikipedia.org/wiki/Domain-specific_language) for the definition of validaion/visibility can be specified and implemented in advance. The interpreter of Domain-specific_language can read and execute the human readable rules for validaion/visibility. There is no more need to update the code if spec changes. This spec should evolve over time – k3b Dec 25 '14 at 12:11
1

A combination of tools might help manage the complexity. I like to start with a stuctured yet descriptive approach (as distinct from a highly formalised approach) which is easy for humans to interact with. PM's should be comfortable with spreadsheets and it can be helpful to layout dependencies in tabular format.

  1. Eg a table for product x field dependencies.
  2. A second table might encapsulate the interactions between fields (field x field). The intersecting cells might initially contain descriptive text.

As a first pass this may expose issues with the logic and/or identify opportunities for simplifying the logic.

And while PMs might shy away from web programming directly, use a modern, expressive client side technology to build up the "language" of your application. Tools such as angular.js help encourage focus on what the components do and minimising noise code. The right web technology should also provide good test support.

psorenson
  • 111
  • 1
0

The question is, what tool would you recommend for modeling (and documenting) all these elements, the dependencies between them and the validation constraints? How would you do the modeling?

We had a similar project. Very complex forms, and a lot of them.

  • The original paper forms
    • Our goal was to make the web pages look exactly like them
  • Excel
    • Screen-form-element data specification
    • data element name (very important during coding) type, length, formatting, general rules
  • Enterprise Architect
    • Basic class design via UML.

Enterprise Architect (EA)

Here is a link.

Qualifier: it's been a few years since I last used it. A complex tool. Big learning curve. Very good UML knowledge required for precise results; there is metadata behind everything. Thus EA functionality is wide, deep, enigmatic, and sometimes quirky.

EA integrates its artifacts very well. But our teams' collective UML and EA tool knowledge was insufficient to make it a satisfactory end-to-end tool. Note that our goal was not to use it that way. Even so, better to not use (some aspects) of the tool than to use it badly.

Each developer used it to design classes for his/her assigned form (or section thereof). The business analyst used it to create use-case diagrams. Did not use it for requirements analysis because the paper forms, form data, and process were well established - and done before we adopted EA.

We never got to leverage this comprehensive tool that had the promise of integration from requirements analysis to actual code. Developers learned only enough to create the rudimentary class and sequence diagrams required for management go-code-approval. And it was apparent to me that even when I generated code-shell from the class diagrams it was too hard (that is, lack of detailed UML knowledge), too inconvenient, too tedious to keep EA in synch with code development. So as soon as we started coding the UML diagrams very quickly became obsolete and were ignored.

Good sequence diagrams are invaluable for understanding class interaction and object instantiation. A nice high-level map when coding.

Warning

Competent and (appropriately) complete business domain design is FAR more important than any tool. I get PTS just thinking about how universally &*$&# our code was except for the very rare time we did a good business model. I could write pages and pages.

radarbob
  • 5,808
  • 18
  • 31
  • As you said, this is a very powerful tool, we already have it actually. This is something the more experienced software developers can work with, but not something for our product managers / owner. I think actually it is quite uncommon to find PM/PO that could potentially work with it, as you said it yourself, the learning curve is quite generous. – Marius Burz Dec 23 '14 at 19:59