Что такое полнота требований
Свойства требований
Свойства требований.
3. Свойства требований. 3-1
Корректность и согласованность (непротиворечивость) 3-4
Необходимость и полезность при эксплуатации. 3-5
Упорядоченность по важности и стабильности. 3-9
Наличие количественной метрики. 3-10
Каких требований не должно быть. 3-10
Литература к лекции. 3-10
Ф. Брукс в своём, теперь уже ставшим классическим, эссе[1], следующим образом охарактеризовал роль требований в разработке программного обеспечения. Строжайшее и единственное правило построения систем программного обеспечения (ПО) – решить точно, что же строить. Никакая другая часть концептуальной работы не является такой трудной, как выяснение деталей технических требований, в том числе и взаимодействие с людьми, с механизмами и с иными системами ПО. Никакая другая часть работы так не портит результат, если она выполнена плохо. Ошибки никакого другого этапа работы не исправляются так трудно (конец цитаты).
Наука извлечения и формализации качественных (иногда говорят «хороших», «правильных») требований носит во многом эмпирический характер. Однако, в практике разработки программных систем накопились определённые представления о том, какими свойствами должны обладать требования к программной системе. Это:
§ полезность при эксплуатации,
§ упорядоченность по важности и стабильности,
§ наличие количественной метрики.
Большинство из этих свойств раскрыто в первом разделе стандарта IEEE [1] и широко обсуждается в работах [3,5]. Рассмотрим указанные выше свойства подробнее.
Полнота. Как известно из теории искусственного интеллекта, неполнота – одно из фундаментальных свойств человеческого знания. При создании программных систем нам приходится иметь дело с характеристиками ещё несуществующей системы. Идея о том, что необходимо сформулировать все требования полностью, т. е. исчерпывающим образом, до начала проектирования, а тем более – реализации системы, изжила себя вместе с так называемым каскадным подходом[2] [2], который поддерживал последовательную модель реализации системы. Спиральный[3] [2] подход, на котором базируется большинство современных методологий, предусматривает поэтапное выделение и детализацию требований на всём протяжении цикла разработки системы.
Тем не менее, требование полноты предъявляется к требованиям, формулируемым к системе. Надо понимать, что данное требование – это скорее тенденция, цель, к которой нужно постараться максимально приблизиться на как можно более ранних стадиях проекта.
Требование полноты можно рассматривать в двух аспектах: полнота отдельного требования и полнота системы требований.
Полнота отдельного требования – свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нём предусмотрены все необходимые нюансы, особенности и детали данного требования.
Полнота системы требований – свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает всё то, что требуется от разрабатываемой системы.
Ясность (недвусмысленность, определённость, однозначность спецификаций). Каждый из совладельцев[4] разрабатываемой системы обладает своим личным опытом восприятия событий внешнего мира. Слово, произнесённое вслух, вызывает индивидуальные ассоциации в семантическом пространстве каждого отдельного воспринимающего субъекта. То, что является ясным, допустим, для кардиохирурга, совсем необязательно будет таковым для специалиста в области программной инженерии.
Соответственно, требование обладает свойством ясности, если оно сходным образом воспринимается всеми совладельцами системы. На практике ясность требований достигается в том числе и в процессе консультаций, в ходе которых происходит «выравнивание тезаурусов» совладельцев системы. Хорошим подспорьем в этом служит согласованный сторонами глоссарий ключевых понятий предметной области.
К. Вигерс [3] даёт следующий совет по повышению ясности документов: «Пишите документацию просто, кратко и точно, применяя лексику, понятную пользователям».
Ещё одной стороной понятия «ясность требования» является его прослеживаемость (см. также понятие трассируемости ниже по тексту). Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
Корректность и согласованность (непротиворечивость). Корректность – одно из важнейших свойств требований. К. Вигерс в [3] вводит понятие корректности требования через точность описания функциональности. В этом смысле корректность в определённой степени конкурирует с полнотой. Но есть и различие: если свойство полноты носит скорее качественный характер: абсолютная полнота представляет недостижимый идеал, к которому можно приближаться, то свойство корректности носит оценочный характер и задаёт дихотомию: каждое из требований либо корректно, либо нет. Кроме того, можно рассуждать о взаимной корректности требований или согласованности (непротиворечивости): если два требования вступают в конфликт, значит – как минимум одно из них некорректно. В иерархии требований (см. материалы лекции 2) можно выделить вертикальную и горизонтальную согласованность. Иными словами, требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям «родительского» уровня. Так, требования пользователей не должны противоречить бизнес-требованиям, а функциональные требования – требованиям пользователя.
Верифицируемость (пригодность к проверке). Признаки (свойства) требований, рассматриваемые в настоящей лекции, нельзя считать независимыми. В математической статистике такие признаки называются кореллируемыми. Так, свойство верифицируемости существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемым участниками процесса создания информационной системы, причём оно является полным, т. е. ни одна из важных для реализации деталей не упущена – значит, это требование можно проверить. При этом в ходе проверки у сторон (принимающей и сдающей работу) не должно возникнуть неразрешимых противоречий в оценках. Методы верификации требований будут рассмотрены в 12-Проверка требований. Так как хорошо сформулированные требования составляют основу успешного создания системы – роль верифицируемости трудно переоценить. Требования к системе представляют основу контракта между Заказчиком и Исполнителем и если данные требования нельзя проверить – значит и контракт не имеет никакого смысла, следовательно, успех или неудача проекта будут зависеть только от эмоциональных оценок сторон и их способности договориться, а это – слишком шаткая основа для осуществления работ.
Необходимость и полезность при эксплуатации. Одни из самых субъективных и трудно проверяемых свойств требований.
Возвращаясь к иерархии требований в лекции 2, наиболее бесспорными требованиями следует считать бизнес-требования. Данные требования формулируют первые лица, представляющие Заказчика, и вряд ли кто-нибудь лучше них сможет сказать, каким условиям должна соответствовать создаваемая информационная система, чтобы соответствовать бизнес-целям предприятия. Тем не менее, если у представителя Исполнителя возникают сомнения в необходимости того или иного бизнес-требования, вызванные интуитивными соображениями, либо опытом внедрения информационных систем на аналогичных предприятиях, он должен проявить инициативу и собрать совместное совещание сторон. Аргументы в пользу отсутствия необходимости требования несомненно будут восприняты, особенно если они будут мотивированы в бизнес-терминологии Заказчика и подтверждены выкладками, прогнозирующими соотношение затрат на выполнение требования и ожидаемой от него эффективности.
Необходимость требований пользователя может вытекать из соответствующих бизнес-требований. Кроме того, требования пользователя могут мотивироваться эргономичностью продукта и особенностями функционирования его отдела (подразделения), недостаточно полно раскрытыми на предыдущем уровне иерархии требований.
Большинство функциональных требований вытекают из требований первых двух уровней. Другие функциональные требования могут лежать вне сферы компетенции Заказчика (который, вообще говоря, не обязан быть экспертом в области IT) и их должен сформулировать Исполнитель. Так, например, информационная система в процессе её использования может начать снижать свою производительность из-за больших объёмов накапливаемых данных. Поэтому целесообразно заложить функции архивирования информации, переключения учётных периодов и т. п., необходимость которых следует не из особенностей бизнеса предприятия внедрения, а из общих принципов построения информационных систем.
Более слабой, чем «необходимость» формулировкой обладает свойство «полезность при эксплуатации». Разграничение между данными свойствами можно провести следующим образом. Необходимыми следует считать свойства, без выполнения которых невозможно, либо затруднено выполнение автоматизированных бизнес-функций пользователей; полезными при эксплуатации следует считать любые свойства, повышающие эргономические качества продукта.
Осуществимость (выполнимость). Является в некоторой степени конкурирующим по введённым выше двум свойствам.
В принципе никто не мешает сформулировать требование, выполнимость которого ограничивается сегодняшним уровнем развития техники и технологии, хотя многое из того, что было невыполнимо десять лет назад, вполне выполнимо сегодня. Можно сформулировать требование, выполнимость которого ограничена научными представлениями о строении Вселенной, например – требование мгновенной передачи информации с земной станции на Марс, хотя и фундаментальные представления иногда меняются, пусть и не так быстро, как развитие IT-технологий.
Возвращаясь с небес на землю, отринем те требования, которые можно признать абсурдными и остановимся на тех, которые выполнимы принципиально. С точки зрения науки управления требованиями, далеко не все из них являются осуществимыми.
Отличной иллюстрацией балансировки между ценностью и выполнимостью требований является так называемый треугольник компромиссов.
В качестве пояснения к рисунку приведём цитату из «белых страниц», размещённых Microsoft в открытом доступе [4]. Хорошо известна взаимозависимость между ресурсами проекта (людскими и финансовыми), его календарным графиком (временем) и реализуемыми возможностями (рамками). Эти три переменные образуют треугольник, показанный на рис. 3-1. После достижения равновесия в этом треугольнике изменение на любой из его сторон для поддержания баланса требует модификаций на другой (двух других) сторонах и/или на изначально измененной стороне.
Необходимо обеспечить возможность переработки требований, если понадобится, и поддерживать историю изменений для каждого положения. Для этого все они должны быть уникально помечены и обозначены, чтобы вы могли ссылаться на них однозначно. Каждое требование должно быть записано в спецификации только единожды. Иначе вы легко получите несогласованность, изменив только одно положение из двух одинаковых. Лучше используйте ссылки на первоначальные утверждения, а не дублируйте положения. Модификация спецификации станет гораздо легче, если вы составите содержание документа и указатель. Сохранение спецификации в базе данных коммерческого инструмента управления требованиями сделает их пригодными для повторного использования (конец цитаты).
Трассируемость. Трассируемость требования определяется возможностью отследить связь между ним и другими артефактами информационной системы (документами, моделями, текстами программ и пр.). Отдельная траса представляет собой направленное бинарное отношение, заданное на множестве артефактов ИС, где первый элемент отношения представляет соответствующее требование, а второй – артефакт, зависимый от данного требования. На практике трассировки анализируются при посредстве графовых, либо табличных моделей.
Процесс трассировки позволяет, с одной стороны, выявить уже на стадии проектирования системы проектные артефакты, к которым не ведёт связь ни от одного из артефактов, описывающих требования, с другой – артефакты, описывающие требования, не связанные с проектными артефактами. В первом из случаев целесообразно убедиться в том, что проектный артефакт действительно имеет право на существование, а не является избыточным. Во втором случае необходимо проанализировать полезность выявленных требований: либо эти требования несут недостаточную полезную нагрузку и могут быть игнорированы, либо имеют место ошибки проектирования: пропущены соответствующие артефакты.
Другая цель трассировки – повысить управляемость проектом: при изменении отдельно взятого требования становится понятно – какие из проектных, рабочих и других артефактов подлежат изменению (см. также материалы лекции 13-Введение в управление требованиями. doc).
Упорядоченность по важности и стабильности. Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика. Разработчик, отталкиваясь от приоритетности требований, управляет процессом реализации информационной системы.
Стабильность требования характеризует прогнозную оценку неизменности требований во времени.
Наличие количественной метрики. Количественные метрики играют важную роль в верификации и аттестации информационных систем. В первую очередь это относится к нефункциональным требованиям, которые, как правило, должны иметь под собой количественную основу (запрос должен отрабатываться не более, чем ___ секунд; средняя наработка на отказ должна составлять не менее, чем ___ часов). Функциональные требования также могут расширяться количественными мерами при помощи так называемых аспектов применимости (см. материал лекции 10-Прототипирование требований).
Каких требований не должно быть
Согласно [5], спецификация требований не должна содержать деталей проектирования или реализации (кроме известных ограничений). Иными словами, требования должны отвечать на вопрос: «что должна делать система», абстрагируясь от вопроса «как она это должна делать». Стремление принимать детальные проектные решения на этапе анализа требований – одно из типичных «ловушек», типичных для неопытных команд разработчиков. Вариантов реализации всегда больше, чем один, а для принятия взвешенного решения нужна максимально более полная информация. Поэтому этапы работы с требованиями, проектирования и реализации планируются поочерёдно, хотя и могут быть частично запараллелены в рамках итерационного подхода к созданию программных систем (см. 15-Требования в управлении проектом).
Литература к лекции
1. IEEE Standard 830-1998, «IEEE Recommended Practice for Software Requirements Specifications»
3. требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил.
4. Microsoft Solutions Framework. Модель процессов MSF, версия 3.1
http://www. /Rus/Download. aspx? file=/Msdn/Msf/MSF_process_model_rus. doc
5. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002.
[1] Brooks, Frederick P. Jr. 1987. No Silver Bullet: Essence and Accidents of Software Engineering. С River, NJ: Prentice Hall PTR.
[2] Royce, Walker W. Managing the development of large software systems: concepts and techniques. Proc. IEEE WESTCON, Los Angeles, August 1970, pp. 1-9
[3] Boehm, B. W. A spiral model of software development and enhancement. IEEE Computer, 21 (5), 1988, pp. 61-72.
[4] Терминология RUP, см. материалы лекции 04-Процесс анализа требований
Чек-лист тестирования требований
Когда разрабатывается новая функциональность системы, аналитик пишет требования, а тестировщик их проверяет. До того, как начать реализацию. Потому что на этом этапе внести исправления дешевле всего.
Вот только на что обращать внимание при тестировании? Есть набор основных характеристик, которыми должна обладать хорошая документация:
Конечно, их может быть и больше. Кто-то использует мнемонику CIRCUS MATTA, кто-то расширяет список под себя и команду. Но эти шесть характеристик — основные. О них и в книгах по тестированию пишут, и в самых разных статьях.
В этой статье я расскажу о каждой из них поподробнее, с картиночками и примерами из жизни.
1. Полнота
Все ли описано? Ничего не забыли? Вдруг у нас остался неописанный функционал или параметр API-метода?
Чтобы проверить этот пункт, просто напишите чек-лист проверок функционала. Вот как начали читать ТЗ, сразу записывайте тесты. Важно именно писать, а не просто прикидывать в уме. Иначе что-то обязательно забудете.
Как-то раз мне прислали на проверку ТЗ на новый функционал. Да, по хорошему надо сразу прикинуть тесты, которые буду писать. А это надо взять ручку, блокнот и начать тест-дизайнить. Но я занималась другой задачей, а ТЗ надо проверить «сегодня», чтобы отправить оценку заказчику.
Поэтому решила проверить «мысленно». Читаю пункт ТЗ, прикидываю, какие могут быть тесты. В итоге задала парочку уточняющих вопросов:
У Заказчика уточнили, документацию пополнили! В остальном меня всё устроило, вроде нормально описано, всё учтено.
Заказчик согласовал ТЗ, разработчик сделал. Пришло время тестировать. Начинаю писать автотесты и. Да, разумеется, сразу получаю еще 5-10 дополнительных вопросов. В ТЗ не были предусмотрены все сценарии, и я о них тоже не подумала, пока прикидывала тесты мысленно.
А как только стала расписывать план автотестов, сразу увидела «белые пятна». При этом у меня 10 лет опыта в тестировании. Не полагайтесь на память и «быстренько мысленно прикину», выделите полчаса и распишите чек-лист проверок подробно.
Чем плохо отложить вопросы на потом? Не слишком профессионально согласовать требования, которые написала твоя команда, а через пару недель задавать уточняющие вопросы. Заказчик подумает: а чего сразу не спросили?
Плюс иногда можно пропустить очень важный вопрос, который трудозатратно делать. А ТЗ, напомню, уже согласовано. Так что всё, что продолбали на этапе согласования, делаем за свой счет.
Да, написать тесты — это дольше, чем просто прочитать документацию. Но зато вы экономите время потом, ведь чек-лист уже готов, бери да проверяй!
2. Однозначность
Требования должны трактоваться всеми одинаково.
«Отчет должен загружаться быстро» → что значит «быстро»?
пользователь будет уверен, что страница будет грузиться доли секунды, даже если это сложный отчет на многомиллионных данных;
разработчик прикинет, что в таких объемах 5 секунд нормальное время отклика, даже быстрое.
Налицо конфликт интересов. И ведь каждый будет тыкать в ТЗ для отстаивания своей позиции. Лучше конкретизировать:
Отчет за год должен загружаться не более секунды.
Отчет за весь период времени должен загружаться не более 5 секунд.
Если в требованиях не указано, что у нового поля с суммой дохода должно быть значение по умолчанию:
Аналитик будет думать, что там будет значение 0. Деньги же, цифра!
Разработчик сделает пустое поле, не указано ведь ничего! А это что-то сломает.
Если в требованиях не указано, как обработать ошибочный сценарий, разработчик может:
Не подумать о нем и никак не обработать — пользователь может огрести страшную ошибку.
Подумать о нем и обработать так, как считает правильным — а тестировщик потом будет доказывать, что надо было делать по другому. Пойдут к аналитику, потратят и его время тоже, а потом еще код переделывать.
Все, что можно прочитать двояко, лучше исправить. Это не значит, что нужно описывать каждую мелочь, но всё зависит от читателей документа.
Если это внутренний документ, а у вас сильная команда — можно не расписывать подробно.
Если этот документ отправят заказчику, надо расписать вообще всё — потому что у заказчика свои тестировщики, и они обязательно зададут кучу «а что, если. ». Если они хорошие тестировщики, разумеется. Это вы знаете свою программу и представляете, как она реагирует на ошибки или что-то такое. Тестировщик заказчика этого не знает, он будет уточнять.
3. Непротиворечивость
Требования не должны противоречить сами себе. Такое обычно бывает, когда требований много. Аналитик просто забывает, что уже писал про параметр и снова придумывает его поведение. Иногда придумывает немного по другому.
Например, есть страница нефункциональных требований, где написано, что любая страница должна грузится не более 3 секунд. Аналитик пишет ТЗ на новый модуль отчетности, который использует много данных и сложные формулы. И он пишет, что отчет может грузиться вплоть до минуты. Явное противоречие!
Если заказчик найдет первый раздел документации, он будет требовать именно такую скорость. И будет прав, кто же хочет ждать?)
4. Необходимость
Помните главный принцип: «Кратко, но емко»? Он действует и в документации тоже.
Круто, когда документация полная. Но это не значит, что простой функционал надо растечь на 10 листов А4. Когда документации много, сложно проверить полноту, сложно удержать в голове, о чем уже говорил, не повторяться и не противоречить самому себе.
Подумайте, так ли уж нужно описывать каждую кнопочку интерфейса? Это правда актуально? Пользователи правда не догадаются, что фильтры по строковым колонкам работают одинаково?
Пишите только то, что необходимо:
В ТЗ — функционал, основной сценарий и альтернативы, типы ошибок.
В пользовательской документации — то, как пользоваться системой. Но не доходя до крайностей и обучения включению компьютера.
5. Осуществимость
А можно ли реализовать то, что тут написано? Насколько это будет сложно и дорого?
Этот пункт обычно проверяют разработчики. Они остужают буйные фантазии из серии «загружать миллионы данных за 0,1 секунду» или что-то архитектурно сложное. Бывает такое, что на бумаге всё звучит просто, а вот сделать это займет человеко-месяц в лучшем случае.
В одной из систем, с которыми я работала, был точечный поиск. Не просто «найди мне все данные, где встречается «Ленина», а именно «найди мне адреса, у которых улица Ленина». Это отсеет фамилию Ленина, комментарий к телефону и другие нерелевантные данные.
Но вот беда — нельзя поискать по двум параметрам ОДНОГО атрибута. Если сказать «Найди мне домашний адрес с улицей Ленина», система вернет:
1. Васю: домашний адрес с улицей Ленина.
2. Петю: домашний адрес с переулком Турчанинов и рабочий с улицей Ленина.
Это баг в системе? Или просто нельзя сделать такой поиск, это неосуществимо? Нужно смотреть по коду.
В той системе для поиска использовали Lucene. Его можно настроить по-разному:
o поиск по любому полю;
o поиск по конкретному полю;
o множественный поиск по конкретному атрибуту (в одном адресе проверить и тип, и улицу);
Но! Чем сложнее сценарий поиска, тем медленнее он работает. Дольше сохраняет данные (потому что структура внутри усложняется), дольше ищет — или потребляет больше ресурсов для той же скорости.
Когда данных с гулькин нос, это неважно. А когда их миллионы, нужно искать баланс. И такой выбор возможностей поиска — это именно компромис для скорости и потребляемых ресурсов под сценарии использования.
Осуществимо желание отсеять Петю? Да. Но это просто не нужно. Потому что вреда принесет больше, чем пользы. Ради того, чтобы в выборку из 1000 человек не попали 10 лишних, платить несколько миллионов за дополнительные мощности серверов смысла просто нет.
6. Тестируемость
Можно ли протестировать этот функционал?
Подумайте об этом заранее. А то бывает так, что разработчик уже всё сделал, и тут только тестировщик понимает, что задачу никак нельзя проверить. Или можно проверить вручную, но нельзя написать автотесты, фреймворк под новый функционал не заточен.
Если в компании принято все покрывать автотестами, то это станет проблемой. Может, разработчик прочитает ТЗ и сам поймет, что ещё фреймворк тестов дорабатывать надо. А может, он не вспомнит об этом. И тогда ваша задача — вспомнить. Чтобы сразу заложить время на доработки.
У меня бывали ситуации, когда мы делали задачу в текущем релизе, а потом ставили новую «Доработать фреймворк автоматизации, чтобы поддержать изменения» в следующий. Иногда забывали про фреймворк, а потом времени в релизе уже не оставалось. А иногда сразу понимали, что всё сразу сделать не успеем.
Иногда про тесты не думаешь, так как уже есть похожие. Например, у нас давно были автотесты на обратный поток в JMS-очередь. А потом для одного из заказчиков мы сделали обратный поток в две JMS-очереди.
Сначала я не подумала о доработке автотестов — ведь возможность проверить «что ушло» есть! А когда добралась до тестирования, пошла к разработчику:
— А как мне указать вторую очередь? Или папка jms — это то, что в обе уйдет?
— Хм, нет, погоди, это только в старую. Надо доделывать фреймворк, поддержать разные очереди.
Ну и ничего, доделали, написала тестов!
Хотя лучше об этом помнить сразу, иначе велик шанс, что тестировать за вас придется разработчику. Или половину проверок переносить на следующую итерацию, что тоже не очень хорошо.
При этом бывает и так, что тестировать все равно придется разработчику. Скажем, когда делают рефакторинг, что может проверить тестировщик? Только регресс провести, посмотреть, что ничего не отломалось. А если есть автотесты, то это проверят они =)
Однако если тесты (авто или ручные) прошли успешно, это ещё не значит, что рефакторинг прошел хорошо. Сама суть рефакторинга — переписать код, чтобы он был более оптимален и читабелен. Чтобы его было легче поддерживать в дальнейшем и интегрировать с другими частями системы.
И именно это и надо проверить! А проверить это может только разработчик. Он и выполняет тестирование в данном случае.
Бонус: мнемоника CIRCUS MATTA и другие доп материалы
CIRCUS MATTA — мнемоника для ревью пользовательских историй. Это как раз про тестирование требований! Истории должны обладать качествами:
Completeness — полнота
Independent — независимость
Realisable — реализуемость
Consistency — консистентность
Unambiguity — однозначность
Specific — специфика заказчика
Measurable — измеримая
Acceptable — приемлемая
Testable — тестируемая
Traceable — трассируемая (можно проставить взаимосвязи)
Achievable — достижимая
Вон сколько пунктов получилось! Мне особенно импонируют пункты «специфика заказчика» и «трассируемость». Это и правда важно. Если у вас коробочный продукт, который кастомизируется под заказчика, обязательно смотрите на пункт «Specific». А трассируемость — очень хороший бонус, облегчающий поддержку документации в актуальном состоянии!