ПОИСК
Это наилучшее средство для поиска информации на сайте
Получение требований из системной модели
из "Разработка и управление требованиями "
Как отмечалось ранее, системная модель может состоять из нескольких независимых и потенциально перекрывающихся моделей. Можно начинать формирование требований из любой из разработанных моделей, как это пояснялось в предыдущих разделах на примерах модели банка и автомобиля. Однако проблема состоит в том, что достаточно сложно сразу получить хорошую структуру для требований, в которой каждое требование однозначно занимало бы свое исконное место. И при этом каждое свободное место в этой структуре означало бы некое поле для маневра дизайнерской мысли, а не присутствовало потому, что что-то упущено. Разработка структуры документа уже рассматривалась нами в главе 4. [c.147]Как только разработана и согласована структура требований, начинается процесс сбора производных требований и размещения их в полученной структуре. Вполне возможно, что некоторые входящие требования могут быть сразу и без изменений помещены в структуру документа. Если это происходит, то обычно свидетельствует о том, что входящие требования весьма детализированы, т.е. очень близки к реализации. [c.148]
Если же вы только начинаете формулировать требования, то самое лучшее - это руководствоваться всеми правилами для написания хороших требований , приведенными в главе 4. Всегда помните и соблюдайте золотое правило - каждое требование должно представлять собой единственное утверждение, реализацию которого можно проверить (т.е. каждое единичное требование должно быть пригодно для тестирования). Как только производное требование сформулировано, необходимо установить связь, идущую от него обратно к одному или более входящим требованиям, которые данное (только что сформулированное) требование удовлетворяет полностью или частично. [c.148]
Когда мы рассматриваем пригодность требования для тестирования, имеет смысл сразу задуматься о критериях, которые будут характеризовать пройден тест успешно или нет. Эти критерии приемки должны быть зафиксированы для каждого требования. В некоторых случаях такой критерий может включаться непосредственно в текст требования, как, например, характеристика производительности. Но в основном рекомендуется отражать приемочный критерий в отдельном атрибуте конкретного требования. [c.148]
После определения критериев приемки (и производительности) необходимо рассмотреть способы, с помощью которых будет демонстрироваться тот факт, что система удовлетворяет этим приемочным критериям. Иными словами, необходимо определить критерии приемки, стратегию проверки, разработать необходимые программы испытаний и инспекций. [c.148]
На том этапе необходимо также оценить степень трудоемкости тестирования и определить, какое тестовое оборудование потребуется для испытаний. Может вполне оказаться, что организация тестирования потребует отдельных разработок, а в некоторых случаях, даже запуска отдельных (дополнительных) проектов. [c.148]
Заключительным набором требований, который также следует рассмотреть, являются ограничения, которые не добавляют дополнительной функциональности, но ограничивают способ, которым может быть реализована необходимая функциональность. На уровне системных требований часть ограничений может без изменений переноситься из пользовательских требований. Например, геометрические параметры системы могут быть жестко заданы заинтересованными сторонами, или заказчики настаивают на том, что одна из существующих систем должна входить в виде подсистемы в новую систему. [c.149]
Вернуться к основной статье