软件设计是从用户故事或者软件需求规格说明书或者软件需求文档出发，根据需求阶段确定的需求功能定义，设计软件系统的整体结构、划分功能模块、确定每个模块之间的数据交换、信息流通、页面交互以及后期的数据收集、整合、展现等;形成软件具体设计方案。
软件设计是把许多概念的事物和问题进行抽象化，并抽象根它们不同的层次和角度;将问题或事物分解并模块化，使得解决问题变得容易，分解越细模块功能越小也就越有利实现。
一、设计阶段
1、概要设计——
结构设计：定义，软件系统各主要部件之间的关系
接口设计：软件内部与外部的数据交换或软件和操作系统间，以及软件和人之间如何通信。
全局数据结构设计：将模型转换成数据结构的定义。
过程设计：系统结构部件转成软件的过程描述
主要是关注如何将需求转换成数据和软件框架。
2、详细设计
关注于将框架逐步求精细化为具体的数据结构和软件的算法表达。发生中的设计行为、数据、算法和程序设计都需要由现代程序所需的界面设计的行为结合。
二、设计原则
1、设计对于分析模型应该是可跟踪的——软件的模块可能被映射到多个需求上。
2、设计结构应尽可能模拟现实
3、设计应该表现出一致性
4、不要把设计当成编写代码
5、在创建设计时就应该能够评估质量
6、评审设计以减少语义性错误
7、设计应模块化，将软件逻辑划分为元素或子系统，并包含数据、体系结构、接口和构件的清晰表示。
界面设计方案
三、软件架构
软件架构涉及到程序的两个特性：（1）模块的层次结构 （2）数据结结构
这源自于需求分析时将真实世界问题定义与软件解决方案要素联系起来的分割过程。当问题的每个部分通过一个或多个软件要素得到解决后与问题的定义和解决相一致，软件和数据结构的进化就开始了。这个过程代表了软件需求分析和设计之间的位置。控制层级也叫程序结构，描述程序组件的组织并意味着控制层级，它并不描述软件程序方面，例如进程顺序、决定的事件/命令、工作循环。
数据结构描述了当个数据之间的逻辑关系，规定了数据的组织、访问方法、关联程度和信息选择处理。
程序结构着重处理每个模块的细节并必须提供一个精确的处理范规范，包括事件顺序、准确的判定、重复操作、数据结构。软件的程序表现是分层的。
四、设计方法论
设计过程中用以促成模块化设计的四个区域：模块、数据、体系、程序设计。
模块设计降低了复杂性、便于修改、且使得支持系统不同部分的并行开发实现起来更容易。模块类型提供的操作特性通过结合时间历史、激活机制、控制模式来表现。在程序结构内部，模块可以被分类为：
1、顺序模块，由应用程序引用和执行，但不能从表现上中断。
2、增量模块，可被应用程序先行中断，而后再从中断点重新开始。
3、并行模块，在处理器环境下可与其他模块同时执行。单独的模块更容易开发，因为功能可以被划分出来，而界面只是用来保证功能的独立。功能的独立性可以使两个定性的标准来衡量：凝聚性——衡量模块的功能强度的相关性 耦合性——衡量模块间的相互依赖的相关性。
五、举例说明
本文转载自：https://www.gylmap.com
软件方案设计在需求开发人员看来，不外乎就是系统的架构设计，也就是我们常说的解决方案，从整个系统层面进行梳理，将系统的功能、架构，数据、信息，页面交互、模块重新进行梳理、扩展、展现的一个过程。
1、架构设计的实践
（1）看透需求——深入了解需求，例如做分销系统后台，必须了解分销概念架构，有一个整体模型，通过视图细化架构；重视功能；需要根据需求全面的考虑整体功能。
（2）架构大方向正确——了解分销系统后台的基本模块，保证与其竞品功能无异议；满足系统数据流向、数据处理、信息产生、信息保存及处理等要求。
（3）设计好架构的各方面——要根据需求开发的结构进行系统功能梳理，各层次及功能要区分。
分销系统后台模块设计方案
2、架构设计的步骤
（1）需求分析
（2）领域建模
（3）确定关键需求
（4）概念架构设计
（5）细化架构设计
（6）架构验证
需求分析。有全面认识需求并权衡不同需求之间相互影响的情况下，设计出的架构很可能有问题。
领域建模。领域建模的目的是：透过问题领域的重重现象，捕捉其背后最为稳固的领域概念，以及这些概念之间的关系。在项目前期，所建立的领域模型将为所有团队成员之间、团队成员和客户之间的交流提供共同认可的语言核心。随着项目的进展，领域模型不断被精化，最终成为整个软件的问题领域层，该层决定了软件系统能力的范围。
概念架构的设计，软件系统的规模越大、复杂程度越高，进行概念架构设计的好处就越明显。
确定对架构关键的需求。这不仅要求对功能需求（如用例）进行筛选，还要对非功能需求进行综合权衡，最终确定对软件架构起关键作用的需求子集。
概念架构设计。概念架构的设计，必须同时重视关键功能和关键质量。业界流行的一种错误观点是“概念架构=理想化架构”，不考虑任何非功能需求，也不考虑任何具体技术。
概念架构要明确：1）如何划分顶级子系统；
2）架构风格选型；
3）开发技术选型；
4）集成技术选型；
5）二次开发技术选型。
在接下来，全面展开规格级的架构设计工作，设计出能实际指导团队并行开发的细化架构。
细化架构设计。一般而言，可以分别从逻辑架构、开发架构、运行架构、物理架构、数据架构等不同架构视图进行设计。
架构验证。对后续工作产生重大影响返工代价很高的任何工作都应该进行验证，软件需求如此，架构设计方案也是如此。至于验证架构的手段，对软件项目而言，往往需要开发出架构原型，并对原型进行测试和评审来达到；而对软件产品而言，可以开发一个框架来贯彻架构设计方案，再通过在框架之上开发特定的垂直原型来验证特定的功能或质量属性。
因此，从架构验证工作得到的不应该仅仅是“软件架构是否有效”的回答，还必须有可实际运行的程序：体现软件架构的垂直抛弃原型或垂直演进原型，或者是更利于重用的框架。这些成果为后续的开发提供了实在的支持。
从最初的概念设计到落地实施，见证了整个软件方案设计，其中就涉及到一个重点，那就是需求开发，整个过程需要管理与把控；这就形成了一个整体的需求开发与管理活动。软件方案设计，就是为了使用户、开发人员更能清晰的认识，从软件的概念期到实际软件研发后的落地整个流程的了解。
项目管理过程
