软件需求规格说明书的知识.docxVIP

评教系统软件需求规格说明书介绍目标本软件需求规格说明书是进一步定制软件开发的细节问题，使软件开发工作更具体。为了使用户、软件开发者及分析和测试人员对软件的初始规定有一个共同的理解，它说明了软件的各项功能需求、性能需求和数据需求，明确标识各项功能的具体含义，阐述实用背景及范围，提供客户解决问题或达到目标所需要的条件或权限，提供一个度量和遵循的基准。项目范围和产品特性特性版本1后续版本管理员设置问卷简单问卷设置防乱评检测问题及评卷时长要求规则管理员发布评教完全实现完全实现邮件通知学生评教发布评教时，利用学院邮箱系统对参与评教的所有学生下发评教通知在评教临近结束，对还未评教的学生进行再次推送邮件通知提醒评教教师查看评教进度在评教进行期间，教师可以进入自己的评教管理界面查看当前的参评率及当前平均分完全实现教师查询评教结果评教结束后，教师可以查看自己的各科平均分，及该分在全院的排名和该科在全院的平均分实现教师总评教分平均分在学院的排名学生评教/重评完全实现完全实现师生互动留言不实现学生在评教中可以对教师进行留言，教师可以收到提示“某专业的学生对其进行了留言”，教师可以对其进行回复参考文献Karl E. Wiegers所著的软件需求（第二版）总体描述产品远景规划“评教系统”的出现取代了之前纸质问卷形式的教学调查，大大节省了问卷耗费的纸质资源及问卷统计所需的人力。而对于学生而言，他们有了更多自主的时间去安排评教（在规定的时间戳内），匿名的规范高于之前的纸质调查，其中有师生匿名留言互动，增进了学生与教师之间的沟通。不管是哪一方面，都以绝对的优势成为主流的教学评教方式。个个高校都普遍已拥有自己的评教系统，所以“评教系统”是评教调查发展的一个阶段产物。用户类和用户特性用户类描述管理员（教秘）管理员是负责管理和发布评教的教务部主管，每次评教问卷的设置，都要综合个个教师之前对问卷不合理的反馈进行改善。问卷发布前，需要对不符合参与评教的学生进行登记，关闭他们的评教资格。评教进行过程中要维护系统中的各类异常，及教师学生的各类反馈，作出处理。教师教师是评教的被评者，他们可以实时跟踪评教情况，对学生的留言进行回复。他们还可以对问卷不合理的情况对管理员进行反馈。学生(优先考虑)学生是评教系统的主要使用人群，全院学生（大约20000多人）的评教都由该系统负责。在评教期间，学生登陆到评教系统对其所修读课程进行评教/重评/留言/回复教师的回复。运行环境OE-1:“评教系统”部署在学校的服务器上，该服务器运行Linux和 Apache HTTPMysql等服务。OE-2: “评教系统”的操作将通过Web浏览器来完成，如：IE5.0以上、Chrome、Firefox等。OE-3: “评教系统”允许用户通过互联网用户登陆访问。设计和实现的约束条件CO-1: 系统的开发模式采用MVC模式。CO-2:系统服务将采用linux + apache+php+mysql + html。CO-3:所有html代码将遵照html5标准。CO-4: 所有脚本都采用python语言来编写。假设和依赖AS-1:只要在评教时间戳内，学生都可以对所修读课程进行评教。AS-2:只要学生旷课达到10次，该学生将失去本课程的评教资格。AS-3:只要学生在距评教结束只剩2天，邮件系统将再次发送评教通知提醒。DE-1:“评教系统”的邮件通知推送依赖于“学院邮箱系统”的邮件发送，它接受“评教系统”评教开始的请求。DE-2:“评教系统”的邮件通知功能依赖于学院邮件系统的推送。DE-3: “评教系统”的参评与被评关系依赖于“教务系统”的学生-课程、教师-课程的关系系统特性登陆描述和优先级用户通过规定的用户名和自设的密码登录评教系统，数据库中用户表有标记以区分学生、教师、管理员。优先级为高。刺激/响应序列刺激：用户输入用户名，密码。响应：根据用户名及密码匹配登录，若密码错误，系统提示并跳转为登录界面。 刺激：用户10分钟内未操作。响应：系统则自动退出登录。功能性需求Login.验证用户输入用户名密码，进行身份验证Login.成功系统数据身份匹配成功，进入主界面Login.时间无操作用户30分钟内无操作，用户自动退出Login.验证失败输入的用户名密码匹配失败，提示登录失败学生评教描述和优先级学生在成功登陆教务系统的评教系统后，他们就可以对他们所修读的课程进行评教/重评或对该课程老师进行留言。优先级为高刺激/响应序列刺激：学生进入评教系统。响应：系统向客户展列修读需评教课程及教师。刺激：学生选择评教的课程。响应：评教问卷。刺激：填写问卷，提交问卷。响应：评教成功。刺激：重评问卷响应：评教问卷。刺激：填写问卷，提交问卷。响应：评教成功。功能性需求Students.评教主界面显示该学生的所有修过的课程/老师（过滤无资格课