2 с ЛЕКЦИЯ 1 Требования пользователя

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