比浏览器更快的访问！
用例
例（use case），或譯使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互動，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。 在1986年，Ivar Jacobson，UML和瑞理统一过程的重要贡献者，提出了用例的概念。Jacobson的思想很有影响力，也很有发展力。之后在这个科目上又有很多贡献，在定义用例是什么和怎么有效的书写用例方面最重要，最有影响力也最全面的，是Alistair Cockburn，他写的书籍是《编写有效用例》。 用例迅速成为获取功能需求最常用的手段。用例最初是和面向对象一同提出的。但是它不止局限于面向对象系统，因为用例实质上不是面向对象。 由于不少测试工程师将测试用例简称为用例，为便于区分两者，将原来的用例称为需求用例。 测试用例（对应英文）已经广为人知，没有歧义，但就文字表面而言，测试用例類似是属于用例，就像红富士苹果属于苹果一样，所以为了更容易区分，需求用例是个更清晰的称呼。.
非功能性需求
在系統工程及需求工程中，非功能性需求（Non-functional requirement）是指依一些條件判斷系統運作情形或其特性，而不是針對系統特定行為的需求。和非功能性需求相對的是功能需求，後者會定義系統特定的行為或功能。非功能性需求也可以視為為了滿足客戶業務需求而需要符合，但又不在功能性需求以内的特性。 一般會在中詳細列出實現功能需求的計劃，而會在系统架构中詳細列出實現非功能性需求的計劃。一般而言，功能需求會定義系統的行為，而非功能性需求會定義系統的特性。 非功能性需求一般會稱為系統的「品質」，有時也會稱為「限制」、「品質屬性」、「品質目標」、「品質服務需求」或「非行為性的需求」。有許多非功能性需求的英文都是以「ility」結尾，例如穩定性（stability）及可移植性（portability），因此非功能性需求有時也稱為「ilities」。 非功能性需求可以分為以下的二類：.
软件工程
软件工程（quote） 1968年秋季，NATO（北約）的科技委員會召集了近50名一流的編程人員、計算機科學家和工業界巨頭，討論和制定擺脫“軟體危機”的對策。在那次會議上第一次提出了軟體工程（software engineering）這個概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。 1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义："将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"。此后，IEEE多次给出软件工程的定义。 在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件、嵌入式系统、人机界面、办公套件、操作系统、编译器、数据库、游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业、农业、银行、航空、政府部门等。这些应用促进了经济和社会的发展，提高人们的工作效率，同时提升了生活质量。 软件工程师是对应用软件创造软件的人们的统称，软件工程师按照所处的领域不同可以分为系统分析师、系统架构师、软件设计师、程序员、测试工程师、界面与交互设计师等等。各种软件工程师人们俗称程序员。.
需求工程
求工程（Requirements engineering，縮寫：RE）係指在工程設計過程中定義、記錄和維護需求的過程。 這在系統工程和軟體工程中是一個共同的角色。 1979年美國企業TRW Inc.的技術報告，可能是第一次使用「需求工程」這個術語，但是直到20世紀90年代IEEE電腦協會教程出版才得到普遍應用，並建立了一個關於需求工程的系列會議，這個會議已經發展成為當前的國際需求工程會議（International Requirements Engineering Conference）。 在瀑布模型中，需求工程作為開發過程的第一個階段。後來的開發方法（包括用於軟體的統一軟體開發過程（RUP））假設需求工程持續於系統的整個生命週期。 需求管理為系統工程實務的子功能，也在INCOSE（系統工程國際委員會）手冊中編入索引。.
