Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 54
Текст из файла (страница 54)
Пока Жилец продолжает удерживать кнопку, происходит следующее. 1. Яркость контролируемого источника постепенно повышается до максимального значения со скоростью 10 процентов в секунду. 2. Когда достигнуто максимальное значение, яркость контролируемого источника постепенно понижается до минимального уровня со ско. ростью 10 процентов в секунду.
э. Котла достигнуто минимальное значение, процесс продолжается с и<ага 1. Когда Жилец отпускает кнопку, происходит след>эощее. 4. Система прекращает изменять яркость освещения. Глава 24. Уточнение прецедентов 251 Выявление пред- и постусловий Иногда необходимо выявить предусловня, которые влияют на поведение системы, описанное прецедептои, а также описать постусловия, такие как состояние системы и перманентные данные, полученные после завершения прецедента. Но использовать пред- и постусловия нужно только тогда, когда необходимо прояснить поведение, выраженное прецедентом.
Важно проводить различие между событиямн, которые запускают потоки прецедента, н прсдусловиями, которые должны быть выполнены до того, как люжно будет инициировать прецедент. Например, предусловием для прецедента "Управление освещением" является то, что домовладелец (Жилец) должен обеспечить наличие определенного набора осветительных приборов, способных изменять яркость. Еще одним прсдусловнем является то, что вьюраниая кнопка пульта должна быть запрограммирована для управления атил~ набором.
(Предполагается, что другис прецеденты описывают. как осуществляются этн предусловия.) Итак, нам нужно сформулировать прсдусловия. Предусловии для прецедента "Управление освещением" ° Для выбранной кнопки пульта должен быть предусмотрен режим "Изменение яркости". ° Выбранная кнопка пульта должна быть предварительно запрограм- мирована длн управления неким набором осветительных приборов. Часто необходимо выявлять и включать в документацию постусловия. Онн позволя. ют точно указывать состояние, которое должно быть истинным по окончании прецедента, даже если использовались альтернативные пути.
Чтобы яркость была такой, как нужно, когда Жилец включает свет в следующий раз, система должна "помнить" уровснь яркости, который был установлен для выбранной кнопки пульта после действий по изменению яркости. Следовательно, это постусловие, которое мы должны записать для данного прецедента. Постусловии для прецедента "Управлеиие освегцением" в После окончания данного прецедента запоминается тек)чцнй уровень яркости для выбранной кнопки пульта.
Теперь соберем все это вместе, В табл. 24.1 содержится все, что получится после того, как л~ы объединим все важные "кусочки" нашего прецедента. (Хотя для прецедента мож. но определить еще много других элементов, они не так важны для нас на данном этапе.) Этот прецедент документироваи в повсствовательном стиле, его можно найти среди артефактов системы НО1.1Б в приложении Л. Таблица 24.1. Определение прецедента Значение Элемент Увфп вввн ив освпцен иви Нпвванив н(яцвденнив Краенов онисание Данный прецедент определяет способ включения н выключения света, а также изменения его яркости а зависимости от того, как долго пользователь удерживает кнопку пульта в нажатом состоянии 252 Часть Ь. Уточнение определения системы Окончание еабв.
241 Значение Элемент Основной поток событий начинается, когда Жилец нажимает кнопку пульта ("Упражнение включениелс"). Певек гвбнеий Если Жилец отпускает ююпку в течение периода времени, отсчиты- ваемого таймером, системз "перскеочает" состояние освещения. Это овна ~ает слел1тоще. ° Если свет был включен, он полностью выключается ° Если свет был выключен, оп включается с тем же уровнем яркости, который был перед последним выключением Если Жилец удерживает кнопку пульта в нансатом состоянии более од- ной секунды, система инициирует действия по изменению яркости для указанной кнопки, Л вьнирна геле нллй нвевн сабы еий Пока Жилец продолжает удерживать кнопку в нажатом сотоянпн, про- изводятся следующие действия.
1. Яркость контролир1емого источника постепенно повышаетсн до максимального значения со скоростью 10 процентов в секунду 2. Когда достигнуто максимальное значение, яркость контролируемо. го источника постепенно снижается до ллинимального уровня со скоростью 1О процентов в секунду $. Когда достигнуто миниллальное значение, процесс продолжаетсн с шага 1 Когда Жилец отпускает кнопку пульта происходит следукнцее. 4. Система прекращает изменять яркость источника ° Выбранная кнопка пульта должна иметь режим, допускающий изменение яркости Предуонмил е Выб1жнная кнопка должна быть предварительно запрограммирована для управления неким набором осветительных приборов По окончании прецедента установленная яркость заполшнается систсьюй 13ослнусвввил Минимальный уровень освеп1еилгя не должен быть раасн О.
Оп должен быть не очень ярким, соответствующим уровню ночного освещения Снеоемьные е~кбсвакил Далее.. После того как все прецеденты выявлены и описаны приблизительно на таком уровне детализации, процесс уточнения той части системы, которую мы решили описывать с помощью прецедентов, заканчивается.
В следующей главе лгы рассмотрим создание спецификаций. Глава 25 Спецификация требований к программному обеспечению (Мооегп Бочаге Кецп1геп~еп1ь Ярес1йсай1оп) Основные положении И Пакет спецификаций требований к программному обеспечению (Модегп ЯЮ Рас)саке) представляет собой набор артефактов, полностью описывающих внешнее поведение системы. Он создает концептуальную модель создаваемой системы. И Докуменгкоицепция (%ьюп досшпегн) служит исходной информацией для создания Модегп Ясэ Рас)шяе. Он определяет потребности пользователей, цели, задачи, целевые рынки н функции системьь в то время как в пакете Мос(егп Ясо Рас)саке основное внимание уделяется деталям реализации этих функций.
И Сбалансировшппяй подход, как правило, закшочается в совместном использо. ванин модели прецедентов и традиционной спецификации требований. После уточнения понимания светелкам настало время разработать стратегию организации и документирования требований. Хотя большая часть усилий в этом процессе действительно направлена на организацию выявленных и детализированных требований к программному оосспечепию, доюшентов, прецедентов и моделей, самым важным является то, что сооокуннопнь данных аряифактоо прсдсншолясгл полную концептуальную хюдгль создаоаемой аннимьь Говоря коротко, лля начала у пас есть части относительно полной концептуальной структуры, с помощью которой мы можем рассуждать о будущей системе. Скорее всего, се еще нельзя потрогать (хотя, возможно, мы уже видели некоторые раскадровки и прототипы), по уже можно начать ее анализировать и проверять наше поиимание системы, несмотря на то что она до сих пор существует только на бумаге и в виде моделей.
Можно сказать, что ь~ы подошли к важному рубежу: созданию концептуальной модели или но. срсдника ()згоху) системы, которую надо построить. 254 Часть 5. Уточнение определения системы Пакет спецификаций требований к программному обеспечению (Мойегп ЯКБ Раска~е) Исторически сложилось, что наиболее популяриый метод документирования требоваиий состоял в )порядочеииой их записи иа естественном языке. Этот метод пересл~атривался и совершеиствовался в ходе выполнения множества проектов, и постепенно бьи разработав ряд стандартов для подобных док)ыеитов, в том числе стандарт 1ЕЕЕ (1пэгпше оГ Е!ес[гка! апб Е!ессгопйз Епк!пеегз) 830: Ьгапс$агс$ Гог 8оймаге Ке9п!гешешг прес!Ксапоп (1994). Но сегодня при наличии совремеииых инструментальных средств и методов чм предпочитаем представлять спецификацию программиых требований (8К5) в виде ло. гической структуры, а ие физического документа.
Различиые детально описанные требоваиия к системе заключаются в пакет. который мы иазываем современным пакетом спецификаций требований к программиому обеспечению (Мос1егп Боймаге Ке9п!гегпспц Ярес!Ясапоп Рас(сабе), в отличие от более ранних форм, которые именуются просто 8К5. Пакет Мос)сгп ЯК8 Рас)сабе связан с докумеитом-концепцией, который служит исходной ииформацисй для его создания. Однако эти два артефакта служат разным целям и, как правило, пишутся разиыми аа торами. На даши1й стадии проекта акцент смещается от общей формулировки потрсбио. стей пользователя, целей, задач, целевых рынков и функций системы к детальноьп описаиию того, как эти функции предполагается реализовывать в решеиии.
На рис. 25.! схематически представлены элсмеиты пакета. На данном этапе иам мужем пакет информации, полностью описывающий вяплягг поведение системы, т.е. набор артефактов следующего содержания: "Вот то, что систеиа должна делать, чтобы предоставить эти функции". Это и есть Мос(егп БКБ Расйабе. Нет веских причин уделять виимаиие различиям между используемыми ииструмеитальиыми средствами. В конце копцов, мы собираем требования и должны обращать виимаиис иа эффсктивиость их сбора и оргаиизации бсзотиосительпо к тому, какие средства используются.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
