Does this make sense . . . business or otherwise

[USZA]

I'm testing a certificate management GUI.

On testing the amend- and cancellation functions of the GUI, I discovered the following:

• A user can amend an expired certificate
• A user can cancel an expired certificate

I subsequently logged bug reports to query this because this just didn't make sense.

The BA closed these reports, saying that it's invalid because

• A user can amend an expired certificate by extending the expiry date to bring the certificate back in force
• The business requirements state that a certificate may be cancelled in any state

Coming from a technical background, my view on this is that:

There should be an explicit Reinstate function to bring a certificate back into force. Not only is this a more elegant way of implementing a Reinstate function but will it also eliminate erroneous input in that the date field is a free-text field and thus prone to erroneous input.

From a pure mathematical and computer science point-of-view, state-changes should be allowed only from certain states. I figured that it would probably cost additional development to restrict cancellation to only in-force states but at the end of the day, you end up with a more robust system.

 

[hellfire]

I hear what you are saying, but you will be running into a brick wall if you try fight 'requirements' based on logic.
Ensure that you keep a record of the requirements specs, a record of all communications regarding your questions on those specs, and then give them exactly what they are asking for.

 

[USZA]

I hear what you are saying, but you will be running into a brick wall if you try fight 'requirements' based on logic.
Ensure that you keep a record of the requirements specs, a record of all communications regarding your questions on those specs, and then give them exactly what they are asking for.

I put this out here to test my own understanding. Not fighting it since the BA's word is law where requirements are concerned, especially since he drew up requirements according to what he wanted the client to have - the client was too vague about what exactly they wanted. I'm qualifying the system against those exact requirements but there's gaps and the BA would have none of it about filling these gaps.

 

[guest2013-1]

I hear what you are saying, but you will be running into a brick wall if you try fight 'requirements' based on logic.
Ensure that you keep a record of the requirements specs, a record of all communications regarding your questions on those specs, and then give them exactly what they are asking for.

Let me fix that for you. "then give them exactly what they are asking for in the GUI"

Having said that, keep a "transaction log" of what changes are made to the certs, by which user, at which time and to what dates (if date is a free field, make it a varchar or whatever) in a table in the db

You can then throw this out as proof whenever they moan about a bug. Or that "your programming sucks". Then you can show them the communication between the BA and yourself and your concerns about the project.

BA's know ****all. All they care about is GUI.