项目概述：
为了缓解水资源浪费问题，需要对消防栓和阀门进行更加方便的监管。本项目开发的目的是统计阀栓用水数据，以图表的形式进行显示，为相关部门对阀栓的监管与维护提供支持。
界首市阀栓监管系统的目标是开发服务器网站。利用阀栓检测设备收集阀栓数据，并传输至管理平台，管理人员可以根据相关数据对阀栓进行实时监控并对阀栓做出相应的处理，包括安排相关人员进行巡视检修等。
为实现消防栓和阀栓实时监控管理，实现用水计量控制、运行维护和消防栓和阀栓监测等业务过程全覆盖管理，涵盖一张图、监测信息、综合报表、权限控制功能模块，提升消防栓和阀栓管理和自动化水平。系统模块结构图：
需求分析：
需求获取：
- 通过团队会议，在会议上与老师沟通获取需求信息。最初的需求信息有许多不甚明确的地方，为了确认这些信息，我们通过团队例会与老师进行面对面交流访谈，确定一些功能的具体使用场景，明确了这些功能应该达到的目标。
- 阅读原需求文档，由于该项目存在一定的基础成果，我们拿到了一份之前的需求文档，通过这份文档，我们获知了本系统的一些基本需求以及相关功能要求和应用场景，作为需求获取的补充。
建立需求模型：
通过初期的需求获取，我们了解了整个系统的功能分类和使用场景，对各类人员使用系统的可能做了分析，确定为以下几种角色场景：
- 巡视及维修人员，可以查看阀栓数据及具体分布情况、查看任务等；
- 监管人员拥有巡视及维修人员所有权限，此外可以对阀栓的具体信息、累计用水量进行查看并导出表格；可以下发任务给巡视及维修人员，同时，可以分配岗位、修改菜单权限、管理阀栓所属单位以及许可证；增加或删除巡视及管理人员账号信息；
- 系统开发维护人员，拥有监管人员的权限，并且可以对该系统进行修改。
通过对这些角色使用系统的场景进行建模，我们确定了如下系统用例：
心得总结
林怡鹏
我们的项目为界首市阀栓监管系统，是在原有的水资源管理系统的基础上进行迭代开发的，本项目开发的目的是统计阀栓用水数据，以图表的形式进行显示，为相关部门对阀栓的监管与维护提供支持。我
们在周老师提供的原系统需求的基础上加入了周老师提出的对该系统的需求变化和添加，经过多次开会进行理解、讨论和修改，最终确定了需求。
首先需要将原系统中的机井这个对象类型及其中部分属性改为阀栓及其属性，之后在阀栓位置的分级中添加道路一级。再之后便是修改确定每个界面的具体显示内容和功能。要积极地与老师交流，在需求
分析的过程中遇到不明确的地方要及时与老师沟通确认；
要善于利用需求分析的各种方法，更有效率地进行需求分析；团队之间要有合理的分工和积极的讨论，良好的协作能够有效提高效率；要不断地完善更新需求，需求唯一不变的就是一直在变化。
杜承龙
在获取需求的过程中沟通是第一要务，有不明确的点出现时及时提出问题才能得到解答。此外，在会议之前应该做好充分的准备，将上次会议到这次会议之间的进度、问题等做好总结，这样才能保证会议上
交流的顺畅进行。我们在进行需求分析的过程中与老师进行的交流略显不足，这导致我们对各项需求仔细分析的时候感到无从下手，这时候也没有及时提出疑问，在一定程度上拖慢了进度，出现了一些返工现
象。
杨廷元
需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。我们所开发的项目是对界首市阀栓进行监控管理。所
涉及的用户有两类，所管理的设备类型有两种，所需要统计的数据有年月日度数据。
在前一版本需求的基础上，我们经过初步的分析，我们对系统的大致功能以及具体的需求变更有了整体的认知。在这个基础上，我们开始设计界面原型，但由于对需求分析的不全面，导致系统中的部分模
块出现功能的不完善和遗漏。
而后我们经过与老师的协商沟通及交流，将需求重新分析整理最后确定下来1.0版本的需求分析文档。但由于需求是不断变化更新的，我们需要为后面的系统更新留下接口，故我们在系统中预留了接口，可
以将新增的功能及对应的变更直接添加到系统中，方便以后适应新的需求变化。
目前由于新增功能较少，老师那边的需求并不十分明确，故我们接下来还得进一步进行讨论更新。通过对该项目的需求分析，对软件设计过程的需求分析方面有了实践认知，对需求分析方面还缺乏经验，考
虑也有许多不全面。暴露出了许多问题，在以后的学习中还需要多加注意。
王斌
对于一个实际的项目来说，需求分析是一个非常重要并且充满了困难的过程。需求分析是项目前期的铺垫工作，也是重要的基础工作之一。需求工作中的缺陷将给项目的进行带来极大风险。需求工程作为软
件工程生命周期的起点是软件开发后继阶段的基础。软件需求是软件开发的目标，也是其项目开发成功与失败的重要因素。有时候错误的需求分析很可能导致软件开发的全盘否定，需求错误的代价会随着项目
的展开儿发生变化。如果需求错误能够及时的修复，那么其代价就会被限定在一定的范围之内。如果没有及时的发现，则很可能让整个软件的开发失去其本来应有的意义。
导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求分析。开发人员在编码觉到，在前期若无足够的需
求分析，获得的需求是片面的，不完整的，这样的程序在开发之初就埋下了风险，因为随着市场和用户的需求不断增加，在开发中若不断补充需求，项目就越变越庞大以致超过其预算范围。计划就不足以对项
目的规模和复杂性、风险、开发周期及需求变更进行合理预估，这使得问题更难解决。产品开发中不断延续的变更会使其结构日见紊乱，补丁代码也使得整个程序难以理解和维护。如果尽早地区别这些可能带
来变更的特性，就能开发一个更为健壮的结构，并能更好地适应它。
在我们小组的项目中，需求获取的途径主要有两种，一个是已有的需求说明，另一个就是与指导老师交流。通过需求说明可以了解到该项目大体要实现的功能，而与老师交流可以获得需求的细节要求。在小
组会议的过程中与老师进行面对面的交流，这是一种非常有并且符合当前应用场景的需求获取手段。在每次的交流过程中，我们必须做好会议记录，记录好需求中有问题的部分以及老师对此的回答。在于老师
进行交流的过程中，我们不仅需要聆听老师的需求说明，还要懂得在老师已说明的基础上进行拓展，发掘老师没有讲出来的潜在需求。这种交流方案使得我们能够准确地理解提出的需求并且能够适应需求的变
化。
在需求分析的过程中，我们可以采取多种方法来表达需求。在需求确认的过程中，我们可以采用原型法，先设计好项目的原型并提供给用户，在已有模型的基础上进行模拟业务流程，分析业务是否走的通并
且有无逻辑上不合理的地方，从而确认需求。也可以通过UML图等进行规范化的需求描述。进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免自己的主观想象，并尽量将分析进度提交给
用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。
标签：需求,分析,老师,系统,阀栓,界首市,心得,进行 来源： https://www.cnblogs.com/unique-yty/p/15552810.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。