系统设计是系统工程中系统分析之后的阶段。在20世纪60年代，随着系统工程的发展，系统设计主要用于大型工程项目等工程型问题，任务比较明确、问题结构比较清楚的结构化问题的解决方案的探索和最优策略的选择。到了20世纪70年代，在企业管理、项目管理、管理信息系统等领域内，人在系统中发挥的作用越来越大，并且这些领域与社会、政治、经济、生态等因素纠缠在一起，系统设计的因素多且复杂，系统设计呈现出非结构性问题。针对此类非结构性问题的系统，切克兰德提出了“软系统方法论”的思想和内容。管理系统设计更贴近于“软系统方法论”的思想，管理系统设计并不是追求“最优”，取而代之的是“可行”“满意”的概念，设计的过程首先是通过概念模型或意识模型的讨论和分析后，通过不断磋商和反馈，才能逐步弄清问题，得到满意的可行方案。

需求分析一般划分为5个部分，即需求获取、需求分析、需求描述、需求验证与需求管理。需求获取、需求分析、需求描述、需求验证往往处于系统论证、分析阶段，而需求管理则贯穿于整个系统的分析、设计、开发与建设过程中；相对来说，需求获取、需求分析、需求描述与需求验证之间的关联要更紧密一些。需求分析是对所获取的需求进行论证和分析，明确哪些需求是可行及可接受的，剔除一部分不必要或不可行的需求；所有需求被确定下来后，要对它们进行反复的论证和分析。需求分析的目的就是构筑系统的总体框架和概念模型。

①确定问题难。主要原因：一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求涉及多因素，比如运行环境和系统功能、性能、可靠性和接口等。②需求时常变化。系统的需求在整个系统生存周期，常会随着时间和业务而有所变化。③交流难以达成共识。需求分析涉及的人、事、物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难。④获取的需求难以达到完备与一致。由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。⑤需求难以进行深入的分析与完善。需求理解无法进行全面准确的分析，不能适应客户环境和业务流程的改变。因此分析人员应认识到需求变化的必然性，并采取措施减少需求变更对系统的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。

需求分析具体分为功能性需求、非功能性需求与设计约束3个方面。功能性需求即系统必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是系统需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从系统帮助用户完成事务的角度上充分描述外部行为，形成需求规格说明书。非功能性需求作为对功能性需求的补充，应包含在需求分析的内容中还应该包括一些非功能需求。主要包括系统使用时对性能方面的要求、运行环境要求。系统设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。设计约束一般也称作设计限制条件，通常是对一些设计或实现方案的约束说明。

需求分析可以分为3个步骤。

①需求分析的第一步是对所获取的需求进行过滤。并不是所有的用户需求都可以被满足。原因可能有技术上的、实施费用上的、系统兼容性要求上的等。技术人员必须了解所有需求的相关情况及其影响。对其进行提前考虑和估算。对于那些被排除在最终系统之外的需求，技术人员有义务帮助用户分析为什么他们提出的要求是不合理的。这样做既是为了保证将来整个系统的完整性、有效性不受影响，也是为了保证在随即进行的系统开发进程中不会因此而产生被动的设计变更。对于系统可以接受的需求条目，需要工程师在此时应当能够掌握每个需求的验证方法。最终确认的需求必须具有“充要性”：既是必须需要的，又是充分需要的。不应当有遗漏，也不应当有冗余，所有需求条目都应当是清晰而准确的，形成有效的文档。由于此文档最终必须经由用户确认，因此文档在描述上要和实际应用相结合，以便用户从他们的角度来理解系统的情况。

②需求分析工作的第二步是构建整个系统的基本框架。为辅助分析，可以建立系统的概念模型来理解系统各部分之间的逻辑关系、运行上下文、运行环境及内部实体之间的控制关系等相对复杂的内容。分析必须在所有系统可能出现的限制条件之内进行。将系统分解成一系列子系统或者组件，系统功能被分别安置在这些子系统和组件之上。分解设计必须非常谨慎地进行，因为一旦系统的结构被确定下来，改变所带来的花费是很大的。系统内部的部件结构之间的配合很容易影响系统的功能。常用的方法是首先在系统各部分的逻辑关系的基础上建立系统的初步模型，然后逐步增加系统限制等外部条件并完善模型。对于每一个阶段性的模型，在其建立完成后，应当根据掌握情况对其进行讨论和论证，决定是否要对模型进行改进。这项工作应当是循环进行的，直至满意为止。在实际工作中，除非是很小的系统，此时通常很难对系统所有子系统和部件做出非常精确的设计。从循环深入的观点看, 每个组件所承担的需求任务又是一个复杂的系统需求，有时需要进行反复的循环深入分析以增加细节，还可能需要补充学习系统所在的知识域内的知识以增进对于需求描述的理解和解释。所有最终的技术实现细节都是高层应用需求不断深入和演化的结果。

③需求分析的第三步工作是需求的优化和系统构架的初步形成。这一步的工作是在第二步的基础上进行的，工作的内容是对系统的基本结构作最后的优化并形成完整的系统结构，可以视为系统的分析与设计工作的前一步。需求的优化和系统构架的搭建这两个工作是衔接的，一般没有明确的边界。但是，需要把握的是，需求分析不会对系统做很深的分解；对于分解过程，应当细致地进行记录，保留记录结果以方便对所有可能出现的系统需求变更进行有效评估。这个过程叫作“需求跟踪”。

从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模方法和面向对象方法。①功能分解方法。将新系统作为多功能模块的组合。各功能可分解为若干子功能及接口，子功能再继续分解，便可得到系统的雏形，即功能分解——功能、子功能、功能接口。②结构化分析方法。一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。③信息建模方法。从数据角度对现实世界建立模型。大型系统较复杂，很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持，实质上也可看成由一系列有序模型构成，其有序模型通常包括功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E-R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。④面向对象方法。面向对象方法的关键是识别问题域内的对象，分析它们之间的关系，并建立3类模型，即对象模型、动态模型和功能模型。面向对象方法主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征（属性）和行为特征（服务）。

进入21世纪后，由于互联网、大数据等新一代信息技术的发展，管理系统的规模越来越庞大，结构变得越来越复杂，这给传统的以软件工程为背景的需求分析方法带来了新的挑战。传统的管理系统的需求分析涉及的利益相关者少、环境因素相对明确、需求获取工作量较小，而新的管理系统的需求分析利益相关者众多、环境因素复杂、需求来源广泛、获取工作量大；传统管理系统需求分析的任务需求数量较少且比较确定、环境与原系统的约束明确、功能性能需求的探索空间较小、需求之间可能存在一定的冲突，而新的管理系统需求分析中往往存在较高层次的能力需求、任务需求多且关系灵活、系统的功能、性能需求存在庞大的探索空间、需求之间存在不可避免的冲突。因此，近些年来以复杂系统和体系特征为对象的管理系统需求问题日益突出，需求分析从关注管理系统的具体任务转到关注管理系统的能力要求的转变，同时基于大数据的分析、预测、评价理论在管理系统的需求分析中也得到了广泛应用。