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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ⇐ Назад
• 1
• 234
• 5
• Далее ⇒