系统分析工作是解决一个问题的工作,目标是将一个对计算机应用系统的需求转化成实际的物理实现,其中 复杂就复杂在实际的面太多.在系统分析过程之中注意问以下的问题,可能会所进行的系统分析设计工作有 帮助.
1)您所完成的系统目的是什么?注意不是功能要求,而是目的.也就是为什么要建设、为什么要现代建设。
2）您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们 会采取什么样的态度？你对他们有多少影响力？
3）您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。
4）你的系统设计思想是什么？是否能够得到各方面的认可。
5）你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有 足够的影响力吗？
6）你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一 阶段完成的情况进行评价？
7）你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？
8）你所完成的系统是否有原型？计算机的或者物理的。
以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。
系统分析工作是解决一个问题的工作,目标是将一个对计算机应用系统的需求转化成实际的物理实现,其中 复杂就复杂在实际的面太多.在系统分析过程之中注意问以下的问题,可能会所进行的系统分析设计工作有帮助
1)您所完成的系统目的是什么?注意不是功能要求,而是目的.也就是为什么要建设、为什么要现代建设。在考虑系统目的时，我更多的侧重于系统的最终目标考虑，因为一个系统不可能一下子完美，为系统留些 余地。
2）您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们 会采取什么样的态度？你对他们有多少影响力？中国it行业的失败之一就是人"太年轻"，一定要有领导的 支持，否则完蛋。不要认为自己对他们会有多少影响力，即便有，也要尽可能的认为是决策者再影响他 们。在中国，一个技术员，你算老几？说到这里我很悲哀。哪些人在系统中起重要作用并弄清楚他们的态 度，这点十分关键。
3）您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。不知道这样说对不对，在系 统建设之前，对你的程序员、对你的领导要有至少不同的两种评价。
4）你的系统设计思想是什么？是否能够得到各方面的认可。如果高明，对领导、对程序员都采用引导， 得到认可的最好办法，就是让他们认可他们自己的想法。（我力图这样做，但做得不好，系统分析员有一 点要学会韬光养晦，忍）
5）你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有 足够的影响力吗？软件发展到一定的程度，不是编程，不是数学，而是管理。
6）你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一 阶段完成的情况进行评价？
7）你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？事实上，不是每种好的工具都要 使用，也并不一定都要他们熟练掌握。提醒诸位一句，当你将方案做得可以不依赖某个程序员，你在程序 员面前就无信任可言，因为从此程序员将受到更大的生存压力。我坚决不在公司使用rose。
8）你所完成的系统是否有原型？计算机的或者物理的。
以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。
这文章很好，我的话是："需求分析实际应该是问题分析"。含义是系统要解决的是问题。而不是用户提出 的需求。经常发现系统完成后，客户说"我的问题还没有解决"。可是，需求分析稿上的目标都搞定了。
既然是问题分析，所以，熟悉目标系统的知识就是必要的。甚至，可以说，一个好的系统分析员也应该是 好的业务专家。
我很高兴在这里遇到许多分析高手，可以交流分析中的问题。我赞同从来的观点。在中国作分析重要的是 人气，因为中国的企业级信息系统的建设在很大程度上可以说并非确有需求，而是迫于某种压力。用户在 很多时候考虑的不是系统的长远发展，而只是短期的成果，要求开发单位在很短的时间内完成一个很大的 系统的开发，没有时间对系统进行周密的分析，在这种情况下，很多开发商就会粗分析，粗设计，尽快进 入编码阶段，这样的系统的生命周期肯定不会很长。说了这么多，只是想说，系统分析员确实应是业务和 管理专家，并且需要有很好的语言组织能力，他需要根据问题域中存在的问题去尽力说服用户，引导用户 需求，毕竟，我们是专家，如果让用户牵着鼻子走，系统不会是成功的系统。（当然了，这要建立在用户 是可引导的前提下）本人拙见。
文章来源于领测软件测试网 https://www.ltesting.net/
