АЛГОРИТМ РАЗРАБОТКИ ТРЕБОВАНИЙ ПРОГРАММНОГО ПРОЕКТА

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

Требования являются основой для любого проекта. Они определяют те потребности «заинтересованных сторон» - пользователей, потребителей, поставщиков, разработчиков и самого бизнеса, - которые являются для них необходимыми, а также тот функционал, которым система должна впоследствии обладать, чтобы удовлетворить эти потребности [5].

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

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

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

Для внедрения системы важен и третий уровень – функциональный или системный, на котором осуществляется формализация требований пользователей. Каждое требование пользователя может стать основой для формулирования нескольких системных требований [1].

Для того чтобы стать всем понятными, требования в большинстве случаев пишутся на «обычном» языке, что привносит проблемы другого рода: необходимость полностью и однозначно обозначить проблемы и зафиксировать потребности без использования профессионального жаргона или предварительных договоренностей – является весьма сложной задачей.

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

Процесс формирования требований и управления ими уже давно признается необходимым действием на пути к успешному созданию сложных систем и изделий или успешному завершению проектов, связанных с программными разработками. Любая организация нуждается в правильном формировании и эффективном управлении требованиями, чтобы быть уверенной в том, что конечный результат отвечает потребностям заказчика, соответствует техническому  заданию и что работа над проектом ведется в рамках выделенного бюджета и запланированных сроков. Не секрет, что результат плохо сформулированного даже одного требования может быть катастрофически разрушительным, потому что в этом случае срабатывает «эффект домино», который, в конечном итоге, приводит к результату, не соответствующему первичной потребности заказчика, требует дополнительного времени на переделку и, как следствие, ведет к значительным перерасходам бюджета. Более того, – известны случаи, когда неудовлетворительное требование являлось той причиной, которая вела к полной потере бизнеса, являлось причиной нанесения ущерба здоровью человека и даже приводило к смертельному исходу. Напротив, правильный процесс формирования требований и управления ими обеспечивают качественный конечный результат и высокий показатель возврата инвестиций [3].

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

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

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

После этого идут процессы сбора, классификации, приоритезации и анализа требований, а также процесс разрешения противоречий. Сбор требований - это процесс взаимодействия с лицами, формирующими требования. Во время этого  процесса продолжается анализ предметной области. На этапе классификации требований бесформенный набор требований преобразуется в логически связанные группы требований. Без сомнения, требования многочисленных лиц, занятых в процессе формирования требований, будут противоречивыми, поэтому на следующем этапе определяются и разрешаются противоречия такого рода. Кроме этого в любом наборе требований одни из них будут более важны, чем другие, поэтому на этапе приоритезации совместно с лицами, формирующими требования, определяются наиболее важные требования. На следующем этапе – этапе анализа – определяется полнота, последовательность и непротиворечивость требований. После того как все требования собраны и проанализированы происходит процесс спецификации системных требований.

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

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

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

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

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

4.   Проверка на выполнимость. На основе знания существующих технологий требования должны быть проверены на возможность их реального выполнения. Здесь также проверяются возможности финансирования и график разработки системы.

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

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

1 Анализ проблем изменения спецификации. Процесс начинается с определения проблем  в требованиях или с прямого предложения внесения изменений. На этой стадии проблема или предложенные изменения анализируются для проверки их обоснованности. Затем могут быть сделаны более определенные предложения относительно изменений в требованиях.

2.    Анализ изменений  и  расчет их стоимости. Эффект от внесения предложенного изменения оценивается с использованием оперативного контроля. Стоимость изменений оценивается двумя показателями: стоимостью внесения изменения в спецификацию и стоимостью внесения изменений в структуру системы и непосредственно в программный код. По окончании этого этапа принимается решение, продолжать или нет внесение изменений в систему.

3.     Реализация изменений. Реализация изменений в системной спецификации, структуре системы и программном коде [4].

С учетом всего вышесказанного блок-схема алгоритма разработки требований программного проекта будет иметь вид, представленный на рисунке (Рисунок 1).

1.     Кравченко Т.К. Управление требованиями при реализации ИТ-проектов. Междисциплинарный научно- практический журнал НИУ ВШЭ «Бизнес-информатика» №3(25). Москва – 2013г.

2.     Корячко  В.П.,  Таганов  А.И.,  Таганов  Р.А.  Методологические  основы  разработки  и  управления требованиями к программным системам. М.: Горячая линия – Телеком, 2009. -224 с

3.     Тавассоли Д. Управление требованиями. Десять шагов на пути к совершенству. IBM, 2009.

4.     Соммервилл И. Инженерия программного обеспечения, 6-е издание.: Пер. с англ. – М.: Издательский дом "Вильямс", 2002. – 624 с.

5.     Халл Э., Джексон К., Дик Д. Разработка и управление требованиями. Практическое руководство пользователя (Второе издание) Telelogic, 2005 -229 с.