Материал: u_lectures
Надежность,
Производительность,
Эксплуатационная пригодность, достаточно хорошо раскрыты в модели FURPS (см. ниже).
Ограничения [8] - формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, ...), которые, в свою очередь, могут относиться, например, к внешним интерфейсам (конец цитаты).
Характеристики продукта. К.Вигерс [8] формулирует характеристику, «фичу»
(feature), как набор логически связанных функциональных требований, которые обеспечивают возможности пользователя и удовлетворяют бизнес-цели.
Существует и более общий взгляд на данное понятие2: «features могут быть как относящимся к функциональным, так и к нефункциональным требованиям и могут изменяться от версии к версии продукта».
С.Орлик в [12] отмечает, что «с точки зрения инженерии требований, features являются самостоятельным артефактом, который может быть соотнесен как с функциональными требованиями, так и с нефункциональными».
Роль характеристик проявляется в первую очередь в области маркетинга: не всякий потенциальный потребитель продукта станет читать его функциональные описания, а набор ключевых характеристик, характеризующих конкурентные преимущества, можно сделать лаконичным и уместить на одной странице рекламной листовки, либо напечатать на компакт-диске.
Классификация RUP
В спецификациях Rational Unified Process при классификации требований используется модель FURPS+ со ссылкой на стандарт IEEE Std 610.12.1990 [7].
Акроним FURPS обозначает следующие категории требований:
Functionality (Функциональность)
Usability (Применимость)
Reliability (Надёжность)
Performance (Производительность)
Supportability (эксплуатационная пригодность). Символ «+» расширяет FURPS-модель, добавляя к ней:
ограничения проекта,
требования выполнения,
требования к интерфейсу,
физические требования,
часть из которых уже была рассмотрена выше.
Кроме того, в спецификациях RUP выделяются такие категории требований, как
требования, указывающие на необходимость согласованности с некоторыми юридическими и нормативными актами;
требования к лицензированию,
требования к документированию.
Методологии и стандарты, регламентирующие работу с требованиями
Среди основополагающих нормативных документов в области работы с требованиями можно выделить следующие.
1.Разработки IEEE:
IEEE 1362 “Concept of Operations Document”.
2 Kurt Bittner, Ian Spence. Use Case Modeling, 2002.
IEEE 1233 «Guide for Developing System Requirements Specifications».
IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»
IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.121990
IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004.
2.Отечественные ГОСТ:
ГОСТ 34.601-90. Информационная технология. Автоматизированные системы. Стадии создания.
ГОСТ 34.602-89. Информационная технология. Техническое задание на создание автоматизированной системы
ГОСТ 19.201-78. Единая система программной документации. Техническое задание. Требования к содержанию и оформлению.
Литература к лекции
1.Макарова Н.В. Информатика: Учебник. - М.: Финансы и статистика, 2003. - 768 с.
2.ERP системы. Современное планирование и управление ресурсами предприятия. Выбор, внедрение, эксплуатация/Дэниел О’Лири;[Пер. с англ. Ю.И.Водопьяновой].
– М.: ООО «Вершина», 2004. – 272 с.
3.Меняев М.Ф. Информационные технологии управления: Учебное пособие: В 3 кн.: Книга 3: Системы управления организацией. – М.: Омега-Л, 2003. – 464 с.
4.Автоматизированные информационные системы, базы и банки данных. Вводный курс: Учебное пособие. – М.: Гелиос АРВ, 2002. – 368 с., ил.
5.Б.Н. Гайфуллин, И.А. Обухов. Автоматизированные системы управления предприятиями стандарта ERP/MRPII. Производственное издание. – М. «Богородский печатник», 2001, 104 с.
6.Петров В. Н. Информационные системы. – СПб.: Питер, 2002. - 688 с.
7.IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990
8.Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.
9.Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002.
10.Алистер Коберн. Современные методы описания функциональных требований к системам. М.: издательство «Лори», 2002. – 263 с.
11.Мацяшек Лешек. Анализ требований и проектирование систем. Разработка информационных :с Диалектика-Вильямс
12.Орлик С., Булуй Ю. Введение в программную инженерию и управление жизненным циклом ПО Программная инженерия. Программные требования. Copyright © Сергей Орлик, 2004-2005.
http://www.sorlik.ru/swebok/3-1-software_engineering_requirements.pdf
13.IEEE Guide to the Software Engineering Body of Knowledge (1) - SWEBOK®, 2004. – http://www.swebok.org
14.ГОСТ Р ИСО/МЭК 12207/99. Государственный стандарт РФ. Информационная технология. Процессы жизненного цикла информационных систем. Издание официальное. – М., 1999.
15.Л.Новиков. Введение в Rational Unified Process.
http://www.interface.ru/rational/interface/151199/rup/main.htm
16.Белые страницы MSF. http://www.microsoft.com/rus/msdn/msf
17.Analyzing requirements and defining Microsoft .Net solution architectures 2000 г. 491 стр. Microsoft Press.
18.Введение в Rational Unified Process/ Ф. Кратчен – СПб.: Вильямс, 2002. – 240 с.
19.Унифицированный процесс разработки программного обеспечения/ А. Якобсон, Г. Буч, Дж. Рамбо – СПб.: Питер , 2002. – 496 с .
20.IEEE 1362 - Concept of Operations Document
21.IEEE 1233 - Guide for Developing System Requirements Specifications.
22.IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»
2. Требования и их свойства. Процесс анализа требований
План лекции
Свойства требований Полнота
Ясность Корректность и согласованность (непротиворечивость) Верифицируемость
Необходимость и полезность при эксплуатации Осуществимость
Трассируемость Упорядоченность по важности и стабильности. Наличие количественной метрики
Каких требований не должно быть Процесс анализа требований
Рабочий поток анализа требований Кто создаёт и использует требования
Организация работы с требованиями на примере MSF
Ф. Брукс в своём, теперь уже ставшим классическим, эссе3, следующим образом охарактеризовал роль требований в разработке программного обеспечения. Строжайшее и единственное правило построения систем программного обеспечения (ПО) – решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно (конец цитаты).
Наука извлечения и формализации качественных (иногда говорят «хороших», «правильных») требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определённые представления о том, какими свойствами должны обладать требования к программной системе. Это:
полнота,
ясность,
корректность,
согласованность,
верифицируемость,
необходимость,
полезность при эксплуатации,
осуществимость,
модифицируемость,
трассируемость,
упорядоченность по важности и стабильности,
наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [1] и широко обсуждается в работах [8,9]. Рассмотрим указанные выше свойства подробнее.
Полнота. Как известно из теории искусственного интеллекта, неполнота – одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками ещё несуществующей системы. Идея о
3 Brooks, Frederick P. Jr. 1987. No Silver Bullet: Essence and Accidents of Software Engineering. С River, NJ: Prentice Hall PTR.
том, что необходимо сформулировать все требования полностью, т.е. исчерпывающим образом, до начала проектирования, а тем более – реализации системы, изжила себя вместе с так называемым каскадным подходом4 [2], который поддерживал последовательную модель реализации системы. Спиральный5 [2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всём протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование – это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования – свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нём предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определённость, однозначность спецификаций). Каждый из совладельцев6 разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесённое вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит «выравнивание тезаурусов» совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К.Вигерс [8] даёт следующий совет по повышению ясности документов: «Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям».
Ещё одной стороной понятия «ясность требования» является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Корректность и согласованность (непротиворечивость).
Корректность – одно из важнейших свойств требований. К. Вигерс в [8] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определённой степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задаёт дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит – как минимум одно из них некорректно. В иерархии требований (см. материалы лекции 2) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования
4Royce, Walker W. Managing the development of large software systems: concepts and techniques. Proc. IEEE WESTCON, Los Angeles, August 1970, pp. 1-9
5Boehm, B.W. A spiral model of software development and enhancement. IEEE Computer, 21 (5), 1988, pp. 61-
6Терминология RUP, см. ниже