If it’s not bad development, is it bad requirements gathering?
By Clinton Jones on Mar 2, 2011
How often haven’t we looked at a piece of software and considered that piece of software to be a piece of junk? It doesn’t do what it says on the tin or it doesn’t solve my problem. When prodded a little further, one quickly determines that the critique is actually more around the behavior of the software artifact itself and not the fundamental premise upon which the software was developed, in other words, the requirements. Comments like, doesn’t show more than ten characters tells me for example, that the developer didn’t consider a scenario for more than ten characters, probably because he only needed to show ten characters when he gathered or defined his requirements.
I am reminded about this every time I download a piece of software for my PC or from the apps store for my phone. My natural orientation is toward free stuff, but I don’t shy away from the ‘pay for it’ software as long as I can be confident that it will do what I want it to do. My process of evaluation involves looking at what I am trying to achieve (usually spurred on by some frustration or pain) and then determining whether the software claims to do what I want. If possible, I try to get an evaluation copy up front and then I put it through its paces and buy the full version if it expires or had some hobbled limitation that is resolved by way of purchase, that’s all provided that it does what i want it to do – ie. meets my functional requirements.
Most recently, I upgraded the software on my MacBook because I wanted the photograph management software to be able to directly load photographs to the internet. The finished product did what I wanted it to by doing what it said it did BUT in order to install it, I did have to upgrade my operating system which was probably in the small print. Since I didn’t go through my due diligence in evaluating prerequisites beyond hardware and since OS upgrade was not a part of my requirements gathering, I didn’t determine this until after I received the initial shipment of software. Basically, my experience was on the whole satisfactory but I did have to jump through a few hoops to get to the end result and spent a little more on the upgrade than I initially planned.
I also recently installed a piece of software on my phone, a free piece (I’m so cheap!!) and the customer reviews of it were all very derogatory, the software in question was a LinkedIn application. Despite the comments from others I installed it, and started using it. For what i wanted it to do, it achieves the objectives I set out for it and certainly it is easier to use than the LinkedIn mobile website. Many free applications one can buy for social media sites are nothing more than shortcuts to the mobile sites so I appreciated the fact that the ‘purveyor’ had actually invested some real time and effort in developing a proper mobile phone application for my specific operating system. That it is free is awesome!
For the last couple of days I have been playing with some advanced functionality with our Transaction product, the SAP transaction automation software that is in use by thousands of SAP users around the world.
While playing with this functionality, I sought out an SAP transaction that had the characteristics that I was trying to deal with with the advanced functionality for a customer. The advanced functionality in question is Index Based Looping, available only in Gui-script recordings but nonetheless an important capability for some use cases. I eventually found a screen that matched my requirements and proceeded to work through scenarios however I was more frustrated by the inconsistency of the SAP UI and the quirkiness of the screen than by Transaction’s inability to address my problem.
A couple of things that I noted in particular, were the fact that with this transaction (XD02 – Customer Change) the adding of credit card information seemed fairly straightforward, the advanced flow logic of the transaction screen also detected where a credit card was in fact used by another customer, and the transaction correctly evaluated the credit card number in accordance with the provider card numbering algorithm. However, the screen didn’t allow you to delete the first row of data in the grid/table although you could delete follow-on rows. It also it didn’t allow you to save the transaction in that screen. Furthermore, the screen, even when maximized, didn’t allow the visual presentation of more than 4 rows of data. Looking back at the overall experience, it was an awful transaction screen and no doubt one that frustrates many a user who has to work in it.
How did this hideous thing come about I wondered? Clearly many of the attributes could probably be resolved fairly quickly by an accomplished ABAPer but that would require a core change to base SAP functionality and this problem is one of the reasons Transaction is such a great product. You can automate screens like this without having to change any programs or configuration in SAP you just need to know what the quirks are of navigating the screen.
The fact that the screen cannot really maximize is, in my mind, a development miss in usability, it may have been ok in the days of 14″ CRT’s but today it is unforgivable. Good application design presupposes that you would want to maximize the use of all screen real estate unless there is an underlying requirement that says, don’t allow this. When this application was written, it probably was assumed that you wouldn’t be using more than one or two corporate credit cards attached to an account, of course retail consumers often have many more. My Amazon account alone has more than two credit cards attached to it and an increasing number of ERP systems in fact store retail customer data so this gap is definitely something that would frustrate more than just me today.
You also cannot save the customer account in this screen and have to back out to the bank accounts screen and only then can you save. This is also a development miss in my opinion. There should be a strong functional reason why I cannot do a global record management action like SAVE and this is usually bound by a triggering procedure that is effected by the follow on action such as payment card processing authorization check or something similar. Backing out from the screen usually (not always) doesn’t do that so I regard this as a design flaw. It probably isn’t something that was evaluated in functional or user acceptance testing or at least not in the change scenario.
The fact that I have to go to a separate screen to maintain payment cards appears to be because this feature was an afterthought and was lazily handled with a button launching a follow on screen rather than presenting all possible payment options on one screen. Esthetically it would have been better to have payment cards in the same screen as bank accounts to avoid mouse clicks in my opinion but evidently this wasn’t easy or there were possibly some underlying technical reasons why this wasn’t done this way. Who’d know?
The fact that I can’t delete the first payment card, well, what can I say, a fail on the part of QAT almost certainly, I can’t fathom why the delete row button is enabled if I can’t actually delete that row. This is a CRUD screen for all rows EXCEPT row1 when there are multiple rows. Not sure why, but it is, should I open a customer support message about this?
Looking back at these issues, I tried to conclude whether these were all design flaws or resulted from requirements gathering misses. Almost certainly it seems many are design flaws and not requirements gaps, the things that frustrated me don’t speak to functional requirements as much as usability; for the most part the screen does what it says on the tin, not very elegantly in some cases, but it does what it is supposed to do. The issues speak more to me about application design standards which clearly were missing or not adhered to, for the responsible developer.
As we prepare for a major release of Transaction with some projected UI enhancements, I am hoping that we will move toward avoiding some of the flaws in the current design, as I see them.
I hope to see improvements in the way that we currently present some features and capabilities in our product.
If you would like to be a participant in this process please be sure to sign up to the Transaction forum on http://community.winshuttle.com/forums/winshuttle-transaction where we will be floating some thoughts and ideas on upcoming changes.
About the author
The Winshuttle blog is written by professional thought leaders who are dedicated to providing content on a variety of topics, including industry news, best practices, software updates, continued education, tips and techniques, and much more.
Questions or comments about this article?
Tweet @Winshuttle to continue the conversation!