需求评审记录

时间:2010年12月25日   地点:N210

作为需求分析的一个阶段小结,IBM实训导师与全系10小组展开对于需求分析的评审,分析问题,解决问题。

3小时的评审,总体来说,ZJU_ASIMS组对于文档,开发计划,WBS划分较清晰,运用MS Project是亮点,Medusa组对于需求的粒度划分有心得,不太多去考虑页面原型的内容,排除因场外因素对于需求分析的干扰,IC组需求考虑的比较细致,对于用户的角色定义较清晰,但同时,同学提出,增量开发的提法对于瀑布开发是不适合的,国政TX很勇敢。

听到了10组的报告,想法如下:

  1. 粒度。需求分析并不是实际开发,所以不需要太多考虑设计方面的问题,即使已经有了页面原型,需求分析是将业主的现实要求转化成物理模型,同时需求分析书需要考虑到各项目干系人的利益需求,平衡各方对于系统的要求。所以粒度考虑需要把握一个度的问题,太过于细化的粒度,对于需求分析阶段是个累赘。
  2. 用例图。到底是include还是extend,需要切实考虑用例间的关系,例如发布新闻与发送邮件之间,并不需要include的关系,不需要对于每一次新新闻的发布,都需要对用户发送邮件,只是给部分订阅新闻的用户发送即可,所以用extend关系即可。
  3. 域模型。域模型分析与类图分析,是两个不同概念的分析方法,所以域模型分析时,不需要将属性,方法都考虑清楚,另外,不需要太多依赖的关系。
具体到我们组Newbie,问题主要存在以下方面:
  1. 考虑不够周到。例如对于订阅新闻的用例,并没有考虑的更深一步,考虑到发送邮件这一用例,但这是并不可少的,但也需要考虑发送邮件的方式与时间,这一点,需要再考虑。
  2. 角色定义。抽取角色,泛化角色,因为之前在考虑用户这一角色的时候,始终会对用户,普通用户和其他用户的的概念产生歧义,而将所有用户抽取成用户,再泛化出五种角色,这也会方便到开发人员在设计时不会产生异议。
  3. 用例规约。基本时间流总体写法都是正确的,但是考虑的不够仔细,异常事件流等写法过于抽象,有些敷衍了事的意思。这比会对今后的开发照成困难。
  4. 团队。这是最大的问题,组员没有百分百的投入项目,PM没有切实履行自己的职责,成员没有需要的项目实训经验,完全还处于一种课程实验的概念,项目会议效率不高,讨论主题不明确,另外队员似乎都不怎么谦虚,这也存在于整个系10组成员中。我觉得这会是我们项目最终成功与否最关键的因素。否则对于想进入IBM实习,都是白日梦。
评审只是一个阶段,是为了能更快捷的找到项目组的问题,希望组员最后能有所行动。


发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

无觅相关文章插件,快速提升流量