学校设备管理系统软件需求分析

>分析需求文档资料，找出所有概念，包括名词、动词和短语。一般来说，名词归为初级类、属性等信息；动词形成主要功能或者类的方法；短语形成业务逻辑或者条件限制。

>确定问题范围，把此范围内的概念进行细化，开成“概念清单”。

>细化结果形成初级类和功能。

>根据功能需求形成主要功能、菜单树和主要界面。

>根据初级类形成界面类和实体类。

分析时应该从以下方面着手

>

>

应用软件开发中的需求分析及方法 软件工程一般具有以下基本活动：软件描述：软件的功能以及软件 *** 作上的约束定义；软件设计和实现：软件要按照描述来设计；软件有效性验证：软件要被确定是有效的，能完成预期的应用；软件进化：软件按应用需要的变更来进化。其中，软件描述的目标是，确定软件系统需要哪些服务以及开发和运行期间受到哪些约束，对服务和约束的发现、分析、建立文档、验证活动，现在常称为需求工程。为此，笔者谈谈如何进行需求分析及方法。 一、 需求的过程 需求工程对于软件过程是一个特别关键的阶段，这个阶段的错误将不可避免地带到后续的系统设计和实现阶段中。需求工程阶段的独特之处在于很少有现成模式或特制的文档可供参考。后续阶段可以建立在前期所做工作基础上（各种相关模型至少在一定程度上可以衍生导出），而需求工程阶段的成果却是靠创建而来的。 需求工程本身就是一个过程，这个过程将产生用以描述系统的需求文档。通常需求在这个文档中被分成两个层次描述：最终用户需要高层次的需求描述；而系统开发人员需要比较详细的系统描述。 （一）需求过程的四个主要阶段 1、可行性研究：指明现有的软件、硬件技术能否实现用户对新系统的要求。从业务角度来决定系统开发是否划算以及在预算范围内能否开发出来。可行性研究是初步的，结果就是要得出结论，该系统是否值得进行更细致的分析。 2、需求的导出和分析：这是一个通过对现有系统分析、与潜在用户讨论、进行任务分析等导出系统需求的过程。也可能需要开发一个或多个不同的系统模型和原型。这些都会帮助分析员了解所要描述的系统。 3、需求描述：需求描述就是把在分析活动中收集的信息以文档的形式确定下来。在这个文档中有两类需求。用户需求是从最终用户对系统需求的抽象描述；系统需求是对系统要提供的功能的详尽描述。 4、需求有效性验证：这个活动检查需求实现、一致和完备。在这个过程中，可发现需求文档中的错误，并加以修正。 当然，需求过程中的各项活动并不是严格按顺序进行的。在定义和描述期间，需求分析继续进行，这样在整个需求工程过程中不断有新的需求出现。因此，分析、定义和描述是交替进行的。 （二）需求的进一步认识 1、软件系统需求 常常分为功能需求、非功能需求和领域需求。 功能需求：包括对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需要明确申明系统不应该做什么。理论上，系统的功能需求描述应该既全面又具有一致性。全面意味着用户所需的所有服务都应该给出描述。一致性意味着需求描述不能前后矛盾。在实际过程中，对大型而又复杂的系统而言，要做到需求描述既全面又一致几乎是不可能的。一方面是因为系统固有的复杂性，另一方面是因为观点不同，需求也会发生矛盾。 非功能需求：对系统提供的服务或功能给出的约束。包括时间约束、开发过程约束、标准等。非功能需求源于用户的限制，包括预算上的约束、机构政策、与其他软硬件系统间的相互 *** 作，还包括如安全规章、隐私权利保护等外部因素。 领域需求：这是来自系统的应用程序领域的需求，反映了该领域的特点。他们也可能是功能需求或非功能需求。 2、软件需求文档 也称软件需求描述（SRS），是对系统开发者要求的正式陈述。IEEE标准为需求文档提出了以下结构：引言（目的、范围、缩略词等），一般描述（产品透视、功能、用户特征、约束等），专门需求（功能、非功能、接口），附录，索引。 二、方法 （一）问题域（应用领域） 是指问题所存在的现实世界中的那个部分。问题域是需求分析员所要研究的首要对象。例如，对一个电梯控制系统来说，它将包含任何现存的硬件（电梯、指示器、传感器、按钮等）、建筑物特征（楼层和电梯井的数目）、预期的使用模式、用户特征、使用约束（如限制短途搭乘）等等。在这个问题域内，问题可以确定为“让电梯在建筑物中更有效使用的控制系统”。为了解决问题，‘解系统’显然有必要在问题域内产生某些效果，构成软件需求的正是这些想要获得的效果，也就是为何做软件需求的原因和目的。 到现在为止，我们得到初步论点。在构建一个新软件系统之前，最好先决定它应当能够做些什么又不要做些什么；从问题域的研究入手，获得问题的描述，以及新的解系统在其中将产生效果的陈述（即需求）；确定新系统所需的行为，以便让它在问题域内产生所需要的效果。 （二）需求分析 通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明。需求分析旨在揭示一个现有的系统（问题域）的结构，而内部设计则是要创建出一个尚未存在的软件系统（解系统）的结构。对于这一重要任务其特性如下： 分析关注问题域及对其建立的模型，而不是解系统； 主要目标是要获得对问题域及存在于其中的问题本质的理解； 分析在本质上先于解系统行为的规格说明（尽管有重叠和反复的过程）。 （三）方法论 方法不只是一种技术，它是解决任务的一种途径，并且通常由一组技术组成。任何分析方法，要使它得到很好的利用，都应当要求并且做到便于描述以下几个方面： 问题域的结构，根据其子域及其相互间的关系； 问题域数据，语法和语义方面 问题子域的内在属性和行为； 问题域中的重要事件及现象； 需求，解系统在问题域中应产生的效果。 具体有以下三个方法： 1、结构化分析（SA） 结构化分析（SA）是一种具有相当长历史的分析方法，其演化的方式既微妙又显得很重要。如同结构化编程一样，它致力于系统范围内的事物处理，数据流以及存储数据结构的建模。建模主要包括数据流模型（DFD），数据字典（DD），实体关系图（ERD）。 结构化分析所用的原型，无论是对开发者还是客户都显得直观易懂，若将初始重点放在对原有系统的建模是对实现理解问题域这一基本的分析目标的有力支持。 结构化分析方法和人们的思维方式很相似，注重的是事物的过程和方面。利用结构化分析很容易去理解一个刚刚接触的问题域，适合对比较生疏领域做软件需求。 2、 面向对象分析（OOA） 面向对象方法最初只是一种系统的结构进行建模的方式，后来扩展到了内部设计，如今也已经开始广泛应用于分析阶段。面向对象分析基本思想是：如果把对象类的建模限定在需求问题域，那么面向对象的基本原理、模型以及表示法均可以用于分析。 OOA（面向对象分析）算不上一种真正的需求方法，OOA的起点是一份原有的需求文档，或者甚至是一份行为规格说明，并且OOA隐含的假设问题域分析已经完成，即分析员已经了解了所要研究的事物。OOA的真正本质意义是作为解系统的高层体系结构的设计，并且有利于系统的下一步开发设计（如果是OOD开发的话）。 OOA的大致方法是：标识出问题域中的对象类；定义这些类的属性和方法；定义这些类的行为；对这些类间的关系建模。 3、 面向问题域分析（PDOA） 面向问题域的分析（PDOA）是一种新技术。PDOA更多的强调描述，而较少的强调建模。描述大致划分为两个部分：一部分关注于问题域，而另一部分关注于解系统的待求行为。一般建议同时有两个单独文档：第一文档含有对问题域相关部分的描述以及一个需求在该域中求解的问题列表（即需求）；第二文档（规格说明书）包含的是对解系统的待求行为的描述以解决需求。其中第一文档才是通过做分析产生的；第二文档推迟到后续的规格说明任务中。 PDOA整个方法过程的基本步骤： 搜集基本的信息并开发问题框架（一种模型），以建立问题域的类型 在问题框架类型的指导下，进一步搜集详细信息并给出一个问题域相关的特性描述 基于以上两点，收集并用文档说明新系统的需求问题框架。问题框架是将问题域建模成一系列互相关联的子域。一个子域可以是那些可能算是精选出来的问题域的任一部分。问题框架的目标就是大量地捕获更多有关问题域的信息。基于不同问题子域的本质及存在于问题子域间的关系，可以把问题框架分类为： 工件系统——系统必须完成针对只存在于系统中的这些对象的直接 *** 作。 控制系统——系统控制部分问题域的行为，包括待求行为框架和受控行为框架。 信息系统——系统将提供有关的问题域的信息，包括信息是自动提供的和信息只在响应具体的请求时提供。 转换系统——系统必须将某种特定格式的输入数据转换成相应的、另一种特定格式的输出。 连接系统——系统必须维持那些相互没有直接连接的子域间的通信。 问题框架法在应用时，建议采用直截了当的策略： 抽象问题域：标识子域；标识子域间的交互；刻画每个子域的特征；生成一个上下文图识别出相关的标准框架；调整框架，尽可能使之适用于问题；使用关于相关框架的内容技术表来指导进一步的分析与文档编制任务。 问题域的描述与必须满足的需求二者之间有着明显的区别，对新的解系统的行为创建与定义应单独处理并且推迟到下一步的规格说明阶段。 4、方法的对比 结构化分析（SA）及其相应的派生方法，曾一度风行了许多年。它最初的版本主要是围绕对数据流以及问题域的数据结构进行建模，而现代的SA则直接将重点放在开发解系统的模型。描述问题域的SA可以算是想当不错的，所产生的功效可见一斑。然而，它对其他方面的支持却不够完善，在处理一些其他类型问题时显得有些笨拙。 面向对象分析（OOA）是当今主流的方法。OOA要求所有的系统均可以按照对象的特点来建模。它也继承了很多结构化分析的思想体系。OOA不能对问题域有个清楚的了解，因而它的起点若是有一份原需求文档，便可大大简化问题域的分析。OOA并不区分问题域描述与解系统描述之间的差异，而是直接交付出新的解系统的高层设计。 SA和OOA还有几点相同特性：主要模型是结构模型；通常焦点集中在对解系统的建模上；两中方法都较少地应用于需求获取领域；分析与内部设计之间没有明显差异。 面向问题域分析（PDOA）被认为是一种较为理想的方法。PDOA特点是重新将重点定位在问题域及需求上，通过对问题域的分类，向分析人员提供具体问题的相关指南。并且它将规格说明作为另行的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。PDOA丰富和完善了现今的“分析”方法，然而人们对它的了解和掌握还有一定距离。 因地制宜的应用三种方法，不仅能够如实的认识问题域，创建出健全的解系统，还能够向用户和设计人员都提供满意的需求文档。 三、 总结 在做软件需求的时候，我们完全没必要去限定要用或将要使用何种方法。我们的目的在于分析软件的需求，通常情况是都用到了所介绍的三种方法。首先我们用面向问题域的方法把问题分成几个部分。接下来用面向结构或面向对象的方法对各个部分进行逐步分析细化。在逐步分析过程运用各种建模技术对问题各部分建立合适的模型来细化需求。随着需求的进一步进行，我们越来越清晰的认识了软件系统的需求。 虽然应用方法使我们能够清楚地去了解软件需求，但是，大部分的需求文档和规格说明书都是以文本的形式记录的，因此，如何去表达我们所了解的需求也是很值得注意的。

需求的定义包括从用户角度（系统的外部行为），以及从开发者角度（一些内部特性）来阐述需求。

关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了所有的开发者，客户被迫与新的需求分析者坐到一起。系统的分析人员说："我们想与你谈谈你的需求。"客户的第一反应便是："我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统"。而实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话，你就确信你已明白用户的需求，那完全是自欺欺人。

需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明"。有些需求分析专家拓展了这个概念："从系统外部能发现系统所具有的满足于用户的特点、功能及属性等"。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性：

需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的"需求"术语存在，真正的"需求"实际上在人们的脑海中，这个人们主要是指客户，但一般情况下，用户并不能描述自己的需要，只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对。系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识。

任何文档形式的需求（例如如下将要描述的需求规格说明书）仅是一个模型，一种描述。

写程序设计文档，要注意简洁和逻辑性，需要明确的是：文档并不是进行设计的目标，也不是设计过程中额外的工作。具体模块和步骤为：

1需求分析

需求分析的结果通常需要使用需求说明文档来描述，目前主流的需求描述方法包括：用户例图、用户故事等方式。这些方式有所不同的侧重，其核心思想就是描述清楚用户的使用场景。

2功能设计

对于主要是用户界面的软件项目来说，功能设计可以看作是画出原型界面，描述使用场景，获得用户认可的过程。而对于没有界面的软件项目来说，则功能设计与需求分析的区分更为模糊。

3系统架构设计

系统架构设计是一个非常依赖于经验的设计过程。需要根据软件项目的特定功能需求和非功能性需求进行取舍，最终获得一个满足各方要求的系统架构。系统架构的不同，将很大程度上决定系统开发和维护是否能够较为容易的适应需求变化，以及适应业务规模扩张。

4模块/子系统概要设计

模块/子系统的概要设计，由架构师参与，核心设计和开发人员负责的方式进行。

在概要设计工作中，需要在架构确定的开发路线的指导下，完成模块功能实现的关键设计工作。在概要设计阶段，需要关注于模块的核心功能和难点进行设计。

5模块详细设计

在瀑布式开发模型中，模块的详细设计会要求比较严格，将所有类进行详细设计。除了一些对于系统健壮性要求非常严格的软件项目，如国防项目，金融项目还要求有详细设计文档之外。其他的项目大多采用其他方式来处理这样的工作，如自动化测试等。

综上所述，软件设计文档作为软件开发团队的沟通、理解、知识共享的手段，具有非常重要的意义。

项目需求分析的概念需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1SRS文档(System Requirement Specification); 2DRM 文档；3Acceptance Plan 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析需求分析就是分析软件用户的需求是什么如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死

需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位大家一定要对需求分析具有足够的重视在一个大型软件系统的开发中,他的作用要远远大于程序设计 二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审

问题识别

就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型, *** 作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标

分析与综合

逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型)

制订规格说明书

即编制文档,描述需求的文档称为软件需求规格说明书请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交

评审

对功能的正确性,完整性和清晰性,以及其它需求给予评价评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法需求分析的方法有很多这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论

原型化方法是十分重要的(是软考等常考的知识点)原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能

原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型以后的目标系统就在原型系统的基础上开发

原型主要有三种类型(软考考过):探索型,实验型,进化型探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。

在使用原型化方法是有两种不同的策略:废弃策略,追加策略废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统系统构造完成后,原来的模型系统就被废弃不用探索型和实验型属于这种策略。

追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略

校园社团小程序技术性分析说明需要考虑以下几个方面：

一、硬件需求：计算机硬件配置（主机、显示器、键盘、鼠标等），网络环境（有线、无线），服务器环境（物理环境，服务器类别，网络带宽等），移动设备（支持的 *** 作系统，设备型号，屏幕尺寸，处理器型号，内存大小等）；

二、软件需求：多媒体技术，网络技术，编程语言，数据库技术，软件安全， *** 作系统，文档编辑软件，用户界面技术等；

三、开发技术分析：确定程序的功能，把握程序的架构，确定技术环境，分析系统和数据的关系，检查程序技术的可行性，分析系统的安全性，确定系统的维护，对程序进行调试，检查程序的可靠性和可维护性，确定程序的发布和运行等；

四、设计技术分析：确定系统架构，构建系统数据库，定义数据库模型，构建系统模块，定义模块功能，搭建系统框架，设计用户界面，设计系统功能，设计系统安全策略等；

五、测试技术分析：确定测试范围，确定测试类别（功能测试，可靠性测试，安全性测试，性能测试），编写测试用例，制定测试策略，运行测试，审查测试报告，编写评估报告等。

总之，校园社团小程序技术性分析说明需要考虑硬件、软件、开发、设计以及测试方面的技术要素，以确保小程序能够满足用户的需求，并能顺利运行。

以上就是关于学校设备管理系统软件需求分析全部的内容，包括:学校设备管理系统软件需求分析、论文高手进：软件开发需求分析的认识和理解、如何进行软件需求分析等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！