Соглашение о требованиях



2 Соглашение о требованиях

Составление соглашения о требованиях — цель второй части первой лабораторной работы. Также соглашение о требованиях является вторым разделом курсовой работы.

Ниже дается описание разделов, которые должны присутствовать в любом соглашении о требованиях (СТ) согласно ГОСТу. Все последующие упоминания о соглашении о требованиях имеют в виду соглашение о требованиях, разработанное в соответствии с данным разделом. Описываемый подход предполагает также декомпозицию проекта и дальнейшую детализацию, отражаемую во внешней спецификации изделия.

Предполагается, что все утверждения, включенные в соглашение о требованиях, являются требованиями, если они не определены как цели. Различие состоит в том, что требование должно быть обязательно выполнено, а цель допускает ее достижение с некоторым приближением.

Описание информации, содержащейся в СТ, дается ниже очень подробно, и, возможно, после чтения первых абзацев появится желание ограничиться беглым просмотром. Однако если вам когда-нибудь придется разрабатывать свой собственный стандарт СТ, вы, вероятно, оцените предлагаемый здесь со всеми подробностями пример и используете его как образец. С учетом того, что сжатость заголовков разделов и большой объем их описаний скрывают порядок и простоту, лежащие в основе результирующего документа, в конце каждого пункта приводится пример оформления на конкретное изделие. Вероятно, вам опять не захочется читать все приложение целиком, поэтому рекомендуется для начала бегло просмотреть его, чтобы получить представление, как выглядит типичное СТ в целом. Затем можно будет обращаться к отдельным его разделам, чтобы иметь дополнительные примеры, иллюстрирующие приводимый материал.

2.1 Описание программного изделия

2.1.1 Наименование и шифры изделия

2.1.1.1 Полное наименование изделия

Указывается предлагаемое полное наименование изделия. После утверждения СТ не должны использоваться никакие другие наименования для данного изделия, кроме сокращенных наименований, которые приводятся ниже.

Пример. ASK (произносится «аск»).

2.1.1.2 Сокращенные наименования

Указываются все предлагаемые сокращения, которыми разрешается заменять наименование, приведенное в пункте 2.1.1.1. После утверждения СТ не рекомендуется использовать никакие другие сокращения. В противном случае делается пометка «Отсутствуют».

2.1.1.3 Шифры изделия

Указываются шифр или шифры изделия, присвоенные в соответствии с требованиями удобства управления его конфигурацией. Если предполагается выпуск печатных изданий и разработка планов поддержки, порядок присвоения шифров конечным результатам работы группы выпуска документации и группы поддержки может быть иным.

Пример. L301A.

2.1.1.4 Шифры проекта

Приводятся все шифры проекта, используемые в процессе разработки изделия.

Пример. C013.

2.1.2 Краткое описание изделия

Описываются кратко и в общих понятиях основные функциональные свойства изделия. Если программное изделие является расширением уже существующего, характеризуются только его новые свойства.

Пример. ASK позволяет специалисту по финансовому анализу или другому лицу с аналогичными аналитическими задачами в интерактивном режиме и на расстоянии запрашивать ЭВМ серии Stella 100 выполнить поиск и обработку финансовой информации из DATABASE, которая содержит фундаментальные сведения и зависимости по данным за 20 лет для большого числа корпораций и отраслей. ASK может также формировать дополнительные общедоступные или частные сведения, файлы корпораций и отраслей, выражения и элементы и использовать их вместе с информацией из DATABASE.

Программное изделие ASK в совокупности с DATABASE образует сервисную систему ASKDATABASE; все три системы являются собственностью фирмы ABCServices.

2.1.3 Сведения об авторском праве

Если предполагается заявить об установленной законом защите авторских прав на данное изделие, это должно реализоваться уже в CТ. В противном случае делается пометка «Не требуется».

Пример. Copyright© 1977 byABCComputersCompany.

2.1.4 Результирующие компоненты изделия

В данном разделе приводится таблица, подобная или эквивалентная таблице 2.1. В данном случае использована заранее подготовленная печатная форма, что уменьшает время подготовки информации и обеспечивает ее согласованность.

В указанной таблице в строке «Тип изделия» ставится метка X против соответствующей характеристики «Основное» или «Вспомогательное». Если изделие не используется для создания других изделий, оно отмечается как основное. В противном случае (например, ассемблер, компилятор или генератор) оно отмечается как вспомогательное.

В графе «Уровень поддержки» выбирается метка 1, 2 или 3 в соответствии с пояснениями в бланке.

Каждый элемент изделия отмечается меткой X в графе «Формируется целиком», если он будет создаваться заново, или в графе «Модифицируется», если будут вноситься только дополнения или изменения. Метка X ставится в графе «Распространяется» (за пределы группы разработки) или «Не распространяется» (за пределы группы разработки) в зависимости от того, что является правильным. В графе «Ответственная группа» пишется Р, И, П или C — по ключу на бланке. Если предполагается выпуск нестандартных изделий, этот факт отмечается в графе «Другие спецификации» и описание соответствующих документов дается сразу после таблицы.

Таблица2.1 — Результирующие компоненты изделия

Обозначения:

Основное изделие — не используется для создания других изделий

Вспомогательное изделие — используется для создания других изделий

Уровень поддержки 1: удовлетворяются заявки на исправление дефектов; возможно сообщение об изменениях; принимаются заявки на расширение функциональных возможностей изделия

Уровень поддержки 2: удовлетворяются заявки на исправление дефектов; возможно сообщение об изменениях; заявки на расширение не принимаются

Уровень поддержки 3: удовлетворяются заявки на исправление дефектов

Р — группа разработки

Формируется целиком

Модифицируется

Распространяется

Не распространяется

Ответственная группа

Спецификации

Внешняя спецификация

X

X

Р

Внутренняя спецификация

X

X



Р

Спецификация испытаний (не надо)

Спецификация сопровождения (не надо)

Другие спецификации

Документация

Техническое описание системы

Справочное руководство

X

X

Б

Окончание табл. 2.1

Справочный буклет

X

X

Б

Руководство оператора

X

X

Б



Тип изделия

Основное

X

Начальный уровень поддержки

Указатель системных сообщений

X

X

Б

Вспомогательное

Информационный листок выпуска

1

X

Другие печатные издания

2

Рекламные материалы

3

Программное обеспечение

Листинги

X

X

Р

Исходные модули

X

X

Р

Объектные модули

X

Р

Контрольные примеры

X

X

Р

И

Средства разработки

X

Прочие средства

Листинги представляют собой комплект распечаток, полученных при компоновке и трансляции программного изделия.

Исходные модули содержат совокупность операторов, которые должны быть ассемблированы или откомпилированы для получения готовой программы.

Объектные модули представляют собой редактируемые или загружаемые программы на машинном языке, получаемые в результате ассемблирования или компиляции исходных модулей, или программу, которая порождается некоторым генератором (если она пригодна для непосредственного выполнения или интерпретации).

Отладочный материал используется для доказательства того, что программное изделие может быть правильно ассемблировано, откомпилировано, отредактировано, загружено и выполнено. Отладочный материал может включать листинги, исходные модули, объектные модули и процедуры.

Средства разработки включают ассемблеры, компиляторы, загрузчики, процедуры получения дампов и тому подобные средства, разработанные в рамках данного проекта с целью получения программного изделия.

2.2 Цели

Формулировка цели создания программного изделия отвечает на вопрос «зачем?». Поэтому в данном разделе указываются все причины выпуска изделия. Часто такой причиной может быть выполнение плана или договора либо устранение недостатков предшествующего изделия.

Пример. Коммерческим планом финансовых служб предусматриваются создание в фирме ABC Services и поставка на рынок интерактивной системы финансового анализа с дистанционным доступом, предназначенной для финансовых кругов. Система ASK призвана удовлетворить требования к программному обеспечению, изложенные в коммерческом плане.

2.2.1 Согласование заявок на проверку

Заявки на проверку представляют собой предписанные изменения изделия, которые являются результатом событий, находящихся вне сферы контроля разработчиков изделия. Если заявки на проверку отсутствуют, этот факт отмечается и пункты 2.2.1.1 и 2.2.1.2 опускаются.

2.2.1.1 Отклоненные заявки

Обычно такие заявки отсутствуют, поскольку внесение изменений является обязательным. Однако учет какого-либо конкретного изменения все же может оказаться нецелесообразным, в этом случае отказ должен быть тщательно обоснован и документирован, начиная с данного раздела СТ.

2.2.1.2 Принятые заявки

Здесь перечисляются все предлагаемые в заявках изменения, которые были одобрены и будут включены в изделие. Если таких заявок нет, следует дать пометку «Отсутствуют».

2.2.2 Согласование заявок на расширение

Если заявок на расширение нет, этот факт отмечается и пункты 2.2.2.1 и 2.2.2.2 опускаются.

2.2.2.1 Отклоненные заявки

Перечисляются все предложения, касающиеся расширения изделия, которые были специально рассмотрены с точки зрения их реализации, но не могли быть приняты, указываются причины их отклонения. Если таких предложений нет, делается пометка «Отсутствуют».

2.2.2.2 Принятые заявки

Перечисляются все предложения на расширение, которые были одобрены и будут реализованы в изделии. Если таких предложений нет, делается пометка «Отсутствуют».

2.2.3 Согласование заявок на внесение исправлений

Если предметом рассмотрения СТ является новое изделие, которое не предназначается для замены другого изделия, внешних запросов на внесение исправлений быть не может. В этом случае делается пометка «Не требуется» и опускается пункт 2.2.3.1.

2.2.3.1 Отклоненные заявки

Если целью является переработка или расширение изделия либо замена изделия с известными ошибками, следует планировать исправление ошибок, обнаруженных на данный момент времени. Поэтому в этом пункте пишется примерно следующее: «Все существенные ошибки, зарегистрированные до последнего срока подачи заявок на внесение исправлений (этап СТ), будут исправлены. Заявки, полученные в период между СТ и датой готовности продукта, будут удовлетворены по возможности». Здесь же отмечаются все существенные ошибки, зарегистрированные до появления СТ, которые не будут исправлены (как правило, в связи с технической сложностью), а также причины такого решения. По мере продвижения работы над проектом неудовлетворенные заявки на внесение исправлений могут накапливаться и фиксироваться. Если такие заявки накопятся, данный раздел СТ должен быть изменен.

2.2.4 Согласование планов

2.2.4.1 Исключенные пункты плана

Если имеются какие-либо плановые указания, требующие особых свойств и возможностей программных средств, которые не могут быть обеспечены, если изделие разрабатывается в соответствии с другими требованиями, описанными в СТ, каждое такое указание необходимо рассмотреть отдельно и пояснить, почему оно будет исключено. Если таких указаний нет, делается пометка «Отсутствуют». Отмечаются также и все другие свойства (не фигурирующие в заявках на расширение), которые были детально рассмотрены и исключены.

Пример. Широкий набор терминальных устройств, требуемый в коммерческом плане финансовых служб, не будет обеспечен. С системой ASK будет эффективно работать только устройство Telcoscope 43 или электрически и функционально эквивалентные терминалы. Рассмотрение команд графического вывода (вместо выдачи таблиц) и сортировки файлов откладывается до следующей версии.

2.2.4.2 Включенные пункты плана

Если необходимость создания изделия обоснована таким документом, как план выпуска изделия, план выпуска серии или описание задачи, то цитируется либо определенное место из каждого документа, либо приводится краткое содержание соответствующих разделов. Плановые указания устанавливают (в самых общих чертах), что должно делаться и почему. Эти указания отличаются от технических обоснований, определяющих в конкретных понятиях технические предпосылки осуществления того, что должно делаться. Для каждой цитаты делается отсылка к соответствующей записи в разделе 2.4.1 СТ.

Пример. Коммерческий план финансовых служб, раздел 5 (см. п. 2.4.1 а).

2.2.5 Перечень требований пользователя

Указываются заказчики изделия и поясняется, почему оно им необходимо. В этом разделе указывается также предполагаемый срок использования изделия. Обычно это будет срок службы оборудования или время до выпуска изделия-преемника. Если данное изделие должно быть заменено, указывается наименование изделия-преемника. Цель этого раздела — дать некоторое представление о степени сложности условий работы программ.

Пример. Система ASK предназначается для специалистов по финансовому анализу или других лиц с аналогичными аналитическими задачами, как, например, управляющий по контролю и регулированию портфеля заказов. Ожидается, что пользователи не знакомы с программированием и не имеют подготовленных операторов терминалов.

В соответствии с документом, указанным в пункте 2.4.1 a, первая версия ASK должна быть готова для продажи через 6—12 месяцев, а вторая версия — не позже, чем через 18 месяцев.

2.2.6 Рассмотренные альтернативы

Кратко описываются альтернативы данной разработки, которые были рассмотрены и отклонены, а также причины отклонения. Если программы должны быть закуплены, поясняется, почему они не могут быть разработаны собственными силами, и наоборот. Лица, критически анализирующие СТ, могут потребовать весомых доказательств необходимости разработки программ, поэтому следует всегда убеждаться, что в данном разделе имеется такой материал.

Пример. Поскольку в распоряжении фирмы ABC Services нет ни одного программного изделия, которое может выполнять функции ASK, должно быть разработано новое изделие. Действующих аналогов в готовом виде не существует. Фирма ABC Services решила заключить единственный договор с фирмой ABC Computers о создании и сопровождении ASK; это решение основывается на прошлом положительном опыте заключения договоров с фирмой ABC Computers.

2.2.7 Окупаемость капиталовложений

Определяется прибыль, которую даст создание изделия, в понятиях, соответствующих целевому назначению организации.

Пример. Фирма ABC Services ожидает, что объем сбыта в финансовой сфере увеличится на 10% в течение 3-х месяцев с момента выпуска изделия и достигнет примерно 170% в течение первого года с момента выпуска. В результате ожидаемой большой прибыли от такого увеличения объема сбыта затраты на разработку изделия ASK окупятся через 8 месяцев после выпуска, что без новой версии ASK даст полную валовую прибыль, в три раза превышающую суммарные затраты на его разработку и сопровождение.

2.3 Стратегия

Формулировка стратегии предполагает ответ на вопрос «что?». Поэтому в данном разделе указывается, что будет представлять собой предлагаемое изделие.

2.3.1 Соглашения относительно представления материала

Для краткого описания изделия может понадобиться специальная терминология. Данный раздел предназначен для того, чтобы представить читателям СТ специальный словарь. И если в пунктах 2.3.1.1 и 2.3.1.2 внешней спецификации можно делать дополнения, то в данном разделе СТ ни одна формулировка не должна меняться.

2.3.1.1 Обозначения

Определяются все обозначения, используемые в СТ. Например, если применяются индексы, дается пример их использования и определяется принцип индексации. В противном случае делается пометка об отсутствии специальных обозначений.

2.3.1.2 Терминология

Четко определяется вся терминология, которая может оказаться специфической для данного изделия.

Пример. Вся специальная терминология определяется в контексте данного документа.

2.3.2 Генерируемое программное обеспечение

Генерируемое программное обеспечение — это то, что получается на выходе компилятора, ассемблера, загрузчика, редактора связей или генератора прикладных программ. Генерируемое программное обеспечение классифицируется как вспомогательное и порождается изделием, описываемым в СТ.

2.3.3 Системное программное обеспечение

Системное программное обеспечение — это все остальное программное обеспечение, включающее операционные системы, компиляторы, утилиты, пакеты прикладных программ и др. Это программное обеспечение относится к основному типу и является изделием, описываемым в СТ.

Разделы 2.3.2 и 2.3.3 строятся одинаково. Там, где слова «программное обеспечение» или «изделие» появляются без определений, они относятся как к генерируемому, так и к системному программному обеспечению. Выражение (a, b) означает a или b. Если это выражение появляется дважды, например (a1, b1)… (a2, b2), выбирается a1 и a2 или b1 и b2.

Поскольку большинство программных изделий являются основными, может появиться желание поменять местами разделы 2.3.2 и 2.3.3, а затем опустить раздел 2.3.3 для основного изделия. Причина выдвижения здесь генерируемого программного обеспечения на первое место состоит в том, что при правильном проектировании сверху вниз генерируемое программное обеспечение является основной целью проектирования и должно быть описано раньше, чем его генератор. Другими словами, структура генерируемых программ должна определять структуру генератора, а не наоборот. Если изделие является основным, под заголовком «2.3.2. Генерируемое программное обеспечение» делается пометка «Не используется» и опускаются пункты 2.3.2.1—2.3.2.3.

2.3.3.1 Общие характеристики функций

Необходимо рассматривать все изделие как один функциональный модуль, чтобы число подразделов было небольшим. Если невозможно адекватно описать изделие без разбиения его на отдельные функциональные модули, следует дать схему, показывающую, как связаны между собой функциональные модули, и присвоить каждому модулю собственное обозначение. Затем для каждого функционального модуля отводится подраздел раздела 2.3.(2,3), в заглавии которого используется слово «функция» с последующим именем функционального модуля (рис. 2.1).

2.3.3.1

ASK

2.3.3.2

Интерфейспользователя

2.3.3.3

Процессоркорректировок

Рис. 2.1 — Структурная схема из соглашения о требованияхдля изделия ASK

Пример.

2.3.3.1 Общие характеристики функций ASK.

2.3.3.1.1 Внешние ограничения ASK.

Отметим, что здесь выполняется именно функциональная декомпозиция, поскольку СТ является функциональным документом и не указывает, как предлагаемое изделие будет физически разбито на модули. Во внутренних спецификациях, создаваемых на основе СТ, обязательно должно быть описано физическое разбиение на модули. Чтобы было легче сопоставлять внутренние спецификации с предшествующими им соглашениями о требованиях, удобно представить какое-либо конкретное физическое разбиение и попытаться определить функциональные модули, которые могут быть реализованы как физические модули. Но, поступая так, следует помнить, что в CТ более важным является четкое разбиение по функциям, а физическое разбиение только подразумевается, но не диктуется СТ.

Разделы 2.3.(2,3).Х организуются по иерархическому принципу, чтобы охватить как можно больше вопросов в первой группе подразделов. Это позволяет при отсутствии новой существенной информации просто ссылаться на подразделы более высокого уровня, как это сделано в разделе 2.3.3.2 для системы, показанной на рисунке. Здесь и далее X — номер модуля системы. В рассмотренном примере X = 1 для общих функций ASK, X = 2 для интерфейса пользователя и X = 3 для процессора корректировок. В других проектах количество и состав модулей могут различаться.

2.3.3.1.1 Внешние ограничения

Перечисляются все ограничения, сфера действия которых шире, чем сфера действия СТ; сюда входят, например, промышленные ограничения или ограничения, касающиеся серии изделий. Может быть разрешено введение дополнительных ограничений во внешней и внутренней спецификации, сфера действия которых ограничена рамками данного изделия, например ограничения на распределение памяти.

В разделе 2.3.(2,3).1.1 перечисляются все возможные ограничения, относящиеся ко всем функциям. Однако, если список оказывается длинным и некоторые ограничения относятся не ко всем функциям, они должны приводиться по ходу изложения как можно раньше.

2.3.3.1.1.1 Действующие стандарты

Перечисляются все промышленные стандарты и собственные технические условия организации, которые должны быть учтены при изготовлении изделия. При этом следует убедиться, что ссылки на эти стандарты имеются в разделе 2.4.1 соглашения о требованиях.

Пример. 2.3.3.1.1.1. Действующие стандарты: Стандарт ABC на программирование (см. п. 2.4.1 д).

2.3.3.1.1.2 Ограничения на совместимость

Всегда должно рассматриваться несколько аспектов совместимости: исходный язык, машинный язык, форматы данных и сообщений, форматы отчетов, форматы листингов и форматы языка управления заданиями (управляющие карты, структура команд и т.п.). Специально должна оговариваться совместимость со следующими программными изделиями:

изделиями-предшественниками, т.е. такими, которые пользователь может заменить новым изделием; если в новом изделии отсутствует какая-либо возможность, которую имеет предшественник, должны быть приведены обоснования ее исключения;

изделиями-компаньонами, относящимися к той же группе средств, которые являются альтернативами нового изделия; примером может служить программа задания выходного формата, которая отличается от другой аналогичной программы только самим форматом;

подобными изделиями, т.е. такими, которые выполняют похожие функции в других программных изделиях той же серии; такими изделиями являются, например, программа сортировки с использованием диска и программа ленточной сортировки;

конкурирующими изделиями, которые выполняют те же функции, но поставляются другими организациями, например Кобол фирмы IBM является конкурентом Кобола фирмы Burroughs.

В каждом случае должно указываться, является ли данное изделие расширением или частным случаем другого продукта, и должна даваться соответствующая ссылка в разд. 2.4.1 СТ. Описываются также условия получения данного изделия из других версий или других изделий.

Пример. Не существует программных изделий или баз данных, совместимых с системой ASK. Файлы, генерируемые системой ASK, будут VSOS-файлами прямого доступа (см. п. 2.4.1 б) и поэтому могут быть непосредственно использованы другими программами.

2.3.3.1.1.3 Программные ограничения

Указывается, если это необходимо, операционная система, с которой должно работать предлагаемое программное изделие, а также другие программные средства, с которыми оно должно стыковаться в процессе работы. Следует убедиться, что указаны все средства, необходимые для загрузки программного изделия либо передачи управления ему или от него.

Если имеются программы, которые должны быть исключены из операционной системы, необходимо указать их и объяснить, почему они исключаются.

Пример. ASK работает с системой VSOS версии 4 (см. п. 2.4.1 б). Любой компонент семейства VSOS может работать одновременно с ASK столько времени, сколько будет доступна конфигурация устройств, описанная в пункте 2.3.3.1.1.4. Процессор корректировок может работать параллельно с интерфейсом пользователя, но интерфейсу пользователя закрыт доступ к файлу, который используется в данное время процессором корректировок.

2.3.3.1.1.4 Аппаратные ограничения

Приводится таблица устройств, используемых при работе программного изделия. Для каждого устройства указывается минимальное, номинальное и максимальное требуемое число. Номинальным является оптимальное число устройств или наиболее вероятное, если оптимум не определен. В случае необходимости каких-либо дополнительных устройств они должны быть отмечены отдельно.



Страницы: Первая | 1 | 2 | 3 | Вперед → | Последняя | Весь текст




sitemap
sitemap