需求分析

通过阅读《我们应当怎么做需求分析》： http://blog.csdn.net/yqmfly/article/details/7679781 一文，我了解了需求分析的基本步骤和一些方法 通过这篇文章的标题，可以得出软件需求大致分为三步：需求调研，需求分析，需求确认 :（1）需求调研：如何与客户交流、建立联系、研讨业务需求，捕获需求 ：（2）需求分析：功能角色分析、业务流程分析与业务领域分析，用例分析及用例图，查询报表分析，原文分析，非功能需求 ：（3）需求确认：需求列表,需求实例，快速原型法，需求规格说明书，评审与签字确认会 一， 需求调研 1.与客户交流的方法 首要的是收集需求，收集需求的方法千千万，直接征集客户意见是最简单粗暴的一种，但是效果却不一定有多好 与客户交流过程，不仅需要我们的理解、设计能力，更需要我们具有与人沟通交往的能力，Wiegers的《Software Requirement》中更是提到，What & Why，在与客户沟通时，我们不能仅仅局限于What ，客户说什么就是什么，而更应该从Why方面展开，通过理解客户的意图来得到对客户意图更深入的理解，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高

课程 班级 学 号 姓 名 实验时间 软件工程导论 12电信1 120705140 张科星 2013.11.1 9 软件工程实验报告一 一、实验名称 排班系统 二、实验目的 完成排班系统的需求分析，建立需求模型计； 系统掌握软件开发过程中需求分析报告的写法。 三、实验主要内容 将整个需求分析过程分为业务分析、用户需求分析和系统需求分析，确定每个模块功能所需要的算法和数据结构，并设计出程序的详细规格说明，可画出详细的程序流程图，为编码做准备，写出详细设计报告。 四、实验原理 详细设计也称过程设计，是程序设计的蓝图。该设计是在数据设计、体系结构设计和接口设计完成之后进行的。过程设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程尽可能的简明易懂。结构化程序设计是实现上述目标的关键技术，因此是过程设计的逻辑基础。过程设计的结果基本上决定了最终程序设计的质量。将程序体系结构元素变换为对软件构件的过程描述。该实验主要是利用过程设计工具进行程序设计。 五、实验结果 排班系统的需求分析报告 第一章、排班系统的简介 由于工作需要进行轮休制度， 一星期中每人休息一天。预先 让 每一个人选择自己认为合适的休息日。请编制程序，打印轮 休的所有可能方案。当然使每个人都满意。 第二章、排班系统业务用列建模 来源： https://www.cnblogs.com/zhangkexing

课程 班级 学 号 姓 名 实验时间 软件工程导论 12网工2 120708244 董姗姗 2013.11.18 软件工程实验报告 一 一、实验名称 新生入校管理信息系统分析。 二、实验目的 完成电子商务环境下新生入校管理信息系统需求分析，建立需求模型计； 系统掌握软件开发过程中需求分析报告的写法。 三、实验主要内容 将整个需求分析过程分为业务分析、用户需求分析和系统需求分析，确定每个模块功能所需要的算法和数据结构，并设计出程序的详细规格说明，可画出详细的程序流程图，为编码做准备，写出详细设计报告。 四、实验原理 细设计也称过程设计，是程序设计的蓝图。该设计是在数据设计、体系结构设计和接口设计完成之后进行的。过程设计的目标不仅仅是逻辑上正确地实现每个模块的功能，更重要的是设计出的处理过程尽可能的简明易懂。结构化程序设计是实现上述目标的关键技术，因此是过程设计的逻辑基础。过程设计的结果基本上决定了最终程序设计的质量。 将程序体系结构元素变换为对软件构件的过程描述。该实验主要是利用过程设计工具进行程序设计。 五、实验结果 电子商务环境下学生入校管理系统需求分析报告 第一章 新生入校管理信息系统简介 学校录取的每名新生在录取通知中会得到一个网址和本人的登录密码，可以通过网络，在家中完成一部分报到手续。 有上网条件的学生，可以在家里登录学校相关网站，完成部分报到手续， 如新生入学登记

组织过程资产库下面有组织级标准过程库， 这个库里一共有19各PA（就是标准过程啦） PA的英文是Process Area CM（配置管理过程，英文是Configuration Management） 项目研发和管理过程中会产生很多工作成果，例如文档、程序和数据等，它们都应当被管理起来，以便查阅和修改。鉴于用户的需求会发生变更，导致项目的相关产品也会随之变更，为了使项目的所有过程和产品保持一致性，并且便于跟踪控制，我们需要建立一套严格的配置管理流程 制定配置管理计划 配置库管理 版本控制 变更控制 配置审计 DAR（决策分析过程，英文是Decision Analysis And Resolution） 当项目出现重大问题的时候，为了降低问题所带来的风险，需要一套系统的方法来帮助项目选择一个解决方案 识别需要决策分析（DAR）的问题 组件决策委员会 建立评价准则和评分方法 提供候选方案 评价候选方案 选择最优解方案 跟踪解决方案 IPM（集成项目管理过程，英文是Intergrated Project Management） 集成项目管理的活动贯穿在项目定义、项目计划、项目开发和项目结束这四个项目阶段过程中 建立已定义过程 使用组织过程资源策划活动 建立工作环境 集成计划 使用集成计划进行管理 贡献组织过程资产 MA（度量和分析过程，英文是Measurement and Analysis

先说项目开发过程中团队人员的分工协作。 　　 一、人员安排 　　毕业至今的大部分项目都是独立完成，虽然也有和其他同事协作的时候，但自认为对团队协作的了解和认知都还有所欠缺。很清楚团队协作的重要性，但尚未有很好的机会在相对成熟的团队中锻炼实践。 　　先抛开 软件开发 团队中人员的具体安排不讲，单纯的看软件开发工作的分工。在上面设想的开发架构中，宏观上可将一个项目划分为前端、程序、 数据库 三个模块。由此可推导出团队中需要的成员：美工、程序员和项目经理。 　　认为理想的软件开发团队由四个专业技能过硬的成员组成：一个美工，熟悉UI的设计并具备将效果图转换成前端页面的能力，也就是得同时精通PhotoShop、HTML、CSS、jQuery等前端知识；一个程序员，熟练掌握代码的编写重构；一个项目经理，具备 需求分析 的能力、数据库设计维护的能力、架构设计的能力、程序编写的能力、前端样式脚本编写的能力，最重要的是对业务流程有精准的把握；一个部门经理，和前三位不一样，部门经理只具备领导能力即可，他是兼职，不需要把全部时间投入到团队中。 　　大部分中小型项目可以由这样的四人团队完成，可如果项目较大，已经大大超出了四个人可完成的工作量，可以再加一个前端开发人员。也就是说两个前端开发者，一个负责UI设计，做出完整的效果图，这个人的设计功底应该比较强；一个负责将效果图转换成页面，并完成样式、脚本等的编写

一 基本信息 标题：高校后勤信息系统的设计与实现 时间：2014 来源：电子科技大学 关键词：后勤信息系统；面向对象开发；管理界面设计；软件系统测试； 二 研究内容 1.论文内容 论文内容包括需求分析，软件设计，软件实现，软件测试； (1)前期工作主要包括对后勤信息软件进行需求分析调研，对各种模块的设计可行性进行评估，做好详细的使用用户报告。 (2)中期工作主要是指对用户报告进行分析，确定需要开发的具体的用户模块有哪些。由于后期包含较多的模块，在设计上不可能全部由一人完成。为了保证 设计的质量，确定把设计部分集中在宿舍管理模块部分。 (3)最后对软件进行分析设计，采用科学的分析方法完成设计诉求，并对软件功能进行测试。 2.论文结构 第一章：绪论，阐述了课题背景，课题研究的内容及目的，并对论文完成的工作，创新点和组织结构进行了介绍。 第二章：介绍了后勤管理信息系统运用到的主要技术，如SQL语言，C/S结构，UML技术等。 第三章：对后勤管理软件的服务策略及设计进行介绍，设计的重心在于根据软件需求完成设计的目标，勾画设计框架，完成模块设计。 第四章：重点介绍了主要模块宿舍信息管理模块的分析及设计流程。详述了用户具体功能模块的划分，系统的数据库设计及软件登录界面的实现。 第五章：阐述软件系统如何实现。分析设计步骤。 第六章：具体论述了系统总体设计及实现，对软件的功能进行测试。 第七章

这几天一直在处理各方面收集到的需求，目前整理的进度应该在80%左右，通过整理和分析得到如下一些数据： 需求数目：353 预估的开发量：2536人天 也就是说，如果我一个人来实现这些需求，一年做250天的话，需要做10.14年，如果365天斗来做的话，需要6.95年，目前预估的开发量还没完成，因此需要的时间只会更多。 有了这些真实的数字，很多想法就理性多了，要仔细甄别需求，确定每个需求的商业价值和估算开发量，计算每个需求的性价比。 舍弃低价的需求，选择高性价比的需求，进行详细分析和整合，逐步将这些用户需求转化为真实的产品需求，并根据人员和时间情况，最终确定下阶段要做什么？ 做产品最难的不是怎么做？而是选择做什么？而选择的核心就是需求的价值，如何衡量需求的价值？ 1、实现需求能给用户带来什么价值？ 2、实现需求能给产品带来什么价值？ 3、技术上能否实现？ 4、时间上有什么要求？ 整理需求的过程就是一个思考的过程，在纷杂的用户需求中明确产品需求就是一个扬弃的过程。 形成这个需求列表后，剩下的就需要团队的智慧了，需要大家来讨论了，希望的曙光就在前方。 来源： https://www.cnblogs.com/Duiker/archive/2009/08/11/1543722.html

说明： 《火球——UML大战需求分析》是我撰写的一本关于需求分析及UML方面的书，我将会在CSDN上为大家分享前面几章的内容，总字数在几万以上，图片有数十张。欢迎你按文章的序号顺序阅读，谢谢！本书已经在各大网上书城及书店销售，欢迎你的关注。 ------------------------------------------------------------------------------------------------------------------------------ 第2章 耗尽脑汁的需求分析工作 摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.2 持续进化的客户需求 你可能曾遇到过这样的情况：客户今天想要一个苹果，明天改变主意要一条香蕉，但后天突然又说还是苹果好，到最后他想要一个西瓜！遇到这样的情况，你会抱怨客户吗？你会后悔当初没有让客户签字 确认 吗？ 楚国有人坐船渡河时，不慎把剑掉入江中，他在舟上刻下记号，说：“这是我把剑掉下的地方。”当舟停驶时，他才沿着记号跳入河中找剑，遍寻不获

第2章 耗尽脑汁的需求分析工作 摘要 ：怎么又变了？当初就应该让客户书面签字 确认 ！你可能会经常发这样的牢骚，可是就算客户书面确认，客户还是会“赖账”的！ 软件 项目 的其中一项不变真理：人是会死的， 需求 是会变的！本章将会和你一起来体验软件 需求分析 工作的风风雨雨，找出需求分析工作的根本之道，了解 UML 如何帮助我们提升需求分析的水平。 2.3 给客户带来价值，需求分析之正路 手机短信订餐系统 接下来我将会介绍一个手机短信订餐系统的故事，这是一个由真实个案改编的故事，通过这个故事来体会 需求分析 工作背后的道理。 某IT公司规模不大，员工100来人。公司有一个简单的定餐系统，员工每天可以在公司内部网站上提交当天午餐定餐，前台汇总各人定餐后，将定餐汇总传真给餐厅，餐厅根据传真送餐。 可是有这样的问题：部分员工因为上午请假或者外出工作，无法再网站上提交订餐，以至于中午回到公司时没有饭吃。 于是老板想出了这样的办法：做一个手机短信定餐系统，不在公司的员工可通过手机短信定餐。 于是成立了手机短信定餐 项目 小组，购买了手机短信收发的硬件，解决了选餐单、定餐、取消定餐等技术问题。但这个系统一会灵一会不灵，问题是出在 软件 、硬件，还是中国移动都难以搞清楚！做项目做麻烦的事情之一就是遇到“幽灵问题”，时而出现时而正常，项目小组挥汗如雨地试图解决这些问题，可一直没有办法搞定。

王争《设计模式之美》 学习笔记 案例介绍和难点剖析 文中作者以一个真实的开发案例，从基础的需求分析、职责划分、类的定义、交互、组装运行讲起，将最基础的面向对象分析、设计、编程的套路给你讲清楚，为后面学习设计原则、设计模式打好基础。 真实案例，给你的微服务增加接口调用鉴权功能。 需求不明确 leader 给到的需求过于模糊、笼统，不够具体、细化，离落地到设计、编码还有一定的距离。 面向对象分析可以粗略地看成“需求分析”。 缺少锻炼 鉴权作为一个跟具体业务无关的功能，我们完全可以把它开发成一个独立的框架，集成到很多业务系统中。 开发这样通用的框架，对工程师的需求分析能力、设计能力、编码能力，甚至逻辑思维能力的要求，都是比较高的。 对案例进行需求分析 第一轮基础分析 设计通过AppID和密钥来认证。 第二轮分析优化 防止“重放攻击”，增加加密token验证。 第三轮分析优化 依然有“重放攻击”风险，引入时间戳作为随机变量。 第四轮分析优化 在允许时间范围内（比如1分钟），依然有攻击风险，这是一个攻防策略。 这里作者还提到了一下，多端多AppID要如何存储，设计时要留有扩展点，当更换存储时减少代码改动，多运用面向对象的编程思想。 我觉得作者这里就是讲一个需求分析，大家主要吸收的是一个分析的过程，一个思考的过程，如何循序渐进，拆解需求，完善设计，迭代优化