欢迎来到小居数码网-一家分享数码知识,生活小常识的网站,希望可以帮助到您。

当前位置:生活小常识 > 数码知识 >
优质

需求规格说明书的概念(需求规格说明书描述了)

数码知识

丁子博优秀作者

原创内容 来源:小居数码网 时间:2024-07-27 18:20:01 阅读() 收藏:60 分享:56

导读:您正在阅读的是关于【数码知识】的问题,本文由科普作家协会,生活小能手,著名生活达人等整理监督编写。本文有1317个文字,大小约为6KB,预计阅读时间4分钟。

编辑导语:需求文档和需求规格说明书,二者都与产品有关,但是其所应用的场景又有所差异。产品经理可以利用需求规则说明书进行系统的校验或评判,使之更好地为实际场景所服务。本篇文章里,作者阐述了他所理解的需求规格说明书,一起来看一下。

需求规格说明书描述了

一、前言

作为一个需求工作经验(ToB端)2年的小白,在没有大手子知道的情况下摸爬滚打磕磕绊绊,属实有点闭门造车,希望大家多指点指点,如何才能更好地完成需求工作。

另一方面,想让自己的胡思乱想可以记录下来,避免真的变成了胡思乱想。

二、编写需规的目的是什么?

为什么要将需规的编写目的放在第一位?

作为产品岗来说,发掘用户需求是我们的最终目标。针对这种思维结构,那么在探讨如何写好需规的前提,我们要想明白需规存在的含义是什么?为了什么而存在?我们不妨继续通过用户场景来分析,我们在什么场景下使用需规呢?

  • 场景A:需求人员在需求传递环节,通过需规来与开发团队的成员讲述我们的系统要做功能A、功能B、功能C等等。
  • 场景B:开发同事发现业务A,有两种理解方式,不清楚该使用哪一种。
  • 场景C:项目进入需求验证阶段,需求同事要验证系统是否通过。
  • 场景D:测试同事提了一个BUG,但开发同事认为这不是BUG,认为需求如此。
  • 针对以上四种场景,我们可感受到,我们需要利用需规去指导、去校验、去评判当前开发的系统是否是正确的。从场景中分析的需规作用,可以理解为一种解决方案。

    我们再进一步地去思考,是否可以认为,需规的根本目的是“保证所开发的系统就是客户想使用的系统”。

    三、需求文档和需求规格说明书有什么区别

    一样又不一样。

    说他俩一样。因为他使用的主要对象都有:开发、测试、项目经理;都是要描述核心业务、具体用例描述、功能&内容描述等。

    说他俩不一样。因为需求文档是站在产品的角度去讲述。而需求是站在系统的角度去讲述的。

    两者都有交集,但没有必要去划分的很清楚到底一不一样。在面对矛盾的时候我们要理解矛盾点在哪里。

    一般来说,矛盾大多是由利益矛盾产生的。那么是谁的利益矛盾呢?

    无非是阅读者与编写者的矛盾。阅读者想要快速地、简练地获取到自己想要的信息,因为懒!毕竟冗长的文档读起来对读者是精神与肉体的双重折磨。而编写者,总是想要把事情说的足够详细避免产生二义性,又或者还是懒!

    所以我认为,需求文档更侧重于对产品的描述,产品的定位、目标市场、目标用户及其竞争产品。而需规更侧重于系统的描述,实现逻辑、约束、输入输出条件等。

    四、从遇到的问题中反思

    既然需规的目的是“保证所开发的系统就是客户想使用的系统”(我们先假定我们的需规内容与客户的想法一致)。我们先从可能存在的场景去分析需规应该有哪些内容。

    1. 一定要有业务场景描述

    其实关于业务场景的描述,更多地想要让文档读者更快地带入到系统中。由于公司资源调整,项目里很多同事换来换去的,直接参照着文档讲,容易给同事们讲的一脸懵逼。所以能够让团队成员更容易理解,更容易融入其中,对于业务场景的描述也是至关重要的。

    我们在描述场景的时候,最好讲明“谁”(参与者),在“什么样的场景下”,为了完成某个“目的”,而做了“什么操作”

    通过上述的几个要素,个人觉得可以通俗易懂的讲述需求背景。

    2. 尽量用用例的方式去划分功能点

    “一千个读者一千个哈姆雷特”,关于需规的结构每个人的理解必然不一样,个人觉得要保持中心思想去做需规:用户可以通过系统完成什么事情。

    即系统的用例,我们通过各种方式来梳理出系统的用例有哪些,这样就可以更直观地看出系统有哪些功能。

    例如:在“场景A”的情况中,我们要来指导开发团队去开发功能,那么我们需要尽量描述清楚每一个功能,一定要保证功能不存在遗漏项。

    那么怎样的逻辑才能让功能描述得全呢?我认为在项目做规划的时候,要把模块范围划分清楚,每一个模块的定义、目的、适用范围,然后再根据模块规划用例。这样就可以保证开发的内容保持功能全覆盖。读者在看的时候也可以很直观地看到,原来我们的系统可以完成这这这等等功能。

    3. 复杂逻辑功能的流程图很重要

    为什么要单独提出来重点功能这个概念呢?我们会发现场景B、C、D总结下来就是我们针对功能的理解都不一样。

    文字描述总会有其弊端,断句、描述顺序、描述逻辑都存在偏向主观。所以我们可以通过画流程图来辅助对文字的描述。

    同时,我们一定要确定好我们的流程图的范围,是针对业务流程进行的还是对这个用例进行描述的。因为我遇到过把业务场景跟用例画在一起的操作。这样很容易误导读者,使读者的迷惑。

    那么为什么要单指复杂逻辑功能呢?其实,我们完成了目的,讲明白需求就可以了,所有的功能都画的话,很浪费时间跟精力的,所以挑重点说就好。

    上面就是小居数码小编今天给大家介绍的关于(需求规格说明书描述了)的全部内容,希望可以帮助到你,想了解更多关于数码知识的问题,欢迎关注我们,并收藏,转发,分享。

    94%的朋友还想知道的:

    (519)个朋友认为回复得到帮助。

    部分文章信息来源于以及网友投稿,转载请说明出处。

    本文标题:需求规格说明书的概念(需求规格说明书描述了):http://sjzlt.cn/shuma/152080.html

    猜你喜欢