Страница разрабатывается

Описание стандарта

Интернациональный стандарт, определяющий процессы, которые должны быть реализованы в ходе процесса инженерии требований для систем и программных продуктов на протяжении всего жизненного цикла.

Классификация требований

Требование — утверждение, которое идентифицирует эксплуатационные, функциональные параметры, характеристики или ограничения проектирования продукта или процесса, которое однозначно, проверяемо и измеримо. Необходимо для приемки продукта или процесса (потребителем или внутренним руководящим принципом обеспечения качества).

Stakeholder Requirement

User requirements (within the context of the StRS) include required inputs/selections/information observations which users/operators/maintainers need to perform through the use of the system; any outputs they require from the system in order to perform these tasks; and any applicable conditions or constraints governing their interaction with (i.e., usability of) the system. These requirements are then used to describe the operational scenarios which specify how to meet these requirements when interacting with the system.

System Requirement

Functional requirements — Define functional requirements applicable to system operation.
Usability requirements — Define usability (quality in use) requirements. Usability requirements and objectives for the system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use.
Performance requirements — Define the critical performance conditions and their associated capabilities by including such considerations as
a) Dynamic actions or changes that occur (e.g., rates, velocities, movements, and noise levels).
b) Quantitative criteria covering endurance capabilities of the equipment required to meet the user needs under stipulated environmental and other conditions, including minimum total life expectancy. Indicate required operational session duration and planned utilization rate.
c) Performance requirements for the operational phases and modes.
System interfaces — Specify requirements for interfaces among system elements and with external entities. Interfaces among system elements should include interfaces with the human element. Interfaces with external entities should include other systems.
Human system integration requirements — Reference applicable documents and specify any special or unique requirements, e.g., constraints on allocation of functions to personnel and communications and personnel/equipment interactions. Define any specific areas, stations, or equipment that would require concentrated human engineering attention due to the sensitivity of the operation or criticality of the task (i.e., those areas where the effects of human error would be particularly serious).
Maintainability — Specify the quantitative maintainability requirements that apply to maintenance in the planned maintenance and support environment. Examples are as follows:
a) Time (e.g., mean and maximum downtime, reaction time, turnaround time, mean and maximum times to repair, mean time between maintenance actions)
b) Rate (e.g., maintenance staff hours per specific maintenance action, operational ready rate, maintenance time per operating hour, frequency of preventative maintenance)
c) Maintenance complexity (e.g., number of people and skill levels, variety of support equipment, removing/replacing/repairing components)
d) Maintenance action indices (e.g., maintenance costs per operating hour, staff hours per overhaul)
e) Accessibility to components within systems and to parts within components
Reliability — Specify the system reliability requirements in quantitative terms, including the conditions under which the reliability requirements are to be met. This may also include the reliability apportionment model to support allocation of reliability values assigned to system functions for their share in achieving desired system reliability.
System modes and states — If the system can exist in various modes or states define these and, as appropriate, use diagrams.
Physical requirements — Include constraints on weight, volume and dimension. Include the construction characteristics of where the system will be installed, requirements for materials to be used in the item or service covered by this specification, and requirements covering nameplates and system markings, interchangeability of equipment, and workmanship.
Adaptability requirements — Define requirements for growth, expansion, capability, and contraction. For example, if the system will require future network bandwidth, the applicable hardware should be specified with extra card slots to accommodate new network cards as demand increases.
Environmental conditions — Include environmental conditions to be encountered by the system. The following areas should be addressed: natural environment (e.g., wind, rain, temperature, flora, fauna, fungus, mold, sand, salt spray, dust, radiation, chemical, and immersion); induced environment (e.g., motion, shock, noise, electromagnetic, thermal); electromagnetic signal environment; self-induced environment (e.g., motion, shock, noise, electromagnetic, thermal); threat; and cooperative environment. Consideration should also be given to legal/regulatory, political, economic, social, and business environment.
System security — Define the system security requirements related to both the facility that houses the system and operational security requirements of the system itself. One example of security requirements might be to specify the security and privacy requirements, including access limitations to the system, such as existence of log-on procedures and passwords, and of data protection and recovery methods. This could include the factors that would protect the system from accidental or malicious access, use, modification, destruction, or disclosure. Especially in safety-critical embedded systems this might incorporate a distributed log or history of data sets, the assignment of certain functions to different single systems, or the restriction of communications between some areas of the system.
Information management — Define the requirements for the system’s management of information that it receives, generates, or exports. Examples include types and amounts of information the system is required to receive and store, any proprietary or other protections levied on the information the system deals with, and what backup and archiving requirements exist for the information.
Policies and regulations — Detail any relevant organizational policies that will affect the operation or performance of the system as well as any relevant external regulatory requirements, or constraints imposed by normal business practices. Examples of requirements include multilingual support, labour policies, protection of personnel information, and reports to a regulatory agency. Specify health and safety criteria, including those basic to the design of the system, with respect to equipment characteristics, methods of operation, and environmental influences such as toxic systems and electromagnetic radiation.
System life cycle sustainment — Outline quality activities, such as review, and measurement collection and analysis, to help realize a quality system. Life cycle sustainment also includes provision of facilities needed to provide operational- and depotlevel support, spares, sourcing and supply, provisioning, technical documentation and data, support-personnel training, initial cadre training and initial contractor-logistics support.
Packaging, handling, shipping and transportation — Define requirements imposed on the system to ensure that it can be packaged, handled, shipped and transported within its intended operational context.

Software Requirement

Specific requirements — Specify all of the software requirements to a level of detail sufficient to enable designers to design a software system to satisfy those requirements.
External interfaces — Define all inputs into and outputs from the software system. The description should complement the interface descriptions in 9.5.3.3.1 through 9.5.3.3.5, and should not repeat information there. Each interface defined should include the following content:
a) Name of item;
b) Description of purpose;
c) Source of input or destination of output;
d) Valid range, accuracy, and/or tolerance;
e) Units of measure;
f) Timing;
g) Relationships to other inputs/outputs;
h) Screen formats/organization;
i) Window formats/organization;
j) Data formats;
k) Command formats;
l) Endmessages.
Functions — Define the fundamental actions that have to take place in the software in accepting and processing the inputs and in processing and generating the outputs, including
a) Validity checks on the inputs
b) Exact sequence of operations
c) Responses to abnormal situations, including
1) Overflow
2) Communication facilities
3) Error handling and recovery
d) Effect of parameters
e) Relationship of outputs to inputs, including
1) Input/output sequences
2) Formulas for input to output conversion
It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does not imply that the software design will also be partitioned that way.
Usability requirements — Define usability (quality in use) requirements. Usability requirements and objectives for the software system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use.
Performance requirements — Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole. Static numerical requirements may include the following:
a) The number of terminals to be supported;
b) The number of simultaneous users to be supported;
c) Amount and type of information to be handled.
Static numerical requirements are sometimes identified under a separate section entitled Capacity.
Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.
The performance requirements should be stated in measurable terms. For example, 95 % of the transactions shall be processed in less than 1 second. rather than, An operator shall not have to wait for the transaction to complete.
Logical database requirements — Specify the logical requirements for any information that is to be placed into a database, including:
a) Types of information used by various functions;
b) Frequency of use;
c) Accessing capabilities;
d) Data entities and their relationships;
e) Integrity constraints;
f) Data retention requirements.
Design constraints — Specify constraints on the system design imposed by external standards, regulatory requirements, or project limitations.
Standards compliance — Specify the requirements derived from existing standards or regulations, including:
a) Report format;
b) Data naming;
c) Accounting procedures;
d) Audit tracing.
For example, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum regulatory or financial standards. An audit trace requirement may, for example, state that all changes to a payroll database shall be recorded in a trace file with before and after values.
Software system attributes — Specify the required attributes of the software product. The following is a partial list of examples:
a) Reliability — Specify the factors required to establish the required reliability of the software system at time of delivery.
b) Availability — Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart.
c) Security — Specify the requirements to protect the software from accidental or malicious access, use modification, destruction, or disclosure. Specific requirements in this area could include the need to:
1) Utilize certain cryptographic techniques;
2) Keep specific log or history data sets;
3) Assign certain functions to different modules;
4) Restrict communications between some areas of the program;
5) Check data integrity for critical variables;
6) Assure data privacy.
d) Maintainability — Specify attributes of software that relate to the ease of maintenance of the software itself. These may include requirements for certain modularity, interfaces, or complexity limitation. Requirements should not be placed here just because they are thought to be good design practices.
e) Portability — Specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems, including:
1) Percentage of elements with host-dependent code;
2) Percentage of code that is host dependent;
3) Use of a proven portable language;
4) Use of a particular compiler or language subset;
5) Use of a particular operating system.

Методы сбора требований

• Structured workshops with brainstorming — Структурированные семинары с мозговым штурмом
• Interviews, questionnaires — Интервью, анкеты
• Observation of environment or work patterns (e.g., time and motion studies) — Наблюдение за окружающей средой или рабочими шаблонами (например, исследование времени и движения)
• Technical documentation review — Обзор технической документации
• Market analysis or competitive system assessment — Анализ рынка или оценка конкурентности системы
• Simulations, prototyping, modelling — Симуляция, прототипирование, моделирование
• Benchmarking processes and systems — Бенчмаркинг процессов и систем
• Organizational analysis techniques (e.g., Strength – Weakness – Opportunity — Threat analysis, product portfolio) — Метод организационного анализа (например, SWOT-анализ, анализ портфеля продуктов)