首先这本书主要讲述了
·问题分析的五个步骤
·业务建模和系统工程
·从客户和涉众那里启发需求的技术
·建立和管理项目范围
·应用和细化用例
·产品管理
·从需求到设计和实现的过渡
·从用例到测试用例的过渡
·敏捷需求方法
初读这本书时从网上看到一句话让我受益匪浅：识别事件的方法:头脑风暴法-主语+谓语+宾语,描述系统可能发生的事情,尽可能全面,同样是宁多勿少的原则,不过你可以根据事件的重要程度进行一个排序,这能加深你对系统的认识
我们仔细理解这句话：
系统边界和参与者，参与者Actor定义:在系统之外,透过系统边界和系统进行有意义的交互的任何事物，透露出参与者的特征:
首先不属于系统，然后通过系统边界直接和系统交互->参与者的确定决定了系统边界的确定，再有进行有意义的交互，最后任何事物
其中第二点的"直接"要注意:如果一个顾客通过售票员买机票,那么对于售票系统来说,售票员是参与者而顾客不是.由此又产生了业务建模和系统建模的区别:对于售票系统来说,当业务建模的时候,我们描述的是顾客来订票,可能还有票务中心的主任来询问售票情况等等事件.但是系统建模的时候,他们都不是我们的对象,我们描述为售票员要售票和提供售票情况的事件的描述,因此这两者在建模的不同阶段是不一样的. 在有些自动系统中,时间往往是触发系统工作的外部事物,因此参与者是时间,不可忽略.
再者就是我们识别参与者方法:面对一个系统时,我们应该问这些问题:谁使用系统?谁改变系统数据?谁从系统获取信息?谁需要系统的支持来完成日常工作?谁负责管理并维护系统正常运行?系统要应付那些硬设备?系统要和其他的系统交互吗?谁对系统产生的结果感兴趣?时间,气候等外部条件呢?当你回答完这些问题之后,你的答案基本上就涵盖了参与者。
再往深处读就会发现。识别参与者的重要性:
根据参与者识别系统用例:因此为了完整系统的功能,你识别的系统参与者宁多勿少.。测试部署阶段你可能会通过识别者的角度去了解系统的完整性.。用例文档编写阶段,参与者不是很重要,但是你应该考虑参与者的泛化关系,避免出现用例的重复功能.
就像我们开发的河北省重大技术需求征集系统就可以发现；我们如果着手创建这个系统首先就要确定参与人员，由此可见重要性，参与者有某个机构的填报员，某个政府部门的审核员以及指派的系统管理员，人后我们才可以去确定功能以及其他的一些基本的信息，这也就是这本书中一开始教会我们的东西，获益匪浅。