Формальные методы определения требований Таблица решений Часто встречаются требования, связанные с комбинацией ввода. Различные комбинации ввода приводят к различным вариантам поведения. Таблицы решениф используются в тех случаях, когда можно чётко определить зависимости поведения системы от комбинации вводов и её состояния. Пример: определить таблицу решений, соответствующую поведению банкомата, при этом будем рассматривать следующие вводы в систему: PIN-код, новый код, снимаемая сумма, сумма средств в банкомате, сумма на счёте, ограничения на разовое снятие, ограничения на снятие за один день, блокировка счёта. \Вводимые установки |Pin-|Новый|Снимаемая|Наличие денег|Ограничение на|Ограничение на|Сумма на|Блоки-|Ограни- | ------------------ |-код|код |сумма |в банкомате |разовое снятие|снятие за день|счёте |ровка |чение на| Функции и поведение\| | |S1>0 |SL>=S1 |S1<=Sr |S1+Sd=S1 |счёта |PIN-код | --------------------+----+-----+---------+-------------+--------------+--------------+--------+------+--------+ Снятие со счёта | 1 |X(-1)| 1 | 1 | 1 | 1 | 1 | 0 |X (-1) | --------------------+----+-----+---------+-------------+--------------+--------------+--------+------+--------+ Просмотр счёта | 1 | X | X | X | X | X | X | 0 | X | --------------------+----+-----+---------+-------------+--------------+--------------+--------+------+--------+ Изменение Pin-кода | 1 | 1 | X | X | X | X | X | 0 | 1 | --------------------+----+-----+---------+-------------+--------------+--------------+--------+------+--------+ Деревья решений Деревья решений используются для графического отображения требований к системе. Обычно определяют последовательность действий. Например: необходимо описать последовательность действий системы-сигнализации: да да Включено дистанционное----Инициировать сообщение---Ответила удалённая----Ничего не делать оповещение о тревоге система да^ \нет |нет поступила последовательность сигналов,/ Включён местный да Включить сирену соответствующая состоянию тревоги сигнал тревоги-----Включить |нет |нет сирену Ничего не делать Ничего не делать Критерии качества требований к ПО При оценке качества спецификации в целом рассматриваются следующие основные элементы: 1) качество каждой отдельной спецификации; 2) качество применяемых методов (качество спецификации прецедентов, акторов и т. п.); 3) качество пакета, объединяющего все отдельные спецификации. Определение качества - это важная и сложная задача. Высококачественный пакет MSRS должен быть: 1) корректным; 2) недвусмысленным; 3) полным; 4) непротиворечивым; 5) упорядоченным по важности и стабильности; 6) поддающимся проверке; 7) модифицируемым, трассируемым и понимаемым. Многие из этих качеств определены ГОСТами. 1) Корректные требований. Набор требований к ПО является корректным тогда и только тогда, когда каждое требование, сформулированное в нём, представляет нечто, требуемое от создаваемой системы. ---- ---- A - потребности пользователя / X \ C - сформулированные требования / //\ \ | |//B| | \ \// / \ A X C / ---- ---- Корректность можно проверить только просмотром требований заказчиком. Реально в проектах встречается ситуация, когда исключается некая информация из области A и включается из области C. 2) Недвусмысленные требования. Требование является недвусмысленным тогда и только тогда, когда его можно однозначно интерпретировать. Если требования будут по-разному интерпретироваться разработчиком, пользователями и другими участниками проекта, то созданная система будет существенно отличаться от того, что хотел получить пользователь. 3) Полнота набора требований. Набор требований является полным тогда и только тогда, когда он описывает все важные требования, интересующие пользователя, в том числе требования. связанные с функциональными возможностями, производительностью, ограничениями проектирования, атрибутами или внешними интерфейсами. Полный набор требований должен предусматривать ответы программы на всевозможные классы ввода (правильные и неправильные). Кроме этого, он должен содержать полные ссылки и подписи рисунков, таблиц и диаграмм набора требований, а также определение всех терминов и единиц измерения. Полнота нефункциональных требований Чаще других пропускают требования производительности и ограничения проектирования. Пользователь считает, что производительность сама собой подразумевается. Производительность надо формулировать примерно так: "время ответа на 90% всех транзакций будет составлять не более 5 секунд". Полнота функциональных требований Проблема полноты функциональных требований более сложная, поскольку разработчик не является экспертом в предметной области. Некоторые требования для пользователя настолько очевидны, что он забывает о них упомянуть. Например: если день расчёта зарплаты попадает на праздник, то нужно рассчитать её на день раньше. Проблема выявления функциональных требований в основном решается методом прецедентов. Применение прототипирования и раскадровки Прототипирование и раскадровка позволяют устранить многие проблемы, связанные с полнотой требования. При этом аналитику следует обратить внимание на граничные условия и неординарные события. 4) Непротиворечивость набора требований. Множество требований являются внутренне непротиворечивым тогда и только тогда, когда ни одно его подмножество, состоящее из отдельных требований, не противоречит другим подмножествам. Конфликты могут иметь различную форму и проявляться на различных уровнях детализации. Если набор требований записан формально и поддерживается автоматическими средствами, конфликт можно обнаружить формальным анализом. В большинстве случаев это нужно делать вручную. Конфликты бывают явными (например, в одном месте записано "в ситуации X надо выполнять Y", в другом - "в ситуации X надо выполнить Z". 5) Упорядочение требований по их важности и стабильности. Требования нужно рассматривать по их важности для клиента. Это позволяет управлять масштабом. Можно приписать требованиям и дополнительные атрибуты (см. концепцию). Оценка стабильности задаётся пользователем или заказчиком (изменение законодательства, изменение форм отчётности и т. д.) 6) Проверяемые требования. Требования в целом являются верифицируемыми тогда и только тогда, когда каждое из составляющих его элементарных требований является верифицируемым. Элементарное требование считается верифицируемым тогда и только тогда, когда существует конечный финансово эффективный процесс, с помощью которого человек или машина могут определить, что разработанная программная система действительно удовлетворяет данному требованию. Очевидно, невозможно доказать, что каждое требование является верифицируемым. Пример: система должна одновременно поддерживать сто пользователей => возникает вопрос об ограничении действий пользователей. 7) Модифицируемый набор требований. Множество требований является модифицируемым тогда и только тогда, когда его структура и стиль таковы, что любые изменения требований можно произвести просто, полно и согласованно, не нарушая существующей структуры и стиля всего множества. Для этого требуется, чтобы пакет имел минимальную избыточность и был хорошо организован в соответствии с содержанием, индексом и возможностью перекрёстных ссылок. Трассируемые требования Требования в целом являются трассируемыми тогда и только тогда, когда ясно происхождение каждого из составляющих его элементарных требований и существует механизм, который делает возможным обращение к этому требованию при дальнейших действиях по разработке. На практике это означает, что каждое требование должно иметь уникальный номер или идентификатор. Качество пакета MSRS 1) Качество оглавления: хороший пакет должен иметь хорошее оглавление; заголовки сами могут быть источником полезной информации о проекте, обычно рекомендуется использовать 3-4 уровня заголовков. 2) Качество индексации: создание индексов - более сложный процесс, чем составление оглавления: а) необходимо определить элементы, по которым будет производиться индексация; б) индексацию следует выполнять при добавлении в пакет каждого нового требования. История исправлений: каждая спецификация должна содержать страницу истории исправлений и содержать как минимум код исправления, дату исправления, краткое описание исправления, имя человека, ответственного за исправление. 3) Неоднозначность и уровень конкретизации требований _ _ ( ) ( ) | | | | +-+-+--+-+-+ | чет нечет| | (Счёт)| |(Вкл.) | | (Выкл.)| +----------+ Функции: а) управляется микропроцессором; б) отслеживает, чётное или нечётное число раз была нажата кнопка счёта; в) детектор перегорания ламп заставляет мигать лампу, которая осталась исправной. Возможная спецификация требований: от нажатия кнопки "включено" до нажатия кнопки "выключено" система является включённой; от нажатия кнопки "выключено" до нажатия кнопки "включено" система является выключенной и ни одна лампа не должна гореть; если любая из ламп перегорает, каждая из ламп должна мигать каждую секунду. Вопросы: а) когда наступает момент мигания?; б) какова длительность мигания? ь| т| с| о| _-_ н| / \ т| / \ я| / \ н| / \ о| / \ П|---/ \--- +--------------------- Степень конкретизации Полностью устранить неоднозначность требований на естественном языке невозможно, однако её можно уменьшить, используя следующие методы: а) эвристика запоминания: необходимо попросить нескольких разработчиков и заинтересованных лиц по памяти вспомнить требования клиента; непонятная часть наиболее трудно вспоминаема и на неё стоит обратить внимание; б) метод ключевых слов: необходимо выделить ключевые слова и выписать их определения, пользуясь авторитетным источником, признаным различными участниками проекта; затем нужно скомбинировать различные интерпретации; например, для слова "мигать" получились бы интерпретации "загораться" и "гаснуть"; в) метод ударения: необходимо читать требования, выделяя интонацией ключевые слова, ища все возможные интерпретации; если верна только одна интерпретация, следует переформулировать требования надлежащим образом; например: Служащий X вводит данные Y в систему Z.