51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

楼主: ghl5502
打印 上一主题 下一主题

需求规格说明书由谁来写?

[复制链接]

该用户从未签到

41#
发表于 2006-5-26 15:56:42 | 只看该作者
应该是有市场人员写!
市场人员是接触客户的,知道和了解客户的要求。
系统分析以后,写好需求,然后要客户确认,客户确认签字以后,交给研发部门。
回复 支持 反对

使用道具 举报

该用户从未签到

42#
发表于 2006-6-3 20:37:43 | 只看该作者
当然是由需求分析人员来写了。
回复 支持 反对

使用道具 举报

该用户从未签到

43#
发表于 2006-7-28 16:30:13 | 只看该作者
完整的流程应该是这样的:
需求规格说明书-由企业IT部门组织企业各部门提出需求,由企业IT部门来写
需求规格说明书-IT企业的系统分析员与企业各部门沟通,对能力很强的企业可以只和企业IT部门沟通
概要设计书-这个时候软件工程才可能上,优秀IT企业可能软件开发工程这个时候还在休息
回复 支持 反对

使用道具 举报

该用户从未签到

44#
发表于 2006-7-31 08:25:20 | 只看该作者
我们公司的用户需求是用业务代表来写,软件需求是由BA来写
回复 支持 反对

使用道具 举报

该用户从未签到

45#
发表于 2006-8-2 17:25:52 | 只看该作者

这样的!

一、需求文档分为:
1、需求规格说明书:完全反应客户最原始的需求,理想的情况下是完完全全记录客户的一言一行而不掺杂任何分析的成分。
很显然,不能由研发人员来写,我们目前是有专门的需求调研人员,由产品经理领导,不涉及到任何UML图
2、需求分析说明书:在客户原始需求的前提下,进行分析归类,并得出不能实现的需求,同时提出需求调研阶段没有明确的需求,这一部分需要调研人员再进行调研,也就是说,需求规格与需求分析有一部分时间是重叠的
这一部分由需求分析的人员来写,一般是经验比较丰富的系统分析人员
二、设计文档分为:
1、概要设计文档:主要是在需求分析说明书的基础上进行,着重在对功能模块的划分、功能流程的细化整理、实体关系的整理、系统间接口的明确,当然最好数据库表也能设计得差不多
2、详细设计文档:在概要设计文档的基础上进行,着重在具体的界面流程的整理、数据库表的完善、系统间接口字段的明确。
三、开始coding

特别的是:在上面的三个大的阶段中,需求调研人员是始终需要参与的,因为无论你那个阶段做得多么好,都不太可能完完全全符合客户的需求(不是你笨,只因为需求是动态的:)),所以需要不断地与客户进行确认、沟通。

欢迎交流:nbm0@hotmail.com
回复 支持 反对

使用道具 举报

该用户从未签到

46#
发表于 2006-8-9 01:54:12 | 只看该作者
说的很好。。。
回复 支持 反对

使用道具 举报

该用户从未签到

47#
发表于 2006-11-2 13:49:38 | 只看该作者
我觉得测试需求分析应该是测试的主管根据软件需求说明写的,然后测试人员 再根据测试需求说明写测试用例。
回复 支持 反对

使用道具 举报

该用户从未签到

48#
发表于 2006-11-7 11:04:55 | 只看该作者
原帖由 tigerricky 于 2006-3-14 17:22 发表
我也来说两句:
软件需求说明书在CMMI三级中是属于需求开发过程的产物。
需求开发过程包括:
1、需求获取
2、需求分析
3、编写需求规格说明书
4、需求确认
5、需求管理

它是在需求获取、分析之后的, ...


Good,and clear.
回复 支持 反对

使用道具 举报

该用户从未签到

49#
发表于 2006-11-28 14:03:44 | 只看该作者
回复 支持 反对

使用道具 举报

该用户从未签到

50#
发表于 2006-12-9 15:25:03 | 只看该作者
应该由市场部门调查收集资料,将用户需求提交给研发部分,技术上分析能否实现,再交个市场部门,如果有异议,进行讨论,之后又市场拟订需求,再交给研发,之后交个测试部门审核
回复 支持 反对

使用道具 举报

该用户从未签到

51#
发表于 2006-12-29 17:40:35 | 只看该作者
这个环节和测试部门应该没有什么关系的,以下是工作的经验
软件本身分两种的,一种是产品,一种是项目;他们的前期过程是不一样的。项目的话,一般是在合同签订之后开始需求阶段,按正规的流程的话,先要有需求调研计划,用户也要确认的,然后在需求调研中可能还有一些辅助文档,比如调研问题表什么的,调研是由项目开发组的人做的,一般是系统分析组(很多都是一两个系统分析员加几个项目组开发人员,某些项目可能还会有业务咨询师,总人员不会少于2个,人数和项目规模有关),调研完成后,由系统分析组的编写项目需求,然后由内部评审,客户评审签字等一系列流程。产品的实际工作中只作个一个,还是公司内部产品,不具有代表性。一般产品有前期市场调查,可行性分析等工作。编写需求的也还是系统分析人员,市场人员可以在此过程中做咨询或者评审。不论产品还是项目,没有见过单纯市场人员写出过需求的。
回复 支持 反对

使用道具 举报

该用户从未签到

52#
发表于 2007-1-19 10:04:48 | 只看该作者
原帖由 hxf 于 2004-10-9 16:34 发表
需求规格说明书,应该由专门的需求人员来写。


赞同!
回复 支持 反对

使用道具 举报

该用户从未签到

53#
发表于 2007-1-25 14:57:53 | 只看该作者
应当是由售前-咨询顾问来写。
但是我也写过。
回复 支持 反对

使用道具 举报

该用户从未签到

54#
发表于 2007-2-19 03:40:33 | 只看该作者

回:

有一种责任叫回帖!大大的一个论坛的版块,如果形成一种回贴(不是灌水)的氛围,版块的兴盛应该指日可待。如果版块是一盆火,那么大家都来烤火的人,所谓是众人拾柴火焰高,如果没了众人的拾柴,并且每一个人都指望着别人的回贴来提高自己的浏览机率,而自己并不想去回别人的贴,那么,这将是坛子即将没落的前兆。
回复 支持 反对

使用道具 举报

该用户从未签到

55#
发表于 2007-2-19 03:40:57 | 只看该作者

回:

有一种责任叫回帖!大大的一个论坛的版块,如果形成一种回贴(不是灌水)的氛围,版块的兴盛应该指日可待。如果版块是一盆火,那么大家都来烤火的人,所谓是众人拾柴火焰高,如果没了众人的拾柴,并且每一个人都指望着别人的回贴来提高自己的浏览机率,而自己并不想去回别人的贴,那么,这将是坛子即将没落的前兆。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    郁闷
    2014-11-5 22:10
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    56#
    发表于 2007-2-25 17:06:26 | 只看该作者
    在我们公司好象是又市场人员提出,PM撰写,最后通过评审
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    57#
    发表于 2007-3-14 17:56:10 | 只看该作者
    我比较赞同tigerricky 和nbmty 的回答, 呵呵,
    其实需求规格说明书可能由专门的需求调研人员来写, 也可能由PM或者开发人员来写,也有可能是大家共同来完成的。
    但是我们是不是对于需求规格说明书应该有一个定论? 比如它包含哪些内容? 因为很有可能有些公司的需求规格说明书包含的内容不同, 所以导致了大家的理解不同。
    另外就是需求规格说明书完成的时间点应该比较重要, 比如说它一定要在进行设计之前确认完毕才可以。
    反而是讨论由谁来写似乎没有那么重要了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    58#
    发表于 2007-3-16 13:40:32 | 只看该作者
    谁写无所谓,关键是写出合格的需求说明书,我认为。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    59#
    发表于 2007-3-24 16:39:40 | 只看该作者
    在我们这由PM来写,工程师写不合适
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    60#
    发表于 2007-4-12 09:56:26 | 只看该作者
    我们公司没有系统分析师,只有产品助理、测试工程师、实施工程师、架构师这几个岗位,我觉得这几个岗位中,架构师来做需求分析是最适合的,特别是UI,UC的设计,可是架构师确不认为这是他的工作,而推给产品助理来完成。大家认为呢?
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-22 03:08 , Processed in 0.077352 second(s), 20 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表