2017-1分析师论⽂：论需求分析⽅法及应⽤
本⼈以“铁路公安派出所业务管理系统”项⽬的开发为背景，着重论述了需求分析⽅法中的⾯向对象分析的整个过程。
该项⽬的建设⽬标是：（1）建⽴枪⽀弹药管理数据中⼼，存储枪⽀弹药的信息和出⼊库的记录数据。（2）合理安排和管理派出所值班备勤警⼒。（3）建⽴执法场所管理数据中⼼，对执法场所的监管更加合理化、及时化。（4）显⽰屏显⽰统计信息。系统需要考虑到推⼴到其⼦管辖区的派出所，并于将来对接智能枪弹管理系统，系统需具有良好的扩展性和松耦合性。
在项⽬开展期间，我担任了系统分析、系统设计与数据库管理等⼤量⼯作。在项⽬需求分析和设计阶段，我着重考虑好系统的框架和原型，为项⽬组及其他分析员进⾏下⼀步的细化分析奠定了坚实的基础。
需求分析的⼯作通常包括以下⼏个⽅⾯：
1. 绘制系统上下⽂范围关系图
⽤于定义系统与系统外部实体间的界限和接⼝的简单模型，它可以需求确定⼀个范围。项⽬需要对接公安局现有的警钟系统，并对在执法场所拘留时间到的嫌疑⼈予以释放，所以系统外部实体包括警钟系统和系统时钟。
2. 创建系统原型
通过快速开发⼯具开发⼀个抛弃式原型，将帮助⽤户更好理解所要解决的问题，更好理解系统。我是使⽤axure 9.0快速进⾏页⾯的简单跳转。
3. 分析需求的可⾏性。
对所有获得的需求进⾏成本、性能和技术实现⽅⾯的可⾏性研究，以及这些需求项是否与其他的需求项有冲突，是否有对外的依赖关系等。
4. 确定需求的优先级
对于需求优先级的描述，可以采⽤满意度和不满意度指标进⾏说明。其中满意度表⽰当需求被实现时⽤户的满意程度。不满意度表⽰当需求未被实现时⽤户的不满意程度。
5. 为需求建⽴模型
即建⽴分析模型，这些模型的表现形式主要是图表加上少量的⽂字描述。根据采⽤的分析⽅法不同，采⽤的图也将不同。需求分析模型主要描述系统的数据、功能、⽤户界⾯和运⾏的外部⾏为，它是系统的⼀种逻辑表⽰技术，并不涉及软件的具体实现细需求分析模型可以帮助系统分析师理解系统，使需求分析任务更加容易实 。同 时它也是以后进⾏软件设计的基础 为软件设计提供了系统的表⽰视图。
6. 创建数据
数据字典是对系统⽤到的所有数据项和结构进⾏定义， 确保开发⼈员使⽤了统⼀的数据定义。因为涉及到枪⽀信息，我特意参考了下《枪⽀管理信息规范》标准来定义枪⽀代号等字段。
7. 使⽤QFD（Quality Function Deployment，质量功能展开）⽅法
将产品特性、属性与对⽤户的重要性联系起来。
考虑到⽤户要求系统将来可以拓展到管理⼦派出所，我们采⽤多租户的ABP（ASP.NET Boilerplate）框架。ABP是⼀个开源的基于
DDD（Domain-Driven Design，领域驱动设计）的强⼤架构模型。为了系统的可⽤性，我们选择跨平台的 core，并前后端分离的angular版本的ABP。因为ABP本⾝是使⽤⾯向对象设计的，为了接下来在整个系统⽣命周期中更好地与系统设计、系统实施衔接，所以在需求分析阶段，我采⽤OOA⽅法对系统进⾏分析。
OOA主要使⽤UML（Unified Modeling Languge）进⾏建模。在项⽬中，我使⽤Microsoft Office Visio 2013 来绘制分析中所需的UML图。OOA过程主要分为⽤例模型、领域模型和分析模型。
1. ⽤例模型
⽤户模型主要是从⽤户的⾓度去建模。
（1）识别参与者
参与者是与系统交互的所有事物。这⾥有⽤户（警员、后勤⼈员）、警钟系统、提醒关押嫌疑⼈时间到的时钟
（2）合并需求获得⽤例
将参与者找到之后，需要为每⼀个参与者确定⽤例。将需求分配给相关参与者，如警⼒排班分配给⼤队队长；枪⽀出⼊库分配给仓库管理员。其次，进⾏合并操作。将识别到的参与者与合并⽣成的⽤例通过⽤例图的形式整理出来，获得⽤例模型的框架。需注意业务⽤例（Business U Ca）和系统⽤例（System U Ca）。⽐如告警是系统⽤例，⽽审核是业务⽤例。
（3）细化⽤例描述
⽤例模型的主要⼯作是形成⽤例规约（U Ca Specification）。⽤例模板定义了⽤例规约的结果。
（4）调整⽤例模型
建⽴初步⽤例后，还需要⽤⽤例之间的关系（主要是关联、依赖（包含、拓展）和泛化）来调整⽤例模型。把⼀些公共信息抽取出来，使系统松耦合，更易维护。⽐如权限管理⽤例，只有审核⼈员才具有枪⽀申请审核功能、导出警⼒排班信息为拓展⽤例。
2. 分析模型
（1）定义概念类
OOA的中⼼任务是找到系统中的对象或类。在命名上，因为ABP的实体需映射到数据库表的实体集DbSet（⼀般使⽤复数），所以在实体类命名中，我们采⽤名词单数。例如枪⽀Gun，我们可命名对应的DbSet为Guns，那么枪⽀的数据库表就为Guns。ABP可以在实体类中使⽤数据标注修改表名或者重载DbContext的OnModelCreating⽅法统⼀为所有的表添加表名前缀，所以我们定义在定义类名时尽量简洁。
（2）确定类之间的关系
类之间的关系可分为关联、依赖、泛化、实现、聚合、组合等。因为DDD的类都继承⾃实体类Entity或者Entity的⼦类
（FullAuditedEntity、AuditedEntity），所以，类之间泛化少，以关联为主。枪⽀类中包含了弹药信息，属于组合关系。类图组合在⼀起可形成领域模型。
（3）为类添加职能
类的职能包括：类的成员变量或属性、类的成员⽅法。⼀个实体类对应定领域层的Entity（实体），DD
D中的实体定义中，实体并不是通过它们的属性定义的，⽽是通过⼀连串的连续性事件和标识定义的。因此我们每个实体都赋予⼀个唯⼀标识的Id，对属性并未很严格，反⽽在成员⽅法上多做丰富。
（4）建⽴交互图
多个对象的⾏为通常采⽤对象交互来表⽰。UML2.0提供的交互图有顺序图、交互概览图、通信图和定时图。我⽤visio画出参与对象（警员⽤户、申请审核者、仓库管理员）在枪⽀申请信息、申请审核信息、枪⽀出库信息、枪⽀⼊库信息的顺序图等。
将⾯向对象的分析⽅法与基于DDD的ABP框架结合起来，使整个开发过程都很清晰流畅。但是因为ABP本⾝⾼集成的，灵活化⽤难度⾼，我们在开发中也遇到了各种难题。⽐如为了跨平台使⽤的entityframework core，数据库映射策略只⽀持TPH(table per Hierarchy)不像ef 6⽀持TPC和TPT。不过，在整个过程中，我们也体会到了DDD的优越性。
