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

Начало

Так или иначе, любое ПО нацелено на решение какой-либо одной или нескольких задач. Если немного переформулировать, то слово “задача” можно заменить на “проблема”. Поэтому начинать писать требования ПО следует с постановки проблемы или ее описания, если другими словами.
Если задача большая, то мнения нескольких заинтересованных в разработке этого ПО лиц могут расходится относительно того, на решение какой задачи преимущественно нацелена программа.
В составлении описании проблемы Вам может пригодиться следующий план:

1. Краткое описание проблемы
2. Перечисление лиц, на которых проблема воздействует
3. Описание воздействия
4. Предлагаемое решение
5. Список преимуществ этого решения

Предположим, что наша система – это обычный сайт компании с формой заказа товаров. До того, как у компании появился сайт, все заказы добавлялись в базу вручную сотрудниками компании.
Тогда краткое описание может выглядеть примерно так: “Система автоматизирует оформление заказа покупателем. “
Перечисление лиц в данном случае будет следующим: Покупатели; сотрудник отдела продаж, добавляющий заказы в базу, руководитель отдела.
Описание воздействия: Клиенты компании теперь могут оставлять заказы просто сделав пару кликов на сайте. Сотрудники компании освобождаются от необходимости добавлять заказы вручную – сайт сам все заносит в базу.
Предлагаемое решение: Сделать сайт в интернете с формой заказа товаров.
Список преимуществ: Снижение нагрузки на отдел продаж. Уменьшение числа ошибок при добавлении заказов. Возможность привлечения новых клиентов.

Границы системы

После того, как задача определена, и приоритеты расставлены, можно переходить к самой системе. Но прежде чем касаться деталей, необходимо определить границы системы, т.е. что относится к системе и что к ней не относится. Иначе можно запросто (касается больших систем) сделать лишнего и превысить допустимый бюджет и сроки.
Границы системы лучше всего изображать в виде UML диаграмм.
Так будет выглядеть наша диаграмма:

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

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

1. Экономические (ограничения бюджета тут все понятно)
2. Политические (особенности организации компании – разработчика ПО)
3. Технические (ограничения в используемых технологиях, платформах)
4. Системные (вопросы интеграции нашей системы с другими)
5. Эксплуатационные (Стандарты, требования безопасности)
6. График и ресурсы (сроки выполнения задач, доступные ресурсы)

С ограничениями я думаю, проблем не будет. А после них… А что делать после определения ограничений я напишу в одном из следующих постов.