需求分析和概念原型——基于音乐播放器
介绍
近期对于需求分析和软件设计有了一个初步的了解，明白作为一个码农，最重要的不仅仅是代码的规范，对于软件的前期分析和设计会深深的影响到整个软件的质量以及完成成本。
在试图完成一项任务之前，一个规范化的软件分析和建构是非常有必要的。
下面试图拿我工程实践项目一个音乐播放器系统来做一个初步的分析，有不足之处，还请大家多多指教。
一、需求分析
1.1什么是需求分析
- 需求就是对用户期望的软件行为的表述
- 获取需求就是需求分析师通过关注用户的期望和需要，从而获得用户期望的软件行为，然后对其进行表述的工作
- 需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作
1.2关键用户需求
从音乐播放器的使用者的角度
①播放歌曲
②下载歌曲
④歌曲查找
⑥自建歌单
⑦歌曲分类
二、用例建模
2.1什么是用例
用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。
用例的几个基本要素：
• A use case is initiated by (or begins with) an actor. 一个用例应该由业务领域内的某个参与者（Actor）所触发。
• A use case must accomplish a business task (for the actor).用例必须能为特定的参与者完成一个特定的业务任务。
• A use case must end with an actor. 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
2.2准确提取用例的基本方法
第一步，从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；
第二步，验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：
必要条件一：它是不是一个业务过程？
必要条件二：它是不是由某个参与者触发开始？
必要条件三：它是不是显式地或隐式地终止于某个参与者？
必要条件四：它是不是为某个参与者完成了有用的业务工作？
如果以上四个必要条件都满足的话，那么该业务领域相关的动名词或动名词短语就是一个用例。
本系统中，歌迷的需求分别有 播放歌曲、搜索歌曲、创建和删除歌曲，可以看出，这三个需求都是一个业务过程，并且都是由歌迷触发，终止于歌迷。
2.3主要用况
歌迷用况
系统管理员用况：
系统有两类参与者，分别是歌迷和管理员。歌迷可以借助该系统完成如下功能：
- 播放歌曲
- 搜索歌曲
- 创建和删除歌单
系统需要管理员进行：
- 上传歌曲
- 审核歌单
三、业务领域建模
3.1什么是业务领域建模
- 业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知
- 开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。
3.2业务领域建模的基本步骤
第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
第四步，将结果用 UML 类图画出来。
3.3项目中的业务领域建模
七、数据模型
歌迷
| 变量名 | 类型 | 唯一 | 含义 |
| userName | string | 是 | 用户名 |
| password | string | 是 | 密码 |
music表
| 变量名 | 类型 | 唯一 | 含义 |
| m_name | string | 是 | 歌曲名 |
| m_startDate | string | 是 | 时间 |
| m_singerName | string | 是 | 歌手 |
| m_album | string | 是 | 所在专辑 |
Album表
| 变量名 | 类型 | 唯一 | 含义 |
| m_name | string | 是 | 专辑名 |
| m_startDate | string | 否 | 时间 |
| m_singerName | string | 否 | 歌手名 |
| _musics | Music | 否 | 歌曲列表 |
Singer表
| 变量名 | 类型 | 唯一 | 含义 |
| m_name | string | 是 | 歌手名 |
| m_category | string | 否 | 歌手类别 |
| _albums | Album | 否 | 专辑列表 |
管理员
| 变量名 | 类型 | 唯一 | 含义 |
| AdName | string | 是 | 管理员账号 |
| password | string | 是 | 密码 |
八、概念原型
首先明确概念和概念原型：
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
概念原型是一种虚拟的、理想化的软件产品形式。
就像“程序=算法+数据结构”一样，“概念原型=用例+数据模型”
从之前的分析中已经得到该项目的概念原型，下面介绍一下该概念原型的工作过程：
歌迷登录系统后，通过选择歌曲分类，客户端将在数据库服务器查询歌曲分类，将结果返回给客户端。此外，歌迷还可以通过自己的账号查询自己的歌单信息，查找自己喜欢的音乐。或者通过搜索音乐进行播放。这些都是建立在歌迷与系统进行交互，并与数据模型交互的情况下产生的。
七、总结
以上对工程实践项目的分析不仅让我加深了从需求分析到软件设计的基本流程，还加深了对工程实践项目的理解。对以后工程实践的项目有很大的帮助，希望以后能更加成熟地运用这些方法完成对软件的分析。以上是我个人对项目的粗略分析，还请指教。
参考：
