Провести интервью с представителями заказчика

· Определить желания и потребности.

· Использовать инструменты поддержки (технологии выражения концепций)

· Набросать графический интерфейс пользователя.

· Определить конфигурацию оборудования.

3. Написать С-требования в форме стандартного документа.

4. Проверить С-требования и согласовать с заказчиком.

Для всех этапов отследить метрики, например:

· Затраченное время на анализ каждого требования.

· Количество страниц С-требований.

· Количество времени общения с заказчиком на страницу.

· Оценка дефектов по проверкам.

Рис. 5.2. Типичная схема для С-требований заказчика

 

Приведем оглавление наиболее известного стандарта IEEE/ANSI 830-1993 – документа организации SRS [6]:

Введение

1.1 Цели документа

1.2 Назначение программного продукта

1.3 Определения, термины и сокращения.

1.4 Ссылки на источники и список литературы

1.5 Обзор спецификации

Общее описание

2.1 Перспективы продукта

2.1.1 Системные интерфейсы

2.1.2 Пользовательские интерфейсы

2.1.3 Аппаратные интерфейсы

2.1.4 Программные интерфейсы

2.1.5 Коммуникационные интерфейсы

2.1.6 Ограничения по памяти

2.1.7 Операции

2.1.8 Требования по адаптации

2.2 Функции программного продукта

2.3 Пользовательские характеристики

2.4 Общие ограничения

2.5 Обоснования, предположения и допущения.

 

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

4. Приложения

5. Указатели

 

Хотя стандарт IEEE не идеален (относительно стар и нуждается в некоторой модификации и дополнении по части объектно-ориентированного анализа и проектирования, но имеет преимущество в том, что однозначно решает большинство вопросов, которые можно было бы истолковать по-разному), он может служить отправной точкой при написании спецификации. Конечно, при ее написании необходимо также учитывать стандарты, принятые в организации – разработчике ПО. В табл.5.1 описаны возможные разделы спецификации, построенной на основании стандарта IEEE.

Таблица 5.1

Структура спецификации требований

Раздел	Описание
Предисловие	Здесь определяется круг лиц, на которых рассчитан данный документ. Описываются предыдущие версии разрабатываемого программного продукта, а также изменения, внесенные в каждую версию. Дается обоснование для создания новой версии продукта.
Введение	Здесь, более развернуто, обосновывается необходимость создания системы (программного продукта). Кратко перечисляются системные функции, и объясняется, как система будет работать совместно с другими системами. Должно быть показано, как разработка системы «вписывается» в общую бизнес-стратегию компании, заказывающей программный продукт
Глоссарий	Дается описание технических терминов, используемых в документе. Здесь не делается каких-либо предположений об уровне знаний или практическом опыте читателя документа.
Пользовательские требования (С-требования)	Описываются сервисы, предоставляемые пользователям, нефункциональные системные требования и требования предметной области. Это описание может быть сделано на естественном языке с использованием диаграмм, блок-схем и других форм записи, понятных заказчику. Здесь также должны быть приведены стандарты на программный продукт и процесс его разработки.
Системная архитектура	Здесь приводится высокоуровневое представление возможной системной архитектуры с указанием, как распределены системные функции по компонентам системы. Обязательно должны быть выделены повторно используемые (т.е. уже существующие) компоненты.
Системные требования (D-требования)	Подробно описываются функциональные, нефункциональные требования и требования предметной области. Если необходимо, нефункциональные требования дополняются описанием интерфейсов других систем.
Системные модели	Здесь представлено несколько системных моделей, показывающих взаимоотношения между системными компонентами и между системой и ее окружением. Это могут быть объектные модели, модели потоков данных или модели данных.
Эволюция системы	Приводятся основные предположения и допущения, на которых базируется система, а также ожидаемые (прогнозируемые) изменения в аппаратных средствах, в потребностях пользователей и т.п.
Приложения	Здесь приводится специализированная информация, относящаяся к разрабатываемой системе, например описание аппаратных средств или базы данных, с которыми должна работать система. При описании аппаратных средств необходимо показать минимальную и оптимальную конфигурации, при которых может работать программная система. Описание базы данных должно отображать логическую структуру данных, с которыми будет работать система, и отношения между ними.
Указатели	В документе возможно использование различных указателей. Это может быть обычный алфавитный указатель, указатель диаграмм или указатель системных функций.

 

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

 

Требования к системе

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

1. Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система будет реагировать на те, или иные входные данные, как она должна себя вести в определенных ситуациях и т.д. В некоторых ситуациях отдельно указывается, что система не должна делать (обратные требования).

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

3. Требования предметной области. Характеризует ту предметную область, где будет эксплуатироваться система. Эти требования могут быть функциональными и нефункциональными.

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

Нужды заказчика несколько труднее определить, чем его желания. Например, заказчик может захотеть, чтобы музыкальное приложение позволяло компьютерным новичкам гарантированно записывать музыку, но ему также может быть нужна периодическая функция автосохранения для избежания потери результатов работы. Является ли последняя характеристика функциональным требованием, или это часть проектирования? Это зависит от соглашения между разработчиком и заказчиком. Заказчик может согласиться с автосохранением, и тогда такая функция становится функциональным требованием, либо оставить разработчику право решать, как добиться безопасной работы для новичков. В этом случае автосохранение будет не требованием, а элементом дизайна, содействующим удовлетворению требований.

 

5.2.1. Функциональные требования

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

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

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

 

5.2.2. Нефункциональные требования

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

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

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

Нефункциональные требования могут относиться не только к самой программной системе. Одни могут относиться к технологическому процессу разработки ПО, другие – содержать перечень стандартов качества, накладываемых на процесс разработки, третьи – указания на использование определенных CASE – средств и описание процесса проектирования, четвертые – обосновывать необходимые ресурсы, организационные возможности организации – разработчика, возможности взаимодействия системы с другими системами, а также вопросы техники безопасности, защиты интеллектуальной собственности и т.п. На рис. 5.3 показана классификация нефункциональных требований.

Нефункциональные требования:

Требования к продукту

Требования к эксплуатации

Требования к эффективности

Требования к производительности

Требования к памяти

Требования к надежности

Требования к переносимости

2. Организационные требования

2.1 Выходные требования

Требования на реализацию

Требования на стандарты

3. Внешние требования

Требования на взаимодействие

3.2 Этические требования

3.3 Юридические требования

Требования о сохранении конфиденциальности

Требования по технике безопасности

Рис. 5.3. Типы нефункциональных требований

 

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

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

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

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

Таблица 5.2

Количественные показатели для нефункциональных требований

Показатель	Единицы измерения
Скорость	Количество выполненных транзакций в секунду. Время реакции на действия пользователя. Время обновления экрана (части экрана).
Размер	Килобайты. Количество модулей памяти
Простота эксплуатации	Время обучения персонала. Количество статей (справок) в справочной системе.
Надежность	Средняя продолжительность времени между двумя последовательными проявлениями ошибок в системе. Вероятность выхода системы из строя. Коэффициент готовности системы.
Устойчивость к сбоям	Время восстановления системы после сбоя. Процент событий, приводящих к сбоям. Вероятность порчи данных при сбое.
Переносимость	Процент машинно-зависимых операторов. Количество машинно-зависимых подсистем.

 

Требования предметной области

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

В качестве примера, можно рассмотреть следующие требования к системе книжного Internet – магазина:

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

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

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

Приведем другой пример требования предметной области, указывающего как должны выполняться вычисления. Это требование взято из спецификации системы «Офис регистратора» - службы, занимающейся регистрацией всей истории учебных достижений обучающегося и обеспечивающей организацию всех видов контроля знаний и расчета его академического рейтинга. Согласно этого требования для перевода обучающегося с курса на курс устанавливается переводной балл GPA, расчет которого осуществляется по следующей формуле:

 

GPA =

 

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

 

5.2.4. Пользовательские требования

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

Вместе с тем при описании требований на естественном языке могут возникнуть различные проблемы.

1. Отсутствие четкости изложения.

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

3. Объединение различных требований в единое пользовательское требование.

Пользовательские требования должны, таким образом, просто описывать основные возможности системы.

Чтобы свести к минимуму неясности при написании пользовательских требований, рекомендуется придерживаться следующих правил[20]:

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

2. Следует делать различие между обязательными и описательными требованиями.

3. Следует использовать разные начертания шрифта для выделения ключевых частей требования.

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

 

5.2.5. Системные требования

 

Системные требования (D-требования) - это более детализированное описание пользовательских требований. Они обычно служат основой для заключения контракта на разработку программной системы и поэтому должны представлять максимально полную спецификацию системы в целом. Системные требования также используются в качестве отправной точки на этапе проектирования системы.

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

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

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

2. В большинстве случаев разрабатываемая система должна взаимодействовать с уже существующими системами. Это накладывает определенные ограничения на архитектуру новой системы.

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

Для того, чтобы спецификации системных требований понимались разными людьми одинаково, разработаны методы описания требований, которые структурируют спецификацию и уменьшают размытость определений. Эти методы представлены в табл. 5.3[20].

Таблица 5.3

Методы описания требований

Система записи	Описание
Структурированный естественный язык	Использование стандартных форм и шаблонов для написания спецификации
Языки описания программ	Использование специальных структурированных языков, подобных языкам программирования, где спецификация требований строится на основе выбранной операционной модели системы.
Графические нотации	Графический язык, использующий для описания функциональных требований диаграммы и блок- схемы, дополненные текстовыми пояснениями. Наиболее известные примеры таких графических языков – диаграммы структурного анализа и проектирования ПО (SADT), диаграмма вариантов использования, и ряд других диаграмм UML.
Математические спецификации	Это системы позиций, основанные на математических концепциях, таких, как теория конечных автоматов или теория множеств. Это формализованная однозначная и лишенная двусмысленности запись системных требований. К ним можно отнести алгебраический подход, при котором система описывается в терминах операций и их отношений, и подход, ориентированный на моделирование, при котором модель системы строится с использованием математических конструкций, таких, как множества и последовательности, а системные операции определяются тем, как они изменяют состояния системы. Таким образом определяется поведение системы.

 

5.2.6. Организация системных требован ий

 

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

• Такой список трудно понять в целом, даже пока он не вырос до десятков и сотен элементов.

• Требования имеют разные типы: например, требования производительности должны обрабатываться иначе, чем требования поведения.

• Некоторые требования можно естественным образом объединить с другими.

• Трудно найти какое-либо конкретное требование и т.д.

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

1. По основным свойствам (свойство - предоставляемый вовне сервис, который обычно определяется с помощью пар «стимул - реакция»). Этот способ организации требований часто воспринимают как «требования», имея в виду, что требования сгруппированы по различным свойствам программы. Надо заметить, что само по себе это не предоставляет никакой систематической организации, поскольку позволяет переходить от свойства одной части программы к свойству абсолютно другой части программы.

2. По режиму (например, системы управления какими-либо объектами могут иметь испытательный, нормальный и аварийный режимы).

3. По вариантам использования (иногда еще называется по сценариям). Идея заключается в том, что большинство детальных требований являются частью варианта использования.

4. По классам. Это объектно-ориентированный стиль. В этом способе организации мы классифицируем требования по классам (первый шаг такой классификации происходит при разработке концептуальной модели предметной области, сущности которой, как известно, наделяются обязанностями).

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

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

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

Стандарт IEEE 830-1993: Детальные требования ООП (00-формат) предлагает следующие способы классификации D-требований.

 

1. Детальные требования (00-формат)

Требования к внешнему интерфейсу

Пользовательские интерфейсы

Аппаратные интерфейсы

Программные интерфейсы

Коммуникационные интерфейсы

Классы / Объекты

Класс / Объект 1

⇐ Предыдущая78910111213141516Следующая ⇒

Поделиться: