Ф. Брукс в своем, теперь уже ставшим классическим, эссеBrooks, Frederick P. Jr. 1987. No Silver Bullet: Essence and Accidents of Software Engineering. С River, NJ: Prentice Hall PTR., следующим образом охарактеризовал роль требований в разработке программного обеспечения.
Строжайшее и единственное правило построения систем программного обеспечения (ПО) - решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно.
Наука извлечения и формализации качественных (иногда говорят "хороших", "правильных") требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определенные представления о том, какими свойствами должны обладать требования к программной системе. Это:
полнота,
ясность,
корректность,
согласованность,
верифицируемость,
необходимость,
полезность при эксплуатации,
осуществимость,
модифицируемость,
трассируемость,
упорядоченность по важности и стабильности,
наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [3.1] и широко обсуждается в работах [3.3,3.5]. Рассмотрим указанные выше свойства подробнее.
Полнота.
Как известно из теории искусственного интеллекта, неполнота - одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками еще несуществующей системы. Идея о том, что необходимо сформулировать все требования полностью, т.е. исчерпывающим образом, до начала проектирования, а тем более - реализации системы, изжила себя вместе с так называемым каскадным подходомRoyce, Walker W. Managing the development of large software systems: concepts and techniques. Proc. IEEE WESTCON, Los Angeles, August 1970, pp. 1-9 [3.2], который поддерживал последовательную модель реализации системы. СпиральныйBoehm, B.W. A spiral model of software development and enhancement. IEEE Computer, 21 (5), 1988, pp. 61-72. [3.2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всем протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование - это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определенность, однозначность спецификаций).
Каждый из совладельцевТерминология RUP, см. материалы лекции Процесс анализа требований разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесенное вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит "выравнивание тезаурусов" совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К.Вигерс [3.3] дает следующий совет по повышению ясности документов: "Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям".
Еще одной стороной понятия "ясность требования" является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Корректность и согласованность (непротиворечивость).
Корректность - одно из важнейших свойств требований. К. Вигерс в лекции 2) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования - требованиям пользователя.
Верифицируемость (пригодность к проверке).
Признаки (свойства) требований, рассматриваемые в настоящей лекции, нельзя считать независимыми. В математической статистике такие признаки называются коррелируемыми. Так, свойство верифицируемости существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемом участниками процесса создания информационной системы, причем оно является полным, т.е. ни одна из важных для реализации деталей не упущена - значит, это требование можно проверить. При этом в ходе проверки у сторон (принимающей и сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы верификации требований будут рассмотрены в лекции Проверка требований. Так как хорошо сформулированные требования составляют основу успешного создания системы - роль верифицируемости трудно переоценить. Требования к системе представляют основу контракта между Заказчиком и Исполнителем и если данные требования нельзя проверить - значит и контракт не имеет никакого смысла, следовательно, успех или неудача проекта будут зависеть только от эмоциональных оценок сторон и их способности договориться, а это - слишком шаткая основа для осуществления работ.
Необходимость и полезность при эксплуатации.
Одни из самых субъективных и трудно проверяемых свойств требований.
Возвращаясь к иерархии требований в лекции 2, наиболее бесспорными требованиями следует считать бизнес-требования. Данные требования формулируют первые лица, представляющие Заказчика, и вряд ли кто-нибудь лучше них сможет сказать, каким условиям должна соответствовать создаваемая информационная система, чтобы соответствовать бизнес-целям предприятия. Тем не менее, если у представителя Исполнителя возникают сомнения в необходимости того или иного бизнес-требования, вызванные интуитивными соображениями, либо опытом внедрения информационных систем на аналогичных предприятиях, он должен проявить инициативу и собрать совместное совещание сторон. Аргументы в пользу отсутствия необходимости требования несомненно будут восприняты, особенно если они будут мотивированы в бизнес-терминологии Заказчика и подтверждены выкладками, прогнозирующими соотношение затрат на выполнение требования и ожидаемой от него эффективности.
Необходимость требований пользователя может вытекать из соответствующих бизнес-требований. Кроме того, требования пользователя могут мотивироваться эргономичностью продукта и особенностями функционирования его отдела (подразделения), недостаточно полно раскрытыми на предыдущем уровне иерархии требований.
Большинство функциональных требований вытекают из требований первых двух уровней. Другие функциональные требования могут лежать вне сферы компетенции Заказчика (который, вообще говоря, не обязан быть экспертом в области IT) и их должен сформулировать Исполнитель. Так, например, информационная система в процессе ее использования может начать снижать свою производительность из-за больших объемов накапливаемых данных. Поэтому целесообразно заложить функции архивирования информации, переключения учетных периодов и т.п., необходимость которых следует не из особенностей бизнеса предприятия внедрения, а из общих принципов построения информационных систем.
Более слабой, чем "необходимость" формулировкой обладает свойство "полезность при эксплуатации". Разграничение между данными свойствами можно провести следующим образом. Необходимыми следует считать свойства, без выполнения которых невозможно, либо затруднено выполнение автоматизированных бизнес-функций пользователей; полезными при эксплуатации следует считать любые свойства, повышающие эргономические качества продукта.
Осуществимость (выполнимость).
Является в некоторой степени конкурирующим по введенным выше двум свойствам.
В принципе никто не мешает сформулировать требование, выполнимость которого ограничивается сегодняшним уровнем развития техники и технологии, хотя многое из того, что было невыполнимо десять лет назад, вполне выполнимо сегодня. Можно сформулировать требование, выполнимость которого ограничена научными представлениями о строении Вселенной, например - требование мгновенной передачи информации с земной станции на Марс, хотя и фундаментальные представления иногда меняются, пусть и не так быстро, как развитие IT-технологий.
Возвращаясь с небес на землю, отринем те требования, которые можно признать абсурдными и остановимся на тех, которые выполнимы принципиально. С точки зрения науки управления требованиями, далеко не все из них являются осуществимыми.
Выполнимость требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами. Так, если стоимость контракта на разработку информационной системы составляет $10000, а затраты на выполнение нового требования, возникшее в момент, когда проект выполнен наполовину, оценивается в $4000, является ли оно невыполнимым? Скорее всего, да, если Исполнитель докажет Заказчику новизну требования (требование не входило в согласованные спецификации) и сложность его исполнения. Но, если требование является критически важным, необходимым, но выпало из поля зрения при подписании контракта Заказчик готов выделить дополнительно финансирование, а Исполнитель - трудовые ресурсы - значит, требование выполнимо. Таким образом, требование осуществимости в ряде случаев также следует считать субъективным, а критерии его оценки лежат в области договоренностей между Заказчиком и Исполнителем.
Отличной иллюстрацией балансировки между ценностью и выполнимостью требований является так называемый треугольник компромиссов.
(рис 3.1)
В качестве пояснения к рисунку 3.1 приведем цитату из "белых страниц", размещенных Microsoft в открытом доступе [3.4].
Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 3.1. После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Необходимо обеспечить возможность переработки требований, если понадобится, и поддерживать историю изменений для каждого положения. Для этого все они должны быть уникально помечены и обозначены, чтобы вы могли ссылаться на них однозначно. Каждое требование должно быть записано в спецификации только единожды. Иначе вы легко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные утверждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования.
Трассируемость
Трассируемость требования определяется возможностью отследить связь между ним и другими артефактами информационной системы (документами, моделями, текстами программ и пр.). Отдельная трасса представляет собой направленное бинарное отношение, заданное на множестве артефактов ИС, где первый элемент отношения представляет соответствующее требование, а второй - артефакт, зависимый от данного требования. На практике трассировки анализируются при посредстве графовых, либо табличных моделей.
Процесс трассировки позволяет, с одной стороны, выявить уже на стадии проектирования системы проектные артефакты, к которым не ведет связь ни от одного из артефактов, описывающих требования, с другой - артефакты, описывающие требования, не связанные с проектными артефактами. В первом из случаев целесообразно убедиться в том, что проектный артефакт действительно имеет право на существование, а не является избыточным. Во втором случае необходимо проанализировать полезность выявленных требований: либо эти требования несут недостаточную полезную нагрузку и могут быть игнорированы, либо имеют место ошибки проектирования: пропущены соответствующие артефакты.
Другая цель трассировки - повысить управляемость проектом: при изменении отдельно взятого требования становится понятно - какие из проектных, рабочих и других артефактов подлежат изменению (см. также материалы лекции 13).
Упорядоченность по важности и стабильности
Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.
Стабильность требования характеризует прогнозную оценку неизменности требований во времени.
Наличие количественной метрики
Количественные метрики играют важную роль в верификации и аттестации информационных систем. В первую очередь это относится к нефункциональным требованиям, которые, как правило, должны иметь под собой количественную основу (запрос должен отрабатываться не более, чем ___ секунд; средняя наработка на отказ должна составлять не менее, чем ___ часов). Функциональные требования также могут расширяться количественными мерами при помощи так называемых аспектов применимости (см. материал лекции 10-Прототипирование требований).
Каких требований не должно быть
Согласно лекции 15).
Лекция начинается с тезиса Ф. Брукса о том, что самая сложная часть разработки ПО — это решение о том, что именно строить. Определение требований — это концептуальная работа, ошибки в которой дороже всего обходятся проекту.
Далее автор переходит к перечислению и подробному анализу свойств качественных требований:
• Полнота: Рассматривается не как абсолютное требование (невозможное в условиях неполноты знаний), а как тенденция к максимальной детализации на ранних этапах. Различают полноту отдельного требования (все нюансы учтены) и полноту всей системы требований (все аспекты системы описаны).
• Ясность (Недвусмысленность): Требование должно одинаково восприниматься всеми «совладельцами» системы. Для этого нужно использовать понятную пользователям лексику и согласованный глоссарий.
• Корректность и Согласованность: Требования должны быть правильными (соответствовать реальным потребностям) и непротиворечивыми как по горизонтали (между требованиями одного уровня), так и по вертикали (между бизнес-требованиями, требованиями пользователей и функциональными требованиями).
• Верифицируемость: Возможность проверки выполнения требования. Это свойство тесно связано с ясностью и полнотой. Если требование нельзя проверить, контракт теряет смысл.
• Необходимость и Полезность: Необходимость определяется вкладом в бизнес-цели. Полезность относится к эргономике и удобству. Иногда разработчик сам должен предложить технически необходимые требования (например, архивирование данных), о которых заказчик мог не подумать.
• Осуществимость: Определяется балансом между ценностью требования и ресурсами на его реализацию. Иллюстрируется «треугольником компромиссов» (ресурсы, время, возможности), где изменение одного параметра ведет к изменению других.
• Модифицируемость: Требования должны быть организованы так, чтобы их можно было легко изменять (уникальная идентификация, отсутствие дублирования, ссылки вместо копирования).
• Трассируемость: Возможность проследить путь от требования к проектным артефактам (и обратно). Помогает выявлять «лишние» требования или нереализованные функции, а также управлять изменениями.
• Упорядоченность по важности и стабильности: Назначение приоритетов заказчиком для управления очередностью разработки и оценка вероятности изменения требования в будущем.
• Наличие количественной метрики: Особенно важно для нефункциональных требований (производительность, надежность), чтобы сделать их проверяемыми.
В конце лекции делается вывод, что перечисленные свойства — это идеал, к которому нужно стремиться, но на практике всегда приходится искать компромиссы.
1. Требования — фундамент проекта. Успех или провал разработки ПО напрямую зависит от того, насколько точно и полно определены исходные требования.
2. Качество требований многогранно. Существует четкий набор критериев (полнота, ясность, непротиворечивость и др.), по которым можно оценить качество спецификации требований.
3. Свойства требований взаимосвязаны. Например, невозможно проверить (верифицировать) неясное или неполное требование. Работа над требованиями требует системного подхода.
4. Требования — это предмет переговоров. На выполнимость требований влияют ограничения по ресурсам и времени, что вынуждает заказчика и исполнителя искать компромиссы в рамках «треугольника проекта».
5. Управление требованиями — непрерывный процесс. Работа с требованиями не заканчивается на этапе составления спецификации. Она включает в себя трассировку, управление изменениями и поддержание истории для обеспечения управляемости проекта на всех стадиях.
1. Почему, по мнению Ф. Брукса, этап определения требований является самым трудным и критичным в разработке ПО?
2. В чем различие между каскадным и спиральным подходом к разработке в контексте работы с полнотой требований?
3. Что означает «ясность» (недвусмысленность) требования и как ее можно достичь на практике?
4. Почему свойство верифицируемости является основой для заключения контракта между Заказчиком и Исполнителем?
5. В чем разница между «необходимостью» и «полезностью» требования? Приведите примеры из текста.
6. Объясните суть «треугольника компромиссов» и как он связан с осуществимостью требований.
7. Для чего нужна трассируемость требований? Какие проблемы в проекте позволяет выявить этот процесс?
8. Как вы понимаете требование «модифицируемости» спецификации? Какие правила помогут ее обеспечить?
9. Перечислите не менее пяти свойств, которыми должны обладать качественные требования к программному обеспечению.
