|
1. 可行性研究 可行性研究的主要任务是“了解客户的要求及现实环境，从技术、经济和社会因素等三方面研究并论证本软件项目的可行性，编写可行性研究报告，制定触目项目开发计划。” （1）技术可行性。在这个方面，应该考虑的问题有：开发风险、资源可用性、技术。 （2）经济可行性。估算成本与效益、开发成本、运行成本、运行效益等。 （3）社会可行性。可分为操作可行性与法律可行性。 可行性的研究步骤：确定软件的目标和规模——>研究分析现有系统——>导出新系统的高层逻辑模型——>重新定义问题——>导出和评价供选择的方案——>推荐行动方针——>草拟开发计划——>撰写《可行性研究报告》。 2. 需求工程 软件需求的定义：用户解决问题或达到目标所需条件或能力；系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权利；一种反映上面所述条件或权能的文档说明。 需求分析的任务：是要准确的回答系统必须做什么。注意：不是确定系统怎么完成工作，而是确定系统必须完成哪些工作，必须提出完整、准确、清晰、具体的要求。 （1） 确定综合需求。 （2） 分析系统的数据要求。 （3） 导出系统的逻辑模型。 （4） 编写文档。 与此同时，需求工程也面临非常多的挑战：问题空间理解、人与人之间的通信、需求的不断变化，因此就需要良好的沟通能力，需求工程对于人员要求为：很强的概括能力、分析能力、社交能力；一定的软硬系统开发经验；能理解用户提出的要求；善于在用户和软件开发机构之间进行良好的通讯。所以，系统分析员的焦点是做什么，而不是怎样做。 3. 软件需求的层次与内涵 软件需求的三个层次：业务需求、用户需求、系统需求，此外，还有非功能性需求。 （1）业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。 （2）用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或 方案脚本(scenario)说明中予以说明。用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。 （3）功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。 （4）非功能需求，包括性能指标和对质量属性的描述。 质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。 4. 需求开发的流程、阶段任务与主要技术 软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和需求管理六个阶段。 （1）需求获取：系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、描述不同运行条件下系统或产品使用状况的应用场景等。需求获取的工作产品为进行需求分析提供了基础。 （2）需求分析与协商：需求获取结束后，分析活动对需求进行分类组织，分析每个需求其它需求的关系来，检查需求的一致性、重叠和遗漏的情况，并根据用户的需要对需求进行排序。在需求获取阶段，经常出现以下问题：用户提出的要求超出软件系统可以实现的范围或实现能力；不同的用户提出了相互冲突的需求。 （3）系统建模：建模工具的使用在用户和系统分析人员之间建立了统一的语言和理解的桥梁，同时系统分析人员借助建模技术对获取的需求信息进行分析，排除错误和弥补不足，确保需求文档正确反映用户的真实意图。常用的分析和建模方法有面向数据流方法、面向数据结构方法和面向对象的方法。 （4）需求规约：软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。 其中，需求规约的原则有：（a）从现实中分离功能，即描述要“做什么”而不是“怎样实现”。（b）要求使用面向处理的规约语言（或称系统定义语言），讨论来自环境的各种刺激可能导致系统做出什么样的功能性反应，来定义一个行为模型，从而得到“做什么”的规约。（c）如果被开发软件只是一个基于计算机的系统中的一个元素，那么整个大系统也包括在规格说明的描述之中。（d）规约必须包括系统运行环境。（e）规约必须是一个认识模型，而不是设计或实现的模型。（f）规约必须是可操作的，以便能够利用它决定对于任意给定的测试用例，已提出的解决方案是否都能满足规约。（g）规约必须允许不完备性并允许扩充。（h）规约必须局部化和松散耦合。它所包括的信息必须局部化，这样当信息被修改时，只要修改某个单个的段落（理想情况）。同时，规约应被松散地构造（即松耦合），以便能够很容易地加入和删去一些段落。 （5）需求验证：作为需求开发阶段工作的复查手段，需求验证对功能的正确性、完整性和清晰性，以及其它需求给予评价。为保证软件需求定义的质量，评审应以专门指定的人员负责，并按规程严格进行。 （6）需求管理：需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制。换句话说，需求管理就是：一种获取、组织并记录系统需求的系统化方案，以及一个使用户与项目团队对不断变更的系统需求达成并保持一致的过程。 5. 需求规格说明书 软件需求规格说明是对分析和综合过程的结果描述，它包含了软件的功能、性能、接口、有效性等需求的描述信息。通常，描述需求规格说明的语言主要分为自然语言、形式化需求描述语言、结构化语言。 进行产品功能描述时，页面内容描述、功能框架、业务流程和用户界面布局的需求描述内容包括： （1）界面内容需求：描述内容是静态or动态数据：哪部分内容是静态的，哪些是动态的文本内容调用；完整描述界面内容：如顶部标题、按钮里的文字等；内容加载是否有特殊需求：是否需要本地缓存还是刷新后要加载新内容；描述输入框中的内容：初始内容、输入后是否有附加功能；界面内容为空时的处理：如是否支持离线、是否要设计空数据界面、是否要引导用户操作；内容长度的限制：内容展示是否限制字数，多出限定字数是是否可以点击查看更多、昵称是否有字数限制、密码是否有字数限制；内容违禁时需求：对敏感词、违禁内容（如：涉及版权、专利、隐私等图片)的处理；过期内容的处理：过期内容是否删除、删除后的内容用户再次点击如何展示；用户内容输入处理：用户在输入框输入空格、特殊字符的处理、用户的输入内容是否保留为历史记录。 （2）产品流程需求：功能框架和流程的功能点：对所有流程中包含的功能进行描述。注意流程中的主导航进入及返回是否是从哪来回哪去；流程描述：页面跳转描述，如A→B页面跳转进行完成说明（包括触发方式：单击\长按\滑动；触发区域：**某个区域；触发前中后状态：禁用、加载时间、动效、中间状态）；页面布局：页面标题栏、导航栏说明，页面反馈如：弹窗\加载状态进度提示；特殊流程描述：如登陆流程中的忘记登陆密码流程；启动页、用户引导页流程描述；页面布局的横竖屏问题；页面布局的不同屏幕尺寸自适应问题；不同模式下页面说明：夜间模式\编辑模式\无图模式。 （3）账号及权限需求：用户个人身份管理会涉及到用户的不同登陆状态登陆、非登陆、账号异常、账号被冻结；同时还涉及用户等级及权限相关需求，如会员与非会员，付费与非付费用户；在进行账号及权限需求描述时要说明不同账号状态及用户权限下显示的内容和功能：不同账号状态说明：登陆状态、非登陆状态不同情况；不同用户等级和权限说明：不同等级用户有哪些权限？在页面展示上有什么不同？不同账号状态切换时是否要特殊展示； ；说明一个账号多终端登陆还是允许多终端登陆同一账号，当一个帐户只允许登录一台机器，需要检查帐户终端数量，原终端帐号踢出是否给予提示；是否有多账号切换，是否要保留历史账号；是否支持第三方账号登陆，登陆后如何绑定自有账号。 （4）硬件环境需求：不同终端水平包括：硬件特性、网络状态等；横竖屏是否需要锁屏；不同分辨率是否需要适配，如何适配；是否调用手机物理按键，什么情况下调用，如何调用；SD卡在做文件导入本地操作时：没有SD卡、SD卡储存已满、储存位置等情况说明；网络时的内容显示，执行联网操作如何给予用户提示；网络信号不好，是否做无超时限制，如何给用户反馈，是否引导用户做其他操作或退出；缓存如何处理，什么情况调用缓存；服务器宕机、出现404、502情况时如何处理。 （5）服务器交互需求：服务器交互需求包括消息推送、数据更新方式、软件权限和后台监管需求；说明必要的push消息业务规则，什么情况需要push消息，push什么内容 ；哪些内容要用户手动刷新，哪些需要自动刷新，哪些是手动+自动刷新；哪些内容从后台切换回前台时要进行数据更新；哪些内容需要实时更新，哪些定时更新；数据展示部分的处理逻辑：每次从服务端请求、缓存到本地；软件权限说明：什么功能在什么情况下调用什么样的权限（位置\通讯录\联网\照片）；数据安全性说明：输入的密码是否以明文形式显示，备份是否加密, 恢复数据是否考虑恢复过程的异常通讯中断；交叉事件安全性说明：运行软件过程中, 如果有来电、SMS、EMS、MMS、蓝牙、红外等通讯或充电时, 是否暂停程序，优先处理通信。处理完毕后是否正常恢复软件, 继续原来的功能；后台的数据检测点，监控哪些数据；后台的哪些功能点为前端提供哪些内容，敏感词、违禁内容如何屏蔽-如何进行内容推荐和排序。
|