ISO/IEC TR 24766:2009
(Main)Information technology — Systems and software engineering — Guide for requirements engineering tool capabilities
Information technology — Systems and software engineering — Guide for requirements engineering tool capabilities
Requirements engineering (RE) is an essential process of the systems and software engineering life cycles. RE has been established as an ISO/IEC standard life cycle process in both ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes and ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes. This Technical Report provides guidance on desirable capabilities of RE tools. It supplements ISO/IEC 14102:2008, Information technology — Guideline for the evaluation and selection of CASE tools, which details a set of evaluation criteria for CASE tools without referencing a specific activity or service area.
Technologies de l'information — Ingénierie des systèmes et du logiciel — Guide pour les capacités d'outil d'ingénierie des exigences
General Information
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR
24766
First edition
2009-12-15
Information technology — Systems and
software engineering — Guide for
requirements engineering tool
capabilities
Technologies de l'information — Ingénierie des systèmes et du
logiciel — Guide pour les capacités d'outil d'ingénierie des
exigences
Reference number
ISO/IEC TR 24766:2009(E)
©
ISO/IEC 2009
---------------------- Page: 1 ----------------------
ISO/IEC TR 24766:2009(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2009
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2009 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 24766:2009(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
2 Normative references.1
3 Terms and definitions .1
4 Requirements engineering process .2
4.1 Overview.2
5 Requirements engineering tool capabilities.3
5.1 Overview.3
5.2 Requirements elicitation.3
5.3 Requirements analysis .6
5.4 Requirements specification .8
5.5 Requirements verification and validation.9
5.6 Requirements management .12
5.7 Other tool capabilities.13
6 Quality characteristics of requirements.14
6.1 Overview.14
6.2 Quality characteristics of requirements artifacts .14
6.3 Tool capabilities for quality characteristics .15
Annex A (informative) Requirements quality characteristics and software quality characteristics.21
Bibliography.23
© ISO/IEC 2009 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 24766:2009(E)
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are members of
ISO or IEC participate in the development of International Standards through technical committees
established by the respective organization to deal with particular fields of technical activity. ISO and IEC
technical committees collaborate in fields of mutual interest. Other international organizations, governmental
and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, the joint technical committee may propose the publication of a Technical Report
of one of the following types:
— type 1, when the required support cannot be obtained for the publication of an International Standard,
despite repeated efforts;
— type 2, when the subject is still under technical development or where for any other reason there is the
future but not immediate possibility of an agreement on an International Standard;
— type 3, when the joint technical committee has collected data of a different kind from that which is
normally published as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether
they can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to
be reviewed until the data they provide are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 24766, which is a Technical Report of type 2, was prepared by Joint Technical Committee
ISO/IEC JTC 1, Information technology, Subcommittee SC 7, Software and systems engineering.
iv © ISO/IEC 2009 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 24766:2009(E)
Introduction
Requirements engineering (RE) is a major activity within the systems and software engineering life cycles.
This activity must be carried out in a comprehensive manner to ensure that a complete set of user needs and
requirements is captured. These user needs and requirements are transformed into a validated set of
technical requirements and managed throughout the life cycle using the RE process activities. RE tools are
used to support many RE and related life cycle activities. RE processes are identified in ISO/IEC 15288:2008,
Systems and software engineering — System life cycle processes and ISO/IEC 12207:2008, Systems and
software engineering — Software life cycle processes.
ISO/IEC 15288:2008 and ISO/IEC 12207:2008 describe a set of RE processes, activities and tasks to be
performed when acquiring or developing systems and software. However, these documents do not address
the RE tool capabilities users can expect in order to support an RE process and other related life cycle
activities.
Many RE processes are human activities that, in the current state of the practice, tools cannot perform, and
that might never be able to be performed by a tool. But wherever possible, a tool should support these human
activities through the facilitation of documentation capture, content management, distribution, discussion
forums, and decision support tools.
This Technical Report describes capabilities of RE tools to benefit the groups of people that acquire, supply,
develop, operate, and maintain an RE process.
This Technical Report will help RE personnel involved in the execution of one or more RE activities to
• obtain a better understanding of the relationship between the activities in which they are involved and
RE tool capabilities,
• identify processes or activities that can be improved through better support by an RE tool, and
• have an objective basis for a better comparison, evaluation and assessment of RE tools.
This Technical Report will help people involved in the purchase of RE tools to
• review RE services that can contribute to RE process improvement, and
• identify criteria for selecting RE tools.
This Technical Report will help RE tool vendors to
• provide RE tools consistent with ISO/IEC 15288:2008, ISO/IEC 12207:2008, ISO/IEC 15940:2006,
and ISO/IEC 14102:2008.
© ISO/IEC 2009 – All rights reserved v
---------------------- Page: 5 ----------------------
TECHNICAL REPORT ISO/IEC TR 24766:2009(E)
Information technology — Systems and software engineering —
Guide for requirements engineering tool capabilities
1 Scope
Requirements engineering (RE) is an essential process of the systems and software engineering life cycles.
RE has been established as an ISO/IEC standard life cycle process in both ISO/IEC 15288:2008, Systems
and software engineering — System life cycle processes and ISO/IEC 12207:2008, Systems and software
engineering — Software life cycle processes.
This Technical Report provides guidance on desirable capabilities of RE tools. It supplements
ISO/IEC 14102:2008, Information technology — Guideline for the evaluation and selection of CASE tools,
which details a set of evaluation criteria for CASE tools without referencing a specific activity or service area.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 12207:2008, Systems and software engineering — Software life cycle processes
ISO/IEC 15288:2008, Systems and software engineering — System life cycle processes
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
activity
set of actions that consume time and resources and whose performance is necessary to achieve, or contribute
to, the realization of one or more outcomes
3.2
manage
provide storing and editing capabilities, tracking history of edition, versioning, author identification, change
management, time stamping, user notification for content changes, security rights control
3.3
management
provision of storing and editing capabilities, tracking history of edition, versioning, author identification, change
management, time stamping, user notification for content changes, security rights control
3.4
functional requirement
requirement that specifies a function that a system or system component must be able to perform
[ISO/IEC 25000:2005]
© ISO/IEC 2009 – All rights reserved 1
---------------------- Page: 6 ----------------------
ISO/IEC TR 24766:2009(E)
3.5
quality requirement
non-functional requirement
capability of a product to satisfy the stated and implied needs when used under specific conditions
3.6
process
set of interrelated or interacting activities which transforms inputs into outputs
[ISO/IEC 12207:2008 and ISO/IEC 15288:2008]
3.7
requirements attributes
set of properties associated with requirements
3.8
stakeholder
party having a right, share, or claim in a system or in its possession of characteristics that meet that party’s
needs and expectations
[ISO/IEC 25000:2005]
3.9
stakeholder equity
degree of the share or claim a stakeholder has in the system of interest or a portion of the system of interest
3.10
user requirements
expression of perceived need from individual or group that benefits from a system during its utilization
NOTE User requirements are requirements issued by a user.
4 Requirements engineering process
4.1 Overview
A requirements engineering (RE) tool should facilitate and support the systematic managing of requirements
throughout the project life cycle. The tool should also support the related activities in the context of the RE
process. The following sub-topics characterize the processes that an RE tool would need to address.
4.1.1 Requirements elicitation
Requirements elicitation is the process of seeking, uncovering, acquiring, and elaborating requirements.
Requirements are elicited rather than just captured or collected. This implies there are discovery, emergence,
and development elements to the elicitation process. Requirements elicitation is an iterative activity and
benefits from continuous communication and validation with stakeholders.
4.1.2 Requirements analysis
Requirements analysis involves refining the requirements by decomposing high level requirements into
details, building prototypes, evaluating feasibility, analyzing overlaps or conflicts between requirements, and
negotiating priorities. The goal is to develop requirements of sufficient quality and detail to reflect the
stakeholders’ needs.
2 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 24766:2009(E)
4.1.3 Requirements specifications
Requirements specification deals with documenting the requirements in a consistent and reviewable way.
Documentation includes the functions and capabilities that a system must provide and the constraints that a
system must respect. Requirements specification is the basis for all subsequent software and system life cycle
activities including project planning, design, and production, as well as the foundation for system testing and
user documentation.
4.1.4 Requirements and product validation
Validation is the process of evaluating a system or software to determine whether it meets stakeholder
requirements. It is performed by examination and through the provision of objective evidence that the
requirements for a specific intended use or application have been fulfilled.
4.1.5 Requirements and product verification
Verification is the process of evaluating a system or software to determine whether it properly reflects the
specified requirements. It is performed by examination and through the provision of objective evidence that
specified requirements have been fulfilled.
4.1.6 Requirements management
Requirements management in conjunction with change management ensures that the requirements remain
aligned with the developed product. Requirements management concerns the collection, analysis, and
validation and verification of requirements with all the communications and negotiations inherent in working
with people.
5 Requirements engineering tool capabilities
5.1 Overview
RE tools allow requirements engineering and management actions to be automated, reducing the cognitive
load on the stakeholder. This section provides a list of required capabilities for an RE tool. The capabilities are
organized according to the system and software requirements activities listed in ISO/IEC 12207:2008,
ISO/IEC 15288:2008, and ISO/IEC TR 19759 (SWEBOK).
This list can be used for:
• Evaluating and choosing an RE tool
• Matching process to specific RE tool capabilities
5.2 Requirements elicitation
5.2.1 Overview
The requirements expressed in the project scope must address all essential business and user needs. The
RE tool should be able to support in identifying stakeholder, capturing and tracing of the business/user
requirements, functional requirements, and the quality requirements during elicitation work.
5.2.2 Requirements capture
The RE tool should support requirements capture by allowing the user to:
• Storing and managing the documentation from interviews, workshops, and observation
© ISO/IEC 2009 – All rights reserved 3
---------------------- Page: 8 ----------------------
ISO/IEC TR 24766:2009(E)
• Storing and managing stakeholder information (e.g., contact lists, comments, and etc.)
• Tracing requirements and generating trace reports
• Creating hierarchical relationships between requirements
• Including design rationale information directly associated with any hierarchical link
• Importing text and graphics from applications (e.g., open text formats)
• Updating existing linked documents from new or changed versions of the source documents without
having to re-establish traceability links
• Storing and managing attributes for classifying or categorizing requirements during identification
• Storing and managing attributes in a variety of formats (e.g., text, enumerated, binary, graphics,
descriptions, attachments), that can be associated with each requirements
• Using tool generated inherent attributes (e.g., unique requirement identification, author, time date,
requirements change history)
• Using flexible search options for requirements by word or attributes (e.g., requirements identifier,
words in text files, user and tool generated attributes)
• Managing the replacement or updating requirements by manual or electronic import
• Using flexible user programming language to develop reports for display or generating documents
from the tool
5.2.3 Capturing “as-is” and “to-be” system elements
Requirements expressed in the project scope must not exclude any essential business, user, functional, and
quality requirements. The RE tool should support capturing "as-is" and the "to-be system elements as follows:
• Storing and managing graphics and text (e.g., architecture, functional decomposition, Work
Breakdown Structure (WBS))
• Storing and managing user definable attributes and additional information associated with a given
requirement (e.g., stakeholders, business process, activity, tasks, policy, constraints)
• Flexible tracing (e.g. forward and backward tracing, one to many and many to one, bi-directional
tracing of text to text, text to graphics, graphics to graphics, elements within graphics, tables and cells
within a table)
• Bi-directional tracing of additional requirements and link between them (e.g., requirements to
requirements, requirements to derived requirements
• Bi-directional tracing of requirements to system elements
• Bi-directional tracing the allocation of requirements to system elements
• Bi-directional tracing of rationale, assignments, criticality, test and validation to the requirements,
allocation, and system elements
4 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 24766:2009(E)
5.2.4 Stakeholder and requirements traceability
All functional and quality requirements should be traceable back to specific user, stakeholder, and business
requirements. The RE tool should support traceability between them as follows:
• Storing and managing the identification and documentation of stakeholders and their roles and
responsibilities
• Flexible searching and reporting of inconsistencies such as unlinked requirements or system
elements (e.g., orphans)
• Bi-directional tracing of user needs and requirements
• Tracing user defined attributes for requirements that was fulfilled, how it was done, and who was
responsible
• Displaying of traceability in graphical and textual form
• Flexible exporting of traceability matrix in both textual and graphical forms (e.g. Comma Separated
Value (CSV), open text format, eXtensible Markup Language (XML), and etc.)
5.2.5 Goal-oriented scenarios and high-level modeling
Scenarios, models, and simulations can be used to describe the specific interaction between a user and a
system to accomplish the goal of requirement. The RE tool should support goal-oriented scenarios and
modeling as follows:
• Storing and managing user defined or tool provided templates for goal-oriented scenarios (e.g.,
simulations and modeling business scenarios, strategic issues)
• Storing and managing user defined scenarios
• Evaluating requirements based on business goals
5.2.6 Elicitation templates and checklists
Templates and checklists provide a consistent structure for recording the requirements descriptions and other
requirements related information. The RE tool should support elicitation templates and checklists as follows:
• Storing and managing user defined or tool provided templates for elicitation (e.g. Quality Function
Deployment (QFD) or Goal Question Metric (GQM))
• Storing and managing user defined or tool provided elicitation checklists
• Storing and managing user defined or tool provided prioritization forms
5.2.7 Prototyping
Prototyping can be used to explore and validate requirements. The RE tool should support prototyping as
follows:
• Presenting information in a graphical user interface (GUI)
5.2.8 Importing and exporting to and from other sources
Requirements should be imported from, or interfaced to users, hardware, and other software systems. The RE
tool should support Importing and exporting to and from other sources as follows:
© ISO/IEC 2009 – All rights reserved 5
---------------------- Page: 10 ----------------------
ISO/IEC TR 24766:2009(E)
• Importing and exporting to and from other tools (e.g. verification, design, spreadsheets, project
management, documents)
• Importing and exporting to and from various standard file formats (e.g., Comma Separated Value
(CSV), eXtensible Markup Language (XML))
5.2.9 Elicitation documentation
The output from the entire requirements elicitation tasks should be stored, retrieved, and edited in various
formats. The RE tool should support elicitation documentation as follows:
• Storing and managing non-textual requirements in the specified format (e.g., bit-mapped graphics,
vector graphics, tables, equations, or formal logic notations)
• Storing and managing textual requirements statements using basic text processor and spell checker
5.3 Requirements analysis
5.3.1 Overview
Requirements analysis includes decomposing high-level requirements into details by building prototypes,
evaluating feasibility, and negotiating priorities. The RE tool should be able to support in decomposing
requirements into functional and quality requirements, and in analyzing requirements feasibility and risk.
5.3.2 Functional requirements analysis
Functional requirements are a statement of required functionality or a behavior that a system will exhibit under
specific conditions. The RE tool should support functional requirements analysis as follows:
• Storing and bi-directional tracing of identified user requirements to functional requirements
• Hierarchical structuring and identification scheme for the elaboration of requirements
• Checking spells and grammars on requirements statements (e.g. word spelling check, passive vs.
active voice)
• Bi-directional tracing of requirements analysis to system implementation (e.g., architecture design,
Work Breakdown Structure (WBS))
5.3.3 Quality requirements analysis
Quality requirements analysis involves significant architectural and design decisions. The RE tool should
support quality requirements analysis as follows:
• Storing and managing quality requirements in quality attributes, policies, or constraints
• Hierarchical structuring and identification scheme for the elaboration of requirements
• Bi-directional tracing of quality requirements to source requirements or user requirement
• Checking spells and grammars on requirements statements (e.g. word spelling check, passive vs.
active voice)
• Bi-directional tracing of requirements analysis to system implementation (e.g., architecture design,
Work Breakdown Structure (WBS))
• Storing and managing the results or the rationale of quality attributes trade-off
6 © ISO/IEC 2009 – All rights reserved
---------------------- Page: 11 ----------------------
ISO/IEC TR 24766:2009(E)
5.3.4 Feasibility analysis
Feasibility analysis evaluates the possibility of implementing each requirement at acceptable cost and
performance. It also identifies technical obstacles. The RE tool should support feasibility analysis as follows:
• Storing and generating user defined or tool provided checklists or templates for various analysis,
(e.g., technical, economical, and operational analysis)
• Storing and managing rationale of feasibility analysis
5.3.5 Modelling
Modeling analysis depicts the requirements at a high level of abstraction. Such models include data flow
diagrams, entity relationship diagrams, or UML diagrams. The RE tool should support modeling analysis as
follows:
• Importing and exporting to and from modeling tools and displaying the results
• Storing and displaying context diagrams, conceptual domain models, and other high level models
(e.g. Goal models, Object models, Task models)
• Storing and displaying analysis of requirements in graphical form (e.g., Unified Modeling Language
(UML), Data Flow Diagram (DFD))
5.3.6 Prototyping
When developers or users are not certain about the requirements, constructing a prototype make the
concepts and possibilities more tangible. The RE tool should support prototyping as follows:
• Presenting information in a graphical user interface (GUI)
• Demonstrating algorithm
5.3.7 Attribute analysis
User defined attributes such as risk, priority, and cost provides metrics for tracking requirements based on
project needs. These attributes are assignable to each requirement. The RE tool should support tracking of
any attribute(s) user defined or tool provided as follows:
• Storing and managing attributes in various formats (e.g. text, numeric, graphics, attachments)
• Detecting and flagging missing attributes
• Storing, sorting, grouping and ordering of attributes
• Managing changes to attributes
5.3.8 Requirements refinement
Requirements refinement identifies the hierarchical relation of requirements and allocates the requirements to
subsystems. The RE tool should support requirements refinement as follows:
• Hierarchical structuring and identification scheme for the elaboration of requirements
• Bi-directional tracing of requirements to parent requirements or user requirement
• Bi-directional tracing of requirements to child requirements or design elements
© ISO/IEC 2009 – All rights reserved 7
---------------------- Page: 12 ----------------------
ISO/IEC TR 24766:2009(E)
• Bi-directional tracing of requirements to verification and validation case element
• Storing and managing the allocation rationale (e.g., how it was done, who was responsible)
• Supporting a flexible set of user defined or tool provided queries on requirements
5.3.9 Risk analysis
Risk analysis provides a standard approach to identify and document potential risks, and propose strategies
for mitigating them. The RE tool should support risk analysis as follows:
• Exchanging information pertinent to risk analysis tools with external risk analysis tools
• Associating requirements with risks as a means of mitigation
5.3.10 Decision methods
Multiple stakeholders decide how to manage and resolve conflicting requirements. The RE tool should support
decision methods as follows:
• Supporting an interface to a possibly separate terminology(glossary) or domain knowledge repository
• Checking requirements’ conformity to predefined templates
• Storing and managing the list of conflicting requirements
• Storing and managing the information and rationale for resolved results
5.3.11 Requirements analysis artifacts
The output from the entire requirements analysis task should be stored, retrieved, and edited in various
formats. The RE tool should support requirements analysis documentation as follows:
• Storing requirements analysis results in both text and graphical formats (e.g., Rich Text Format
(RTF), eXtensible Markup Language (XML),JPEG)
• Storing, managing, and exporting requirements analysis results using basic text processor and spell
checker
• Storing and managing non-requirements items, such as constraints on resources (e.g., time, budget,
people) and considerations on design
5.4 Requirements specification
5.4.1 Overview
The specification states the functions and capabilities that a software or a system must provide and the
constraints that it must respect. The RE tool should be able to support for all requirements b
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.