1,265
社区成员
发帖
与我相关
我的任务
分享需求分析完了接下来做什么？
需求分析告一段落，业务需求都有了，UC也差不多写好了，接下来是设计，设计阶段该干什么呢？
我感觉：
1.确认系统的物理结构，网络拓扑
2.需求分级
3.类图
4.ER图
5.交互图
...后面干什么呢？
我感觉：
1.确认系统的物理结构，网络拓扑
2.需求分级
3.类图
4.ER图
5.交互图
...后面干什么呢？
...全文
请发表友善的回复…
发表回复
wwolfboy 2005-03-30
- 打赏
- 举报
后面该是DFD图了
soft_2008 2005-03-30
- 打赏
- 举报
programming....how mary use case do you have?how mary project do you join and successful?how do you think your plan is pass?!how about the guest think and point?
selinachen 2005-03-30
- 打赏
- 举报
转自林锐博士的培训稿
3.2 需求开发过程域
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。
需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
3.3 需求管理过程域
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
3.2 需求开发过程域
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。
需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。
需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。
需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。
3.3 需求管理过程域
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。
需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。
需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
pwpw 2005-03-29
- 打赏
- 举报
那要看你是个什么开发模型咯
比如 瀑布型 喷泉型 螺旋型 等等
一般需求之后是概要设计、详细设计、编码、测试
其实我认为在详细设计和编码之间应该还有个重要的测试报告书的阶段
这样对编码会带来很好的效果，而不是等到编码完了后再去写测试报告书
比如发现一些业务逻辑上的或别的错误时，不至于重新编码
比如 瀑布型 喷泉型 螺旋型 等等
一般需求之后是概要设计、详细设计、编码、测试
其实我认为在详细设计和编码之间应该还有个重要的测试报告书的阶段
这样对编码会带来很好的效果，而不是等到编码完了后再去写测试报告书
比如发现一些业务逻辑上的或别的错误时，不至于重新编码
sword_hero 2004-09-20
- 打赏
- 举报
5，jinhongze说的有道理
jinhongze 2004-09-20
- 打赏
- 举报
瀑布型虽然很经典，但是问题也很多，完全的瀑布型是很理想化的，我建议你多研究一下迭代增量模型。
jinhongze 2004-09-20
- 打赏
- 举报
其实需求分析要在配合版本控制的前提下反复迭代，就像绘画一样，从打轮廓开始，逐渐细化，反复到用户那里确认，越接近用户需求，刻画的越细腻，那么你分析出来的东西就越有价值，将来生产出来的产品就越成功。至于在软件开发的这条“流水线”上的下一步就是结合自己公司的实际情况（如已有的技术平台、技术研发力量和技术核心储备等）进行设计，当然也是由粗到细的过程。评审报告可能对极限编程不太合适，但适当在这条流水线上的设置若干检查点进行项目监控还是很有必要的，就是总要纠正项目是否“跑偏”。当然这也要结合自己公司的实际情况。CMMI是好东西，但我们要我们要抓住精髓，而不要拘泥于形式。
sword_hero 2004-09-20
- 打赏
- 举报
to chenlong9610(剑魔)
评审报告？我们这的需求评审结果就是"通过:
评审报告？我们这的需求评审结果就是"通过:
chenlong9610 2004-09-11
- 打赏
- 举报
to sword_hero(sword)
对你做的需求分析做同行评审，拿出评审报告！
对你做的需求分析做同行评审，拿出评审报告！
sword_hero 2004-09-10
- 打赏
- 举报
可以认为通过需求评审了，下一步要干什么啊？
就是项目经理写项目计划，项目计划写完之后，就是总体设计，详细设计，编码。。。。。。。
总体设计，详细设计，编码阶段都干些什么啊
就是项目经理写项目计划，项目计划写完之后，就是总体设计，详细设计，编码。。。。。。。
总体设计，详细设计，编码阶段都干些什么啊
chenlong9610 2004-09-10
- 打赏
- 举报
当然，每做好一步都需要同行评审，确立理程碑，通过之后，才能进行下一步！
chenlong9610 2004-09-10
- 打赏
- 举报
to sword_hero(sword)
不知道你有没有通过同行评审，是对你写的需求规约的同行评审，你现在已经进入了比较关键的时候，千万不能少同行评审，只有通过同行评审，需求基线才能确定。
当然需求确定之后，就是项目经理写项目计划，项目计划写完之后，就是总体设计，详细设计，编码。。。。。。。
不知道你有没有通过同行评审，是对你写的需求规约的同行评审，你现在已经进入了比较关键的时候，千万不能少同行评审，只有通过同行评审，需求基线才能确定。
当然需求确定之后，就是项目经理写项目计划，项目计划写完之后，就是总体设计，详细设计，编码。。。。。。。
sword_hero 2004-09-10
- 打赏
- 举报
各位大歌，讨论一下需求分析基本完成后，进入设计阶段该怎么做吧
rose together都好
rose together都好
chenlong9610 2004-09-10
- 打赏
- 举报
to dearmite(笨笨的我*_^)
使用ROSE工具，公司体制要效好，而且需要有一定的基础（效贵），而且一般小公司不会去购买（10-20人）！像这样的公司太多了！
ROSE是一个非常好的工具。
使用ROSE工具，公司体制要效好，而且需要有一定的基础（效贵），而且一般小公司不会去购买（10-20人）！像这样的公司太多了！
ROSE是一个非常好的工具。
项目花园范德彪 2004-09-10
- 打赏
- 举报
另外,ROSE,出了一堆的模型,
写代码人员也跟不上,
TOGETHER这一点可和ROSE不一样了,
几乎是,出一几个类之后,
有些代码,公用的东东,就可以着手了,
就算是前面把类设计错了,
方法定错了,
也没有关系,重构就是了,
<重构>那书的作者不是说,
"每天都构建"么,
写代码人员也跟不上,
TOGETHER这一点可和ROSE不一样了,
几乎是,出一几个类之后,
有些代码,公用的东东,就可以着手了,
就算是前面把类设计错了,
方法定错了,
也没有关系,重构就是了,
<重构>那书的作者不是说,
"每天都构建"么,
项目花园范德彪 2004-09-10
- 打赏
- 举报
ROSE也支持一些重构
但是,不支持类,抽象出接口,
不支持,......
而这些个功能,在设计的过程中,太重要了,
ROSE讲究的是总体出发,
一次性定好????
但现在,<重构>,的理论,是完全相反,
也比较合乎情理,
偶也认为这样做容易一些,
先是拍拍,把类搞出来,
然后,再重构,
合并等等,
感觉比ROSE快上不少,
但是,不支持类,抽象出接口,
不支持,......
而这些个功能,在设计的过程中,太重要了,
ROSE讲究的是总体出发,
一次性定好????
但现在,<重构>,的理论,是完全相反,
也比较合乎情理,
偶也认为这样做容易一些,
先是拍拍,把类搞出来,
然后,再重构,
合并等等,
感觉比ROSE快上不少,
sword_hero 2004-09-10
- 打赏
- 举报
to 剑魔
你说的是需求分析阶段的活动是吗？目前我们的UC基本写完了，也就是说，需求评审完成了，当然，还会去迭代的，我们进入了设计阶段，主要的活动是什么呢？
你说的是需求分析阶段的活动是吗？目前我们的UC基本写完了，也就是说，需求评审完成了，当然，还会去迭代的，我们进入了设计阶段，主要的活动是什么呢？
项目花园范德彪 2004-09-10
- 打赏
- 举报
我现在的感觉是,
设计前半段,用ROSE,
等是需求的细化,与类化,
然后,生成JAVA代码后,
马上,转用eclipse +together,
这个重构的功能,
模型和代码一致性上,ROSE是无论如何追不上了,
尤其是现在的eclipse3.0 + together6.3
速度又快,又好用,
设计前半段,用ROSE,
等是需求的细化,与类化,
然后,生成JAVA代码后,
马上,转用eclipse +together,
这个重构的功能,
模型和代码一致性上,ROSE是无论如何追不上了,
尤其是现在的eclipse3.0 + together6.3
速度又快,又好用,
chenlong9610 2004-09-10
- 打赏
- 举报
1、可以做业务流程图和业务描述！业务流程图和业务描述一一对应！
2、业务流程图：图形模式，可泳道图
3、业务描述：用户操作界面，业务规则（如，客户要是总经销商）！
4、补充规约。
需求规约做好之后，需要同行评审（内部），修改，内部做好之后用户确认。
用户确认之后，修改，需要将“需求规约”基本定型，那么“需求基线”基本确定！
2、业务流程图：图形模式，可泳道图
3、业务描述：用户操作界面，业务规则（如，客户要是总经销商）！
4、补充规约。
需求规约做好之后，需要同行评审（内部），修改，内部做好之后用户确认。
用户确认之后，修改，需要将“需求规约”基本定型，那么“需求基线”基本确定！
sword_hero 2004-09-10
- 打赏
- 举报
虾米钱啊
加载更多回复（3）
