Требования пользователя
Первая фаза жизненного цикла связана с подробным определением решаемой проблемы. Цель этой фазы — сформулировать задачу, которая должна быть выполнена с использованием компьютера, а также определить, что предполагается получить в результате автоматизации. Программное изделие может разрабатываться как по индивидуальному заказу в соответствии с требованиями заказчика, так и для широкого коммерческого применения, в последнем случае роль заказчика выполняет рынок, требования которого обязан всесторонне учитывать разработчик. Поэтому понятие заказчика, или пользователя разрабатываемого изделия, будем трактовать, исходя из этого положения. Считается, что ответственным за определение требований является пользователь (заказчик), и в этой работе ему должны помогать инженеры, знающие компьютерные технологии. Выходным результатом работ на этой фазе служит документ Требования пользователя (ДТП), который утверждается после всестороннего критического обзора и рассмотрения.
Основной вид деятельности в этой фазе — сбор требований пользователей и их тщательное документирование в ДТП. Здесь подготавливается и план работ следующей фазы.
Сбор требований пользователя к будущей автоматизированной системе осуществляется путем обследования существующей технологии обработки данных (обычно путем изучения документопото-ков), путем опроса специалистов, специально проводимыми интервью с пользователями. Поскольку, по мере сбора, требования могут изменяться, уточняться и добавляться, вся эта деятельность в целом представляет собой итеративный процесс, предполагающий многократные повторения, необходимые для достижения максимальной детализации, четкости и однозначности в формулировке каждого требования, а также достижения полноты охвата всех требований пользователя.
Первым шагом в определении требований пользователя должно быть уяснение операционной обстановки, т.е. должна быть выработана четкая картина реальной обстановки, в которой будет функционировать разрабатываемый программный продукт.
Повествовательное описание окружающей обстановки и условий работы целе сообразно дополнить схемами потоков документов, указав в потоках связи с внешними системами по отношению к рассматриваемой.
Все требования пользователей делятся на:
1. Требования, отражающие возможности системы, реализация которых обеспечивает решение поставленной проблемы.
2. Требования, определяющие ограничения на способы и пути решения проблемы или на пути достижения поставленной цели.
Требования первой группы описывают функции и операции, необходимые пользователю. Важную часть здесь составляют атрибуты точности. Во многих случаях появляются временные и пространственные требования, которые целесообразно представить в виде последовательности выполняемых операций, в виде регламента подготовки выходных документов с указанием периодичности и сроков их выдачи с привязкой к соответствующим документам.
Требования-ограничения могут включать требования использования определенных форм документов для взаимодействия с другими системами, стандартных описаний данных, форматов, а также требования применения определенных компьютеров, операционных систем и т.п. Для диалоговых систем пользователь может пожелать, например, использовать специфические экранные формы или шаблоны, специальные средства помощи, создаваемые программными средствами. Ограничения могут включать и требования качественного типа. Защита данных от несанкционированного доступа, приспособленность изделия к адаптации, переносимость в другие операционные среды — все это может быть отнесено к требованиям-ограничениям. При этом пользователь должен подробно описать потери, порождаемые нарушением подобных требований, чтобы разработчик мог критически оценить каждое требование.
Каждое требование пользователя должно описываться следующими атрибутами:
1.Идентификатор, позволяющий проследить выполнение каждого установленного требования через все фазы ЖЦПИ.
2. Уровень важности, устанавливаемый в соответствии со шкалой рейтингов, принятой пользователем для разрабатываемого изделия.
3. Стабильность требования, указывающая степень его постоянства на протяжении ЖЦПИ. При этом должны быть отмечены требования, которые могут быть изменены в результате получения в процессе проектирования новой информации или в результате накопления опыта эксплуатации.
4. Приоритет, указывающий определенную временную последовательность в реализации различных требований, особенно для развивающихся систем, когда, например, отдельные функциональные подсистемы могут разрабатываться достаточно независимо и последовательно.
5. Источник возникновения требования должен указываться либо в виде ссылки на конкретный внешний документ, либо на пользователя (группу пользователей), который установил это требование.
6. Проверяемость требования, т.е. каждое требование должно поддаваться проверке выполнения. Это определяет возможность контроля того, что требование включено в проект и может быть реализовано программными средствами и протестировано.
7.Ясность формулировки, означающая определенность и однозначность требования и отсутствие какой-либо неопределенности.
