Характеристики правильно составленной спецификации требований к ПО

Спецификация требований должна быть [15]:

a) Корректной (каждое требование, изложенное в ней, является требованием, которому должно удовлетворять программное обеспечение);

b) Однозначной (каждое изложенное в ней требование может интерпретироваться только однозначно. Как минимум, для этого требуется, чтобы каждая характеристика конечного продукта была описана с использованием одного уникального термина);

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

d) Непротиворечивой (никакой набор отдельных требований, описанных в ней, не находится в противоречии с ней или с каким-то документом более высокого уровня);

e) Упорядоченной по ее значимости и/или устойчивости (каждое требование должно иметь идентификатор и относиться к определенному классу требований: необходимые, условные и необязательные);

f) Проверяемой (каждое требование, изложенное в ней, может быть проверено.);

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

h) Отслеживаемой (должен четко прослеживаться источник каждого из ее требований и SRS облегчает обращение к каждому из требований при дальнейшей разработке или модернизации документации).

В процессе работы с требованиями участвуют так называемые «заинтересованные лица»[10], к числу которых мы будем относить:

− Пользователей (людей, кто будет непосредственно использовать ПО; пользователи могут описать задачи, которые они решают (планируют решать) с использованием ПС, а также ожидания по отношению к атрибутам качества, отображаемые в пользовательских требованиях, в этой роли выступает преподаватель);

− Заказчиков (людей, которые являются целевой аудиторией на рынке программного обеспечения, в этой роли выступает преподаватель);

− Инженеров по программному обеспечению (людей, ответственных за техническую оценку путей решения поставленных задач и последующую реализацию требований заказчиков, в этой роли выступают студенты ‑ члены команды разработчиков).

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

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

Комментарии к примеру. В спецификации качества перечисляются основные требования по показателям качества:

- описывается уровень надежности ПС;

- формулируются требования по быстродействию;

- требования к разработке интерфейса и т.п.

Функциональная спецификация включает в себя:

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

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

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

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

Таблица 2 – Перечень исключительных ситуаций

Название подсистемы	Название исключительной ситуации	Реакция системы
1 Справочная	1.1 Не возможно открыть файл справки	Выдача сообщения «Файл справки поврежден»
1.2 Не возможно найти файл справки	Выдача сообщения «Отсутствует файл справки»
2 Файловая	2.1 Попытка открытия файла с несобственным форматом	Выдача сообщения «Файл поврежден или недопустимого формата»
2.2 Файл с заданным именем не существует	Выдача аналогичного сообщения
…	…	…

 

Таблица 1 – Перечень функций, выполняемых системой (фрагмент)

Название подсистемы	Название функции	Информационная среда
Входные данные	Выходные данные
Назначение (наименование)	Тип, ограничения	Назначение (наименование)	Тип, ограничения
1 Справочная	1.1 Выдать сведения о разработчиках	Сведения о разработчиках системы (ФИО, номер группы)	Текст (МЕМО)	Визуальное отображение информации	‑
1.2 Выдать сведения о системе	Файл справки	Текстовый (*.HTML)
Код ошибки	целое
2 Настройки параметров	2.1 Задать количество букв в пересечении	Диапазон количества букв: минимальное максимальное	Целое	Текущее значение букв в пересечении	Целое
2.2 Подключить словарь понятий	Имя файла	Строка, *.dict	Список понятий и их определений	Динамический массив строк
Код ошибки	Целое
2.3 Задать длину кроссворда	Диапазон длин: минимальное максимальное	Целое	Текущее значение длины	Целое
Код ошибки	Целое
…	…	…	…	…
3 Файловая	3.1 Загрузить файл с кроссвордом	Имя файла	Строка, *.kros	Кроссворд	Объект, структура определяется в ходе проектирования
Код ошибки	Целое

 

ЛАБОРАТОРНАЯ РАБОТА № 6
разработка прототипа интерфейса пользователя системы

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

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

Для чего нудна разработка пользовательского интерфейса? Как минимум, для этого есть две причины:

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

- хороший интерфейс может стать преимуществом против конкурентов, плохой ‑ послужить причиной неудачи всего проекта.

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

- опыт работы пользователей с компьютером, типовые ситуации использования;

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

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