需求设计

需求是根据客户提的要求而做成的文档，必须遵守
设计是你根据需求文档做出的实现方案
所以设计必须基于需求

 

需求是客户的要求，他们要求什么样就是什么样

设计是将客户的要求再细化，用你的框架来实现他的需求。

在设计过程中不可避免会遇到你的设计和需求的冲突，这个一个办法是和客户协商，来修改需求，如果客户坚持，那么只能你修改设计了。

所以，还是要看客户的配合。

 

软件需求 又名软件需求规格说明书(资深架构师得出) 这个可不是用户需求(销售与用户沟通得到的)
是在用户需求的基础之上 理解分析 得出的
软件需求规格说明书应该包含 
系统的架构(硬软都有)方面,性能,安全,运行服务器等
系统的面向对象(客户)
系统的功能(明确)用软件业内词汇描述(例如:XXX线程从XX库XX表取出符合业务数据干什么事情)
数据字典(DB)设计
页面原型(根据功能 可以明确页面肯定有的元素,其他重要度不高的随便用什么元素的UI工程师负责搞定)
...

在来看设计
设计分为概要设计与详细设计
概要设计 是通过需求软件模型化
比如软件的架构分层 对模块设计 类的设计
详细设计 就是对类的详细设计 牵涉到类属性 方法的设计

从设计上来看是你需求的具体化 软件化从第0层到第2层

至于你说的需求影响设计什么的 
如果有理论上只应该是需求变更,需求变更又分为客户变更与内部变更(需求变更不多说,这个鸟东西,实在扯皮,每个公司管理需求变更都和吃S一样难)

当然以上所说的是比较标准的CMMI3+的需求与设计,但是在实际中每个公司的确不一样,我们退而求其次的做法就是根据人来定!
就和人家国外球队,是根据教练打造阵容,国内菜点,就教练适应阵容...
现阶段的项目组的人达到什么样的水平或是习惯什么 就那样去做 任何分析设计都是在准确无误的传递消息,就与写方法一样
谁规定非要这样定义方法 参数是这个就行了?
目的只是为了明确,在明确的前提下 在形成一些规定.

 

A 需求关注功能，设计关注性能
B 需求关注做什么，设计关注怎么做
C 需求关注销售，设计关注成本
D 需求关注概要，设计关注详细
E 需求是文档，设计是图形
F 需求可以不用UML，设计要用UML