不队-需求分析心得

不队-需求分析心得

 

项目名称:基于Facebook的舆情分析系统

指导老师:王涛

 开发队名:不队

 开发团队:黄昇阳【PM】、马浩、陈前、樊鑫

项目概述:本系统包括移动端,网页端,服务器端三大部分,总系统模块结构图如下

 

软件工程导论慕课,可参考:

https://hnu.yuketang.cn/pro/lms/8wwRFTshQ3r/9691278/studycontent

软件工程需求分析,可参考:

https://www.cnblogs.com/jsjblc/p/3567372.html

 

本篇博客主要基于以下几个方面对本次的需求分析进行心得分享:

1. 需求分析的过程与方法

2.  需求分析中出现的问题及解决方法

3.  需求分析总体概述及评价

4.  数据库设计项目总结

 

 

一. 需求分析的过程与方法

1)需求分析的过程

    需求分析阶段的过程,可以分为以下四个方面:问题识别,分析与综合,制订规格说明,评审。
 
    问题识别:
    就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括:功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率),安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标。
 
    分析与综合:
    逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型)。
 
    制订规格说明书:
          即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交。
 
    评审: 
          对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。

:我们基于我们需求分析的过程,重新提炼并精化了这四个方面,并对其有了更加深刻的理解,这里我们对我们项目需求分析的理解与经验一一进行阐述。

 

           1. 问题识别

  对于这一部分,我们理解为根据得到的需求,这部分可以通俗意义理解为老师对我们需要做的需求的描述与期望,我们以多名专业的计算机工程师的角度,从系统可行性与方法上找到粗略的实现的逻辑,并对一些要求,如需求的目标,需求的软件要求,安全性要求等做出估计与评估。对应到我们的业务上,如我们的爬虫系统,需要爬取的数据量为多少篇,需要有什么格式,在哪个系统环境下爬取,通过什么方式爬取,怎么展现给用户等,并依次对软件消耗和成本做出估计的预期。但需要注意的是,我们根据不同的项目所需要考虑的自然不同,对于我们软件工程课程的开发来讲,我们需要考虑到安全性,但可能就不会也不需要考虑的那么细致了。

 

    2. 分析和综合

 

    对于这一部分,我们理解为根据我们通过系统角度翻译过来的需求,更加细致的去设计如何实现的,在这一阶段中,我们很明显的就会发现,我们所需要开发的需求有些
部分是不合理,有些部分是做不到的,那么就需要我们不断地对其进行更改与检查,然后优化到一个可行,或者说合理的版本以供后续的开发进程与实现。并综合所有的需
求,设计一个详细的逻辑模型,其实也就是用例图。这里需要注意的是我们需要区分不合理的需求与较难的需求,在我们第一次进行分析综合时,我们错把很多较难的需求看作了不合理的需求,受到了老师的批评,并且用例也失去了完整性,损失了较多时间。

 

     3. 制订规格说明书

    对于这一部分,我们理解为一个成果汇报,它其实是写开发团队需求分析的结果以及标准的,也有着专门的范式文档,统一称为软件需求规格说明书,这也其实就是我们最后上交的需求文档的一部分,后续的开发过程都要依据这个文档来进行开发与流程管理,因此,这也是需求分析的最最重要的成果的体现与展示,也对后续的开发过程起到至关重点影响作用。这里需要知道的是,其实网上有较多的需求文档的模版,而且软件工程这门课是鼓励我们使用模板的,但我们需要根据自己项目的特点与不同,自己对模版进行修改,更改为更加适合我们的版本,这才是真正的借鉴。

 

4.评审 

     我们基于已有的需求分析文档与需求分析过程文档,对我们实现功能对应需求的完整性等进行验证,软件工程导论课上曾讲过,功能修改的代价是随着开发的进程而不断增大的,那我们未雨绸缪的不断测试,其实就是为了能更早的将这些问题扼杀在摇篮中,减少我们因需求分析不到位而带来的功能变更等问题,这样会大大增加我们开发的开销。这里我们有一个比较好的做法是,谁做的需求分析,那么由另一个不同的人去进行评审。这种当局者迷旁观者清的应对方法可以帮助我们更好的找出我们需求分析中的问题并及时的进行改正,我们在这里进行分享,真的是一个十分好的方法,就是有点消耗人力。

 

                                                                                                 

 2)需求分析任务                

    需求分析需要实现的是将软件用户对于软件的一系列意图、想法转变为软件开发人员所需要的有关软件的技术规格,并由此实现用户和开发人员之间的有效通信,它涉及面向用户的用户需求、业务需求和面向开发者的系统需求这两个方面的工作内容,因为已经是确定了的需求,所以我们不考虑业务需求,也就是需求的业务扩展。

 

1.用户需求   

   用户需求是用户关于软件的一系列意图、想法的集中体现,涉及软件的操作方式、界面风格、报表格式,用户机构的业务范围、工作流程,以及用户对于软件应用的发展期望等。因此,用户需求也就是用户关于软件的外界特征的规格表述。 实际上,用户需求提出了一个有关软件的基本需求框架,具有以下特点:

(1)用户需求直接来源于用户,可以由用户主动提出,也可以通过与用户交谈,或对用户
进行问卷调查等方式获取。由于用户对计算机系统认识上的不足,分析人员有义务帮助用户挖掘需求,例如,可以使用启发的方式激发用户的需求想法。如何更有效地获取用户需求,既是
一门技术,也是一门思维沟通艺术。

(2)用户需求需要以文档的形式提供给用户审查,因此需要使用流畅的自然语言或简洁清
晰的直观图表来进行表述,以方便用户的理解与确认。

(3)可以把用户需求理解为用户对软件的合理请求,这意味着,用户需求并不是开发者
用户的盲目顺从,而是建立在开发者和用户共同讨论、相互协商的基础上。

(4)用户需求主要是为用户方管理层撰写的,但用户方的技术代表,软件系统今后的操作
者,以及开发方的高层技术人员,也有必要认真阅读用户需求文档。

 

2.系统需求

   系统需求是比用户需求更具有技术特性的需求陈述,是提供给开发者或用户方技术人员阅
读的,并将作为软件开发人员设计系统的起点与基本依据。 系统需求需要对系统在功能、性能、数据等方面进行规格定义,由于自然语言随意性较大, 在描述问题时容易发生歧义,因此系统需求往往要求用更加严格的形式化语言进行表述,例如 PDL 伪码,以保证系统需求表述具有一致性。 系统需求涉及有关软件的一系列技术规格,包括:功能、数据、性能、安全等诸多方面的
问题。

(1)功能需求

    功能需求是有关软件系统的最基本的需求表述,用于说明系统应该做什么,涉及软件系统
的功能特征、功能边界、输入输出接口、异常处理方法等方面的问题。也就是说,功能需求需 要对软件系统的服务能力进行全面的详细的描述。 在结构化方法中,往往通过数据流图来说明系统对数据的加工过程,它能够在一定程度上
表现出系统的功能动态特征。也就是说,可以使用数据流图建立软件系统的功能动态模型,这里以登录的数据流图为例。

 

(2) 数据需求

    数据需求用于对系统中的数据,包括:输入数据、输出数据、加工中的数据、保存在存储
设备上的数据等,进行详细的用途说明与规格定义。 在结构化方法中,往往使用数据字典对数据进行全面准确的定义,例如,数据的名称、别 名、组成元素、出现的位置、出现的频率等。当所要开发的软件系统涉及到对数据库的操作时,
还可以使用数据关系模型图(ER图)对数据库中的数据实体、数据实体之间的关系等进行描述。

    这部分主要在构建数据库的时候运用,需求文档中并没有过多涉及,只是简要的提了一下

(3) 其他需求

    其他需求是指系统在性能、安全、界面等方面需要达到的要求,本项目中并没有过多关于这方面的需求,也仅仅只提到了几句。

 

3)基于敏捷开发的用例图设计              

     对于用户需求,我们考虑同结对编程一样运用软件工程导论课程中的相关知识优化我们项目的进

 程,我们尝试构建了用例模型并进行项目的简单敏捷开发实践,以下是相关步骤:

 

           1. 找到所有的参与者与用例并进行简单描述

                这里我们考虑项目开发团队作为参与者的模拟,比如使用系统的用户以及后台的管理人员,超级管理员等,用例在需求文档中其实已经

              以需求用例的形式给出,我们根据其关系,按用户,管理员,超级管理员对其进行了进一步的权限划分。

 

           2. 进行用例的编写,按照事件的重要程度进行划分,并设计用例图,以注册登录的用例图的详细示意为例:

                    

       

 

 

 

二. 需求分析中出现的问题及解决方法

         我们在与老师沟通需求以及进行需求分析、设计需求文档的过程中,都出现了很多的问题,我们通过与老师同学的交流,以及自己的学习,逐一解决了这些问题,现在对其中较为典型的一些问题做出举例。

 

问题一:老师给的需求过难且较少,无法形成完整的前后端

问题详细描述:王老师主要跟我们讲了后端所需要的爬虫技术,而对前端的功能与需求的界面并没有过多具体的要求

问题解答:我们基于一篇计算机工程上关于需求分析的论文(1000—3428(2002)01-—0006-— 03)从三个方面解决了这个问题。

 

问题二:需求在项目进行过程中发生改变

问题详细描述:我们确定好要完成一个类似机器学习的图像识别系统,并进行初步的设计与学习后,因为人数以及难度的原因,变为了舆情分析系统。

问题解答:我们基于csdn上关于此类问题的经验,发现了以下三种解决方法,并利用第一种进行了需求变更的快速过度,使得这样的需求变更并没有很大程度上影响到开发              团队的心态、项目进度与流程。

      • 为变更请求的收集、分析和组合制定一个定义明确的过程,保证你的客户知道他/她的切入点。
      • 为每个开发阶段设定转折点,超过这个转折点就不允许进行某些改变——例如,一旦一个模块完成75%,就不允许进行重大改变。
      • 保证向所有股东清楚地通报变更请求(和变更批准),以及进行变更的根本原因,因而还要对主项目计划进行更新。

 

 

问题三:客户并不(确切地)知道他们需要什么

问题详细描述:我本问题并没有出现在我们的项目中,因为老师给的需求都是他们做过或者说正在做的,所以需求十分的明确,但这不能不说明这样一个问题普遍存在在与客户交流的需求分析中,所以我们将此也展示了出来

问题解答:我们基于查找到的资料,总结了以下四点作为这种问题的解决与处理方式

 

      • 确保在项目开始之初,你用了足够的时间来了解项目的目标、交付成果和范围。
      • 确定客户所使用的任何假设,用批评的眼光评估项目给终端用户可能带来的好处和风险。
      • 尝试为项目写出一份具体的远景陈述,包括它提供的特殊功能或给用户带来的好处,以及希望它解决的所有商业问题。
      • 让客户阅读、考虑并同意前面完成的软件需求规范,调整他们的期待,保证双方充分理解项目交付成果。 

 

三. 需求分析总体概述及评价

    在这一段时间,我们团队项目小组进行了团队项目的需求分析工作,总体来讲,我们将其分为了系统层,业务层和用

户层三个层级,并基于这三个层级,对我们的团队项目进行了系统且具体的分析。

    针对系统层,主要分析的是在系统层面该团队项目应当实现的需求,具体表现为各种对外接口,如硬件接口,软件接口,

通信接口等,具体分析了在系统层面,我们应当实现的功能性需求和非功能性需求,以及在一些数据层面应当实现的一

些数据需求,同时确定整个项目实现的开发平台和环境,操作系统环境为 Windows10,IDE开发环境是IntelliJ IDEA,数

据库开发环境是MySQL,服务器环境是Tomcat9,并确保整个系统的可维护性和可拓展性。

    对于业务层,我们主要对该项目我们应当实现的各项业务目标进行了具体分析,且分析了该项目所处的开发背景,针对业

务的具体目标,我们主要从反爬虫保证日爬取量层面做出了大量考量,从不同角度层面对项目应当实现的业务目标进行提

取归纳,包括管理者,用户和公司层面。在业务层层面中主要分析了该项目研究开发的可行性以及必要性。

    对于用户层,我们主要从web端和andriod端,进行了大量的用户用例分析,范围涵盖用户从登录注册到系统使用的各个层

面,同时将系统角色分为用户,管理员和超级管理员三个不同的层级,用户拥有注册账号,登录系统,重置密码,功能类

别选择,热门事件,最新资讯,开始舆情搜索,开始舆情分析,开始文字情绪分析,查看舆情报告,查看用户报告,下载

报告,修改个人信息,提交用户反馈,查看历史记录,发表爬客动态,删除爬客动态,查看论坛动态18项使用权限,管理

员拥有整个系统的管理权限,包括查看系统访问量,管理用户信息,管理用户反馈,管理爬客动态,管理舆情数据,管理

上传记录,管理错误日志,超级管理员拥有对整个系统管理的最高权限,包括管理用户信息,管理舆情系统,管理爬虫数

据。针对这些不同的用户用例,我们均分析设计了每个不同用例的用例图,同时对不同用例进行流程及数据需求的分析,

并将所有用例的用例图进行总结归纳,合成了总的用例图。(总用例图见文后)

   总体来看,我们通过将需求分析分为系统层,业务层和用户层三个层级,分级进行了整个项目的需求分析,确定了项目在

不同层级的功能性需求和非功能性需求。在系统层中,确定系统层面的具体需求及项目开发环境;在业务层中,详细分析

项目研究开发的可行性和必要性,并提出对应的业务目标;在用户层中通过分析大量用户用例,并设计对应用例图及流程,

最终确定用户层的各项需求。化大为小,化繁为简,最终在整个小组的同心协力下,成功完成了小组团都项目的需求分析。

 

 

四. 需求分析项目总结

   这次的需求分析项目,给与我们之后开发起到了引领方向的作用,也为我们和老师(客户)之间的共识搭起了桥梁。

   首先,我们通过不断地与老师沟通,确认需求,并通过软件工程导论上学习到的方法,以及自我的学习,通过需求

分析过程与需求分析方法及用例图为例的敏捷开发办法,进行了uml的设计,原形的设计以及用例图的设计与修正,最

终完成了本次的设计,并且也有了一定的需求分析经验。其次,在这次的需求分析任务中,我学到了uml的使用方法,

明白了需求分析过程及敏捷开发方法的实践,将会带我在以后与客户进行需求分析的时候更加熟练,更加得心应手,

这种做中学的方式也让我更加深刻的领会到了软件工程导论教授的知识在实践中的运用以及一些自己看似学明白的知

识在实践的情况下如何去完成的过程,真的极大地提升了我的软件工程思维的深度与学习兴趣。

    更多的,在这次需求分析实践中,虽然出现了很多的问题,也造成了我们效率不高,错误频出的结果,但当最终完

成了这次的任务,我们得到了非常多的需求分析的经验。在之后的项目开发过程中中,我们运用在这次需求分析的处

理,那无疑可以让我们更加的上手与高效。也会更加获得客户的认可,也是为学校争光。 最后,我想说的是,通过这

次的开发,我明白了其实很多的困难并不来自于实践有多困难,而是在于与队员的协作、沟通团结,主体设计的宏观

结构的设计与思路,开发方法的选择等等问题上。尤其是如何学会与团队的其他人相处与合作,真的是非常重要的一

件事,这是我在这次的数据库设计中学到的非常重要的事,我相信,这也会在我以后的学习与工作中,起到非常大的

帮助与作用!

   最后,在本次项目的实现过程中,我出现了很多问题,请教了很多人,主要为同学和各位软件工程的老师们,我发

现老师们都十分的博学和乐于助人,而且这种请教的效率要比我自己冥思苦想很久要来的高效很多,而我也会去给一

些别的同学去解答问题,这无疑极大地提高了我的团结协作的能力,也充分的培养了我的团队精神。当然,我也有时

会选择去自己在一些平台上查询相关的资料与解决方案。这也很好地提高了我的自我学习能力与资料查找能力。尤其

是在这次的需求分析中,极大地提高了我与人交流的能力,我觉得这对于一个软件工程的学生来说是十分重要的。

    希望接下来的数据库设计以及之后的迭代开发中,我们依旧乘风破浪,勇往直前!

声明:转载自本队成员。

链接:https://www.cnblogs.com/mahao0221/p/15581135.html

posted @ 2021-11-20 15:42  湖大挨踢攻城狮caesar  阅读(36)  评论(0)    收藏  举报