本标题结论由以下观点所支持： 从事“高端”经济活动所获得的收益要超过(经常是大大超过)从事“低端”经济活动，“高端”经济活动集中于驱动经济增长的“领导部门”(leading sectors。比如：英国工业革命时代的棉纺织、炼铁、煤炭、机械制造等；第二次工业革命时代的炼钢、石油、汽车、化工和电力等；20世纪70年代至今，信息通信、航空航天、生物制药、医疗设备和信息密集的服务业等 一个国家能够生产出经受得住国际竞争、提高国民收入水平、持续获得超过平均利润率收益的产品和服务的主要源泉，是该国拥有和不断发展、提高的技术能力 技术进步如果能够对经济发展产生作用，就必须采取产品形式。关键产品的开发可以带动相关技术网络和创新系统的发展。因此，关键技术领域中的关键产品开发对于国家技术能力的增长具有重大意义，而在这种产品研发过程中，做好需求分析和管理往往成为整个项目和产品成败的关键 复杂产品的需求分析和管理是非常复杂和困难的： （1）客户的要求（Needs）和期望（Expectations）难以捉摸、不可穷尽 （2）做好需求（Requirement）分析和管理的标准又很高：需求应当是明确（Unambiguous）、正确（Correct）、完整（Complete）、一致（Consistent）、可追溯（Traceable）、可实现（Achievable）和可验证（Verifiable）的 （3)需求存在多样类别：比如安全性需求、功能需求、客户需求、运行需求、性能需求、物理与安装需求、维修需求、接口需求、附加审定需求、衍生需求等等 欢迎大家做个小游戏：假如开发一个能够令自行车自动驾驶的装置，需要定义多少种设计上的需求？ 如下是摘自wikipedia的，有关requirement、requirement analysis and management的一些资料，仅供参考。 一、Requirement 源自： Wikipedia In engineering , a requirement is a singular documented need of what a particular product or service should be or perform. It is most commonly used in a formal sense in systems engineering , software engineering , or enterprise engineering . It is a statement that identifies a necessary attribute, capability, characteristic, or quality of a system in order for it to have value and utility to a user. In the classical engineering approach, sets of requirements are used as inputs into the design stages of product development . Requirements are also an important input into the verification process, since tests should trace back to specific requirements. Requirements show what elements and functions are necessary for the particular project. The requirements development phase may have been preceded by a feasibility study , or a conceptual analysis phase of the project. The requirements phase may be broken down into requirements elicitation (gathering, understanding, reviewing, and articulating the needs of the stakeholders ), analysis (checking for consistency and completeness), specification (documenting the requirements) and validation (making sure the specified requirements are correct). Contents 1 Product versus process requirements 2 Requirements in systems and software engineering 3 Product requirements 3.1 Types of product requirements 3.2 Characteristics of good requirements 3.2.1 Verification 3.2.2 Requirements analysis or requirements engineering 3.3 Documenting requirements 3.4 Changes in requirements 4 Disputes regarding the necessity of rigour in software requirements 5 See also 6 References 7 External links Product versus process requirements Projects are subject to three sorts of requirements: Business requirements describe in business terms what must be delivered or accomplished to provide value. Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set of business requirements.) Process requirements describe activities performed by the developing organization. For instance, process requirements could specify specific methodologies to be followed, and constraints that the organization must obey. Product and process requirements are closely linked. Process requirements often specify the activities that will be performed to satisfy a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement for the product to be maintainable (a Product requirement) often is addressed by imposing requirements to follow particular development styles (e.g., object-oriented programming ), style-guides, or a review/inspection process (process requirements). Requirements in systems and software engineering In systems engineering, a requirement can be a description of what a system must do, referred to as a Functional Requirement . This type of requirement specifies something that the delivered system must be able to do. Another type of requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called Non-functional requirements , or 'performance requirements' or 'quality of service requirements.' Examples of such requirements include usability, availability, reliability, supportability, testability and maintainability. A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements as far as possible avoids saying how the system should implement the requirements, leaving such decisions to the system designer. Specifying how the system should be implemented is called "implementation bias" or "solution engineering". However, implementation constraints on the solution may validly be expressed by the future owner, for example for required interfaces to external systems; for interoperability with other systems; and for commonality (e.g. of user interfaces) with other owned products. In software engineering, the same meanings of requirements apply, except that the focus of interest is the software itself. Product requirements Types of product requirements Requirements are typically placed into these categories: Architectural requirements describe what has to be done by identifying the necessary system architecture of a system , Functional requirements describe the functionality that the system is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities. Non-functional requirements describe characteristics of the system that the user cannot affect or (immediately) perceive. Nonfunctional requirements are sometimes known as quality requirements or ilities . Constraint requirements impose limits upon the design alternatives or project/process operations. No matter how the problem is solved the constraint requirements must be adhered to. Non-functional requirements can be further classified according to whether they are usability requirements, look and feel requirements, humanity requirements, performance requirements, maintainability requirements, operational requirements, safety requirements, reliability requirements, or one of many other types of requirements. In software engineering this categorization is useful because only functional requirements can be directly implemented in software. The non-functional requirements are controlled by other aspects of the system. For example, in a computer system reliability is related to hardware failure rates, and performance is controlled by CPU and memory. Non-functional requirements can in some cases be decomposed into functional requirements for software. For example, a system level non-functional safety requirement can be decomposed into one or more functional requirements. See FURPS . In addition, a non-functional requirement may be converted into a process requirement when the requirement is not easily measurable. For example, a system level maintainability requirement may be decomposed into restrictions on software constructs or limits on lines or code. Characteristics of good requirements The characteristics of good requirements are variously stated by different writers, with each writer generally emphasizing the characteristics most appropriate to their general discussion or the specific technology domain being addressed. However, the following characteristics are generally acknowledged. Characteristic Explanation Unitary (Cohesive) The requirement addresses one and only one thing. Complete The requirement is fully stated in one place with no missing information. Consistent The requirement does not contradict any other requirement and is fully consistent with all authoritative external documentation. Non-Conjugated (Atomic) The requirement is atomic , i.e., it does not contain conjunctions. E.g., "The postal code field must validate American and Canadian postal codes" should be written as two separate requirements: (1) "The postal code field must validate American postal codes" and (2) "The postal code field must validate Canadian postal codes". Traceable The requirement meets all or part of a business need as stated by stakeholders and authoritatively documented. Current The requirement has not been made obsolete by the passage of time. Feasible The requirement can be implemented within the constraints of the project. Unambiguous The requirement is concisely stated without recourse to technical jargon, acronyms (unless defined elsewhere in the Requirements document), or other esoteric verbiage. It expresses objective facts, not subjective opinions. It is subject to one and only one interpretation. Vague subjects, adjectives, prepositions, verbs and subjective phrases are avoided. Negative statements and compound statements are prohibited. Mandatory The requirement represents a stakeholder-defined characteristic the absence of which will result in a deficiency that cannot be ameliorated. An optional requirement is a contradiction in terms. Verifiable The implementation of the requirement can be determined through one of four possible methods: inspection, demonstration, test or analysis. To the above some add Externally Observable, that is, the requirement specifies a characteristic of the product that is externally observable or experienced by the user. Such advocates argue that requirements that specify internal architecture, design, implementation, or testing decisions are probably constraints, and should be clearly articulated in the Constraints section of the Requirements document. The contrasting view is that this perspective fails on two points. First, the perspective does not recognize that the user experience may be supported by requirements not perceivable by the user. For example, a requirement to present geocoded information to the user may be supported by a requirement for an interface with an external third party business partner. The interface will be imperceptible to the user, though the presentation of information obtained through the interface certainly would not. Second, a constraint limits design alternatives, whereas a requirement specifies design characteristics. To continue the example, a requirement selecting a web service interface is different from a constraint limiting design alternatives to methods compatible with a Single Sign-On architecture. Verification All requirements should be verifiable. The most common method is by test. If this is not the case, another verification method should be used instead (e.g. analysis, demonstration or inspection or review of design). Certain requirements, by their very structure, are not verifiable. These include requirements that say the system shall never or always exhibit a particular property. Proper testing of these requirements would require an infinite testing cycle. Such requirements must be rewritten to be verifiable. As stated above all requirements must be verifiable. Non-functional requirements, which are unverifiable at the software level, must still be kept as a documentation of customer intent; however they may be traced to process requirements that are determined to be a practical way of meeting them. For example, a non-functional requirement to be free from backdoors may be satisfied by replacing it with a process requirement to use pair programming . Other non-functional requirements will trace to other system components and be verified at that level. For example system reliability is often verified by analysis at the system level. Avionics software with its complicated safety requirements must follow the DO-178B development process. Requirements analysis or requirements engineering Main article: Requirements analysis Requirements are prone to issues of ambiguity, incompleteness, and inconsistency. Techniques such as rigorous inspection have been shown to help deal with these issues. Ambiguities, incompleteness, and inconsistencies that can be resolved in the requirements phase typically cost orders of magnitude less to correct than when these same issues are found in later stages of product development. Requirements analysis strives to address these issues. There is an engineering trade off to consider between requirements which are too vague, and those which are so detailed that they take a long time to produce - sometimes to the point of being obsolete once completed limit the implementation options available are costly to produce Documenting requirements Requirements are usually written as a means for communication between the different stakeholders. This means that the requirements should be easy to understand both for normal users and for developers. One common way to document a requirement is stating what the system shall do. Example: 'The contractor shall deliver the product no later than xyz date.' Other ways include use cases and user stories . Changes in requirements Requirements generally change with time. Once defined and approved, requirements should fall under change control . For many projects, requirements are altered before the system is complete. This is partly due to the complexity of computer software and the fact that users don't know what they want before they see it. This characteristic of requirements has led to requirements management studies and practices. Disputes regarding the necessity of rigour in software requirements Most agile software development methodologies question the need for rigorously describing software requirements upfront, which they consider a moving target. Instead, extreme programming for example describes requirements informally using user stories (short summaries fitting on an index card explaining one aspect of what the system should do), and considers it the developer's duty to directly ask the customer for clarification. Agile methodologies also typically capture requirements in a series of automated acceptance tests . See also Business requirements Software requirements Requirements analysis Requirements elicitation Requirements management Requirement prioritization Requirements traceability Specification (technical standard) References ^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management . O'Reilly Media. p.98. ISBN 978-0-596-00948-9 . http://www.stellman-greene.com/aspm/ . SPAN title="ctx_ver=Z39.88-2004rft_val_fmt=info:ofi/fmt:kev:mtx:bookrft.genre=bookrft.btitle=Applied+Software+Project+Managementrft.aulast=Stellmanrft.aufirst=Andrewrft.au=Stellman, Andrewrft.au=Greene, Jenniferrft.date=2005rft.pages=p.wbr98rft.pub=O'Reilly+Mediarft.isbn=978-0-596-00948-9rft_id=http://www.stellman-greene.com/aspm/rfr_id=info:sid/en.wikipedia.org:Requirement" ^ Wiegers, Karl E. (2003). Software Requirements, Second Edition . Microsoft Press. ISBN 0-7356-1879-8 . ^ Young, Ralph R. (2001). Effective Requirements Practices . Addison-Wesley. ISBN 978-0201709124 . ^ Davis, Alan M. (1993). Software Requirements: Objects, Functions, and States, Second Edition . Prentice Hall. ISBN 0-13-805763-X . External links Look up requirement in Wiktionary , the free dictionary. Discovering System Requirements The International Institute for Business Analysis and The IIBA's Business Analysis Body of Knowledge Writing Good Requirements Gottesdiener, Ellen (2009). The Software Requirements Memory Jogger: A Desktop Guide to Help Business and Technical Teams Develop and Manage Requirements . Addison-Wesley. ISBN 157681114X 二、Requirement Analysis概念解析 源自：Wikipedia Requirements analysis in systems engineering and software engineering , encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders , such as beneficiaries or users. Requirements analysis is critical to the success of a development project. Requirements must be documented, actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design. Requirements can be architectural , structural , behavioral , functional , and non-functional . Contents 1 Overview 2 Requirements engineering 3 Requirements analysis topics 3.1 Stakeholder identification 3.2 Stakeholder interviews 3.3 Joint Requirements Development (JRD) Sessions 3.4 Contract-style requirement lists 3.4.1 Strengths 3.4.2 Weaknesses 3.4.3 Alternative to requirement lists 3.5 Measurable goals 3.6 Prototypes 3.7 Use cases 3.8 Software requirements specification 4 Types of Requirements 5 Requirements analysis issues 5.1 Stakeholder issues 5.2 Engineer/developer issues 5.3 Attempted solutions 6 See also 7 References 8 Further reading 9 External links Overview Conceptually, requirements analysis includes three types of activity: Eliciting requirements : the task of communicating with customers and users to determine what their requirements are. This is sometimes also called requirements gathering. Analyzing requirements: determining whether the stated requirements are unclear, incomplete, ambiguous, or contradictory, and then resolving these issues. Recording requirements: Requirements might be documented in various forms, such as natural-language documents, use cases , user stories , or process specifications. Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews , or holding focus groups (more aptly named in this context as requirements workshops) and creating requirements lists. More modern techniques include prototyping , and use cases . Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced. Requirements engineering Systematic requirements analysis is also known as requirements engineering . It is sometimes referred to loosely by names such as requirements gathering , requirements capture , or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper, as opposed to elicitation or documentation of the requirements, for instance. Requirements Engineering can be divided into discrete chronological steps: Requirements elicitation, Requirements analysis and negotiation, Requirements specification, System modeling, Requirements validation, Requirements management. Requirement engineering according to Laplante (2007) is "a subdiscipline of systems engineering and software engineering that is concerned with determining the goals, functions, and constraints of hardware and software systems." In some life cycle models, the requirement engineering process begins with a feasibility study activity, which leads to a feasibility report. If the feasibility study suggests that the product should be developed, then requirement analysis can begin. If requirement analysis precedes feasibility studies, which may foster outside the box thinking, then feasibility should be determined before requirements are finalized. See Stakeholder analysis for a discussion of business uses. Stakeholders (SH) are people or organizations (legal entities such as companies, standards bodies) that have a valid interest in the system. They may be affected by it either directly or indirectly. A major new emphasis in the 1990s was a focus on the identification of stakeholders . It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include: anyone who operates the system (normal and maintenance operators) anyone who benefits from the system (functional, political, financial and social beneficiaries) anyone involved in purchasing or procuring the system. In a mass-market product organization, product management, marketing and sometimes sales act as surrogate consumers (mass-market customers) to guide development of the product organizations which regulate aspects of the system (financial, safety, and other regulators) people or organizations opposed to the system (negative stakeholders; see also Misuse case ) organizations responsible for systems which interface with the system under design those organizations who integrate horizontally with the organization for whom the analyst is designing the system Stakeholder interviews Stakeholder interviews are a common technique used in requirement analysis. Though they are generally idiosyncratic in nature and focused upon the perspectives and perceived needs of the stakeholder, very often without larger enterprise or system context, this perspective deficiency has the general advantage of obtaining a much richer understanding of the stakeholder's unique business processes, decision-relevant business rules, and perceived needs. Consequently this technique can serve as a means of obtaining the highly focused knowledge that is often not elicited in Joint Requirements Development sessions, where the stakeholder's attention is compelled to assume a more cross-functional context. Moreover, the in-person nature of the interviews provides a more relaxed environment where lines of thought may be explored at length. Joint Requirements Development (JRD) Sessions Requirements often have cross-functional implications that are unknown to individual stakeholders and often missed or incompletely defined during stakeholder interviews. These cross-functional implications can be elicited by conducting JRD sessions in a controlled environment, facilitated by a trained facilitator , wherein stakeholders participate in discussions to elicit requirements, analyze their details and uncover cross-functional implications. A dedicated scribe and Business Analyst should be present to document the discussion. Utilizing the skills of a trained facilitator to guide the discussion frees the Business Analyst to focus on the requirements definition process. JRD Sessions are analogous to Joint Application Design Sessions. In the former, the sessions elicit requirements that guide design, whereas the latter elicit the specific design features to be implemented in satisfaction of elicited requirements. Contract-style requirement lists One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages. An appropriate metaphor would be an extremely long shopping list. Such lists are very much out of favour in modern analysis; as they have proved spectacularly unsuccessful at achieving their aims; but they are still seen to this day. Strengths Provides a checklist of requirements. Provide a contract between the project sponsor(s) and developers. For a large system can provide a high level description. Weaknesses Such lists can run to hundreds of pages. It is virtually impossible to read such documents as a whole and have a coherent understanding of the system. Such requirements lists abstract all the requirements and so there is little context This abstraction makes it impossible to see how the requirements fit or work together. This abstraction makes it difficult to prioritize requirements properly; while a list does make it easy to prioritize each individual item, removing one item out of context can render an entire use case or business requirement useless. This abstraction increases the likelihood of misinterpreting the requirements; as more people read them, the number of (different) interpretations of the envisioned system increase. This abstraction means that it's extremely difficult to be sure that you have the majority of the requirements. Necessarily, these documents speak in generality; but the devil, as they say, is in the details. These lists create a false sense of mutual understanding between the stakeholders and developers. These contract style lists give the stakeholders a false sense of security that the developers must achieve certain things. However, due to the nature of these lists, they inevitably miss out crucial requirements which are identified later in the process. Developers can use these discovered requirements to renegotiate the terms and conditions in their favour. These requirements lists are no help in system design, since they do not lend themselves to application. Alternative to requirement lists As an alternative to the large, pre-defined requirement lists Agile Software Development uses User stories to define a requirement in every day language. Measurable goals Main article: Goal modeling Best practices take the composed list of requirements merely as clues and repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over. Prototypes In the mid-1980s, prototyping was seen as the best solution to the requirements analysis problem. Prototypes are Mockups of an application. Mockups allow users to visualize an application that hasn't yet been constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of applications led to fewer changes later and hence reduced overall costs considerably. However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem: Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time. Designers often feel compelled to use patched together prototype code in the real system, because they are afraid to 'waste time' starting again. Prototypes principally help with design decisions and user interface design. However, they can not tell you what the requirements originally were. Designers and end-users can focus too much on user interface design and too little on producing a system that serves the business process. Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations. Prototypes can be flat diagrams (often referred to as wireframes ) or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application. Use cases Main article: Use case A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end-user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end-user or domain expert . Use cases are often co-authored by requirements engineers and stakeholders. Use cases are deceptively simple tools for describing the behavior of software or systems. A use case contains a textual description of all of the ways which the intended users could work with the software or system. Use cases do not describe any internal workings of the system, nor do they explain how that system will be implemented. They simply show the steps that a user follows to perform a task. All the ways that users interact with a system can be described in this manner. Software requirements specification A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements . In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints). Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification. Requirements are categorized in several ways. The following are common categorizations of requirements that relate to technical management: Customer Requirements Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS). The customers are those that perform the eight primary functions of systems engineering, with special emphasis on the operator as the key customer. Operational requirements will define the basic need and, at a minimum, answer the questions posed in the following listing: Operational distribution or deployment : Where will the system be used? Mission profile or scenario : How will the system accomplish its mission objective? Performance and related parameters : What are the critical system parameters to accomplish the mission? Utilization environments : How are the various system components to be used? Effectiveness requirements : How effective or efficient must the system be in performing its mission? Operational life cycle : How long will the system be in use by the user? Environment : What environments will the system be expected to operate in an effective manner? Architectural Requirements Architectural requirements explain what has to be done by identifying the necessary system architecture of a system . Structural Requirements Structural requirements explain what has to be done by identifying the necessary structure of a system . Behavioral Requirements Behavioral requirements explain what has to be done by identifying the necessary behavior of a system . Functional Requirements Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished. Functional requirements analysis will be used as the toplevel functions for functional analysis. Non-functional Requirements Non-functional requirements are requirements that specify criteria that can be used to judge the operation of a system, rather than specific behaviors. Performance Requirements The extent to which a mission or function must be executed; generally measured in terms of quantity, quality, coverage, timeliness or readiness. During requirements analysis, performance (how well does it have to be done) requirements will be interactively developed across all identified functions based on system life cycle factors; and characterized in terms of the degree of certainty in their estimate, the degree of criticality to system success, and their relationship to other requirements. Design Requirements The “build to,” “code to,” and “buy to” requirements for products and “how to execute” requirements for processes expressed in technical data packages and technical manuals. Derived Requirements Requirements that are implied or transformed from higher-level requirement. For example, a requirement for long range or high speed may result in a design requirement for low weight. Allocated Requirements A requirement that is established by dividing or otherwise allocating a high-level requirement into multiple lower-level requirements. Example: A 100-pound item that consists of two subsystems might result in weight requirements of 70 pounds and 30 pounds for the two lower-level items. Well-known requirements categorization models include FURPS and FURPS+, developed at Hewlett-Packard . Requirements analysis issues Stakeholder issues Steve McConnell, in his book Rapid Development , details a number of ways users can inhibit requirements gathering: Users do not understand what they want or users don't have a clear idea of their requirements Users will not commit to a set of written requirements Users insist on new requirements after the cost and schedule have been fixed Communication with users is slow Users often do not participate in reviews or are incapable of doing so Users are technically unsophisticated Users do not understand the development process Users do not know about present technology This may lead to the situation where user requirements keep changing even when system or product development has been started. Engineer/developer issues Possible problems caused by engineers and developers during requirements analysis are: Technical personnel and end-users may have different vocabularies. Consequently, they may wrongly believe they are in perfect agreement until the finished product is supplied. Engineers and developers may try to make the requirements fit an existing system or model, rather than develop a system specific to the needs of the client. Analysis may often be carried out by engineers or programmers, rather than personnel with the people skills and the domain knowledge to understand a client's needs properly. Attempted solutions One attempted solution to communications problems has been to employ specialists in business or system analysis. Techniques introduced in the 1990s like prototyping , Unified Modeling Language (UML), use cases , and Agile software development are also intended as solutions to problems encountered with previous methods. Also, a new class of application simulation or application definition tools have entered the market. These tools are designed to bridge the communication gap between business users and the IT organization — and also to allow applications to be 'test marketed' before any code is produced. The best of these tools offer: electronic whiteboards to sketch application flows and test alternatives ability to capture business logic and data needs ability to generate high fidelity prototypes that closely imitate the final application interactivity capability to add contextual requirements and other comments ability for remote and distributed users to run and interact with the simulation See also Business analysis Business Analysis Body of Knowledge (BABOK) Business process reengineering Creative brief Design brief Information technology Data modeling Functional requirements Model-driven engineering Model Transformation Language Non-functional requirements Process architecture Process modeling Requirements elicitation Requirements management Requirements Traceability Search Based Software Engineering Software prototyping Software Requirements Specification Systems analysis System requirements Software requirements References ^ a b c d e f g h Systems Engineering Fundamentals. Defense Acquisition University Press, 2001 ^ Executive editors: Alain Abran, James W. Moore; editors Pierre Bourque, Robert Dupuis, ed (March 2005). "Chapter 2: Software Requirements" . Guide to the software engineering body of knowledge (2004 ed.). Los Alamitos, CA: IEEE Computer Society Press. ISBN 0-7695-2330-7 . http://www.computer.org/portal/web/swebok/html/ch2 . Retrieved 2007-02-08 . "It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly." ^ Wiegers, Karl E. (2003). Software Requirements (2nd ed.). Redmond, WA: Microsoft Press. ISBN 0-7356-1879-8 . http://www.processimpact.com . ^ Phillip A. Laplante (2007) What Every Engineer Should Know about Software Engineering . Page 44. 三、Requirements management 源自：Wikipedia Requirements management is the process of documenting, analyzing , tracing , prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. It is a continuous process throughout a project. A requirement is a capability to which a project outcome (product or service) should conform. Contents 1 Overview 2 Traceability 3 Requirements activities 3.1 Investigation 3.2 Feasibility 3.3 Design 3.4 Construction and test 3.5 Release 4 Tools 4.1 SysML 4.2 RMsis for JIRA 4.3 RequirementOne 5 See also 6 References 7 Further reading 8 External links Overview The purpose of requirements management is to assure the organization documents, verifies and meets the needs and expectations of its customers and internal or external stakeholders . Requirements management begins with the analysis and elicitation of the objectives and constraints of the organization. Requirements management further includes supporting planning for requirements, integrating requirements and the organization for working with them (attributes for requirements), as well as relationships with other information delivering against requirements, and changes for these. The traceability thus established is used in managing requirements to report back fulfillment of company and stakeholder interests, in terms of compliance, completeness, coverage and consistency. Traceabilities also support change management as part of requirements management in understanding the impacts of changes through requirements or other related elements (e.g., functional impacts through relations to functional architecture), and facilitating introducing these changes. Requirements management involves communication between the project team members and stakeholders, and adjustment to requirements changes throughout the course of the project . To prevent one class of requirements from overriding another, constant communication among members of the development team is critical. For example, in software development for internal applications, the business has such strong needs that it may ignore user requirements, or believe that in creating use cases , the user requirements are being taken care of. Traceability Main article: Requirements Traceability Requirements traceability is concerned with documenting the life of a requirement. It should be possible to trace back to the origin of each requirement and every change made to the requirement should therefore be documented in order to achieve traceability. Even the use of the requirement after the implemented features have been deployed and used should be traceable . Requirements come from different sources, like the business person ordering the product, the marketing manager and the actual user. These people all have different requirements for the product. Using requirements traceability, an implemented feature can be traced back to the person or group that wanted it during the requirements elicitation . This can, for example, be used during the development process to prioritize the requirement, determining how valuable the requirement is to a specific user. It can also be used after the deployment when user studies show that a feature is not used, to see why it was required in the first place. Investigation In Investigation, the first three classes of requirements are gathered from the users, from the business and from the development team. In each area, similar questions are asked; what are the goals, what are the constraints, what are the current tools or processes in place, and so on. Only when these requirements are well understood can functional requirements be developed. A caveat is required here: no matter how hard a team tries, requirements cannot be fully defined at the beginning of the project. Some requirements will change, either because they simply weren’t extracted, or because internal or external forces at work affect the project in mid-cycle. Thus, the team members must agree at the outset that a prime condition for success is flexibility in thinking and operation. The deliverable from the Investigation stage is a requirements document that has been approved by all members of the team. Later, in the thick of development, this document will be critical in preventing scope creep or unnecessary changes. As the system develops, each new feature opens a world of new possibilities, so the requirements specification anchors the team to the original vision and permits a controlled discussion of scope change. While many organizations still use only documents to manage requirements, others manage their requirements baselines using software tools. These tools allow requirements to be managed in a database, and usually have functions to automate traceability (e.g., by allowing electronic links to be created between parent and child requirements, or between test cases and requirements), electronic baseline creation, version control, and change management. Usually such tools contain an export function that allows a specification document to be created by exporting the requirements data into a standard document application. Feasibility In the Feasibility stage, costs of the requirements are determined. For user requirements, the current cost of work is compared to the future projected costs once the new system is in place. Questions such as these are asked: “What are data entry errors costing us now?” Or “What is the cost of scrap due to operator error with the current interface?” Actually, the need for the new tool is often recognized as these questions come to the attention of financial people in the organization. Business costs would include, “What department has the budget for this?” “What is the expected rate of return on the new product in the marketplace?” “What’s the internal rate of return in reducing costs of training and support if we make a new, easier-to-use system?” Technical costs are related to software development costs and hardware costs. “Do we have the right people to create the tool?” “Do we need new equipment to support expanded software roles?” This last question is an important type. The team must inquire into whether the newest automated tools will add sufficient processing power to shift some of the burden from the user to the system in order to save people time. The question also points out a fundamental point about requirements management. A human and a tool form a system, and this realization is especially important if the tool is a computer or a new application on a computer. The human mind excels in parallel processing and interpretation of trends with insufficient data. The CPU excels in serial processing and accurate mathematical computation. The overarching goal of the requirements management effort for a software project would thus be to make sure the work being automated gets assigned to the proper processor. For instance, “Don’t make the human remember where she is in the interface. Make the interface report the human’s location in the system at all times.” Or “Don’t make the human enter the same data in two screens. Make the system store the data and fill in the second screen as needed.” The deliverable from the Feasibility stage is the budget and schedule for the project. Design Assuming that costs are accurately determined and benefits to be gained are sufficiently large, the project can proceed to the Design stage. In Design, the main requirements management activity is comparing the results of the design against the requirements document to make sure that work is staying in scope. Again, flexibility is paramount to success. Here’s a classic story of scope change in mid-stream that actually worked well. Ford auto designers in the early ‘80s were expecting gasoline prices to hit $3.18 per gallon by the end of the decade. Midway through the design of the Ford Taurus, prices had centered to around $1.50 a gallon. The design team decided they could build a larger, more comfortable, and more powerful car if the gas prices stayed low, so they redesigned the car. The Taurus launch set nationwide sales records when the new car came out, primarily because it was so roomy and comfortable to drive. In most cases, however, departing from the original requirements to that degree does not work. So the requirements document becomes a critical tool that helps the team make decisions about design changes. Construction and test In the construction and testing stage, the main activity of requirements management is to make sure that work and cost stay within schedule and budget, and that the emerging tool does in fact meet requirements. A main tool used in this stage is prototype construction and iterative testing. For a software application, the user interface can be created on paper and tested with potential users while the framework of the software is being built. Results of these tests are recorded in a user interface design guide and handed off to the design team when they are ready to develop the interface. This saves their time and makes their jobs much easier. Release Requirements management does not end with product release. From that point on, the data coming in about the application’s acceptability is gathered and fed into the Investigation phase of the next generation or release. Thus the process begins again. Tools There exist both desktop and Web-based tools for requirements management. A Web-based requirements tool can be installed at the customer′s datacenter or can be offered as an on-demand requirements management platform which in some cases can be completely free . On-demand services would normally include all special hardware and software. Other services may include technology and processes designed to secure your data against physical loss and unauthorized use, 24×7 data availability, and assurance that the service will scale as you add users, applications, and additional activities. Some on-demand requirements management platforms charge a fee while others are free to use. SysML The system engineering modeling language SysML incorporates a requirements diagram allowing the developer to graphically organize, manage, and trace requirements. RMsis for JIRA RMsis is simple, intuitive and specific requirement management extension for JIRA . This tool provides a user friendly collaborative platform for effectively managing requirements . The tool is currently not available as a standalone product. It works with JIRA only. RequirementOne RequirementOne is an on-demand requirements management platform. It is a fully hosted requirements management solution, where the only system requirements would normally be Internet access and a standard Web browser. See also Requirement Requirements analysis Requirements traceability Process area (CMMI): Requirements Development (RD) Requirements Management (REQM) Product requirements document References ^ Stellman, Andrew; Greene, Jennifer (2005). Applied Software Project Management . O'Reilly Media. ISBN 978-0-596-00948-9 . http://www.stellman-greene.com/aspm/ . ^ "Requirements management" . UK Office of Government Commerce . http://www.ogc.gov.uk/delivery_lifecycle_requirements_management.asp . Retrieved 2009-11-10 . ^ A Guide to the Project Management Body of Knowledge (4th ed.). Project Management Institute. 2008. ISBN 978-1-933-89051-7 . http://www.pmi.org/ . ^ Gotel, O., Finkelstein, A. An Analysis of the Requirements Traceability Problem Proc. of First International Conference on Requirements Engineering, 1994, pages 94-101 ^ "Requirements Management Tools Survey" . International Council on Systems Engineering . http://www.incose.org/ProductsPubs/products/rmsurvey.aspx . Retrieved 2009-11-10 . ^ "RMsis Documentation" . Optimizory Technologies Private Limited . http://docs.optimizory.com/display/rmsis . Further reading CMMI Product Team (August 2006) ( PDF ). CMMI for Development, Version 1.2 . Technical Report CMU/SEI-2006-TR-008. Software Engineering Institute . http://www.sei.cmu.edu/library/abstracts/reports/06tr008.cfm . Retrieved 2008-01-22 . Colin Hood, Simon Wiedemann, Stefan Fichtinger, Urte Pautz Requirements Management: Interface Between Requirements Development and All Other Engineering Processes Springer, Berlin 2007, ISBN 354047689X External links Critical Issues in Requirements Management - Panel Discussion with Executives from IBM/Rational, Cognition Corporation, PTC, Chrysler, and Siemens. Web 2.0 Requirements Management - What does it look like and why is it relevant? Forbes Requirements Management Software Directory INCOSE Requirements Tools Survey Jiludwig Requirements Management Tools Directory Requirements Management Tool Resources Washington State Information Services Board (ISB)policy: CMM Key Practices for Level 2 - Requirements Management U.K. Office of Government Commerce (OGC) - Requirements management Requirement Writing 101 for Product Management The 2011 State of Requirements Management Report
标签: 产品研发
