【摘要】：需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意几个问题：有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。既然前人付了学费，后人就不要拒绝坐享其成。
3.1.2 需求分析如何进行
需求分析不像侦探推理那样需从蛛丝马迹着手，而是应该先了解宏观的问题，再了解细节的问题。
一个应用软件系统（记为S）的涉及面可能很广，可以按不同的问题域（记为D）分类，每个问题域对应于一个软件子系统。
S=｛D1，D2，D3，…，Dn｝
问题域Di由若干个问题（记为P）组成，每个问题对应于子系统中的一个软构件。
Di=｛P1，P2，P3，…，Pm｝
问题Pj有若干个行为（或功能，记为F），每个行为对应于软构件中的实现接口。
Pj=｛F1，F2，F3，…，Fk｝
需求说明书应该对于那些只想了解宏观需求的领导，和需要了解细节的技术员都合适。在写需求说明书时应该注意几个问题：
（1）最好为每个需求注释“为什么”，这样可让程序员了解需求的本质，以便选用最合适的技术来实现此需求。
（2）需求说明不可有二义性，更不能前后矛盾。如果有二义性或前后矛盾，则要重新分析此需求。
了解需求的方式有好几种：
（1）直接与客户交谈。如果分析人员生有足球评论员的那张“大嘴”，就非常容易侃出需求。
（2）有些需求客户讲不清楚，分析人员又猜不透，这时就要请教行家。有些高手真的很厉害，你还没有开始问，他就能讲出前因后果。让你感到“听君一席言，胜读十年书。”
（3）有很多需求可能客户与分析人员想都没有想过，或者想得太幼稚。要经常分析优秀的和蹩脚的同类软件，看到了优点就尽量吸取，看到了缺点就引以为戒。既然前人付了学费，后人就不要拒绝坐享其成。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
