IEEE 29148-2011 pdf free download – Systems and software engineering — Life cycle processes — Requirements engineering.
5 Concepts
5.1 Introduction This clause presents concepts that apply to requirements themselves, and to the information items generated during the process of documenting requirements. The concepts apply to the properties of requirements at all levels of the system-of-interest. The concepts also apply to the processes used in the elicitation, analysis, allocation, documentation, and management of requirements.
5.2 Requirements fundamentals
5.2.1 General Requirements engineering is an interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software or service of interest. Requirements engineering is concerned with discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements. The result of requirements engineering is a hierarchy of requirements that: ? enables an agreed understanding between stakeholders (e.g., acquirers, users, customers, operators, suppliers)  is validated against real-world needs, can be implemented ? provides a basis of verifying designs and accepting solutions. The hierarchy of requirements may be represented in one or more requirements specifications (see Clauses 8 and 9 for specification templates and content).
5.2.2 Stakeholders Stakeholders vary across projects when considered in the context of requirements engineering. A minimum set of stakeholders consists of users and acquirers (who may not be the same). Complex projects can impact many users and many acquirers, each with different concerns. Project requirements can necessitate including two other groups as part of the minimum set of stakeholders. First, the organization developing, maintaining, or operating the system or software has a legitimate interest in benefiting from the system. Second, regulatory authorities can have statutory, industry, or other external requirements demanding careful analysis.
5.2.3 Transformation of needs into requirements Defining requirements begins with stakeholder intentions (referred to as needs, goals, or objectives), that evolve into a more formal statement before arriving as valid stakeholder requirements. Initial stakeholder intentions do not serve as stakeholder requirements, since they often lack definition, analysis and possibly consistency and feasibility. Using the Concept of Operations to aid the understanding of the stakeholder intentions at the organizational level and the System Operational Concept from the system perspective, requirements engineering leads stakeholders from those initial intentions to structured and more formal stakeholder requirement statements.
These statements are well-formed and meet the characteristics of subclauses 5.2.4, 5.2.5, and 5.2.6. The stakeholder requirements are then transformed into system requirements for the system-of-interest, in accordance with subclauses 5.2.4, 5.2.5, and 5.2.6. Consistent practice has shown this process requires iterative and recursive steps in parallel with other life cycle processes through the system design hierarchy. The recursive application of the processes in Clause 6 will generate lower-level system element requirements.
Clause 6 details the processes to perform stakeholder requirements definition and requirements analysis. Clauses 7, 8, and 9 contain further guidance on information items associated with documenting the requirements. Annex A provides requirements for the content of a System Operational Concept and Annex B provides guidelines for the content of a Concept of Operations.
NOTE See ISO/IEC 26551:—, Software and systems engineering — Tools and methods of requirements engineering and management for product lines for additional guidance on requirements development techniques, including requirements reuse.IEEE 29148 pdf download.