Stupid software requirements - need your examples

From: Gints Plivna <gints.plivna_at_gmail.com>
Date: Thu, 17 Feb 2011 16:16:32 +0200
Message-ID: <AANLkTik2ON2WBjTbTGcX5fKspLXJbCfF82ipMhX-2pqi_at_mail.gmail.com>



Hello!

I'm quite sure most of you at least once have been in a situation when you HAD TO implement a requirement, which is stupid, results in slow performance and in principle cannot be optimized. And you either silently or loudly blamed the person who could imagine something like that :)

So (as I'm actually mostly system analyst) I'm seeking examples for a small presentation to highlight such cases for my colleagues to avoid them. I know quite many developers blame requirements gatherers and system analysts for these requirements and they are right, because such requirements should not be accepted or at least customer has to be informed about the consequences.

OK and now a few cases to encourage your imagination: 1) Paging through unlimited ordered search results. I've seen quite many cases when search form is abused to statistics report and after searching for something one gets records 1-20 out of 564653. 2) Various statistical information in an entry form that should be calculated on the fly. For example We have 8767769 questions, 32490 topics, 325489 users and 1233 active users. Who the hell care? 3) Searching for arbitrary substring, i.e. LIKE %whatever%. 4) Logging each transaction for a time-consuming process. For example a banking app should log every operation for the month closing process, which analyses each transaction for each client in the previous month.
5) Requirement to synchronize every single transaction with other systems. Also an example from banking world - bank app is calculating journal entries and synchronizing each one with card system.

If you don't want to tell them in public with your name, you can drop me a private e-mail and I will later publish summary without any names of course.

TIA Gints Plivna
http://www.gplivna.eu

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Feb 17 2011 - 08:16:32 CST

Original text of this message