需求的定义
原文地址：https://blog.csdn.net/qq_34781336/article/details/84834801
功能性需求 functional requirement 规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavioral requirement），因为习惯上总是用 “应该” 对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。
注意：用户需求不总是被转变成功能需求。
产品特性：所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
非功能性需求是指依一些条件判断系统运作情形或其特性，而不是针对系统特定行为的需求。包括安全性、可靠性、互操作性、健壮性、易使用性、可维护性、可移植性、可重用性、可扩充性。
将飞机订票系统中的以下方面做如下的划分，F代表“功能性”，NF代表“非功能性”，X代表“不应当是需求”。简要的说明功能性或非功能性需求的种类。对于不应当是需求的方面，说明其原因。
1.如何输入有关航班、乘客及订票信息。F：输入
2.什么信息要出现在机票和报告中。F：输出
3.如何计算乘机费用。F：计算
4.什么信息必须存储在旅行社和其他人访问的数据库中。F：数据存储
5.这个系统应该设计成可以处理常旅客计划。NF：可扩展性
6.这个系统在任何时候都必须是可用的。一周中只允许有2分钟宕机时间。NF：有效性
7.必须使用某排序算法根据离开时间对航班排序。X：这是一个设计问题
如何进行功能需求分析
需求分析特指 “软件功能需求分析”，通常由需求分析人员经过调研和分析，准确理解用户的需求后，将业务需求转化为功能需求的过程。
-
需求获取
获取需求是指通过多种方式收集各人员对软件的意见和想法，例如现存问题、期望、业务逻辑等，即谁需要？要什么？为什么？怎么做？……
获取需求的方式有用户访谈、问卷调查、观察等，收集到需求可能多种多样，需进行筛选、分析、排序，进而得到有效的业务性需求。 -
需求分析
需求分析是指将收集到的业务需求进行整理，对业务分门别类，转化为开发可实现的功能需求，输出相关的功能需求列表。分析时可借助脑图、Visio、excel等工具，梳理相关业务流水线，抽象为功能模块。 -
设计功能（画原型/撰写需求规格说明书）
得到满足需求的功能列表后，按优先级排序，梳理软件框架，然后借助Axure等原型工具绘制软件的线框图，也称为软件原型，或者通过需求规格说明书的形式来描述软件功能。原型和需求规格说明书都是功能描述的形式，原型更直观，说明书更细化，可根据自己的情况选择。 -
需求验证
输出原型或需求说明书后，需组织相关人员进行需求评审，验证已梳理的功能需求是否符合需求提出人的要求，一般会邀请客户接口人、用户代表、开发人员、项目经理参与评审，这个过程可能是反复进行的，直至需求评审通过。
软件开发中的需求分析
原文地址：http://www.woshipm.com/pmd/1033421.html?tdsourcetag=s_pctim_aiomsg
对于功能需求的分析我们主要从两方面入手：业务场景和系统界面。
-
业务场景
什么是业务场景？
场景是我们设计功能时的一个重要参考依据。所谓场景，就是用户在进行这步操作时所处的周围环境。这里的周围环境包含的维度很多，比如用户的属性，年龄、身份、工作等。场景不仅指物理环境，比如在车上、飞机上、教室里，还指任务场景，比如开空调的业务场景是因为夏天很热，需求是身体凉快不热。
任何产品都是一种物质存在，要使其有意义，就应该置其于恰当的社会环境中，而且这种环境与其他工具或人密不可分。可以通过一个表格来描绘业务场景，比如描绘信评人员在财报更新的时候需要做跟踪评级。
为了保持寝室卫生，大学几个室友在寝室决定轮流打扫寝室卫生
用户在提需求的时候，多问几个为什么，为什么要提这个需求？目前是遇到什么困难？现在是怎么做的？如果涉及到业务数量的，还可以问下量大不大？比如某公司就只有一个客户做某业务，为了这一个客户去开发一个大功能，浪费人力、物力甚至造成项目延期。
但也不是说，就不做，如果后续做这项业务的客户会越来越多，开发功能是需要的。
将用户提出的需求业务场景梳理清楚后，接下来就是需要过滤用户的需求，有时候客户提出的需求并不是“真”的需求。很多时候因为客户自己本身对业务的不了解或者对行业知识不了解，基于某些情况，客户提出一些假需求，客户提出“假需求”的情况有：
-
客户对自己本身对业务或行业上的知识不是很了解；
-
客户基于“花少的钱获得更多的功能”心理提出很多个性化的需求；
-
客户在提需求的时候有时候也会撒谎；
-
客户不知道自己要什么导致假需求的产生。
识别客户的需求到底是不是真的需求，最重要的一条是识别客户提出需求的动机，知道为什么客户会提出这个需求？（又回到业务场景的问题了）
知道客户提出需求的动机以后，多问几个为什么，如果客户在回答问题的时候前后不连贯，或者没有逻辑，这类需求往往就是假的需求。
在过滤掉客户假的需求以后，需要知道如何去表达需求，为了使需求更连贯和完整，建议采用 “情景场景剧本” 的方式来表达需求。
把需求当成一个情景剧，有人物、有业务场景、有目标、有故事背景、有做事的动机、有情节等，可以用语言或者图形的方式将故事描绘出来。
如果发现故事中有些情节是是断裂的或者是讲不通的，那有可能你的需求并没有真正弄清楚，需要重新去梳理一下你的这个需求。
-
功能界面
将用户的需求理解清楚后，只是脑海中或者文字的说明，需要更形象，通常是除了文字说明还需要画原型图，很难理解的需求，画出系统界面后，开发人员能一下子看明白。
功能界面需要将每个功能按钮、查询条件、交互方式、以及界面上字段的类型、取数来源、排序等都需要细化。
Axure
画原型图的工具用的比较多的是Axure。以上是画的比较好的原型图，连滚动条和翻页都考虑到了，可以说是比较具体的，开发人员一看就知道要怎么做。
-
相关阅读
撰写功能需求说明文档
原文地址：https://www.jianshu.com/p/370194ba26da
功能需求说明文档是作为产品人需要做出的基础文档说明，在工作中是必不可少的。此类型说明文档主要应用的场景为产品要上线一个新功能，或者可以成为一项服务。对此，做出该功能的需求说明文档，为功能的开发和实现提供依据。
功能需求说明文档应包括以下五个部分：
-
目标
确定目标是一项任务开始的基础，只有在明确的目标指引下才能保证以最高的效率完成工作。此部分内容需要明确此次工作的目标，提出需求并开发此功能的原因是什么，为什么会有这样的需求，最终希望达到的目标是什么。 -
定义
当提出的功能中有一些名词大家不太了解，或者不容易辨别，此时需要对这些名词进行定义，详细说明他的意义及背景，方便开发等人员了解，避免概念混淆。 -
模块划分
本部分主要是对下一步功能需求进行的模块划分。之所以涉及到模块划分，是因为产品可能分别存在PC端、手机端以及H5等平台上。不同平台之间的需求设计可能存在些许差异。因此，需要按照平台进行模块划分，在第四部分“功能需求”部分则按照不同的模块进行针对性展开说明。 -
功能需求
此部分在第三部分模块划分的基础上，针对不同的模块进行详细的说明。这部分的内容时文档的核心，必须对各模块的功能需求做出尽可能详尽的说明。
在功能提出后，需要详细说明功能触发场景、文案、统计数据（埋点探针的设置，需要统计哪些指标，此部分一定要做的尽量全面，如果后期发现数据不全再返工是一件事倍功半的事情）、边界条件（指的是展示内容的边界，要展示内容的数量、刷新方式等），如有必要则给出原型图。 -
优先级
优先级是工作当中必备的说明。在提供说明文档的时候，需要给出需求的优先级，如果需求内容不多，可以在第四部分按优先级进行排序即可。在需求较多的情况下，则单独咋第五部分给出任务优先级，为开发人员提供参考。
网友评论