需求分析的功能需求可以画图吗，系统架构设计师必读软件工程中的需求工程、系统分析与设计、DFD、DD及

在软件开发的世界里，需求就像灯塔，指引着整个开发过程的方向。咱们先来说说功能需求，这就好比是软件的“超能力”，是用户在系统里能完成任务的必备本事，开发人员得一板一眼地把这些功能给实现出来。比如说我们使用一款在线办公软件，能够进行文档编辑、多人在线协作这些功能，那都是根据功能需求来开发的。

1. 非功能需求，它是系统得有的素养。这分为软件质量属性像可维护性，如果一个软件不好维护，出了小问题都得费九牛二虎之力才能解决，那就很麻烦；还有可靠性也很关键，要是软件动不动就崩溃，就像个调皮捣蛋的小孩子，时不时闹点脾气，那可不行。效率也得讲究，如果软件运行起来像蜗牛一样慢，那用户肯定是要抓狂的。再讲讲其他非功能需求，它就像一些附属的小规则一样。

2. 设计约束就有点像是紧箍咒。像有些项目必须用国有自主知识产权的数据库系统，这个就没得商量，就像孙大圣头上的紧箍一样，得照着做。还有非得运行在UNIX操作系统之下，这都是特定的约束条件。

需求工程是个挺牛的事，要用上那些经过验证的原理、方法，还得用合适的工具和记号，把要开发的系统和它的行为特征还有各种约束都给描述清楚。一个好的需求那可得有点特质。无二义性很重要，不能让开发人员乱猜测这个需求到底是啥意思；完整性就是得全面，不能说有缺口；一致性就像是穿衣服得搭配协调，不能自相矛盾；可测试性那就是说能检验这个需求是不是做到位了；确定性，需求得明明白白；可跟踪性就好比你走过的路都能留下脚印，便于查看；正确性就不用说了；必要性强调的是需求得是真正需要的需求分析的功能需求可以画图吗，不是多余的。

需求分析人员就像是个翻译官，把用户那些零零散散的要求和期望变成有条理的用户需求。就有了需求定义，也就是软件需求规格说明书SRS。这可是需求开发活动的产出，就像是一张地图，让项目干系人与开发团队对系统最初的规定有共同的认识，整个开发工作都得围绕这个基础。

需求验证像是个挑刺的过程，也就是需求确认，得跟用户一块确定需求没问题，对着需求规格说明书SAS进行检查，这里面包括两个步骤。

再说说需求变更和风险，这可是挺头疼的事。像是无足够用户参与，就像盖房子没问人家主人想要啥样的，那盖出来的房子主人能满意吗？忽略用户分类也不行，不同的用户群体需求不一样。用户需求不断增加就像个不断膨胀的气球，一不小心就爆了；模棱两可的需求就像是迷糊蛋，让人不知道到底要干啥；不必要的特性那就是画蛇添足；过于精简的SRS也不对，信息不全面。不准确的估算更是个*烦。

需求跟踪矩阵就像个账本，原始需求和用例有对应了就打个对号，能把需求情况记得清清楚楚。

在软件生存周期不同的阶段，像是结构化分析、结构化设计和结构化编程等方法就派上用场了。

外部实体也很有趣，就像是软件世界之外的小使者，是软件系统外的人员或者组织。是系统数据的发源地或者归宿地。

概要设计是搞系统总体结构设计的，把系统功能分配给各个软件模块，还得搞清楚每个模块的功能和它们之间的调用关系，弄出软件的模块结构图，这就是系统结构图。模块之间调用传递控制变量的时候，被调用模块还能根据变量的值选择性执行功能。模块间通过软件外面的环境联合就像搭桥一样，用I/O连接到特定设备、格式、通信协议上。

详细设计的主要任务就是给每个模块规划好实现算法，设计好需要的局部数据结构。

问题分析图(PAD)是个好帮手，像个小助手一样支持结构化程序设计。它逻辑结构清晰，图形还标准化，能引导设计人员用结构化程序设计方法，这样程序质量就上去了。