This is important feedback. It is our main goal to make the user experience easier rather than harder while at the same time providing advanced features for the power users. We had a lot of requests for the search to be more robust, to include wild cards, search additional fields as well as attachments like Word, PDF, and Excel. This is why we turned to the Lucene engine which is used by many other tools and follows standard search practices (see my note on Google below).
I do see your managers point regarding the ID. It is the one field that I could see being returned even if it isn't an exact match. So 23 for example would return REQ-233, REQ-23, REQ-623456, UC-123, BUG-23...as well as any area in the system where 23 exists alone. This is actually better than the classic approach in that the classic approach would return anything with 23 anywhere in the text. For some this could return a LOT of results which begins to defeat the purpose. If someone wanted to more specific match the wild cards would still be available.
Note on Google
Google is obviously a very powerful search engine and is somewhat of a different situation than us but thier approach is very similar and maybe even less useful. For example, they don't allow wildcards (in fact if you put an * in the phrase it's pretty much ignored). However, for
common words Google makes some assumptions; "irefighter" will return
results for "Firefighter" as well as "irefighter" but "erwyn" will not
return any results for "Derwyn". Google provides AND, OR and the
ability to put quotes around a phrase which is exactly how our search works today. So the only difference is that we don't make any assumptions. We assume the requested syntax is what the user wants so 23 is anything that is just 23. But it makes sense that we might make some assumptions, as Google does, to help the user along in areas that are more common.
Thanks for the feedback.
