<< April 2007 | Home | June 2007 >>

Requirements Gathering geht schief!

If requirements are gathered by someone who isn't an end user, but who is an expert in the domain, there is the likelyhood that the requirements will be only roughly accurate. If that gatherer then leaves the project and you lose touch with the end users, your'e even more likely to lose your way.

On a number of occassions I have seen the end users arguing with the developers as a project comes to a close, over whether what was implemented was what was required.

More frequently than not, the system will do what is required, it's just that it does it in a different way. There is more than one way to write a Word document for example! Systems that are complex naturally have more than one solution. It depends on how the persons implementing that solution think - their entire background, culture and education can affect the solution. A fully trained kitchen fitter might have a very different perception of how a kitchen design system should work compared to a software Architect, Developer or Business Analyst. But if the system allows them to design a kitchen, is it relevant if the dialogs, screens, functions and/or business processes of the system are different? Take an SAP system for example. These come preconfigured with thousands of business Processes, Forms, Dialogs, Data Models, etc. SAP allows for example, a company to implement a Supply Chain application. But there are many, many companies which have changed their business processes to match their new SAP system. That demonstrates that there really are many different ways to get to the end goal. Isn't there a joke about asking 10 accountants to describe your companies expense policy and getting 13 answers?

So what to do with disappointed end users? Well, a rigorous training program will get them to understand what you have implemented and perhaps even why. This training should be hands on, and one to one (or no more than three). You can really show them how the system works, using real world examples.

NOTE: if you cant get the real world examples to work, its time to change projects.

The best solution however, and only in terms of getting requirements right, not say in terms of cost or time, is to work very very closely with the customer from the start. Frequent releases to them, so that they can play with the system and give instant feedback on what needs to change are extremely important to building a system that does exactly what the customer wants.

Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!

Login doesn't appear to work?

I've come across the following problem in IE7 in several products which I initially commented on at the MVN Forum forum (incidentally MVN Forum is a great open source Java Web Forum). Here is a copy:

First, thanks for MVNForum - I've used it before, and I have now come back 4 years later to use it again. Its perfect for an all Java platform!

But I have a strange bug, which I have figured out. For some reason, with IE7, Tomcat 5.5.9 (and later), MySQL 4.1.x, I find that with IE7 only (not Firefox), it is putting the jsessionid into the URL instead of using a cookie. I have tried changing all the settings in MVN as well as in IE, but it still uses URL rewriting when using my site, even though the cookies work perfect on this forum... I can't figure that bit out...

Anyway, I debugged into MVNForum to see what was going on, and I noticed that after one enters their login details, it sends a redirect. In this redirect, the "redirect-to URL", does not contain the jsessionid, and so a new session is started. That means users cannot then do admin, or whatever, depending on user permissions, because the server thinks its a new session and wants them to authenticate again.

I used the debugger and on line 426 of com.mvnforum.user.UserModuleProcessor (right at the bottom of the process(HttpServletRequest, HttpServletResponse) method), I modified the value of the responseURI in the JVM, to include ";jsessionid=XXX" where XXX was the value of my session ID. It worked perfectly.

I would suggest that in this processor, and the corresponding admin processor (if there is one), that it check if the original request URI contained the jsessionid. If yes, then it should add it to the response URI.

I would look into changing settings in the browser in more detail, but to support any user on any browser, I would rather fix a bug serverside.

Please let me know if/when this bug will be fixed in release, so I can download the latest patched version.

To test it, disable cookies in the browser.

Tags : ,
Social Bookmarks :  Add this post to Slashdot    Add this post to Digg    Add this post to Reddit    Add this post to Delicious    Add this post to Stumble it    Add this post to Google    Add this post to Technorati    Add this post to Bloglines    Add this post to Facebook    Add this post to Furl    Add this post to Windows Live    Add this post to Yahoo!