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