摘要： higoals: 在需求调研中，用户和我，谁应该是主导角色？barbeque: 有两种情况：如果是软件适应稳定的业务模式，必须由用户主导；如果软件起到改变业务模式的作用，很可能是代表领域专家意见的人员主导 在barbeque的访谈中看到了这样一段问答。和公司一些销售人员交流时，他们大都认为我们软件部对客户的需求调研、分析做的不好，所以导致了项目无法达到客户的满意，迟迟不能结项。他们提议，不应该采......
摘要：我刚接手的一个项目，一个核心的业务子系统在很多地方客户都提了完善的意见、并且有很多功能还无法实现，易用性设计也比较差。总之要改造的地方很多。我采用用例把所有要改造的功能点重新表述出来，这在分析系统功能上要远比使用菜单表达更合理，因为即便一个最底层的子菜单也并不代表就是一个软件的功能点，另外，菜单的组织是着眼于便于客户使用和便于导航的，它和系统功能并没有一一对应的关系。 用例毕竟是软件领域的技术方法......
探索需求（6）—业务VS系统«程序员»杂志第七期有篇潘加宇的文章«业务建模vs系统建模».最近正好一直在做业务建模与系统建模的工作,所以对这篇文章中的很多观点体会颇深. ? 1.“业务建模并不意味着有软件项目开发跟随”. 记得一年前,公司一个会我发言,为了说明扎扎实实调研分析透客户单位的实际业务对后期系统需求分析的重要以及要避免过早去考虑软件系统需求甚至设计的时候,我说“我们就假设我们调研不是要开发软件,就是要弄清楚实际业务,建立业务模型以优化业务管理”.我想只有这样我们才能抑制住自己的浮躁,技术人员往往让过早的系统分析与设计来掩盖其对业务的稀里糊涂.他们往往在没搞清楚实际业务时就臆想以后的系统,而在真正分析设计系统时又去臆想客户的实际业务,当然这种分析设计是建在沙丘上的建筑.所以当我们抱怨客户的需求总是在变的时候,我们是不是也要反思一下,他们的业务多少年来从不变化,是不是我们根本没有真正理解业务,自然也不能很好的捕获到客户真正的需求,更不要说给客户有价值的需求建议. ? 2.“业务建模有助于描述‘战场’的真实态势,帮助你从中寻找软件的切入点” 【程序编程相关:
ThumbSMS拓展企业短信应用】 【推荐阅读:
svg至flash的转化】 最近对项目一个子系统的改造就是采取先建立业务模型而后编写系统用例进入需求分析设计的过程....
下一页 摘要：众所周知，归并排序（mergesort）就是以分治的思想，把输入数列分为几段，递归的把这几段排好，然后再通过归并（merge）操作把这几段拼起来，从而将整个数列排序。典型的归并就是2路归并排序。 归并排序的时间复杂度是o(nlogn)的，但它的一个显著问题就是需要额外的存储空间来辅助排序，空间复杂度是o(n)的，与quicksort和heapsort相比就逊色了不少。能否让它的空间复杂度为o(1)......
