BS ISO/IEC/IEEE 24774:2021 pdf download – Systems and software engineering — Life cycle management — Specification for process description.
NOTE  Two prominent International Standards in process description for software and system engineering are ISO/IEC/IEEE 12207 and ISO/IEC/IEEE 15288. These two standards have very similar process models. The information items associated with their process definitions are given in ISO/IEC/IEEE 15289. Other International Standards provide further characterization of a single life cycleprocess by elaborating the process elements and levying specific requirements on the execution of the process. This document is applicable when processes are described for various process definitions in any party, organization or standard relating to systems and software engineering processes.Additionally, if processes are highly automated and require little human control or intervention, it can be appropriate to combine several processes into one process description. NOTE 1  Often a set of processes are developed; and some processes are decomposed into more than one level. However, decomposition of processes into more than three levels is likely to be confusing and hard for humans to use. Procedures differ from process descriptions in that procedures are written in steps to be followed in order. Procedures can be written as instructions to the persons performing the procedure. Procedures can also be written to assist an evaluator or auditor to understand the procedure, especially its controls or outputs. NOTE 2  ISO/IEC/IEEE 82079-1 provides detailed requirements for writing instructions. Required activities are stated in process descriptions using either the imperative (as a command), or as a ‘shall’ statement.
Generally, several software or systems engineering processes are performed concurrently during a life cyclestage. However, concurrent activities (e.g. installation and quality assurance inspections) are not necessarily part of the same process, since their purpose, resources, methods, outputs, and outcomes are different. Process descriptions may be used either to describe generic processes (for example “project management process”) or to describe a particular instance of a generic type (for example “project management process for project A”). For specific process descriptions, generic process descriptions may be instantiated with respect to roles or responsibilities, resources, required inputs and outputs, constraints and controls, and time.
5.3.2  Process name The name of a process description shall be stated as a short noun phrase that presents a descriptive heading for the process. The name identifies the principal concern of the process and distinguishes the process from other processes in the model. Because of the latter criterion, it may sometimes be necessary to tailor the name of a process. For example, one may have a “software architecture process” which is later refined as a “software detailed design process” or “data architecture process” or “interface architecture process.” Process names should end in the word process. Wordy noun-verb or verb-noun phrases can get confused with processactivities and often represent an attempt to summarize the purpose or process so that the name can stand for the purpose. A descriptive noun phrase – the name of the process – is more useful. The intent is to give a name, not a summary. NOTE  Although the term “process name” is preferred and used throughout this document, “process title” is an acceptable alternative. 5.3.3  Process purpose The purpose element of the process shall be stated as one or more related high-level goals for performing the process. In cases where processes seem to overlap, the purpose element should be used to characterize the scope or bounds of the process. Whenever possible, the purpose element should be succinctly captured in a single sentence. Summarizing the activities or outcomes of the process in the purpose statement should be avoided. Use of the conjunction “and” to connect multiple clauses should be avoided as it would indicate that the description is being written as an aggregation of marginally related outcomes rather than as a statement of a single purpose. The purpose element shall begin with the words, “The purpose of the xxx process is… “. The phrase, “in order to” may be useful in recording the objective of the process.