问题跟踪器要求

我可以补充一下：

• 平台（操作系统和编程语言）取决于你对维护的舒适程度，或任何一个人在内部拥有这个平台。
• IDE集成如果您打算将其用于应用程序问题工作stream（即，它是否以有用的方式与Eclipse或Visual Studio进行交互）。
• SCM集成 ，再次如果你要跟踪应用程序的问题。 将错误或function绑定到源代码库中很方便。 对于帮助台票types的工作没有帮助。

此外，如果这将服务于一个帮助台angular色，也许库存跟踪或许可证跟踪。

更新

• 凭借问题或应用程序的types，可以根据新问题分配默认资源（即技术人员/程序员）的能力（自动化的1级分类）

可能附加文件。
使用模板的可能性：像创build一个新的预先确定的子表格的情况。
可以logging案件的工作时间。

沿着安全线路，端点之间的encryption很重要，但并不总是提供。

FogBugz中的虚拟用户function相当不错。 我比标准组更喜欢它。 我认为现在使用它已经有几年了。

无论何时查看软件平台/软件包，都需要考虑产品本身的支持。 错误修复的速度有多快？ 它是开源的，所以你可以自己解决问题，或者你会依赖于另一家公司？

小事 – 主题/模板/标志定制。 一些企业会喜欢他们可以定制的解决scheme，以适应他们的企业形象。

1. 白皮书或解决scheme部分允许支持人员search已知问题或HOWTO 。
2. 监控行动的票据创build
3. 附加文件/日志
4. 智能手机友好的非现场访问接口
5. 自动升级未解决的问题

基于票证状态的stream程pipe理系统stream程（像Jira一样）