[讨论]需求获取在系统开发中的地位

引:面对一个系统,如何能做好需求,如果确实做不好这个需求,那么在设计开发中该注意些什么?
当有需求变更的时候,不能不改变原来的需求,或者加进新的功能需求,那又该怎么办?
面对自己的代码越来越庞大,该怎么办?
如何在实际开发过程中做到代码精简?


需求分析:
在学校的时候,一直就在学软件工程相关的东西。老师们就是一个劲的给我们灌输需求——》设计——》开发——》需求维护管理的思想。
也一直觉得就是应该这样的:需求确定了之后,再设计,设计好了,再编码。
可是,在实际情况中,往往很多时候没有那么多时间让你去获取需求、设计框架。
还有的情况是想尽力获取需求的,可是无奈不可能获取整个系统的所有需求。

我的情况:
这个时间,我一直在做一个项目,是公司自己根据市场需求设计开发的,而不是由其他提出要求的。
由于,我是一个纯新手,但是公司决定做这个项目,很大程度上是想让我学习学习。
一开始在开发的时候,也大致获取了一些需求,然后根据这些需求,再加点自己的想法,就上马了。可是,到了商家那儿,有一些是对的,可是另一些他根本就不这么干。
所以,他提出了他自己的看法。觉得有理,就改程序。
一开始在改的时候,也希望能够为日后的维护打好基础,尽量做到代码的可读性,和可维护性。
可是久而久之,我们本身和商家对自己的要求也都越来越高了。我们当初没有想到的,他当初没有想到的需求,都慢慢地冒出来了。
也久而久之,在不断的改代码的过程中,我自己也开始对自己的代码感到陌生了:越来越庞大,越来越复杂。
然后,到最后,变得是牵一发而动全身。

我也非常的清楚,这些其实都是需求获取没有做好,当然,设计本身也是一个非常大的漏洞。
但是,面对这样的情况(当初一时不能确定所有的需求,是真的不能确定,某些需求是要在系统功能加强的基础上才会显现出来):不知道各位是如何处理的。

大家不妨讨论讨论。

汇聚杭州外卖:外卖汇
Tag标签: 需求
posted @ 2008-03-18 17:26 随风逝去(叶进) 阅读(1626) 评论(20)  编辑 收藏 所属分类: C. 软件工程

  回复  引用    
#1楼 2008-03-18 18:16 | crash123 [未注册用户]
尽量把自己认为独立的模块封装.实在变化太大了,就只有小块的重写.实际上在开发的一开始无法得到客户最真实的需求,要是作项目的化,就好办,一开始都白纸黑字的写在那,客户想加功能都不行,加功能就意味着加钱.要是内部项目的话,就只有先应付着,在最开始的时候,尽量作些臃余设计.重复使用的功能尽量调用一个模块.等需求都了解的差不多的时候,就开始重写优化程序.

一句话,不要指望客户能一开始就知道他们想要什么,只有当他们看到东西,才知道他们真正想要什么.如果时间充裕的化,建议作个原型,给他们看.
  回复  引用  查看    
#2楼 2008-03-18 19:09 | chegan      
需求分析的重要再怎么强调都不为过,需求的获取根据不同的用户也是千差万别。并且也是在不断变化着的,我们能做的就是尽量考虑的多点,询问的多点,示例多点,引导多点
  回复  引用  查看    
#3楼 2008-03-18 19:33 | 金色海洋(jyk)      
其实微软在这方面做得就很好,看看windows的发展就知道了。

windows 95 不断地出补丁

补丁多了出了一个 windows 98

再不断地出补丁,


然后用nt的内核作了一个 windows me 。

winme 不理想,然后又出了一个 xp,才算是稳定了一些,但是还是不断地出补丁。

现在是 vista了。


结合你的情况(其实是我对你的描述的理解)和我的经验做一个假设:

第一天我们拿到了 一成 的需求,这时我们会认为这就是几乎全部的需求了,于是我们开始做设计,然后编写代码。

第二天,我们拿到了两成的需求,由于变动不是很大,于是我们只做了点小的修改,

第三天,我们拿到了三成的需求,由于变动不是很大,于是我们又做了点小的修改,

第四天,我们拿到了五成的需求,傻眼了,变化比较大,怎么办?继续做小的修改吗?已经力不从心了,已经快失控了!

这时候我们是不是应该拿着这已知的五成需求重新做一下设计,然后尽量地设想或者询问出来剩下的五成以及未来的需求。


当然我们不可能一下就做到很理想,其实两三个循环下来也未必能够理想。



好像我说的这些和你学校里说的也差不多。


需求固然重要,但是更重要的是经验,现在你遇到的困境,80%的原因是由于你的经验不足造成的。

而不是你说的没做好需求。



1、举一反三,不要用户提出来一个需求就只考虑一个需求,还要考虑到相关的和雷似的需求。

注意:这里说的是“考虑”,考虑 != 实现。

2、没了,尽量多的积累经验吧。

3、因为要不断地重构,所以前期要轻装简行,行动要快,

可以用点打草惊蛇的方法,把客户的需求全都引出来。


  回复  引用  查看    
#4楼 2008-03-18 19:41 | 金色海洋(jyk)      
这个模板有问题,回复的右面的文字都被挡住了。
  回复  引用  查看    
#5楼 2008-03-18 22:19 | 电机拖动      
@金色海洋(jyk)
WinMe是3.x内核系列的吧?
  回复  引用  查看    
#6楼 2008-03-18 22:26 | 电机拖动      
博主说的问题的确是一个需求问题

但从文中看来,你们的软件一开始是行业软件,后来怎么又成专用软件了?

不管是行业通用的,还是某用户专用的,都是有需求的。绝对不是自己猛想就行的。既然你们的产品做出来是为了给别人用,那么你就需要去找目标客户讨论需求,至少也需要行业专家才行,不然做出来的东西真不知道是给谁用的了……

另外,需求与设计虽然有关系,但是不会说紧密到什么地步上去,毕竟,没有谁敢说自己的软件就完全符合用户需求的,要知道需求肯定会变的(全世界都这样,不仅仅是咱们中国),你的框架再好,也不能说能够一劳永逸。这点上,我觉得金色海洋说的不错,patch多了就直接出新版本(不然,免费维护期要多少年才够呢?)
  回复  引用  查看    
#7楼 2008-03-18 22:30 | spgoal      
需求变更在整个软件开发过程都存在,按照你所说的,这样完全迁就客户,就算在灵活的软件架构也顶不住,还是要靠一些商务的手段来限制其无休止的变更需求。
  回复  引用  查看    
#8楼 2008-03-18 23:15 | 金色海洋(jyk)      
@电机拖动
记不清了,不过这个不重要的.

重要的是在这个模版里面,一行不能写太多的文字,多了的话,后面的就看不到了.
像我这样,手动的多敲几个回车,强制换行。


开个玩笑.:)
  回复  引用    
#9楼 2008-03-19 08:40 | jackyw [未注册用户]
迭代开发,一开始要开发与系统核心相关的模型,使用领域模型的方式而
不是事物脚本的形式,因为随着逻辑的复杂事物脚本形式会更加复杂。
即使开始时不是事物脚本的形式,以后也要不断重构,消除重复代码。
在系统越来越庞大的时候,要分离核心领域和辅助领域以及基础架构代码。

  回复  引用  查看    
#10楼 [楼主]2008-03-19 09:20 | 随风逝去      
@金色海洋(jyk)
@电机拖动
出个新版本是不是推翻原来的设计,重新来过;或者是借鉴原来的...?
如果是这样,在开发成本上会不会太大啊?
  回复  引用  查看    
#11楼 [楼主]2008-03-19 09:21 | 随风逝去      
@spgoal
变更管理肯定是要的,可是就是在客户提出需求之后,发现这些需求还确实这么回事。当然,有些需求还是立马可以枪毙掉的!
  回复  引用  查看    
#12楼 [楼主]2008-03-19 09:22 | 随风逝去      
@金色海洋(jyk)
关于模板的问题,我就不清楚了,前一个模板,有朋友反映是IE下显示不正常!
郁闷!
  回复  引用  查看    
#13楼 [楼主]2008-03-19 09:25 | 随风逝去      
@电机拖动
系统其实应该是个行业软件,只是在给具体的客户看的时候,他就提出了自己的想法。
而且,不同的客户提出的需求有时候还会矛盾! 当然,基本是一致的!
  回复  引用  查看    
#14楼 [楼主]2008-03-19 09:27 | 随风逝去      
@jackyw
重构、消除重复代码不知道一般是如何进行的?
各位有没有好的介绍或学习资料啊?
  回复  引用    
#15楼 2008-03-19 11:50 | 喝小酒的网摘 [未注册用户]
版本控制没有做好:)
  回复  引用  查看    
#16楼 2008-03-19 13:31 | xiao_p      
想要一步到位的了解需求 个人感觉基本是不太可能的。

迭代的开发 是比较可取的。

但是,如果涉及的人数比较多,需求难以整理的情况下,还是走一步看一步吧! 呵呵,这种情况给谁做都比较困难!
  回复  引用    
#17楼 2008-03-19 17:01 | ligc [未注册用户]
面对不断变化的客户需求,从程序角度来讲可以多融入一些设计模式,提高可扩展性。
  回复  引用  查看    
#18楼 2008-03-19 18:25 | 金色海洋(jyk)      
>>出个新版本是不是推翻原来的设计,重新来过;或者是借鉴原来的...?
>>如果是这样,在开发成本上会不会太大啊?


第一个问题要看实际情况,看情况而定。

第二个问题,成本确实会很大,所以才会有一些公司坚持不下去了,倒闭了。

残酷了一点,但是社会就是这样。

  回复  引用  查看    
#19楼 2008-03-20 12:35 | 毁于随      
这样的问题很突出.也就是一直在讨论的敏捷开发和迭代开发.另外,在架构的设计上也肯定存在N多问题,运用设计模式以及必要的软件工程理论来改进开发过程.这不是一个短时间可以通过自己的摸索而能领悟的东西,不过还好是我们能看到存在这样那样的问题,这样才会有目标,能看到差距.留个名,学习中....
  回复  引用  查看    
#20楼 [楼主]2008-03-20 13:39 | 随风逝去      
@毁于随
软件工程的思想要付诸实践才是有用的。其实,在很多情况下我感觉,理论的东西应该都懂,只是在实际操作的时候就有点偏差了。

标题  
姓名  
主页
Email (博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
博客园首页

新闻频道

社区

小组

博问

网摘

闪存

  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2008-03-25 14:45 编辑过
成果网帮您增加网站收入


相关链接:
 
Free Web Counter
Free Web Counter