杨长春的个人空间

一般来说，在绘制软件原型时，都要在原型上写一些事例数据，如表格中的，label上的。新手很容易犯这种错误：不注意原型数据的展示。例如：明明某个字段有唯一性控制，在原型上却出现相同的数据（如出现了两个“LK0292”工号，姓名却不同）。明明某个字段应该是其它字段运算的结果，在原型上却不是这样。明明某个字段需要排序，但在原型上出现的数据却是杂乱的。一个叫“张三”的，明明在第一行的职务是“总经理”，到第三行又变成了“操作工”。……随随便便敲点字母数字文字，看上去像节省时间，其实未必。要知道，原型上的数

《实战需求分析》由清华大学出版社出版，作者杨长春。本书是一本系统讲解软件需求分析及设计的书，面向管理软件，以实战为主。书中包括大量案例以及来自作者工作实践中的经验心得，主要讲述了需求分析的工作步骤、需求分析的工作内容、如何进行需求调研、如何进行系统规划、如何设计软件、如何设计出好软件、快速原型开发模型、需求文档的撰写、如何应对需求变更、如何成为需求分析高手。适合从事需求分析工作的专业人士、希望从事需求分析工作的IT人、希望了解需求分析工作的IT人、计算机相关专业的大学生、管理相关专业的大学生、企

正在策划一个产品，其中要用到企业中人员的上下级关系。上下级关系，直觉上只是个简单的树状结构，如果不深入思考，容易将之简单化，其实，这里面还是有很多麻烦事的。例如，有些企业，某些人的上级不止一个，属于多领导，虽然有些口头上的分工，但分工并没有非常明确，还有的时候，一个人可能会有兼职，如某车间主任兼职工会主席，他就属于两个不同的管理条线下，还有些企业，对排名，特别是领导的排名很重视，可在兼职的情况下，在不同的岗位下，排名是不一样的，等等。怎么表达企业里面员工上下级的关系，兄弟们主要分成了两大阵营，相

本部门主要从事面向互联网的管理软件的开发。部门中有一个叫做“需求工程师”的岗位，大概的工作职责就是，根据项目经理或者客户提出的要求，进行软件设计，然后将设计稿交给开发人员开发。这是个联系用户与技术人员的桥梁，重要性嘛，怎么强调都不过分。有段时间，我发现他们工作中，最苦恼的事情不是客户漫无边际的要求，不是客户不断的需求变更，也不是研发人员认死理的工作态度，最苦恼的事竟然是，研发人员往往容易把他们的设计要求理解错误，导致开发出来的功能好多根本就不是需求人员想要的，导致需求人员与研发人员经常在办公室中

做过挺长时间的管理软件系统分析工作，还真有点体会，总结总结。 原则一，永远记住，客户不是系统分析员。有些朋友，做系统分析时，总是说客户不认真提需求，系统开发进程被需求变更淹没时，就埋怨客户的需求没有提好。但就是忘了重要的一点：客户就是客户，客户不是系统分析员，如果客户能把需求提得那么清楚，要你干嘛？ 原则二，对一些原则常怀敬畏之心。有时候，也许你知道名家们给出的一些设计原则，也许你知道一些前辈分享的经验，也许某老鸟给了你一些建议。除非你对这些原则、经验、建议完完全全、不打折扣

从事管理软件设计，一般都是从用户需求分析开始。从事软件工作的，大概谁都知道需求分析的重要性，可能大部分人都吃过需求分析不充分的亏。兵法云，“谋定而后动”。对一个项目而言，需求分析应该是“谋”的一部分，谋不好就急吼吼地从事后面的工作，实在是一件非常危险的事情。让需求分析者最兴奋的事是，遇到一个既精通业务又对自己的业务信息化有许多想法的人，甚至他是一个软件爱好者。有时遇到牛人，他提出的需求，你记录下后稍作改动就直接可以当做需求分析规格说明书用了。当然，这种事情千年难遇，可遇而不可求啊。而且，在这种情

客户是家欧资企业，用的全是进口机器，上万种零件，价值很高，用我们的系统进行零件管理有一段时间了，但总觉得不如意，这次想进行一次彻底的优化工作。首先，我走访了与零件管理相关的一些部门，如零件仓库、采购部、技术部、工程部等。在了解了他们当前的零件管理流程及需求后撰写了需求分析规格说明书，写完后便准备召开一次需求分析讨论会，以确认他们的需求。然而，我发现仅仅通过这份说明书很难指导下面的工作，因为客户往往提出的都是一些比较抽象的需求，写出来一点问题都没有，但如何满足这些需求就有些不明不白了。于是我决定进