Разработка требований
На этом этапе важно задокументировать все требования к
будущему программному обеспечению. Необходимо посвятить
достаточно времени обсуждению деталей проекта со всеми
заинтересованными сторонами. Все поступающие данные нужно
проанализировать и систематизировать. Важно также учесть все
технические ограничения, которые могут возникнуть на стороне
заказчика. Итогом данного этапа должно стать создание подробной
спецификации, отвечающей всем требованиям заказчика. Также
следует обратить внимание и на другие факторы, которые могут
затруднять процесс разработки. К ним относятся дедлайны,
установленные заказчиком, а также бюджетные ограничения.
Обратите внимание: чем больше информации о проекте вы
соберете, тем меньше времени потратите на исправление ошибок,
доработку проекта, пересмотры бюджета, обсуждения и решение
других вопросов.
Важной задачей является создание подробного
документа
видения (или образа) проекта
, который включает краткое описание
проекта, бизнес-цели, а также критерии успеха проекта, факторы
бизнес-рисков и описание конечного пользователя продукта.
Готовый документ необходимо передать на утверждение
заказчику, чтобы убедиться в том, что все поставленные требования
были учтены, а также чтобы проинформировать его о любых рисках,
которые могут возникнуть после релиза проекта.
После того, как все основные вопросы решены, рекомендуется
провести дополнительные обсуждения и интерактивные семинары со
всеми заинтересованными сторонами. Это поможет выявить какие-
либо неочевидные моменты, которые в дальнейшем могут стать
причиной внесения изменений в интерфейс приложения или
необходимости переписывания паттернов кода. Данный этап может
37
также включать заполнение анкет, рассмотрение кейсов, мозговой
штурм и т.д.
Многие проекты заходят в тупик из-за дополнительных
требований, которые всплывают на стадии разработки. Поэтому очень
важно понимать начальные бизнес-цели и главную идею будущего
приложения.
Спецификация требований программного обеспечения (SRS)
описывает требования, которым должно отвечать создаваемое
программное
обеспечение.
Она
должна
быть
логичной,
последовательной, доступной и полной. Требования могут
выражаться в разных формах, например, в виде традиционных
утверждений долженствования (н-р, «Система Staff Manager должна
поддерживать следующие браузеры: Google Chrome, Apple Safari,
Mozilla Firefox, Opera, IE 8+») или в виде пользовательских историй
(н-р, «поскольку я являюсь менеджером, мне необходим доступ к
персональной информации всех сотрудников»).
Существует большое количество шаблонов спецификаций.
Выбор определенного шаблона зависит от специфики проекта. В
большинстве случаев, спецификация включает в себя описание
продукта,
классы
пользователей,
функциональные
и
нефункциональные требования к разрабатываемому программному
обеспечению. Иногда в шаблон также входит прототип. Главное —
сделать спецификацию понятной, лаконичной и полезной для
разработчиков.
Для создания прототипа вам необходимо выяснить следующее:
способ получения и обработки входящих данных для создания
необходимых данных на выходе;
форма, в которой должны быть представлены выходные
данные.
Мокапы (или прототипы) передаются UI/UX-дизайнерам,
которые превращают их в красочные шаблоны.
|