Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 61
Текст из файла (страница 61)
° Акторы должны иметь простые осмысленные имена, которые смогут понять поль. зователи и клиенты. Важно, чтобы имена акторов соответствовали их ролям. В противном случае их необходимо переименовать. Критерии качества пакета Мойегп буКЯ Расйаае Помимо индивидуальных критериев качества существуют критерии, применяемые к самому пакету. Эти критерии позволяют удостовериться, что сам пакет является высоко. качественным и понимаемым. При работе с документацией сложнее всего найти необходимую информацию. Сколько раз вы говорили: "Я экаю, что требование. касающееся безотказности, находится где.
то здесь," но не могли найти его. Слишком часто мы думаем, что достаточно просто эа. фиксировать собранные требования. Но это ие так. Мы обнаружили, что Мобегп БВБ Рас)гаке ие просто организовывает и хранит гребо. ванна; он также упрояГоет их ислааьэоэание. Хороший пакет спецификаций обладает следующими характеристиками. Хорошо составленное оглавление Обязательным элементом хорошего 535 является хорошо составленное оглавление (ТаЫе ог Сопгепм.
ТОС). Мы убедились, что ТОС предоставляет еще больше преиму. ществ, чем может показаться иа первый взгляд. Например, стремление к хорошему ТОС подталкивает автора к использованию полезных заголовков, которые затем возникают в оглавлении ЬИ8. Посмотрите иа оглавление данной книги, и вы заметите, что заголовки Глава 27. Критерии качества требований к программному обеспечению 279 сами по себе могут служить руководством для читателя. Таким образом, оглавление на.
поминает сжатую версию пакета. При наличии современных инструментальных средств непростительно не иметь ог. давления. Оглавление создается автоматически; автор может выбрать необходимый уро. вень детализации и форматирование. Мы считаем, что трех или четырех уровней зато. ловков вполне достаточно для обеспечения нужного уровня детализации пакета Мобегп БКБ Рас!сабе. Для того чтобы отделить друг от друга основные элементы оглавления, по.
лезно использовать дополнительные промежутки. Одной из часто встречающихся проблем является то, что ТОС не обновляется так, как это нужно для отражения текущего вида пакета. Следует удостовериться, что в про. пессе публикации БКБ всегда обновляется ТОС, чтобы гарантировать правильность разбиения на страницы. Оглавление становится ненужным, если оио не обновляется. Из-за этого читатель начинает беспокоиться, что в БКБ что-то не так. К сожалению. оглавление сложно создавать, если необходимо включить в него не. сколько разнородных документов. Предположим, готовится БКБ-пакет, содержащий не. сколько документов ЪУоп3, несколько разработанных с помощью другого средства спецификаций прецедентов и несколько выполненных в Ехсе! схем.
Невозможно найти сред. ство, которое сможет одновременно работать с подобными входными данными и подготовить хорошее оглавление. В таких случаях можно попытаться создать многотомное оглавление, в котором верхний уровень используется для указания основньпс групп, таких как документы Ътоп!, файлы модели прецедентов, электронные таблицы Ехсе!. Затем можно применять отдельные ТОС-средства для создания оглавлений каждой из групп.
Хороший индекс Индексы являются важной составной частью любого БКБ. В отличие от оглавлений, создание индексов — более сложное дело, так как авторы должны определить, по каким элементам будет проводиться индексация. После этого создание индекса не представляет труда. Часть проблем индексации является следствием различия представлений, поддерживаемых командой проекта. Например, в медицинском приборе требования восстановле. ния после ошибки предохранительного устройства могут рассматриваться как "предохранительный" элемент одними членами команды и кзк элемент "исправления ошибки" другими членами.
Обе точки зрения правильны; данные требования следует проиндексировать двумя способами. Откровенно говоря, над индексацией приходится поработать, но, как правило, это нужно делать только один раз для каждого добавляемого в БКБ нового требования. После этого элементы индекса существуют вместе с пакетом и становятся важной частью понимания проекта. Индексирование следует использовать для того, чтобы иметь доступ к пакету, помимо ТОС. Иными словами, не имеет смысла создавать индекс, элементы которого уже есть в оглавлении. Необходимо такое индексирование, чтобы читатель мог обратиться к понятиям, а пе к заголовкам.
Как и оглавления, индексы всегда следует обновлять в процессе публикации, чтобы обеспечить целостность пакета. 280 Часть 5. Уточнение определения системы История исправлений Крайне неприятно обнаружить. что вы просматривали устаревшую версию БВБ. Кале дая спецификация требований должна содержать страницу, посвященную истории исправлений, где хранится информация о соответствующих изменениях каждой версии элементов пакета. Как минимум, эта страница должна содержать следующую информэ цию. ° Номер исправления или код каждого изменения опубликованной информации ° Дату каждого исправления опубликованной информации ° Краткое описание произведенных исправлений ° Имя человека, ответственного за исправление Кроме того, может оказаться полезным снабдить каждый изменяемый элемент Яб маркером исправлений.
Отметки о внесении исправлений на полях полюгзкзт читателю найти изменения. Большинство современных автоматических средств работы с документацией и требо. ваниями обеспечивают мощные возможности контроля исправлений и автоматического ведения истории версий. Пользуйтесь ил~и! П)>едосямрезсение. Не устанавливайте контроль исправлений слишком рано (см. главу 34, "Управление изменениями"). Во время внесения исправлений одно и то же требование можно переделывать несколько раз, прежде чем его удастся удовлетворительно сформулировать. Не имеет смысла записывать все эти попытки; поэтому не включайте для пакета режим контроля исправлений, пока не достигнете относительной стабильно. сти в процессе разработки программы.
С другой стороны, не стоит слишком откладывать, в противном случае вас захлестнет неуправляемый процесс. Глоссарий Так как природа каждой прикладной области уникальна, в проектах со временен стремятся разработать специальный язык или систему сокращений. Чаще всего сокращения бывают мнемоническими, например "БКБ". Их следует по возможности избегать. Также нужно воздерживаться от использования терминов, имеющих смысл только в контексте определенной ситуации. Хороший БКБ содержит словарь таких терминов, чтобы помочь пользователям понять язык данной прикладной области. Следует позаботиться о том, чтобы включить в глоссарий объяснения всех специфических терминов проекта, аббревиатур и специальных фраз.
Глава 28 Теоретически обоснованные формальные методы спецификации требований ;;"Основпъге воложеннж ' ° Формальные методы спецификации требований применяются тогда, ко-:. гда.'описание требований слишком сложно для естественного язъва или ° вам не удается создать недвусмысленную спецификацию. ° К формальным методам относится использование псевдокода, конечных ,,', автоматов, деревьев решений, диаграммдеятелъносги,модеяей сущность- ~.ц,",1.* .-',' '* связь, объектно ориентированных моделей и схем потоков данных. До сих пор мы исходили из предположения, что болылинство требований будет написано на естественном языке команды разработчиков (в форме традиционных утвер.
ждений илн прецедентов). Кроме того, предлагалось сопроводить требования диаграммами, таблицами, схемами и т.п., чтобы прояснить значение требований пользователя. Но иногда присущая естественному языку неоднозначность просто неприемлема, осо. бенно когда требования касаются жизненно важных вопросов или когда неправильное поведение системы может привести к чрезвычайным экономическим или юридическим последствиям. Если определение требования сложно сформулировать на естественном языке и невозможно предотвратить неправильное понимание спецификации, следует попытаться написать эту часть требований с помощью теоретически обоснованных формальных методов.
Можно выбрать одно из перечисленных ниже формальных средств спецификации. ° Псевдокод ° Конечные автоматы ° Деревья ре~нений ° Диаграммы деятельности (блок-схемы) ° Модели сущность-связь ° Объектно-ориентированные модели ° Схемы потоков данных 282 Часть Б. Уточнение определения системы Мы не будем подробно описывать применение какого-либо из этих средств, так как каждое из них достойно отдельной книги. Мы просто предлагаем краткий их обзор. В Модегп ЬКБ Рас)са8е формальные методы следует использовать экономно и последовательно. При выборе конкретного формального метода необходимо руководствоваться здравым слгыслоьь При создании системы управления ядерным реактором, возможно, каждый аспект системы является критическим; однако в болынинстве систем не более 10 процентов требований требуют такой степени формальности.
Если это возможно, следует использовать только один из этих формальных методов для всех требований определенной системы. Это упростит не очень подготовленному читателю задачу прочтения и понимания элементов пакета. Если все разрабатываемые организацией системы относятся к одной прикладной области, такой, например, как те. лефонные системы коммутации, то можно использовать один и тот же формальный ме.
тод для всех систем. Но в большинстве организаций нереально придерживаться единст. венного метода для всех требований во всех системах; тот, кто пишет требования, должен выбрать подход, наиболее соответствующий конкретной ситуации.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
