Проектирование ИС

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

      INCOSE (International Council on Systems Engineering) дает более  детальное определение системы: "комбинация взаимодействующих  элементов, созданная для достижения  определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы". Таким образом, происходит разделение между системными требованиями, как обобщающему понятию и требованиями к программному обеспечению, как выделенному подмножеству системных требований, направленных исключительно на программные компоненты системы. Этот же подход прослеживается в стандарте ГОСТ Р ИСО/МЭК 12207/99: работы, связанные с системой в целом и с программным обеспечением выделяются в отдельные группы в целях удобства оперирования.

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

1.2.4. Функциональные, нефункциональные требования и характеристики продукта

      Функциональные  требования регламентируют функционирование или поведение системы. Они отвечают на вопрос "что должна делать система" в тех или иных ситуациях. Функциональные требования определяют основной "фронт работ" Разработчика, и устанавливают цели, задачи и сервисы, предоставляемые системой Заказчику.

      Функциональные  требования записываются посредством предписывающих правил: "система должна позволять кладовщику формировать приходные и расходные накладные". Другим способом являются так называемые варианты использования - популярный и весьма продуктивный способ представления требований.

      Нефункциональные  требования, соответственно, регламентируют внутренние и внешние условия или атрибуты функционирования системы. К. Вигерс выделяет следующие основные группы нефункциональных требований:

• Внешние интерфейсы;
• Атрибуты качества;
• Ограничения.

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

      Основные  атрибуты качества:

• Применимость;
• Надежность;
• Производительность;
• Эксплуатационная пригодность.

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

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

      Существует  и более общий взгляд на данное понятие: "features могут быть как относящимися к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта".

      С точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными.

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

1.2.5. Классификация Rational Unified Process (RUP)

      В спецификациях RUP при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990.

      Акроним FURPS обозначает следующие категории  требований:

• Functionality (Функциональность)
• Usability (Применимость)
• Reliability (Надежность)
• Performance (Производительность)
• Supportability (эксплуатационная пригодность).

      Символ "+" расширяет FURPS-модель, добавляя к ней:

• ограничения проекта;
• требования выполнения;
• требования к интерфейсу;
• физические требования.

      Кроме того, в спецификациях RUP выделяются такие категории требований, как

• требования, указывающие на необходимость согласованности с некоторыми нормативно-правовыми актами;
• требования к лицензированию;
• требования к документированию.

1.3. Свойства требований

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

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

• полнота;
• ясность;
• корректность;
• согласованность;
• верифицируемость;
• необходимость;
• полезность при эксплуатации;
• осуществимость;
• модифицируемость;
• трассируемость;
• упорядоченность по важности и стабильности;
• наличие количественной метрики.

      Рассмотрим  указанные выше свойства подробнее.

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

      Тем не менее, требование полноты предъявляется  к требованиям, формулируемым к  системе. Надо понимать, что данное требование - это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.

      Требование  полноты можно рассматривать  в двух аспектах: полнота отдельного требования и полнота системы  требований.

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

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

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

      Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований может быть достигнута в процессе консультаций, в ходе которых происходит "выравнивание тезаурусов" совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.

      К.Вигерс дает следующий совет по повышению ясности документов: "Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям".

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

      Корректность  и согласованность. Корректность - одно из важнейших свойств требований. К. Вигерс вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определенной степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задает дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит - как минимум одно из них некорректно. В иерархии требований можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования - требованиям пользователя.

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

      Необходимость и полезность при  эксплуатации одни из самых субъективных и трудно проверяемых свойств требований.

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