Доработка

Доработка – любые изменения в работе Радиант, направленные на решение задач, не предусмотренных изначально.

Описания к требованиям по доработке могут составлять:

Составление требований (задания на разработку (ЗНР))

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

Также на встречах с заказчиком может присутствовать и описыватель, который обсуждаемые требования опишет в виде руководства по использованию.

Таким образом, итого встреч (обсуждений) с заказчиком будут следующие описания:

  • требования на разработку
  • руководство по использованию (необязательно)

Составляющие ЗНР

  • Лица, принимающие участия в составлении требований.
  • Среда разработки:
    • Доступа к ней.
    • Настройка оной.
  • Поддерживаемые выпуски обозревателей
  • Описание разрабатываемого решения (РР)

Описание разрабатываемого решения (РР)

В ЗНР требуемое действие, пошаговость, случаи использования и т.п (расписанные по шагам), должны быть описаны ровно один раз. Все остальные упоминания оных должны лишь ссылаться на них.

Это позволит постановщикам избежать путаницы, когда поправив в одном месте требование они забывают исправить это в другом. В случае же единственного описания РР этого можно избежать.

Разработчикам же:

  • проще давать оценку сходу, ибо разное описание одного и того же в разных разделах выглядит как разные решения, а на деле являются одним;
  • проще сверять что всё выполнено согласно ЗНР, не переключаясь между описаниями одного и того же на разных страницах.

Особенности для работ по ВС

  • Доступа к сторонним площадкам, к которым необходимо отправлять запросы.
  • Рабочие примеры запросов REST/SOAP к сторонним службам.
    • В случае REST запросов уточнить необходимость в определённом порядке полей.

Особенности содержания ЗНР для разработчиков

Все сторонние сведения о работе доработки, напрямую не связанные с разрабатываемым решением, в итоговом ЗНР для разработчиков лучше указывать в сжатом виде, либо не указывать вовсе, поместив оные в отдельную запись.

Выгоды:

  1. меньше времени требуется на написание такого ЗНР;
  2. меньше времени требуется на чтение такого ЗНР и соответственно на оценку;
  3. легче сверять выполненные шаги разработчикам с описанием, где нет лишнего;
  4. легче проверяющему проверять пользовательские случаи.

Итоговое ЗНР следует выдавать в неизменяемом виде, например, в виде .pdf, дабы исключить случаи исправления требований на ходу, без уведомления разработчика, после начала разработки.

Изменение требований

Уже в ходе разработки могут быть изменены, а обновлённое описание требований следует выпустить отдельно.