This must be in real-time
The system must support historisation
The system must support multitenancy
The system must provide reports for every screen.
Usually those sentences are just mentioned as side notes or in the small print, as if they go without saying anyway and are the most evident thing in the universe.
But usually they imply a huge communication gap, that can cost buckets of money and bring wagon loads of grief.
Do you know other requirements that fall into the same category?
Update: @asztupak on twitter
It should support all features the previous system had
Update: Comments on Hacker News
This product will use 80% of the platform, and have 30% new functionality. Defining in percentages is a surefire way to blow a project.
ReplyDeleteI specially like this one:
ReplyDelete"The system must support historisation"
I once worked on a system that had the marvelous idea to have most entities historisable (know that big state owned company with red logos?). We did it for a few months and removed most versioning capabilities afterwards. And it was not about budgetm but a matter maintainability. Just imagine how great it was to build consistent revision histories of object graphs...
@andre
ReplyDeleteI had the same experience, twice...
Historisation seems to be solvable quite neatly and easily with a generic technical solution. There even exist out-of-the box solutions (Hibernate Envers, Genome Historisation Support ...).
These solutions bear the danger that developers/stakeholders think the problem is solved, but in usually the problem must be really solved on a higher level else the solution just becomes unusable and over complicated...
The historisation thing doesn't have to be a problem. That's not to say an alarm bell shouldn't go off at a nonchalant mention of it - but - if it's recognised it's a large and complicated task, and the entirely automated solutions typically do not work beyond toy examples - it's still a slog, but you /can/ get it right, or at least adequate. It's just incredibly boring and finicky to deal with the inevitable wierd exceptions about not storing hashes, anonymising such and such a historical record when viewed on a tuesday by a man in a hat, etc.
ReplyDeleteThere is an excellent book on storing time-varying data in RDBMS:
http://www.cs.arizona.edu/people/rts/tdbbook.pdf
I heard that during my career as consultant/dev:
ReplyDelete"The system must be multilingual" (Think about encoding, left to right, right to left, up to down, down to up writing.)
"It should behave like Google" (Users are used to A++ products and want a same level of quality with a very limited budget/time and a team smaller than 1'000 of Phds developpers)
"The system has been maintained by genius (junior) developers, now we would like modifications." (=> Crappy code, spagetti, useless documentation, sum of as many architectures as they were developers, ...).
"We cannot help you, only the (main) developper had the knowledge." (Arrfff solo developers who write "shortcut code" only to deliver fast without maintenance or readability in mind)
(In a cascading dev. organisation) "The specification are not done. You will developp while we decide about what the application must do." (This works only in "mature" teams using the right tools and being used to TDD, continuous dev, etc.)
We need an UnDo function - and not just for a single action, but for multiple actions.
ReplyDeleteThe system must be able to import data in bulk from some "standard" format (as yet undefined).
Leave room on all buttons and labels to account for translations into other languages.
Must support non-arabic character sets.
508 compliance required (without defining what exactly this means in this case).
iPhone interface to the system.
Everything should be customizable by users e.g. form fields can be "user defined" and look and feel should be customizable by the user, who can even insert images and text. But we can't afford a proper content management system.
ReplyDelete@jonas
ReplyDelete@anonymous
Completely agree on this.
Eclipse cdo (the thingie I commit on) has this versionability in its core too (@anonymous: its used in pretty large apps far beyond toy examples). The solutions for the standard JEE world sound like they bring proven solutions too.
Things are implementable. But even with standard frameworks the work ahead is still very large. IMHO this is mostly due to 2 additional factors (that generic solutions cannot bring in - this matches your arguments):
1) versioned entites have to be dealt with in every other layer (from UI down to the service etc.). A lot of extra work.
2) the business mostly has even more specific criteria that matter on the timeline (ex. special states: 'to be committed', 'active', 'inactive' etc.) If you have these, getting a consistent timeline for graphs get even more complicated and tedious.
I have heard many such requirements as well
ReplyDelete1) system should have optimum performance
(no note on whats the criteria for optimum means.)
2) SHould be user friendly
(most generic statement I watch for)
3) If condition statements (in requirements) without else :)