Разработка сложных программных изделий

       

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


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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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


Содержание раздела