Требования к внешнему интерфейсу
Ниже рассмотрены конкретные рекомендации по написанию разделов этого параграфа, согласно [11.1]:
Интерфейсы пользователя
Основные характеристики UI:
· ссылки на стандарты графического интерфейса пользователей или стилевые рекомендации для семейства продукта, которые необходимо соблюдать;
· стандарты шрифтов, значков, названий кнопок, изображений, цветовых схем, последовательностей полей вкладок, часто используемых элементов управления и т.п.;
· конфигурация экрана или ограничения разрешения;
· стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки;
· быстрые клавиши;
· стандарты отображения сообщений;
· стандарты конфигурации для упрощения локализации ПО;
· специальные возможности для пользователей с проблемами со зрением.
Интерфейсы оборудования
Опишите характеристики каждого интерфейса между компонентами ПО и оборудования системы. В описание могут входить типы поддерживаемых устройств, взаимодействия данных и элементов управлений между ПО и оборудованием, а также протоколы взаимодействия, которые будут использоваться.
Интерфейсы ПО
Опишите соединения продукта и других компонентов ПО (идентифицированные по имени и версии), в том числе базы данных, операционные системы, средства, библиотеки и интегрированные коммерческие компоненты. Укажите назначение элементов сообщений, данных и элементов управления, обмен которыми происходит между компонентами ПО. Опишите службы, необходимые внешним компонентам ПО, и природу взаимодействия между компонентами. Определите данные, к которым будут иметь доступ компоненты ПО.
|
|
|
Интерфейсы передачи информации
Укажите требования для любых функций взаимодействия, которые будут использоваться продуктом, включая электронную почту, Web-браузер, протоколы сетевого соединения и электронные формы. Определите соответствующие форматы сообщений. Опишите особенности безопасности взаимодействия или шифрования, частоты передачи данных и механизмов синхронизации.
Другие нефункциональные требования
В этом разделе описываются остальные нефункциональные требования, не относящиеся к требованиям к интерфейсу, которые представлены в разделе 4, и к ограничениям, описываемым в разделе 2.5.
Требования к производительности
Укажите специальные требования к производительности для различных системных операций. Обоснуйте их необходимость для того, чтобы помочь разработчикам принять правильные решения, касающиеся дизайна. Например, из-за жестких требований к времени отклика базы данных разработчики могут зеркализовать базу данных в нескольких географических местоположениях или денормализовать связанные таблицы баз данных для получения более быстрого ответа на запрос.
|
|
|
· Приложение А. Словарь терминов (глоссарий).
· Приложение Б. Модели анализа. В этот раздел помещаются все модели, построенные в процессе анализа требований (см. материалы "Расширенный анализ требований. Моделирование" ).
· Приложение В. Список вопросов.
Это динамический список еще не разрешенных проблем, связанных с требованиями. Это могут быть элементы, помеченные как "ТВD" (to be determined - необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п.
Документирование требований в MSF
В начале фазы проектирования проектная группа работает с проектными требованиями. Они подразделяются на:
· бизнес-требования,
· требования к эксплуатации,
· системные требования,
· требования пользователя.
Одним из основных результатов фазы проектирования является функциональная спецификация, которая служит:
· инструкцией команде разработчиков о том, что они должны будут создать;
· основой для оценки объема работ;
· четкое соглашение с Заказчиком о том, что должно быть сделано;
|
|
|
· основой для синхронизации работы всей проектной команды.
С шаблонами соответствующих документов можно ознакомиться на сайте Microsoft, [11.3].
Проверка требований
Верификация и валидация
Термин "верификация" (verification) в русскоязычной литературе обычно переводят, как "проверка". Термин "валидация" - как "проверка правильности", "аттестация", "утверждение".
Согласно стандарту IЕЕЕ 1012-1986, верификация представляет собой процесс оценивания системы или компонента с целью определить, удовлетворяют ли результаты некой фазы условиям, наложенным в начале данной фазы. Валидация в этом же стандарте определяется, как процесс оценивания системы или компонента во время или по окончании процесса разработки с целью определить, удовлетворяет ли она указанным требованиям.
Трудно ожидать от читателя, впервые столкнувшегося с этой терминологией и ее определениями в этом и других стандартах, ясности понимания. По крайней мере, у автора настоящего курса лекций при первом знакомстве с определениями тех же понятий в ISO IEC 12207 возникло четкое ощущение, что авторы стандарта явно чего-то не договаривают. Посудите сами: согласно данному стандарту, верификация - это подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования полностью реализованы. С другой стороны, валидация - это подтверждение экспертизой и представлением объективных доказательств того, что конкретные требования к конкретным объектам полностью реализованы. Правда, к чести авторов последнего стандарта, они приводят примечание, которое несколько приближает читателя к пониманию: "валидация связана с экспертизой продукта в целях определения его соответствия потребностям пользователя". В этом и заключается суть отличия: если верификация связана с выяснением того, удовлетворяет ли разрабатываемый объект, либо процесс его создания сформулированным требованиям, то валидация отвечает на вопрос - правильно ли разработан целевой объект (продукт), удовлетворяет ли он потребностям заказчика. Другой аспект валидации заключается в том, что она обычно увязывается с формальной приемкой (аттестацией) системы.
|
|
|
Некоторые стандарты, например SWEBOK, IEEE 1059-93 "IEEE Guide for Software Verification and Validation Plans", вводят для этих двух процессов обобщающее понятие V&V (Validation and Verification). Согласно IEEE 1059-93, верификация и валидация программного обеспечения - упорядоченный подход в оценке программных продуктов, применяемый на протяжении всего жизненного цикла. Усилия, прилагаемые в рамках работ по верификации и валидации, направлены на обеспечение качества как неотъемлемой характеристики программного обеспечения и удовлетворение пользовательских требований.
Из вышесказанного ясно, как осуществить верификацию и валидацию АИС и (или) процесса ее создания: в первом случае необходимо убедиться, что АИС (компонента, процесс) соответствует сформулированным требованиям, во втором - что АИС действительно работает! Но если критерием проверки АИС служат требования, то что может послужить критерием проверки самих требований? Ответ заключается в том, что требования должны удовлетворять свойствам, сформулированным в "Свойства требований" , Кроме того, следует убедиться в том, что [12.1]:
· в спецификации требований к ПО должным образом описаны предполагаемые возможности и характеристики системы, которые удовлетворят потребности различных заинтересованных в проекте лиц;
· требования к ПО точно отражают системные требования, бизнес-правила и др.;
· требования обеспечивают качественную основу для проектирования и сборки ПО.
Дата добавления: 2021-03-18; просмотров: 183; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!