随笔分类 - 软件需求分析
1
摘要：所花时间 （包括上课） 8:00~9:50 19:30~21:00
阅读全文
摘要：所花时间 （包括上课） 8:00~9:50 19:30~21:00 9:00~10:30 表格的隐藏：display：none 显示display：table-row（格式不变）
阅读全文
摘要：所花时间 （包括上课） 8:00~9:50 15:00~17:30 19:00~21:30 14:00~15:30 14:45~16：00 业务目标包括：度量、范围、好处 业务用例文档的编写
阅读全文
摘要：所花时间 （包括上课） 8:00~9:50 互联网的思维是女性的，所以也是多变的； 所以要时刻站在它的角度上考虑问题。 进行项目的开发时，要站在用户角度上考虑 问题，去想如何做是他们更方便。
阅读全文
摘要：星期一 星期二 星期三 星期四 星期五 星期六 星期日 所花时间 （包括上课） 8:00~9:50 19:00~21:30 代码量（行） 200 博客量（篇） 学到的知识点 提问时可以采取三种提问方式，金字塔 型， 漏斗型，菱型；问的问题不能太宽 泛；做需求应该按照从上到下的顺序进行需求捕获。 文本
阅读全文
摘要：所花时间 （包括上课） 去做需求之前应先商议好具体要讨论什么问题， 进行需求分析时要尽量脱离开办公室，从用户的 日常工作入手进行需求捕获。
阅读全文
摘要：所花时间 （包括上课） 分析系统的利息相关者和系统进行的交互 用户故事的优势使其在众多需求方 法中脱颖而出，而其也有不足之处 ，这些不足之处需要一些额外的花 费来弥补；用户故事虽然简单易懂 ，但是很好的使用它也不容易，所 以要留意迭代过程中可能出现的各 种症状，然后对症下药；还有就是 用户故事可能会
阅读全文
摘要：用户故事得到这么多人的肯定，是因为它自身的优势有很多：1、用户故事强调口头沟通，因为传统的通过各种文档进行表达，每个人对于文字的含义的理解都不同，所以在阅读文档的过程中可能会因为理解的不同对项目的完成造成影响；2、人人都可以理解用户故事，并且用户故事可以增强人们对各种事件的记忆；3、用户故事的大小适
阅读全文
摘要：所花时间 （包括上课） 13:50~14:00 需求分析需要分析其利益相关者 ，系统目标需要有度量进行约束 还要有该目标带来的好处 用户故事虽然不是最好的需 求方法但相对于其他需求方 法范围更小，而且其对客户 可见，所以客户便于可以计 算出项目的速率便于获取项 目的进展情况。
阅读全文
摘要：每一轮迭代完成之后需要开迭代计划会议为下一轮的迭代计划。迭代计划会议包括：1、讨论故事；2、从故事中分解出任务；3、开发人员承担每个任务的职责；4、以上3项完成之后每个开发人员对其任务量估计，尽量保证自己领取的任务在下轮迭代结束时可以完成。 讨论故事：开发人员充分理解故事，在其中分解出任务；需要理清
阅读全文
摘要：小组成员：张一博，严羽卿，孙梅，何琳琳 题目： 某大学为进一步推进无纸化考试，欲开发一考试系统。系统管理员能够创建专业方向、课程编号、任课教师等相关考试基础信息。教师和考生进行考试相关工作。系统与考试有关的主要功能如下：（1）考试设置：教师制定试题（题目和答案），制定考试说明、考试时间和提醒时间等考
阅读全文
摘要：所花时间 （包括上课） 在进行需求分析时需要根据业务目标确定系统的上下文范围 ，即分析该与该系统进行外部数据交流的系统或人 在项目开始之前要对故事点进行估算， 按照优先级分配到相应的迭代长度，每 个迭代长度要尽可能短，发布计划应该 以一个可接受的日期范围为起点，包括 相应的功能。
阅读全文
摘要：因为需要将每个用户故事按重要性分配到相应的迭代过程，所以每个迭代过程的时间就可以根据用户故事大致估算出来，所以要学会估算用户故事所需的时间。估算用户故事可以采用故事点估算的方法，这种方法的优点就是团队可以定义自己认为合适的故事点，可以根据自己团队的情况具体定义，比较灵活。正因为这个原因，有的团队倾向
阅读全文
摘要：所花时间 （包括上课） 19:00~19:46 14:55~15:48 敏捷开发过程中要不断捕获用户需求， 而用户故事则根据实际用户需求在每 个迭代过程进行演进；还需要一个有 实际用户或用户代理参与的客户团队， 方便开发人员时刻了解用户对于软件 操作的需求，以及他们的使用习惯。 每个好的故事卡都是简
阅读全文
摘要：每个迭代过程后需要进行验收测试。验收测试有两个流程：1、将测试要点记录在故事卡的背面，任何时候发现新的测试，都可以记录下来；2、将测试要点变成全面的测试，这些测试用来演示故事已正确、完整地实现。而且故事卡上写有测试的一些内容会提醒程序员在实现的时候该注意什么，所以为了让程序员尽早了解测试的内容，应该
阅读全文
摘要：开发软件可以通过编写用户故事来确立开发的目标和方向。而在编写故事前首先要对所有用户进行分类，根据角色的不同属性进行分类。步骤为：1、通过头脑风暴，列出初始的用户角色集合；（要坚持‘已确认的角色代表的是单一用户’的原则）2、整理最初的角色集合；（确认角色之间的关系；用户角色定义的是人而不是外部系统）3
阅读全文
摘要：所花时间 （包括上课） 项目的首项任务是根据上下文范围确定业务目标； 阅读用户故事与敏捷方法
阅读全文
摘要：软件需求是一个软件项目成功的关键因素，许多软件项目失败都是因为软件需求的“不完整、不准确、不一致”。而软件需求是从业务需求经用户需求最终得到系统需求的，所以业务需求是软件需求的源头，而业务需求又是从客户业务中来的，客户有问题且需要解决的业务才是业务需求。所以准确、完整的根据用户的描述获取用户的业务需
阅读全文
摘要：第一步：先了解liz遇到的问题，分析这些问题发生的原因，然后将基本的系统要实现的功能讲述给liz询问其是否满意 欠缺的内容：1、缺少区别欠款账户的规则 2、客户资料的存储方式 3、系统权限分配 4、客户需要的具体的系统功能 系统功能：查看账户信息（包括历史信息） 确认问题账户 根据规则分别列出各个类
阅读全文
摘要：阅读书目：《软件需求十步走》 读后感发表日期：阅读书目：《用户故事与敏捷方法》 读后感发表日期：第一篇：10月1日 第二篇：10月3日 第三篇：10月7日 第四篇：10月15日 第五篇：10月22日 第六篇：10月29日
阅读全文
1