News for hackers. Stuff that matters.
Re:Dear Client, Here’s Why That Change Took So Long by SkyBelow on Tuesday May 07, 2019 @04:16PM (#19853049)
For me, it was more "These things you call NFRs, I do not understand the purpose of them, especially given how they are decided."

Requirements like "The system must be secure.", "The system must not go down.", or "The system must not have performance issues."

I'm lost as to what the purpose of such statements are as they don't let me know where real focus needs to be given. Not every system is mission critical and deserves equal resources devoted to ensure uptime.

Re:Dear Client, Here’s Why That Change Took So Long by DougWebb on Tuesday May 07, 2019 @04:25PM (#19853125)
As developers, the most useless bug reports we get are "It's broken". The NFRs you describe sound like "The system must not be broken", which probably makes a lot of sense to someone who's likely to submit a useless bug report.
Re:Dear Client, Here’s Why That Change Took So Long by pjmlp on Tuesday May 07, 2019 @05:00PM (#19853407)
The purpose of those statements are to uphold contracts and compensation clauses when things go wrong and end up in court due to refuse of payment for delivering broken software (which might be debatable if that was indeed the case).
Re:Dear Client, Here’s Why That Change Took So Long by SkyBelow on Wednesday May 08, 2019 @09:28AM (#19858604)
See, that would make sense if it was something like 'our system must have 99.9% uptime'. But to say it cannot have any downtime, at the same time as our releases requiring us to take it down during the release, and at the same time the business contracts allowing for downtime for releases, means that the NFRs do not have any realistic requirements and are thus useless.

It's like saying mobile devices must be supported. Does that mean only top of the line recent releases? Does that mean 8 year old smartphones? Does that mean the internet browser on the Nintendo DS?