Ис. Конспект лекций Маглинец Ю. А. Красноярск сфу 2007 Введение. Понятие и классификация требований
 Скачать 0.88 Mb.
|
|
Раскадровка Решением промежуточного между электронным и бумажным вариантами прототипов UI класса, является презентации, изготовленные при помощи средств электронного офиса (например, комбинации Microsoft Visio и Microsoft PowerPoint). В этом случае пользователь лишён свободы выбора, предоставляемой ему поведенческим прототипом. Но идею пошаговой смены экранов в процессе реализации сценария варианта использования вполне можно реализовать. Данный вид решения определяется в [22], как пассивная раскадровка. Активная раскадровка является дальнейшим развитием понятия пассивной раскадровки, с применением средств анимации и т.п. Третий вид раскадровки, вводимый в [22] – интерактивная представляет собой электронный одноразовый горизонтальный прототип. Иллюстрированные сценарии прецедентов Иллюстрированные сценарии прецедентов, ИСП [15], наряду с прототипами позволяют достичь лучшего понимания между Заказчиком и Разработчиком. Но если прототипы адресованы скорее Заказчику, нежели Разработчику, то с ИСП ситуация обстоит наоборот: они содержат дополнительные сведения, помогающие Разработчику лучше понять специфику проблемной области и, тем самым, лучше отразить её в интерфейсе пользователя. Основная идея ИСП – «разбавить» текст описания сценария варианта использования аспектами применимости. Аспект применимости – информация, позволяющая расширить описание прецедента описаниями, конкретизирующими те или иные его особенности и, в конечном итоге, повысить степень комфортности пользователя. Различают [15] 3 разновидности аспектов применимости: ориентиры, средние значения атрибутов и объёмы объектов, средняя интенсивность использования. Ориентиры Ориентиры – это описание опциональных функциональных возможностей системы. Отсутствие таких возможностей не приводит к фатальной неудаче. Присутствие – улучшает применимость, снабжая полезной информацией. Ориентиры следует расценивать не как требования, а как пожелания или рекомендации. Пример. Описание потока событий ИСП для прецедента «Оформить заказ», расширенного ориентирами (текст в квадратных скобках). В процессе выполнения прецедента менеджер по приёму заказов выбирает заказчика из клиентской базы, определяет товарные позиции из справочника и указывает их количество. Система отображает на мониторе наименование позиций, цену, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты. Система рассчитывает итоговую сумму. [Менеджер должен иметь возможность видеть текущее сальдо расчётов с клиентом и данные по последним десяти сделкам со статистикой по дисциплине соблюдения договорных обязательств] Средние значения атрибутов и объёмы объектов Данная информация позволяет оптимальнее построить пользовательский интерфейс и оценить на ранних стадиях проекта «узкие места» в обработке данных, которые могут повлиять на производительность системы. Так, при выборе из 2 возможностей лучше подойдёт элемент управления checkbox, при выборе, ограниченном 2-3 десятками позиций – выпадающий список, при многообразии, измеряемом тысячами вариантов, потребуются дополнительные средства фильтрации и поиска. Пример. Описание потока событий ИСП для прецедента «Оформить заказ», расширенного объёмами и средними значениями объектов (текст в фигурных скобках). В процессе выполнения прецедента менеджер по приёму заказов выбирает заказчика из клиентской базы {до 10000 клиентов} , определяет товарные позиции из справочника {товары разбиты на 10 категорий, количество позиций в категории не превышает 500} и указывает их количество {до 100 позиций, средняя закупка – 8 позиций} . Система отображает на мониторе наименование позиций, цену, сумму и количество на складе. Менеджер назначает скидку и определяет порядок оплаты {на данный момент существуют 3 варианта порядка оплаты}. Система рассчитывает итоговую сумму. Средняя интенсивность использования Средняя интенсивность использования позволяет выделить сценарии «массового» использования, в которых всё должно быть идеально (быстродействие, удобство пользования, минимум действий на выполнение операций). Например – интерфейс кассира в супермаркете. Другая крайность – сценарии, выполняемые от случая к случаю, не каждый день и не требующие особой оперативности (например, расчёт заработной платы за месяц). Эти данные позволяют, структурировать подачу информации, убрать из «главных» интерфейсов редко используемые опции и т.п. Пример. Фрагмент описания потока событий ИСП для прецедента «Оформить заказ для нового клиента», расширенного объёмами и средними значениями объектов (текст в круглых скобках). В процессе выполнения прецедента менеджер по приёму заказов выбирает заказчика из клиентской базы (в 95% случаев) , либо вызывается интерфейс регистрации нового клиента (в 5% случаев) Литература к лекции 14. Фаулер М., Скотт К. UML в кратком изложении. Применение стандартного языка объектного моделирования: Пер. с англ. – М.:Мир, 1999. – 191 с., ил. 15. Леоненков. Самоучитель UML. 16. Мацяшек Лешек, А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML.: Пер. с англ. - М.: Издательский дом "Вильямс", 2002. - 432 с.: ил. - Парал. тит. Англ. 17. Маклаков С.В. Bpwin Erwin Case-средства разработки информационных систем. – Москва “ДиалогМифи ” – 2000 18. Вигерс Карл Разработка требований к программному обеспечению/Пер, с англ. — М.:Издательско-торговый дом «Русская Редакция», 2004. —576с.: ил. 19. Орлов C. Технологии разработки программного обеспечения: Учебник. – СПб.: Питер, 2002. – 464 с.: ил. 20. Каменова, Громов. Моделирование бизнеса. Методология ARIS. — М.: Весть- МетаТехнология, 2001. 21. Брауде Э. Технологии разработки программного обеспечения. – СПб: Питер, 2004. – 655 с.: ил. 22. Леффингуелл Д., Уидриг Д. Принципы работы с требованиями к программному обеспечению. М.: ИД “Вильямс”, 2002. 23. Л.Новиков. Введение в Rational Unified Process. http://www.interface.ru/rational/interface/151199/rup/main.htm 6. Документирование и проверка требований План лекции Документирование требований в соответствие с ГОСТ РФ Структура ТЗ в соответствие с ГОСТ 34.602-89 Описание требований к системе в соответствие с ГОСТ 34.602-89 Документирование требований в RUP Документирование требований на основе IEEE Standard 830-1998 Документирование требований в MSF Верификация и валидация. Двусмысленность требований "Золочение" продукта Минимальная спецификаций Пропуск типов пользователей Методы и средства проверки требований Неофициальные просмотры требований Инспекции Разработка тестов Определение критериев приемлемости Чтобы требования, выявленные и описанные (см. материалы лекции 3 и лекции 4 ) приняли силу соглашения между Заказчиком и Разработчиком, их необходимо оформить в виде документа. В российской практике для этого обычно используется документ «Техническое задание», ТЗ, в западной – «Software Requirements Specification», SRS (спецификация программных требований). По сути это – один и тот же документ, поэтому далее по тексту будем употреблять термин «ТЗ», рассматривая различные шаблоны его построения – как на основе российских ГОСТ, так и западных методологий и стандартов. Документирование требований в соответствие с ГОСТ РФ Документирование требований регламентировано российскими ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению» и ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» (ТЗ на АС) [27-28]. Второй документ, по сути, является более проработанной версией первого, адаптированной к созданию автоматизированных информационных систем, поэтому далее рассмотрена структура ТЗ в соответствие с ГОСТ 34.602-89. Несмотря на то, что для сферы IT 17 лет – это целая эпоха, данный документ практически не устарел: его авторам удалось разработать сбалансированные рекомендации, абстрагируясь от конкретных технических и технологических решений. Кроме того, он по-прежнему играет роль государственного стандарта РФ и при заключении контрактов с государственными предприятиями Разработчика могут обязать оформить ТЗ в соответствии с духом и буквой этого документа. Структура ТЗ в соответствие с ГОСТ 34.602-89 В задачи лекции не входит перечисление всех правил и рекомендаций данного ГОСТ, желающие могут ознакомиться с ним непосредственно. Ниже будут перечислены разделы, предусмотренные ГОСТ и рассмотрены основные моменты, на которые следует обратить внимание. Общие сведения – в этом разделе, помимо юридических реквизитов сторон и пр. деловой информации ГОСТ рекомендует указать источники и порядок финансирования работ. Назначение и цели создания (развития) системы – здесь необходимо указать показатели объекта автоматизации, которые должны быть достигнуты и критерии оценки достижения этих показателей. Данным разделом на практике часто пренебрегают и совершенно напрасно – ведь именно в этом разделе закладываются высокоуровневые бизнес-требования и формулируются критерии их достижения. Характеристика объектов автоматизации – достаточно важный раздел. Его основные «разрезы» - организационная структура, структура управления, структура расположения предприятия и его филиалов. Хорошее описание объекта автоматизации позволяет сэкономить время на определение классов пользователей, для крупных территориально-распределённых систем – заложить структуру и топологию сетевых коммуникаций. Требования к системе – ключевой раздел настоящего документа, поэтому он будет рассмотрен ниже, более подробно. Раздел «Состав и содержание работ по созданию системы», говоря современным языком, описывает процесс создания системы, включая выбор методологии, определяющий содержание стадий, этапов и фаз и его конкретизацию для проекта (количество этапов и итераций, их основное содержание). Порядок контроля и приемки системы – также один из ключевых компонент ТЗ. Он распределяет роли Заказчика и Разработчика в подготовке системы к испытаниям и проведению испытаний. Здесь уместно оговорить правила проведения испытаний, сформулировать основные тестовые сценарии и критерии приёмки. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие, опять же, аппелируя к современной терминологии, оговаривают порядок проведения реинжиниринга предприятия, который необходимо осуществить для того, чтобы добиться от внедрения АИС должного эффекта (подбор и обучение персонала, изменения в организационной структуре и т.п.). Документ заканчивается разделами «требования к документированию» и «источники разработки», определяющими, соответственно, перечень и формы документации, подлежащей разработке и перечень уже имеющихся документов, содержащих предпосылки для разработки. В качестве приложений ГОСТ рекомендует использовать расчет ожидаемой эффективности системы и оценку научно-технического уровня системы. Описание требований к системе в соответствие с ГОСТ 34.602-89 ГОСТ разделяет все требования к системе на три класса: требования к системе в целом; требования к функциям (задачам), выполняемым системой; требования к видам обеспечения. Среди требований к системе в целом (системные требования) указываются требования к: структуре системы (здесь закладываются высокоуровневые архитектурные решения, либо структурные ограничения, вводится деление на подсистемы, комплексы и модули, решаются вопросы коммуникации компонент системы и системы с внешним миром), режимам функционирования системы; персоналу (указывается численность, требуемая квалификация и режим работы); надежности; безопасности; эргономике и технической эстетике; транспортабельности для подвижных АС; эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы; защите информации от несанкционированного доступа; сохранности информации при авариях; защите от влияния внешних воздействий; патентной чистоте; стандартизации и унификации, а также показатели назначения (параметры, характеризующие степень соответствия системы ее назначению) и дополнительные требования (распространяются на обучающие подсистемы, средства контроля работоспособности системы и др.). Требования ГОСТ к функциям (задачам), в переводе на современный язык, подразделяются на: перечень функциональных требований в привязке к подсистемам и очередям автоматизации; временной регламент реализации функциональных требований; требования к качеству реализации каждого из функциональных требований (в том числе - форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов); перечень и критерии отказов для каждого функционального требования, по которому были заданы требования по надежности. Требования к видам обеспечения. Среди видов обеспечения ГОСТ указывает математическое, информационное, лингвистическое, программное, техническое, метрологическое, организационное, методическое. Документирование требований в RUP Шаблон SRS, предложенный в RUP 18 , по сути представляет собой контейнер, в который необходимо «упаковать» артефакты, полученные в процессе специфицирования требований. Кроме того, SRS частично перекликается с документом «Видение» (см. материалы « лекции 4 »). Шаблон удобен своей компактностью и лаконизмом. 1. Введение. 1.1. Цель. Документ должен исчерпывающим образом описывать внешнее поведение системы, а также нефункциональные требования и ограничения. 1.2. Краткая сводка возможностей. 1.3. Определения, акронимы и сокращения. 1.4. Ссылки. 1.5. Краткое содержание.. 2. Обзор системы 2.1. Обзор прецедентов. Содержит список имён и кратких описаний вариантов использования и акторов с иллюстрациями в виде диаграмм прецедентов. 2.2. Предположения и зависимости. Данная секция описывает ключевые технические возможности, компоненты, подсистемы, связанные проекты, которые могут влиять на жизнеспособность разрабатываемой системы. Предположением (assumption) называется положение, которое считается истинным при отсутствии доказательства или определяющей информации. [8]. При определении зависимостей (dependencies) проекта от внешних факторов, необходимо проанализировать, какие новые операционные системы, регламенты бизнес-процессов, стандарты качества, информационные системы 18 http://www-306.ibm.com/software/rational/ могут появиться на предприятии внедрения и как это может повлиять на функционирование изготовляемой АИС. 3. Описание требований 3.1. Описание вариантов использования. Параграф содержит описание вариантов использования и связанных с ними нефункциональные требований, либо ссылки на соответствующие артефакты. 3.2. Специальные требования. Параграф содержит описание функциональных требований (не описанных, как варианты использования), а также описание нефункциональных требований общего характера (не сопоставленных ни одному прецеденту в предыдущем разделе), либо ссылки на соответствующие артефакты. 4. Вспомогательная информация. Сюда включается информация, облегчающая понимание документа. Это может быть оглавление и приложения, например, описывающие прототипы пользовательского интерфейса. Документирование требований на основе IEEE Standard 830-1998 Рассмотрим шаблон документа описания требований, составленный К.Вигерсом [8] на основе стандарта [25]. Данный стандарт содержит развёрнутое описание требований, которое может быть оптимизировано для нужд конкретной организации. 1. Введение 1.1 Назначение документа. 1.2. Поддерживаемые соглашения. 1.3. Предполагаемая аудитория и рекомендации по последовательности работы с документом для каждого класса читателей. 1.4. Границы проекта. Здесь содержится ссылка на документ «Концепция», если таковой имеется, либо краткое резюме продукта. 1.5. Ссылки. 2. Общее описание. 2.1. Общий взгляд на продукт. Здесь необходимо определить - является ли описываемый продукт новым членом растущего семейства продуктов, новой версией существующей системы, заменой существующего приложения или совершенно новым продуктом. Если спецификация требований определяет компонент более крупной системы, укажите, как это ПО соотносится со всей системой и определите основные интерфейсы между ними. 2.2. Особенности продукта. Перечисляются ключевые особенности продукта или его главные свойства. Здесь уместно поместить контекстную диаграмму (в виде диаграммы вариантов использования, потоков данных или др. спецификаций). 2.3. Классы и характеристики пользователей. Документируется процесс поиска акторов, в котором выявляются все пользователи системы и осуществляется обобщение (выделение классов) пользователей. Найденные классы описываются (например – уровень квалификации, доступный функционал и т.д.). 2.4. Операционная среда. Рассматривается среда функционирования АИС, включая аппаратные средства, операционные системы, для распределённых систем – географическое расположение пользователей и серверов, топология сети. 2.5. Ограничения проектирования и реализации. Рассмотрим классификацию ограничений [8]: определенные технологии, средства, языки программирования и базы данных, которые следует использовать или избегать; ограничения, налагаемые операционной средой продукта; обязательные соглашения или стандарты разработки; обратная совместимость с продуктами, выпущенными ранее; ограничения, налагаемые бизнес-правилами; ограничения, связанные с оборудованием, например требования к быстродействию, ограничения памяти или процессора; соглашения, связанные с пользовательским интерфейсом существующего продукта, которые необходимо соблюдать при его улучшении форматы и протоколы обмена данными. 2.6 Документация для пользователей. 2.7 Предположения и зависимости 3. Функции системы Для каждой i-й функции составляется следующее описание. З.i Наименование i-й функции системы. З.i.1 Описание и приоритеты. Приводится краткое описание функции и указывается её приоритет (степень важности/очерёдности реализации). З.i.2 Последовательности «воздействие - реакция». Необходимо перечислить последовательность воздействий, оказываемых на систему (действия пользователей, сигналы внешних устройств и др.), и отклики системы, определяющие реакцию конкретной функции. З.i.З Функциональные требования. Необходимо дать детализацию i-й функции, перечислить детализированные функциональные требования, включая реакцию на ожидаемые ошибки и неверные действия. Каждому детальному функциональному требованию присваивается уникальный идентификатор. 4. Требования к внешнему интерфейсу Ниже рассмотрены конкретные рекомендации по написанию разделов этого параграфа, согласно [8]: 4.1 Интерфейсы пользователя Основные характеристики UI: ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для семейства продукта, которые необходимо соблюдать; стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления и т.п.; конфигурация экрана или ограничения разрешения; стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки; быстрые клавиши; стандарты отображения сообщений; стандарты конфигурации для упрощения локализации ПО; специальные возможности для пользователей с проблемами со зрением. 4.2 Интерфейсы оборудования Опишите характеристики каждого интерфейса между компонентами ПО и оборудования системы. В описание могут входить типы поддерживаемых устройств, взаимодействия данных и элементов управлений между ПО и оборудованием, а также протоколы взаимодействия, которые будут использоваться, 4.3 Интерфейсы ПО Опишите соединения продукта и других компонентов ПО (идентифицированные по имени и версии), в том числе базы данных, операционные системы, средства, библиотеки и интегрированные коммерческие компоненты. Укажите назначение элементов сообщений, данных и элементов управления, обмен которыми происходит между компонентами ПО. Опишите службы, необходимые внешним компонентам ПО, и природу взаимодействия между компонентами. Определите данные, к которым будут иметь доступ компоненты ПО. 4.4 Интерфейсы передачи информации Укажите требования для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, Web-браузер, протоколы сетевого соединения и электронные формы. Определите соответствующие форматы сообщений. Опишите особенности безопасности взаимодействия или шифрования, частоты передачи данных и механизмов синхронизации. 5. Другие нефункциональные требования В этом разделе описываются остальные нефункциональные требования, не относящиеся к требованиям к интерфейсу, которые представлены в разделе 4, и к ограничениям, описываемым в разделе 2.5. 5.1 Требования к производительности Укажите специальные требования к производительности для различных системных операций. Обоснуйте их необходимость для того, чтобы помочь разработчикам принять правильные решения, касающиеся дизайна. Например, из-за жестких требований к времени отклика базы данных разработчики могут зеркализовать базу данных в нескольких географических метаположениях или денормализовать связанные таблиц баз данных для получения более быстрого ответа на запрос. Приложение А. Словарь терминов (глоссарий). Приложение Б. Модели анализа. В этот раздел помещаются все модели, построенные в процессе анализа требований (см. материалы лекции 09-Моделирование требований). Приложение В. Список вопросов Это динамический список еще не разрешенных проблем, связанных с требованиями. Это могут быть элементы, помеченные как «ТВD» (to be determined — необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п. |