Постановка требований к программному обеспечению в компании Новтехпром

Здесь стоит обратить внимание на две вещи:

  • Выполнить удовлетворительно эту часть работы без активного участия заказчика невозможно.
  • Ошибки на данном этапе обходятся очень дорого в буквальном смысле.

Мы выработали некоторый порядок постановки требований, которого стараемся придерживаться.

Для относительно небольших проектов мы просто записываем требования со слов заказчика.

Для некоторых проектов может потребоваться несколько таких встреч с разными представителями заказчика.

Затем анализируем, уточняем и оформляем это либо как часть договора, либо в виде приложения к нему.

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

Основным результатом постановки требований является:

  • Ответ на вопрос, Какова главная цель проекта?
  • Список и краткое описание заинтересованных сторон. (То есть, все, кто имеет какое-то отношение к программе). А также:
    • Расположение пользователей программы.
    • Обстановка, в которой будут работать пользователи.
    • Оборудование, которое они будут использовать.
    • Ответы на вопросы, какую долю в их ежедневных обязанностях будет занимать работа с программой, какую работу помимо работы с программой они должны выполнять.
  • Понимание вариантов использования программы.
  • В какой программно-аппаратной среде предполагается развертывать создаваемое программное обеспечение.

Документация, связанная с требованиями, может включать следующие документы:

  • Описания и диаграммы бизнес-процессов.
  • Таблицы бизнес-правил и специальных терминов.
  • Видение. В данном документе описываются различные важные аспекты, связанные с разработкой проекта. Это может быть перечень и краткая характеристика заинтересованных сторон краткий анализ программ-аналогов, присутствующих на рынке, примерная оценка денежных затрат, времени на разработку, аргументирование обоснование целесообразности разработки (или, наоборот, нецелесообразности).
  • Начальный вариант списка всех вариантов использования программы (прецедентов) или диаграмма.
  • Полное, подробное описание 10% наиболее значимых прецедентов. Которое содержит набор сценариев в формате:
    • Действия пользователя
    • Реакция системы
    • Действия пользователя
    • Реакция системы
    • ..
    • и нефункциональные требования, связанные с данным прецедентом.
  • Начальный вариант дополнительной спецификации требований. Здесь описываются нефункциональные требования к программе, которые относятся ко всей программе в целом и не входят в описания прецедентов.
  • Общий план разработки.

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