①在需求上耗费多少时间就会导致产品开发推迟多少时间。
②客户不懂技术,说不出他们想要的新系统/产品是什么样的,所以只有我们开发人员自己来定义需求。
③我们开发组的人员都清楚需求是什么,不用写需求文档,而且写出来别人也看不懂,干脆我们直接设计或尽快编写出代码就行了。
④无需设定需求优先级,我们在交付产品时会完成全部的需求,这样才能使客户感到满意。
①含糊的需求描述:
“工资总额由上一条记录获得”
“所有客户都具有同一控制域”
②错误的需求描述:
“所有系统将九月作为财政年度的起始时间”
③不完整的需求描述:
“出错信息显示在屏幕的第24行”
④矛盾或不一致的需求描述:
“C=A+B”;“C=A-B”
⑤无法测试的需求:
“系统应具有友好的界面”
①客户专有需求
对于有着明确问题的特定客户,最终客户享有决定权。 ②市场需求
对于在市场上广泛出售的产品,营销团队扮演着顾客和用户代表的角色,产品必须拥有顾客。
③社会需求
系统的目的是造福社会,而不需要客户(支付报酬)。
一些开源/自由软件,科学研究软件
④综合
为特定客户开发,但最终希望面向市场的软件。
①反应组织机构或客户对系统和产品提出的高层次的目标需求,其限定了项目的范围和项目应达到的目标。
②文字处理系统
用户使用系统能够有效地纠正文档中的拼写错误,系统能满足用户的业务要求以及提高用户的工作效率。
①主要描述软件系统必须完成的任务、实际业务或工作流程等。软件开发人员通常可以从业务需求进一步细化出具体的功能需求和非功能需求。
②文字处理系统
当找到文档中拼写错误时,通过可供选择的单词表,选择单词表中的一个单词后,替换原来的单词。
①指开发人员必须实现的软件功能或软件系统应具有的外部行为。
②文字处理系统
查找文档中的单词,并高亮度的显示出错的单词。用对话框显示可供选择的单词表,实现整个文档范围内的替换。
①指实现的软件系统功能应达到的技术指标,如:计算效率和精度、可靠性、可维护性和可扩展性等。
②文字处理系统
检查单词的速度快,准确率要求达到99%,系统的有较高的有效性和可靠性等。
①指软件开发人员在设计和实现软件系统时的限制,如:开发语言、使用的数据库等。
②文字处理系统
文件内部格式要与Word系统一致。 开发平台为Linux系统,使用C语言等。
①需求规格说明也称需求规约或功能规格说明,是需求工程的最终产物。
②需求规格说明是软件所应满足的全部需求,并可用文档化的方式完整和精确地陈述这些需求。
③需求规格说明是项目相关人员对将要开发的软件系统所达成的共识,是进行系统设计、实现、测试和验收的基本依据,也是整个软件开发过程中最重要的文档。
④需求规格说明应该精确的描述系统必须提供的功能和非功能,以及所要考虑的约束条件和限制。
①完整性
不能遗漏任何必要的需求信息。遗漏需求将很难查出。
每项需求都必须将所要实现的功能描述清楚。
开发人员可以从需求规格说明中获得设计和实现这些功能所需的所有必要信息。
②正确性
每一项需求都必须准确地陈述其要开发出的功能性。
只有用户代表才能确定用户需求的正确性,这就是为何一定要有用户的积极参与的原因。
没有用户参与的需求只是评审者凭空猜测。
③可行性
每一项需求都必需是在已知系统和环境的权能和限制范围内可以实施的。
最好在获取需求过程中,始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作,由他来负责技术可行性上的检查。
④必要性
每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。
“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”
要使每项需求都能回溯至某项客户的输入,如使用实例或别的来源。
⑤划分优先级
给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。
不划分优先级,将导致项目管理者在开发或节省预算或调度中就丧失控制自由度。
⑥无二义性
对所有需求说明的读者都只能有一个明确统一的解释。
尽量把每项需求用简洁明了的用户性的语言表达出来。
避免二义性的有效方法包括对需求文档的正规审查,编写测试用例,开发原型以及设计特定的方案脚本。
⑦可验证性
检查一下每项需求是否能通过设计测试用例或其它的验证方法,如用演示、检测等来确定产品是否确实按需求实现了。
如果需求不可验证,则确定其实施是否正确就成为主观臆断,而非客观分析了。
一份前后矛盾,不可行或有二义性的需求也是不可验证的
用非形式化的语言指出感兴趣的主题现象,并命名(designation)。 例如:
Parent (x, p): p是x的父母。
Female(x): x是女性。
术语的形式化定义(definition)和使用。 例如:
Mother(x,m) = Parent(x,m) and Female(m)
Sister(x, y) = Female(y) and mother(x,m) and mother (y,m) and father(x,f) and father(y, f)
关于领域性质的无可驳的描述(refutabledescription)。无可驳性依赖于与主题现象的一致性。例如:
对所有的m和x,Parent(x, m)蕴含not(parent(m,x))
开发过程中的带有假设性质的概略描述(rough sketch)。 例如:
“人与人之间总是通过某种方式相互联系”
“每个人实际上只能有一一个家”
补充:
如何获取需求信息?
①识别:风险承担者,目标,分析角度,系统边界,应用实例,…
②核心技术:
座谈,问卷,代表会议
采用人种学方法(社交嵌入系统)
采用原型法,或参与设计法(缺乏了解的系统)
如何分析需求信息?
概念建模
如何就需求达成共识?
①进行经验主义的模型验证
②当出现矛盾和分歧时,提供磋商的方法和手段
如何表达需求?
自然语言与形式化语言的合理搭配
如何保持需求的现时性?
①需求发生变化时,及时更新
②产品线的维护
系统理论
①什么是系统
②系统的控制和演化
系统工程
工程生命周期
数学与逻辑
①一阶逻辑
②模态逻辑,时序逻辑,及其他非经典逻辑
③代数和关系模型
计算机科学
①自动机理论
②抽象,分解,和面向对象
③软件体系结构和设计模式
杜会科学
①人类学与民族方法学
②组织行为学
③社会心理学
④政治学
认知科学
①认知心理学
②语言学.
③知识表示(人工智能)
哲学
①经验主义和科学哲学
②现象学,认识论和本体
③符号语言学
…
用户
①利用计算机系统所提供的服务的人
②直接操作计算机系统的人,就是直接使用软件系统的人
客户
①掌握经费的人,通常有权决定软件需求。客户可以是用户,也可以不是用户。
②正式接受新开发或修改后的硬件和软件系统的某个人或组织.
软件开发人员
为客户开发软件系统的人
项目相关人员(利益相关方) 提出和定义软件需求相关的人,包括所有用户、客户和软件开发人员