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

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

• 预估每周招生人数与校区有关
  • [popexizhi]没有仔细分析的结果
• ~ 前导课内容
  • [popexizhi]此内容是交流会议上特殊提出的内容，在自考等课程中等人数用的，此内容自己交流时根本没有考虑过，自己分析有二：
    一，自己就没有想过这个事，一直顺着谢的思路走，没有查看原始排课数据的结果；
    二，事后自己还认为只是对系统的分析方式不一样，不区分应该可以看到的;(自己感觉第二个理由有道理，但这里使用不充足，有个自己找借口的嫌疑：）)
    
    现在想来，这个课对排课的人数还是有不少影响的，应该是第一分析的结果，自己思维和操作的疏漏。
• 教师和教师的可用时间
  • 计划排课时为全部时间可用的
    • [popexizhi]
      这个问题，是开始分析过于细化了，把时间的内容考虑的太详细了，计划中这样详细的级别初步可能是不太妥的。
      思维上是不同时期的数据处理都放到一个不合适的时间去考虑了。
      最后使用最简单的不考虑时间全部可用的方式是直接将这个问题忽略了。使用中最后也是要调整的，到没有太多的问题，只是考虑自己如何在之后的工作中：
      1.区分这种细节问题到底在哪个时期处理，这个在测试时也在考虑，要好好像一下，对于系统的不同关注程度和侧重点如何影响需求和测试的？
      2.这个问题是否是个伪问题？就是说本身这样考虑就是错的，plan中考虑半年甚至一年以上不可用时间就是错误呢？那么久有参考价值吗？分析一下，也不对，这个有部分数据是有价值的，半年前大的计划或特殊事件是可以计划的，这个也分人和事的不是吗？离开需求本身谈这个问题多少有点儿无依据，再想想吧！
      
• 教师的可讲模块应该修改为可讲单元
  • [popexizhi]这么没有太多问题，就是写错了，自己当时认为的就是可讲单元，应该是笔误，但刚才回顾了一下，这个位置从来没有深究过，直到龙哥给自己指出来，龙哥所以发现，是因为代码实现时要针对不同内容，感觉和我们的日常理解不符合，才告诉自己的。嘻嘻，这里如果是自己，在写测试用例和准备测试数据时，应该是可以分析出来的。
    对，做需求时一直郁闷自己不能同时分析测试的思路，无法有效的检查自己的需求潜在问题的事，要好好思考一下，如何改进。进来自己写的coding也存在同样问题，对测试类的描述很是单一，好好想想，这才是自己改进自己思维的不错方法呢，不是吗？:)hope you like this way.
    
    
• ~ 校区的地址的范围写的最大地址是60个字符，太小了
  • [popexizhi]
    这个是佳哥给自己提出来的，其实在其他数据的长度限制上自己有相同的问题。当时的借口是先写这个，之后再定，好吧我理解其他做需求和代码人的想法了，这个在其他重要流程功能前太微小了，但是这个“之后”其实是不处理的待名词，直到测试人员提出这个问题，我们才开始去抱怨一下然后再改。（这个是自己现在可以看到的常态）
    自己后来在想要做一个数据分析的脚本，对业务处拿来的数据自己分析一下，之后在统计的基础上在对这个最大或是可选择类进行设置，只是这个工作到现在都没有做，还老老实实的躺在plan中。自己的next就是自己做，同时找找其他的软件有可以处理这个自己想要结果的内容的没有。
    这个过程应该成为需求分析时有原始数据的一部分内容，还有就是如果是日常的可用内容就要做统计，在这里参考使用的。
    -----------------------------------------分析到这里了，下次开始位置---
    
• 需求说明书中：要求在需求中明确提出每个字段的所属层次的问题
• in[new]：教室人数的最大浮动上限人数是多少（如果没有找到适合要求的教室，提示要求租用） 没有加入级别的需求
• 教师信息中开户人字段
• 教室方负责人
• + - ~ 计划开课之前的人数与校区相关，当前业务处理为上期那个学校遗留的人员就在哪个校区继续学习
  • [popexizhi]这个部分应该在发现预估人数与校区有关后统一再处理一下看是否有遗留与校区有关的人数问题。推荐现在做也不晚
    【ok了】
• ~ 教学通知和财务审批时要求多级审批