ИСТОРИЯ СБОРА ТРЕБОВАНИЙ В IT

АННОТАЦИЯ

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

Ключевые слова: требования к программному обеспечению, сбор требований, IT-проект, разработка ПО, заказчик, пользовательские требования

Если посмотреть на современные IT-проекты, может показаться, что сбор требований существовал всегда. Перед началом разработки проводятся встречи с заказчиком, обсуждаются задачи будущей системы и согласовываются её функции. Однако в первые десятилетия существования программного обеспечения ничего подобного не было.

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

Карл Вигерс в книге «Разработка требований к программному обеспечению» обращает внимание на то, что по мере роста сложности программ стали проявляться серьёзные организационные проблемы. Заказчики ожидали один результат, а разработчики представляли его совершенно иначе. Пока программа была небольшой, подобные расхождения ещё удавалось исправить. Но когда проекты начали занимать месяцы и годы работы, цена ошибки резко возросла [1, с. 3].

Особенно заметной ситуация стала в 1960-х годах. Компьютеры начали использоваться не только в научной среде, но и в бизнесе. Организации стремились автоматизировать бухгалтерский учёт, управление запасами, обработку документов и другие процессы. Вместе с этим росли требования к программным системам. Простого разговора между руководителем и программистом уже было недостаточно.

Иногда выяснялось, что готовая система решает совсем не ту проблему, ради которой создавалась. Программа могла работать без ошибок, но сотрудники компании всё равно не получали ожидаемого результата. Причина часто заключалась не в коде, а в неверном понимании задачи на начальном этапе.

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

Многие идеи, которые сегодня кажутся очевидными, появились именно из-за неудач прошлых лет. Каждая сорванная разработка подтверждала одну закономерность: чем меньше внимания уделялось первоначальному выяснению потребностей, тем больше проблем возникало в дальнейшем. Исправление недочётов после завершения проекта обходилось значительно дороже, чем их предотвращение на раннем этапе.

Со временем требования начали фиксировать документально. Это позволило избежать ситуаций, когда разные участники проекта по-разному трактуют одни и те же договорённости. Документ становился ориентиром, к которому можно было обратиться в спорной ситуации. Благодаря этому взаимодействие между заказчиком и исполнителем становилось более понятным и предсказуемым.

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

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

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

Список литературы:

1. Вигерс К., Битти Дж. Разработка требований к программному обеспечению. — 3-е изд. — СПб.: БХВ-Петербург, 2016. — 736 с.