Updated

ru/security/password.md

@@ -12,3 +12,4 @@ lang-ref: security-password
 содержанием оного будет отправлено письмом на настроенные ящики для получения. С
 точки зрения безопасности увеличивать количество мест, где хранят данные по
 доступам, не стоит и, соответственно, подобные уведомления лучше не рассылать.
+Это же касается и уведомлений по другим направлениям, помимо рассылки писем.

ru/term/custom.md

@@ -15,7 +15,7 @@ lang-ref: term-custom
 - разработчик
 - [описыватель](/ru/term/writer)
 
-## Составление требований
+## Составление требований (задания на разработку (ЗНР))
 
 Первоначально постановщик обсуждает с заказчиком и при необходимости с
 разработчиком, с последующей передачей разработчику на выполнение.
@@ -28,13 +28,56 @@ lang-ref: term-custom
 - требования на разработку
 - руководство по использованию (необязательно)
 
-## Требования на разработку
+## Составляющие ЗНР
 
-Уже в ходе разработки могут быть изменены, а обновлённое описание требований
-следует выпустить отдельно.
+- Лица, принимающие участия в составлении требований.
+- Среда разработки:
+  - Доступа к ней.
+  - Настройка оной.
+- Поддерживаемые выпуски [обозревателей](/ru/term/browser)
+- Описание разрабатываемого решения (РР)
+
+### Описание разрабатываемого решения (РР)
+
+В ЗНР требуемое действие, пошаговость, случаи использования и т.п
+(расписанные по шагам), должны быть описаны ровно один раз. Все остальные
+упоминания оных должны лишь ссылаться на них.
+
+Это позволит постановщикам избежать путаницы, когда поправив в одном месте
+требование они забывают исправить это в другом. В случае же единственного
+описания РР этого можно избежать.
+
+Разработчикам же:
+
+- проще давать оценку сходу, ибо разное описание одного и того же в разных
+  разделах выглядит как разные решения, а на деле являются одним;
+- проще сверять что всё выполнено согласно ЗНР, не переключаясь между описаниями
+  одного и того же на разных страницах.
+
+### Особенности для работ по ВС
 
-## Особенности описаний требований к доработкам по Радиант
+- Доступа к сторонним площадкам, к которым необходимо отправлять запросы.
+- Рабочие примеры запросов REST/SOAP к сторонним службам.
+  - В случае REST запросов уточнить необходимость в определённом порядке полей.
 
-Так как зачастую доработки касаются изменения работы страниц, то желательно
-указать список [обозревателей](/ru/term/browser) и их выпуски, которые стоит
-учитывать (поддерживать) при разработке.
+### Особенности содержания ЗНР для разработчиков
+
+Все сторонние сведения о работе доработки, напрямую не связанные
+с разрабатываемым решением, в итоговом ЗНР для разработчиков лучше указывать
+в сжатом виде, либо не указывать вовсе, поместив оные в отдельную запись.
+
+Выгоды:
+
+1. меньше времени требуется на написание такого ЗНР;
+2. меньше времени требуется на чтение такого ЗНР и соответственно на оценку;
+3. легче сверять выполненные шаги разработчикам с описанием, где нет лишнего;
+4. легче проверяющему проверять пользовательские случаи.
+
+Итоговое ЗНР следует выдавать в неизменяемом виде, например, в виде .pdf, дабы
+исключить случаи исправления требований на ходу, без уведомления разработчика,
+после начала разработки.
+
+## Изменение требований
+
+Уже в ходе разработки могут быть изменены, а обновлённое описание требований
+следует выпустить отдельно.