排课系统pope需求交流时遗漏的问题II

需求说明书中：要求在需求中明确提出每个字段的所属层次的问题

• [popexizhi]
  这个问题是自己在测试要求中最早加入的，其实想想有问题，这个最终版本应该是从设计那里拿到的，至于需求中加入的目的，是在需求调查时，统计分析原始数据使用的，所以不是所有的内容都会有的，但是对应业务中最重要的单据数据是应该有的。
  对了，同时想到一个问题，这次的需求的最大一个没想到的问题，需求说明书怎么能让业务人员写呢？！：）是啊！这个是需求人员调研的结果，这个中应该是需求分析人员的调研结果才对啊！：）不过不是坏事，这里可以总结这样的身份写的问题。
  
  （10/7/12）
  

in[new]：教室人数的最大浮动上限人数是多少（如果没有找到适合要求的教室，提示要求租用） 没有加入级别的需求

• [popexizhi]
  这个是一类问题，统一说一下吧，需求交流时使用的是业务人员给的文字版，自己总结了一个list的字段内容，这里做的太大了，好多的字段内容，没有区分不同的大小使用范围。这个问题在开发和设计时一下就表现出来了，自己当时写说明书时，感觉没有测试的思路，其实这里有两个思维的漏洞：
  一，当时可以想如果自己是开发人员，如何实现这个功能，这样再对字段区分就好多了，温伯格的意见，想不出way，就顺着路往前跳一步试试。ok
  二，设计的方法从一定程度上影响需求，这个加入的内容，应该是设计时加入的吧？！自己在做需求时一直再考虑这个问题，需求和设计的界限应该是什么？现在还在想，如果说没有指导的思想，不区分两者，潜在的风险是什么？
  

教师信息中开户人字段

• [popexizhi]
  借口是当时工作量大没有仔细分析业务人员写的内容是否正确，但同时一个问题，有无系统方法解决这样的问题？自己想到设计数据流，这个也是使用设计完善需求的，好吧，再想想别的方法
  

教室方负责人

• [popexizhi]问题同上

-------------------------分割线-------------------------------------------
下次要做的内容：

1.
~ 计划开课之前的人数与校区相关，当前业务处理为上期那个学校遗留的人员就在哪个校区继续学习

• [popexizhi]这个部分应该在发现预估人数与校区有关后统一再处理一下看是否有遗留与校区有关的人数问题。推荐现在做也不晚
  【ok了】

~ 教学通知和财务审批时要求多级审批 


的分析，
2.之前问题的统计
3.总结一下