需求 你能给出一些非功能性（或者质量）需求的例子么？ .._IT教育论坛
&>&&>&&>&&>&软件开发者面试100问
软件开发者面试100问
需求 你能给出一些非功能性（或者质量）需求的例子么？ 如果客户需要高性能、使用极其方便而又高度安全，你会给他什么建议？ 你能给出一些用来描述需求的不同技术么？它们各自适用于什么场景？ 需求跟踪是什么意思？什么是向前追溯，什么是向后追溯？ 你喜欢用什么工具跟踪需求？ 你怎么看待需求变化？它是好是坏？给出你的理由。 你怎样研究需求，发现需求？有哪些资源可以用到？ 你怎么给需求制定优先级？有哪些技术？ 在需求过程中，用户、客户、开发人员各自的职责是什么？ 你怎么对待不完整或是令人费解的需求？
功能设计 在功能设计中有哪些隐喻？给出几个成功的例子。 如果有些功能的执行时间很长，怎么能让用户感觉不到太长的等待？ 如果用户必须要在一个很小的区域内，从一个常常的列表中选择多个条目，你会用什么控件？ 有哪些方法可以保证数据项的完整？ 建立系统原型有哪些技术？ 应用程序怎样建立对用户行为的预期？给出一些例子。 如何入手设计一组数量庞大而又复杂的特性，你能举出一些设计思路吗？ 有一个列表，其中有10个元素，每个元素都有20个字段可以编辑，你怎样设计这种情况？如果是1000个元素，每个元素有3个字段呢？ 用不同的颜色对一段文本中的文字标记高亮，这种做法有什么问题？ Web环境和Windows环境各有些什么限制？
技术设计 什么是低耦合和高聚合？封装原则又是什么意思？ 在Web应用中，你怎样避免几个人编辑同一段数据所造成的冲突？ 你知道设计模式吗？你用过哪些设计模式？在什么场合下用的？ 是否了解什么是无状态的业务层？长事务如何与之相适应？ 在搭建一个架构，或是技术设计时，你用过几种图？ 在N层架构中都有哪些层？它们各自的职责是什么？ 有哪些方法可以确保架构中数据的正确和健壮？ 面向对象设计和面向组件设计有哪些不同之处？ 怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模？ 怎样按照等级制度给动物王国（包括各种物种和各自的行为）建模？
结构 你怎样保证你的代码可以处理各种错误事件？ 解释一下什么是测试驱动开发，举出极限编程中的一些原则。 看别人代码的时候，你最关心什么地方？ 什么时候使用抽象类，什么时候使用接口？ 除了IDE以外，你还喜欢哪些必不可少的工具？ 你怎么保证代码执行速度快，而又不出问题？ 什么时候用多态，什么时候用委派？ 什么时候使用带有静态成员的类，什么时候使用单例？ 你在代码里面怎么提前处理需求的变化？给一些例子。 描述一下实现一段代码的过程，从需求到最终交付。
算法 怎样知道一个数字是不是2的乘方？怎样判断一个数是不是奇数？ 怎样找出链表中间的元素？ 怎样改变10,000个静态HTML页面中所有电话号码的格式？ 举出一个你所用过的递归的例子。 在哈希表和排序后的列表中找一个元素，哪个查找速度最快？ 不管是书、杂志还是网络，你从中所学到的最后一点算法知识是什么？ 怎样把字符串反转？你能不用临时的字符串么？ 你愿意用什么类型的语言来编写复杂的算法？ 有一个数组，里面是从1到1,000,000的整数，其中有一个数字出现了两次，你怎么找出那个重复的数字？ 你知道“旅行商问题（Traveling Salesman Problem）”么？
数据结构 怎样在内存中实现伦敦地铁的结构？ 怎样以最有效的方式在数据库中存储颜色值？ 队列和堆栈区别是什么？ 用堆或者堆栈存储数据的区别是什么？ 怎样在数据库中存储N维向量？ 你倾向于用哪种类型的语言编写复杂的数据结构？ 21的二进制值是什么？十六制值呢？ 不管是书、杂志还是网络，你从中所学到的最后一点数据结构的知识是什么？ 怎样在XML文档中存储足球比赛结果（包括队伍和比分）？ 有哪些文本格式可以保存Unicode字符？
测试 什么是回归测试？怎样知道新引入的变化没有给现有的功能造成破坏？ 如果业务层和数据层之间有依赖关系，你该怎么写单元测试？ 你用哪些工具测试代码质量？ 在产品部署之后，你最常碰到的是什么类型的问题？ 什么是代码覆盖率？有多少种代码覆盖率？ 功能测试和探索性测试的区别是什么？你怎么对网站进行测试？ 测试栈、测试用例、测试计划，这三者之间的区别是什么？你怎么组织测试？ 要对电子商务网站做冒烟测试，你会做哪些类型的测试？ 客户在验收测试中会发现不满意的东西，怎样减少这种情况的发生？ 你去年在测试和质量保证方面学到了哪些东西？
维护 你用哪些工具在维护阶段对产品进行监控？ 要想对一个正在产品环境中被使用的产品进行升级，该注意哪些重要事项？ 如果在一个庞大的文件中有错误，而代码又无法逐步跟踪，你怎么找出错误？ 你怎样保证代码中的变化不会影响产品的其他部分？ 你怎样为产品编写技术文档？ 你用过哪些方式保证软件产品容易维护？ 怎样在产品运行的环境中进行系统调试？ 什么是负载均衡？负载均衡的方式有哪些种？ 为什么在应用程序的生命周期中，软件维护费用所占的份额最高？ re-engineering和reverse engineering的区别是什么？
配置管理 你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？ 你一般会把哪些东西纳入版本控制？ 怎样可以保证团队中每个人都知道谁改变了哪些东西？ Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？ 怎样管理技术文档——如产品架构文档——的变化？ 你用什么侗剧管理项目中所有数字信息的状态？你最喜欢哪种工具？ 如果客户想要对一款已经发布的产品做出变动，你怎么处理？ 版本管理和发布管理有什么差异？ 对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？ 同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？
项目管理 范围、时间、成本，这三项中哪些是可以由客户控制的？ 谁该对项目中所要付出的一切做出估算？谁有权设置最后期限？ 减少交付的次数，或是减少每个每个交付中的工作量，你喜欢哪种做法？ 你喜欢用哪种图来跟踪项目进度？ 迭代和增量的区别在哪里？ 试着解释一下风险管理中用到的实践。风险该如何管理？ 你喜欢任务分解还是滚动式计划？ 你需要哪些东西帮助你判断项目是否符合时间要求，在预算范围内运作？ DSDM、Prince2、Scrum，这三者之间有哪些区别？ 如果客户想要的东西太多，你在范围和时间上怎样跟他达成一致呢？
先收藏。有时间再慢慢看。
ABD都有道理，但不是必须的，有些项目或变化情况下是不一定发生的。而进行原因分析是必须要做的，也首先要做的工作。答案是C。
本帖标题：
本帖地址：
注意：本论坛的任何言论仅代表发言者个人的观点，与希赛网立场无关。请对您的言论负责，遵守中华人民共和国有关法律、法规。如果您的帖子违反希赛网论坛规则，将立即删除。
&&&&&&&&&&&&
希赛网 版权所有 & &&当你收集需求时，你可以从用户的需求清单中找出他们想要软件完成什么样的任务，有相关的用例、故事板、需求说明出书来捕捉这样的信息，那么什么又是非功能性需求，又有什么样的内容定义呢？
不合理或无法说清的非功能性需求如：
系统一定要快
系统必须要安全
系统要有尽量高的灵活性
系统要有较高的可用性
非功能需求的大体分类:
性能需求：
响应时间：从发出请求到收到反馈的时间，比如点击超链接或桌面应用中的按钮。
延时时间：消息从从A到B,经过你的系统所有的时间。　　
可用性需求
使用正常运行时间的百分比描述可用性如:99.9%，99.99%等。
使用可容忍的停机时间百分比来描述可用性如：0.1%，0.01%等。(当容忍停机时间为0.1%时，平均每天留给用户维护、升级与处理故障的时间为1.44分钟)　　
可伸缩性与并发性密不可分，就是处理更多用户、请求、数据、消息的能力，可以以“相同时间内处理多少东西”来描述(如每秒请求数)。
系统可以使用不同的方式来执行单个任务，需求描述用例如：用户可以通过配置文件等方式来改变内部业务规则的能力。
安全性包括了认证，数据传输与存储的机密性，例如对于web应用来说，用户认证应该是最基础的东西。
这个属性是滥用与模糊的，它指软件将来可以做现在还不能做的事情的能力，例如可以通过插件或API的方式实现某些需求的扩展。
审计(可追溯性)
系统能够对重要数据或行为变化的事件进行记录，而需求明确这些变化由谁做出，什么时候做出，做出什么样的信息。
其它非功能性需求
国际化　　
提炼非功能性需求
从用户描述中提炼,例如从“系统一定要快”等关键字提炼性能需求并反馈回用户。
从系统所在的业务领域中提炼,此部分在用户描述中被忽略而需要我们提出并反馈用户。
尝试量化非功能性需求并能够可测
　　　　　　
阅读(...) 评论()posts - 299,&
comments - 1617,&
trackbacks - 0
设计之路：如何进行软件需求分析？
1、需求分析的重要性
软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
通常，包括可行性分析与开发项计划、、设计（和）、编码、测试、维护等活动。
常用的三种软件生命周期（瀑布模型、迭代式模型和快速原型模型）中，需求分析中都占据了举足轻重的作用，是系统分析、软件编程、软件测试和系统维护的输入物。
1.1 瀑布模型
瀑布模型由于酷似瀑布闻名，（Waterfall Model）首先由Royce提出。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。
瀑布模型图示如下：&&&&&
从上图可看出，需求分析的产出物《需求规格说明书》（有的项目组还会产出软件原型，例如静态HTML原型等）是后续设计、编码、测试和系统维护的基础。
可将瀑布模型的“需求分析”阶段细分为“软件概念”和“用户需求分析”两个阶段，前者用于收集用户的原始需求，包括用户在功能、行为、性能、设计约束等方面的期望，并经过初步分析后形成《用户需求说明书》，而后经过进一步分析，将用户需求精确化、完全化，最终形成《需求规格说明书》。
可将瀑布模型中的“系统设计”细分为“架构设计”和“详细设计”两个阶段，前者在总体上把握，更关注架构层面，包括系统的总体架构，以及各个子系统或各个模块之间的关系。后者更注重细节，包括系统设计的方方面面都要在详细设计中有所体现。
作为系统分析师，或系统架构师，主要在“需求分析”和“系统设计”阶段体现自己的作用，后续的各个阶段主要通过与项目组成员的沟通贯彻自己的设计。
1.2 迭代式模型
迭代式模型是是（Rational Unified Process，，)推荐的周期模型。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。
在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程（编码流程）和测试工作流程。实质上，可将它理解为多个小型的瀑布式项目。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
迭代式原型图示如下：&&&
在每一个迭代中，“需求分析”阶段与瀑布模式一样，是后续系统分析、编码和测试阶段依赖的基础。如果需求分析有较大偏差，势必造成迭代过程中产生的一个产品子集有较大偏差。
1.3 快速原型模型
快速原型（Rapid Prototype）模型在功能上等价于产品的一个子集。注意，这里说的是功能上。的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。
在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。
在快速原型模型中，原型最重要的目的是为了确定用户的真正需求。从某种程度上，可以将快速原型理解为需求分析的一种更直观的方式，也是业界比较认可和取得良好效果的一种方式。
2、需求分析的目标
通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。
需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。
3、如何进行需求分析
3.1 需求分析的困难
需求分析的目标，说得通俗一点，就是确定“做什么，不做什么”。但需求分析却不像想象的那么简单，主要因为如下原因：
3.1.1 客户需求自身经常变动
这世间的一切，只有“变化”是绝对的，从这点来理解，软件系统的需求不断变化也是可以理解的。老听设计人员和开发人员抱怨客户的需求老是变化，其实应该将“需求变化”理解为一种常态。
引起需求变化的原因诸多，例如：
（1）因为某些前置条件未满足，之前按照“妥协”方案实现，但若在某个时间点上这些前置条件被满足，于是引起了需求的变化。
（2）某个后台操作之前不需要走审批流程，但因为客户的某个内部流程改变，需要走审批流程，势必引起需求 -& 设计 -& 编码 -& 测试的一系列变更。
【对策】：因为需求变动无可避免，系统分析师在进行需求分析时需要明确：
（1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需求。以便在进行系统设计时，将软件的核心建筑在稳定的需求上，否则将会吃尽苦头。
（2）在合同中一定要说清楚“做什么”和“不做什么”。如果合同含含糊糊，日后扯皮的事情就多。小的变动影响不大，也不致影响进度，但是对于一些改动会引起设计重大改变的需求，需要在合同中清楚说明。
3.1.2 客户说不清楚需求，分析人员理解错误
客户的计算机水平、对需求的理解、表达程度都参差不齐。有些客户对需求只有朦胧的感觉，当然说不清楚具体的需求。有些客户心里非常清楚想要什么，但却说不明白。有的客户本身就懂软件开发，能把需求说得清清楚楚，这样的需求分析将会非常轻松、愉快。
不同性格、不同水平、与客户交流前准备情况不同的的系统分析师去跟客户讨论需求时，会得到很不不一样的结果。
作为系统分析师，可以引导客户，先阐述常规的需求，再由客户否定不需要的，最终确定客户真正的需求。一个好的系统分析师，能从客户的一两句话中提出很多自己的观点或可进行拓展，进而进一步挖掘客户需求，或者若与之前的需求矛盾，可进行正确需求导向。
【对策】：若客户说不清楚需求，为了不造成理解错误，系统分析师可采用多次沟通的方式，例如第一次通过客户初步了解需求，回去分析哪些是合理需求，那些是自相矛盾或不合理的需求，以及哪些是需要进一步明确的需求。经过细化后，第二次交流可提供PPT或简单的Word文档与客户进行第二次深入交流。第三次交流可通过建立快速模型进一步与客户交流得到精确的需求。需求分析也可参考“迭代式模型”来进行不断迭代，一直到挖掘出客户所有的潜在需求为止。
3.1.3 客户在没看到原型或完整系统时，有一些潜在需求未被挖掘
甚至有不少这样的客户，去进行需求沟通时提不出太多的需求，但是在你做完整个系统时，潜在需求突然迸发出来。
【对策】：为了避免此种情况对项目造成破坏性影响，建议相关人员为一些大的功能模块建立快速原型让客户进行确认，并在合同中一定要说清楚“做什么”和“不做什么”
3.1.4 多个相关方需求相互冲突，需求有二义性
若些需求若牵涉客户不同部门，若有不一致意见，若私自按某一方的意见进行修改，很可能在后期涉及到按另一个部门的想法进行改造。
【对策】：对于这种客户内部有冲突的需求，需求组织客户方相关部门一起讨论，由客户更高领导层决定实现哪一方的需求，或者采用折衷方案。需求说明不可有二义性，更不能前后相矛盾。如果有二义性或前后相矛盾，则要重新分析此需求。
3.2 需求分析的活动
3.2.1 需求获取
通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
软件需求常见的获取方法（在《》一文中写得很详细）如下：
Ø&面谈
个人觉得面谈是获取软件需求的最有用的方法，也是需求分析时常用的方法。通过多方面谈，得到的信息最多，进行我们现在所做的系统，与移动集团客户部、业务支撑部、网管中心、系统运营人员等都进行过面谈。
面谈需准备的内容：面谈对象和面谈问题。
面谈对象：需要尽量让面谈对象包括可与系统相关的涉众，并具有代表性，保证涵盖到每个角色。一般包括谁为系统付费，购买系统？谁使用系统？谁会受到系统结果的影响？谁来监管该系统？谁来维护系统？
Ø&问卷调查
调查问卷无法取代面谈在需求获取阶段的作用，问卷调查的问题和答案具有一定的引导性，在某种程度上会影响结果。
问卷调查的结果好坏与问卷的设计有直接的关系，在做这个项目时，运营人员在进行前期推广会议上，也给企业客户发过调查问卷，但因为诸多原因，效果不甚理想，基本没为我们项目需求分析出多少力。
Ø&小组讨论
小组讨论是指将与项目某个问题相关的人员聚集在一起开会讨论。优势：容易在内部取得对方案的认同，有利于项目的开展；在讨论会上每个相关人员都可发表自己的意见，保证了获取信息的全面性。缺点：不容易把握。
对于涉及系统边界的需求，或一些相互冲突的需求，采取该种方式是非常可取的。
Ø&情景串联
由于软件产品的抽象性，大部分涉众在脑海子未有一个清晰的产品轮廓，影响涉众对产品的理解。基于此可考虑编写清晰、完整的情景描述文档。
&1、采用PPT加图片的方式描述情景：一个好的PPT能更直观的描述各种情景；
2、采用原型法（比较推荐这种方法）。
Ø&参与、观察业务流程
涉众描述的业务流程可能由于某些原因会遗漏掉重要的信息，需求分析人员可申请参与到他们具体的工作，观察、体验业务操作过程。需求分析员在观察业务操作过程时，可根据实际的情况提问并详细记录，记录业务操作员操作过程，操作过程中碰到的难题，可获取真实的材料和理解整个业务。
Ø&现有产品和竞争对手的描述文档
阅读现有产品文档有利于了解当前系统情况，从中也可以了解业务流程，对操作员反映的系统问题有着更深层次的理解。
3.2.2 需求建模
要有效地收集需求，您要做的第一步是建模，它包括创建体系结构的表示形式以捕获需求、就解决方案方法进行交流、以及分析所提出的系统设计。其目的是使用模型来表现系统中的关键方面。然后，您可以在形式化的分析、模拟和原型设计中使用这些模型，以研究预期的系统行为，并且可以在编写文档或总结时使用这些模型，以便就系统的性能和外观进行交流。
Ø&域建模
域建模指的是，您对问题域创建相应的模型并且把它划分为若干个内聚组的过程。然后，您可以在抽象模型中捕获业务流程、规则和数据。
域模型是一种用于理解问题域的工具。您需要从信息系统之外的角度来理解这个域，这一点是很重要的。
Ø&用例建模
用例模型描述了各种参与者（人和其他系统）和要分析的系统之间的主要交互。用例应该说明系统如何支持域和业务流程模型中的业务流程。
用例模型应该将系统放到上下文环境中，显示系统和外部参与者之间的边界，并描述系统和参与者之间的关键交互。用例建模可以描述利益相关者（例如，用户和维护人员）所看到的系统行为。
Ø&组件和服务建模
组件模型为子系统、模块和组件的层次结构分配需求和职责。每个元素作为一个自包含的单元，以用于开发、部署和执行的目的。组件模型的元素由它们所提供和使用的接口来进行规定。在这里，没有考虑其中的内部细节。
服务模型将应用程序定义为一组位于外部边界（用例）、架构层之间的抽象服务接口，并且提供了通用的应用程序和基础结构（安全、日志记录、配置等等）。支持应用程序需求的这组服务可以与现有的内部和外部提供的接口规范相匹配。所得到的分析结果可以确定预置策略，并将项目活动划分为特定类型的部分，这取决于给定的服务是否已经存在（内部或者外部的，并且其中每个服务都具有适当的活动）、存在但需要进行修改（定义一个新的接口，并规划其实现）、或者必须构建新的服务。
Ø&性能建模
可以通过各种各样的方式来度量性能，最显而易见的方式是，应用程序执行其关键操作任务的速度。然而，作为一名架构师，必须考虑性能建模过程中其他的几个方面：
l&构建和部署应用程序的速度如何？
l&构建、维护和运行需要多少花费？
l&该应用程序能在多大程度上满足其需求？
l&对于必须使用该应用程序的人来说，需要为其付出多大的开销？
l&该应用程序会对其他应用程序和基础结构产生怎样的影响？
【说明】需求建模是一门深奥的学问，在做这个项目时，需求建模基本只是用到了“用例建模”，对一些典型流程进行用例建模。域建模、组件和服务建模和性能建模基本是空白状态，希望在下一个项目中有所改进。
3.2.3 形成《需求规格说明书》
生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约。
3.2.4 需求验证
以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性。
3.2.5 需求管理
支持系统的需求演进，如需求变化和可跟踪性问题。
要在需求变更时，同步更新《需求规格说明书》以及相关文档，要知道，一个正确的文档是指导软件系统不同阶段的参考，但一个没有同步更新的文档是对软件系统有破坏性作用的，相关人员会受到错误引导。
4、参考文档
1、《需求分析的作用及如何进行需求分析》（张友生）：
3、《软件项目需求分析困难的原因》：
4、《需求建模》：
5、《软件需求获取方法》：
6、《系统域建模技术》：
阅读(13432)
&re: 设计之路：如何进行软件需求分析？
需求调研的重要阶段 &&&&&&
&re: 设计之路：如何进行软件需求分析？
前期准备很重要的&&&&&&
&re: 设计之路：如何进行软件需求分析？
从客户调研，设计，测试，评估一整个流程下来才算数真正的需求分析&&&&&&
3012345678910111214151617181920212223242526272829303112345678910
&&&&&&生活将我们磨圆，是为了让我们滚得更远——“圆”来如此。&&&&& 我的作品：& & &&& （2015年12月出版）& & &&& & & & （2015年7月出版）& & &&&&&&&& &（2010年5月出版）&&&&&
留言簿(252)
积分与排名
阅读排行榜
评论排行榜君，已阅读到文档的结尾了呢~~
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
软件架构中的非功能需求
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer-4.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口