Основные положения Требование - это некоторое свойство программного обеспечения, которым должна обладать система или её компонент, чтобы удовлетворять требованиям контракта, стандарта, спецификации либо иной формальной документации. Требование - 1) условия или возможности, необходимые пользователю для решения проблем или достижения целей; 2) условия или возможности, которыми должна обладать система или системные компоненты, чтобы выполнить контракт или удовлетворять стандартам, спецификациям или другим формальным документам; 3) документирование представления условий или возможностей для пунктов 1) и 2). Классификация требований Для удобства работы и управления требованиями их классифицируют. Классификация требований по определённым типам позволяет разделить требования по уровням абстракции, природе, назначению и другим признакам. Требования: к продукту: в своей основе - то, что формулирует заказчик, цель, которую он преследует (получить хороший конечный продукт, т. е. функциональный и удобный в эксплуатации), поэтому требования к продукту являются основополагающим классом требований; в дальнейшем мы будем более подробно рассматривать и классифицироать этот тип требований; к проекту (процессу): требования к тому, как разработчик будет выполнять работы по созданию целевой системы. Бизнес-требования: описывают высокоуровневые цели организации или заказчиков системы. Как правило, их формулируют те, кто финансирует проект, либо покупатели системы, менеджеры пользователей, отдел маркетинга и т. д. Бизнес-требования относятся к наивысшему уровню абстракции требований и обычно характеризуют цели организации, её миссию в решении проблем бизнеса. На практике иногда аналитики пренебрегают бизнес-требованиями, что в итоге может привести к созданию системы, которая будет удобна в эксплуатации, но не решает задачи бизнеса. Ключевые возможности (характеристики продукта) Ключевая возможность - это набор логически связанных функциональных и нефункциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-требованиям. В области коммерческого программного обеспечения ключевая возможность представляет узнаваемую всеми заинтересованными лицами группу требований, которые важны при принятии решения о покупке, т. е. это фактически элемент маркетингового списка в описании продукта. В отличие от бизнес-требований, которые описывают цели организации, ключевые возможности на высоком уровне абстракции описывают функциональность и характеристики качества разрабатываемой информационной системы. Пользовательские требования: описывают цели и задачи, которые пользователи смогут решать при помощи системы, т. е. они описывают систему с точки зрения конечного пользователя, т. е. человека, непосредственно работающего с системой. На практике часто пользовательские требования идут в разрез с бизнес-требованиями, например, заказчик хочет получить дешёвую систему, а пользователь желает работать с удобным пользовательским интерфейсом, реализация которого может дорого обойтись заказчику. Подобные противоречия должен идентифицировать и решать системный аналитик. Функциональные требования: определяют функциональность программного обеспечения, которую разработчик должен обеспечить, чтобы пользователи смогли выполнять свои задачи в рамках пользовательских и бизнес-требований. Иногда эти требования называют требованиями поведения, поскольку они описывают детальное поведение системы, выполняемые ею действия и отклики, а также информацию, которой система будет управлять. Поскольку функциональные требования являются низкоуровневым описанием действий системы, они часто реализуются на уровне методов класса и данных, которые обрабатываются в конкретном методе. Характеристики качества: описывают цели и аттрибуты качества разрабатываемой системы. Аттрибуты качества системы представляют собой дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков. К таким характеристикам относятся: лёгкость и простота использования, производительность, удобство эксплуатации и технического обслуживания, надёжность и устойчивость к сбоям, взаимодействие системы с внешним миром, расширяемость, требования к пользовательским и программным интерфейсам. Ограничения: к требованиям данного типа относятся технические ограничения и бизнес-правила. Технические ограничения касаются выбора способа разработки, внешнего вида и структуры продукта, используемых языков программирования, технологий и платформ. Бизнес-правила включают корпоративные политки, правительственные постановления, промышеленные стандарты, вычислительные алгоритмы и т. д. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности. Иерархия требований [Бизнес-требования] | v [Ключевые возможности (характеристики продукта)] | | v v [Требования пользователя]< [Характеристики качества] | \ | v -------\ v [Функциональные требования] [Ограничения] Системные требования и требования к ПО Существует две основные трактовки понятия "системные требования". Виргес формулирует этот термин следующим образом: высокоуровневые требования к продукту, который содержит множество подсистем, т. е. это требования к системе. При этом под системой понимается программная, программно-апаратная либо человеко-машинная система. В практике компьютерной инженерии бытует другой, более узкий контекст: под системными требованиями понимаются требования, выдвигаемые прикладной программной системой, в частности, информационной, к среде своего функционирования (системной или аппаратной). Управление требованиями В качестве основы управления качеством требований к ПО предлагается использовать 6 уровней зрелости процесса управления требованиями. Каждый последующий уровень процесса управления качеством требований. Каждый последующий уровень полностью включает в себя предшествующий. +----------+ +----------------+ +------------------+ +--------------------+ +-----------------+ +-------------------+ |Уровень 0 | |Уровень 1 | |Уровень 2 | |Уровень 3 | |Уровень 4 | |Уровень 5 | |Отсутствие+->|Документирование+->|Документирование +->|Организация тр-ий +->|Трассировка тр-ий+->|Комплексность тр-й | |требований| |требований | |требований | |-план управления | |-семинар | |-Трассировка на | | | |-интервью | |-Анкеты | |-Атрибуты | |-Иерархий тр-й | | элементы | | | |-Анализ | |-Мозговой штурм | |-Типы | |-Отношения между | |-Показатели тр-й | | | | документов | |-Уточнение тр-й | |-Варианты использов.| | требованиями | |-количественная | | | |-создание | |-Шаблон документов| |-Прототипы | |-Трассировка тр-й| | оценка тр-й | | | | документов | |-Коллективная | |-Структуризация | |-Анализ влияния | |-интеграция со | | | |-Экспертная | | проверка | |-Опред. значений | |-Анализ сферы | | средой разработки | | | | оценка | |-Документ. | | атрибутов | | деятельности | |-система управления| | | | | | замечаний | |-Шаблоны требов. | |-Типовые решения | | изменениями | | | | | |-БД тр-й | |-Модели тр-й | | тр-й | | | | | | | |-Управление | |-Контрольные листы | | | | | | | | | | версиями | |-рекомендации | | | | | +----------+ +----------------+ +------------------+ +--------------------+ +-----------------+ +-------------------+ 0: команда разработчиков уверена в том, какой продукт следует реализовать; члены команды разработчиков считают, что они экономят время, пропуская этапы задачи выявления и документирования требований 1: цель уровня заключается в получении документов, описывающих требования. На основе документов в дальнейшем разрабатываются сценарии тестирования, архитектура ПО, руководства пользователей и другая проектная документация