The trouble of finished software

added by rufflelesl
11/21/2011 9:04:35 AM

6 Kicks, 265 Views

I think that there is a very important question, and that is the question of what constitutes a finished software. Well, that might seem easy. It should just work as specified.


11/21/2011 9:06:01 AM
I agree with avoiding terms like "finished". We usually call it acceptance testing, and we go through formal design process with our clients which involves us mocking up UI and describing the functionality of screens, processes, and reports. That design document is then made part of the contract. We have also considered writing BDD style language (gherkin syntax) in our design documents so that the agreed upon design can be directly tested against.

11/21/2011 9:21:57 AM
Specifying requirements is more about communicating and understanding. Usually, business, IT, suppliers, partners do not meet eye to eye on requirements. There are always gaps in implementing the requirements because of the underlying flaws of the software that is being integrated. Completeness to me means both verifying the software against the requirements and validating if the requirements are right.

11/21/2011 9:15:03 PM
Indeed. Software is never finished; it just meets some (vaguely acceptable) criteria.