Hello Tim, Thanks for the quick reply. I let 1 of the users know that he is now a recognized bug ;-)
On the other hand: what does RFE stand for. I found about 2 dozen possibilities on google. Thanks, Larry ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Timothy Powell Sent: Friday, November 19, 2010 3:13 PM To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** In ref to Risk Level being consistent with Urgency, Impact and Priority: Support tells me that numerous RFEs to get Risk Level changed to be consistent with Urgency, Impact and Priority have been rejected. I insisted on my own RFE to add to the pile. I'll let you know how it turns out. Tim From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, November 19, 2010 2:49 PM To: arslist@ARSLIST.ORG Subject: Re: "Working as designed" type defects ** Everyone, This topic has several different facets. I will try and address the different aspects I see. 1) Consistency of functionality across application is important. Absolutely. Everything from using consistent wording to consistent options, to consistent interaction. This should be true across all applications. Now, are the applications as good as they should be in some cases? No. Are they getting better with every release? Yes Is the goal to keep working on things so that there is more and more consistency of interaction? Yes There are times when there are changes to interaction that hit different applications at different times. That can introduce some temporary inconsistency until the other application(s) catch up with the new approach. But, those are a different type of issue. The things called out on this thread are about wording and operation and function for specific operations type consistency. This should be done better. 2) "As designed" response from support Well, there is always the balance of something being wrong or something working the way the product was intended. So, yes, even when there is some inconsistency of operation, if the product is working as it was intended (we will get to whether the intended was good or not in a bit), the answer you are getting is an accurate one. If something isn't working, then that is different. That may be a design error if it is not working. If something is not working, then you should push back on the "as designed" labelling. If it is working but is just not doing what you would like (or is not the same as some other application) this is not a design error -- it is doing what it was designed to do -- but it is something that could be done better to allow the solution as a whole to do better. What I have seen in this thread is that things are working but you would like them to be working differently so that the same things are the same way in different applications (and that is a justified desire) 3) The RFE (Request for Enhancement) process Now, if something is working and you want it to work differently, that is an enhancement request to the system. This is true whether it is just to work differently in isolation or whether it is to change it to work like it does somewhere else. This is no different than asking for a new capability of the system. Customers are always encouraged to submit enhancement requests to add to or alter the behavior of the system to do better for them. We have to treat RFEs differently than defects (bugs). A bug is not working and it should be fixed so that it works. No one will be disrupted by a feature that didn't work that now does. However an enhancement that adds functionality or changes how something interacts when it was working before can be disruptive and so needs to come in as a new feature in a release. I understand that there is subtlety here and that there are gray areas between things. And, you should feel free to have a discussion if something does fall into the gray area. But, most things will clearly fall on one side of the line or the other. There is a process for handling things on either side of the line to allow the best and most orderly response. Would it be better if there were no inconsistencies? You bet! But, they do creep in sometimes. We need to be diligent about working them out of the system. So, if you have had things that are "as designed" that are working but you wish they worked differently, please enter an RFE for the change to have it considered for a product enhancement. If you have things that are "as designed" but are NOT working, then it is fair to ask how something can be designed to not work! Your input is invaluable in helping to move the product forward. Input from customers has led to a number of significant cleanups in the applications in the past few releases and we are getting good response to the 7.6.3 release and another wave of consistency is coming in the next few releases. Also, some modularization going on inside the applications is making it more likely that consistent interaction will occur in many areas with more sharing of logic and interaction. This is a good discussion and it is important to keep BMC honest and not just hide behind an "as designed" shield. Please keep up the pressure. But, I hope this note has helped to explain a bit about why there are differences in something not working at all vs. not working best because another way is better and why they are different and why the difference is an important one in deciding how to respond to the report. I hope it also has helped encourage more submissions of RFEs to report consistency problems and ask for better in future releases. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Guillaume Rheault Sent: Wednesday, November 10, 2010 10:54 AM To: arslist@ARSLIST.ORG Subject: "Working as designed" type defects ** I'm sending this post to the list community to see what is the general feeling about issues that BMC Support classifies as "working as designed" The category of issues I am referring to specifically here is inconsistencies in functionality between ITSM modules or within a single specific module. More specifically, and to name only a few, in ITSM 7.5.1 but apparently still present in 7.6.3: - Assigned group searches in tasks are different than assigned group searches in change - Assigned group searches, change manager group searches, and change implementer group searches are different - Task tab in problem investigation is different than the task tab in the incident form When I raise these issues with BMC support, I get the reply that it's working as designed. Well the problem with that, is that customization is required to make functionality, and look and feel consistent. It seems to me that BMC should create a "Design Defect" classification in addition to the existing defect classification, which are essentially implementation defects. I mean why should I need to create an RFE for something that should work consistently in the first place? Seems like "Working As Designed" is simply an easy way out of the situation. Quality Assurance **should** catch these defects. Is this too much to ask? A defect is a defect because the customer perceives that as a defect, that should be the bottom line. This is not new functionality, only making the functionality and user interface work to the way it is expected. Thoughts? Guillaume _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _attend WWRUG11 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
