by “shall”) are requirements and others are recommendations (“should”) and permissions (“may”). Activities are intended to group together related tasks.
Here’s the complete set of activities and tasks from the Software Configuration Management process. (This example is atypical because each activity has only a single task.):
220.127.116.11 Activities and Tasks
The project shall implement the following activities in accordance with applicable organization policies and procedures with respect to the Software Configuration Management Process.
18.104.22.168.1 Process implementation. This activity consists of the following task:
22.214.171.124.1.1 A software configuration management plan shall be developed. The plan shall describe: the configuration management activities; procedures and schedule for performing these activities; the organization(s) responsible for performing these activities; and their relationship with other organizations, such as software development or maintenance. The plan shall be documented and implemented.
NOTE The plan may be a part of the system configuration management plan.
126.96.36.199.2 Configuration identification. This activity consists of the following task:
188.8.131.52.2.1 A scheme shall be established for identification of software items and their versions to be controlled for the project. For each software item and its versions, the following shall be identified: the documentation that establishes the baseline; the version references; and other identification details.
184.108.40.206.3 Configuration control. This activity consists of the following task:
220.127.116.11.3.1 The following shall be performed: identification and recording of change requests; analysis and evaluation of the changes; approval or disapproval of the request; and implementation, verification, and release of the modified software item. An audit trail shall exist, whereby each modification, the reason for the modification, and authorization of the modification can be traced. Control and audit of all accesses to the controlled software items that handle safety or security critical functions shall be performed.
NOTE The Software Problem Resolution Management Process could provide support for this activity.
18.104.22.168.4 Configuration status accounting. This activity consists of the following task:
22.214.171.124.4.1 Management records and status reports that show the status and history of controlled software items, including baselines shall be prepared. Status reports should include the number of changes for a project, latest software item versions, release identifiers, the number of releases, and comparisons of releases.
126.96.36.199.5 Configuration evaluation. This activity consists of the following task:
188.8.131.52.5.1 The following shall be determined and ensured: the functional completeness of the software items against their requirements and the physical completeness of the software items (whether their design and code reflect an up-to-date technical description).
184.108.40.206.6 Release management and delivery. This activity consists of the following task:
220.127.116.11.6.1 The release and delivery of software products and documentation shall be formally controlled. Master copies of code and documentation shall be maintained for the life of the software product. The code and documentation that contain safety or security critical functions shall be handled, stored, packaged, and delivered in accordance with the policies of the organizations involved.
The description is not quite as brief, and now phrased differently. It describes things that are required or recommended to be done to achieve the outcomes.
Both descriptions contain “Notes”. In an ISO/IEC standard, a note is never a requirement; it merely provides guidance to the user. The activities/tasks description contains notes suggesting packaging of documentation and associated process. The note just below the title of the process is more interesting, though. It suggests that, in some circumstances, one might want to apply the more general Configuration Management process—one that is suited to hard and soft items—that can be found elsewhere in the standard. This is just another example of the degree of flexibility afforded to the user of 12207.
Suppose the user wants even more detail and