我所在的小组开发的项目是：在线电力监测系统。（没错，一听名字就很专业。）在三番几次，轮番轰炸指导老师后，终于搞明白了要做什么，简单点来说，就是要创新SCADA系统。（什么是SCADA系统呢？问得好，请自行百度）
但是光是知道了要做什么还不行，重要的是要把知道的进行文字化描述，有规范地整理出来。写需求文档的时候，才深刻理解了所谓的“只可意会不可言传”，当然，这个“言传”是有条理地说给纸听。
（废话有点多了，开始正题）
需求的设计，我是根据功能的分类来进行设计的，一开始我觉得把功能需求给说清就行了，其他的一些规定，提示什么的可以参照需求文档案例来写，但是，我漏了一个个非常非常重要的东西，那就是用户角色。（BTW:因为设计数据库的时候没有认真考虑过用户角色之间的关系，被小班讨论的老师给骂了）系统整体的设计是要考虑，系统给谁来用，谁能用系统做什么，系统的功能有哪些。而我注意到了系统的功能有哪些，其实本质上，软件工程的设计是与人打交道的过程，必不可少的要考虑用户群体，以及相应需求，还有用户体验，要站在用户的视角来看问题，这点我一直都做得不够好。
有时候，有些功能需求可能很复杂，很难用言语去描述，那么我们就可以用各种图来辅助表述。例如用例图，活动图等，类图和时序图主要是给开发人员使用和理解。现在就得说到用例图和活动图的设计了，我也把它们嵌到了需求文档的相应位置。关于用例图，要说明白谁做了什么，这个一定是要用主谓宾的句子结构完成的，并且，谓语动词尽量要求用强动词。有人可能会问了，什么是强动词，什么是弱动词？我的理解：弱动词=无比正确的废话，意思就是，这个动词无论放在哪里，放在我这个项目的这个用例图，或者放在其他项目的其他用例图，它都正确，但是不准确。那么我们如何选择强动词呢，这个要靠积累与天赋，毕竟我也没做好，没资格谈。此外，要考虑主体之间的关系（是否继承派生），以及活动之间的关系（include还是extend），include是指指向的活动必须完成，指出的活动才算完成，extend则可以理解为即使指向的活动未完成，指出的活动也可以完成。
下面可以分析一下我做的用例图：(starUML编辑的）
关于活动图，对于复杂的活动，可以用活动图来辅助描述，但不是所有的活动都需要活动图，一些简单的活动并不需要活动图。活动图要分清分支和判定点两个概念，分支可以表现并行，活动图面向对象，同时也是是内部处理驱动的流程，下面贴上我的其中一个活动图，它结合了一些简单的活动。
总而言之，需求分析与设计是一个非常重要，也非常花时间的过程，从项目开始到结束，跨度非常大，而我们的需求也在不断地修改中（当然，开发期间有一段稳固期）。