Раздел 2. Фазы жизненного цикла программного изделия

Глава 6. Определение требований пользователя и требований к программному изделию

Требования пользователя

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

Основной вид деятельности в этой фазе — сбор требований пользователей и их тщательное документирование в ДТП. Здесь подготавливается и план работ следующей фазы.

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

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

Все требования пользователей делятся на:

1. Требования, отражающие возможности системы, реализация которых обеспечивает решение поставленной проблемы.

2. Требования, определяющие ограничения на способы и пути решения проблемы или на пути достижения поставленной цели.

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

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

Каждое требование пользователя должно описываться следую­щими атрибутами:

1.Идентификатор, позволяющий проследить выпол­нение каждого установленного требования через все фазы ЖЦПИ.

2. Уровень важности, устанавливаемый в соответ­ствии со шкалой рейтингов, принятой пользователем для разраба­тываемого изделия.

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

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

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

6. Проверяемость требования, т.е. каждое требование должно поддаваться проверке выполнения. Это определяет возмож­ность контроля того, что требование включено в проект и может быть реализовано программными средствами и протестировано.

7.Ясность формулировки, означающая определенность и однозначность требования и отсутствие какой-либо неопределен­ности.

Требования к программному изделию

Вторая фаза ЖЦПИ — фаза определения требований к про­граммному изделию, которая является фазой "анализа проблемы". Главной целью этой фазы выступает разработка полной, непроти­воречивой и корректной совокупности требований к программному обеспечению на основе всестороннего изучения требований пользо­вателя. За выработку требований отвечает разработчик. В качестве участников этой фазы должны привлекаться пользователи, инжене­ры-программисты, специалисты по техническим средствам, а также обслуживающий персонал. Ответственным за выполнение работы, как правило, назначается системный аналитик. Руководитель про­екта организует взаимные консультации и обсуждения, поскольку участники обсуждений могут иметь разное представление о конеч­ном продукте, и их взгляды должны синтезироваться в четкие и не­противоречивые формулировки требований.

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

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

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