Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Функциональные требования — описывается в системной спецификации (system requirement specification, SRS). Определяют функциональность ПО, которую разработчики должны построить, чтобы пользователи смогли выполнить свои задачи в рамках бизнес-требований. Иногда именуемые требованиями поведения (behavioral requirements), они содержат положения с традиционным "должен" или "должна": "Система должна по электронной почте отправлять пользователю подтверждение о заказе".
Нефункциональные требования — требования, которые определяют критерии работы системы в целом, а не отдельные сценарии поведения. Нефункциональные требования определяют системные свойства, такие как производительность, удобство сопровождения, расширяемость, надежность, средовые факторы эксплуатации.
К действиям по управлению требованиями относятся:
- определение основной версии требований (моментальный срез требований для конкретной версии продукта);
- просмотр предлагаемых изменений требований и оценка вероятности воздействия каждого изменения до его принятия;
- включение одобренных изменений требований в проект установленным способом;
- согласование плана проекта с требованиями;
- обсуждение новых обязательств, основанных на оцененном влиянии изменения требований;
- отслеживание отдельных требований до проектирования, исходного кода и вариантов тестирования;
- отслеживание статуса требований и действий по изменению на протяжении всего проекта.
Сформулируйте определение пользовательского интерфейса. Приведите описание подходов к разработке ПИ.
Пользовательский интерфейс это среда, обеспечивающая взаимодействие пользователя и программного обеспечения. Пользовательский интерфейс – это то, с чем человек может работать непосредственно (т.е. интерфейс через экран, клавиатуру, мышь и т.д.).
подходы к построению интерфейсов:
Золотое сечение
Золотое сечение — это самая комфортная для глаза пропорция, форма, в основе построения которой лежит сочетание симметрии и золотого сечения, способствует наилучшему зрительному восприятию и появлению ощущения красоты и гармонии.
С развитием дизайна и технической эстетики действие закона золотою сечения распространилось на конструирование машин, мебели и т. д. Проектирование компьютерных интерфейсов — не исключение. Формы диалоговых окон и элементов управления, стороны которых относятся как 1,618, очень привлекательны для пользователей.
Кошелек Миллера
Этот принцип назван так в честь ученого-психолога Г. А. Миллера.
Применяя принцип кошелька Миллера в дизайне интерфейсов, следует группировать элементы в программе (кнопки на панелях инструментов, пункты меню, закладки, опции на этих закладках и т. п.) с учетом этого правила— т. е. не более семи в группе, в крайнем случае — девяти.
Итак, принцип кошелька Миллера говорит о семи плюс-минус двух элементах. Такие небольшие группы объектов наиболее хорошо воспринимаются взглядом пользователя.
Принцип группировки
Согласно этому правилу, экран программы должен быть разбит на ясно очерченные блоки элементов, может быть, даже с заголовком для каждого блока. При этом группировка, естественно, должна быть осмысленной: как расположение элементов в группах, так и расположение самих групп друг от друга должны быть продуманы.
Бритва Оккама
Философский принцип, носящий название "Бритва Оккама", гласит: "Не множить сущности без надобности".
На языке интерфейсов это означает, что:
· любая задача должна решаться минимальным числом действий;
· логика этих действий должна быть очевидной для пользователя;
· движения курсора и даже глаз пользователя должны быть оптимизированы.
Видимость отражает полезность
Смысл этого принципа состоит в том, чтобы вынести самую важную информацию и элементы управления на первый план и сделать их легкодоступными пользователю, а менее важную — переместить, например, в меню.
Умное заимствование
Заимствование широко распространенных приемов дизайна интерфейсов и удачных находок авторов конкурирующих программ позволяет резко сократить время обучения и повысить комфорт пользователя. При работе он будет использовать уже приобретенные навыки — этот вопрос затрагивает и принцип равенства между системой и реальным миром.
Заимствование чужих интерфейсных находок не является чем-то зазорным. Программы, лидирующие па рынке, являются неистощимым источником вдохновения для разработчиков более мелких программ, поразительно напоминающих легендарный Norton Commander: FAR, Volcov Commander, DOS Navigator, DISCo Commander.
Модель ролей.
Эта модель дает список ролей пользователей системы, каждая из которых представляет собой абстрактную группу задач и нужд некоторого множества пользователей. Ролевая модель может определять связи между ними — по уточнению, по включению, по сходству — и набор из одной-двух-трех центральных ролей, на которых, в основном, и будет нацелено проектирование.
Кроме того, каждая роль может быть снабжена профилями, указывающими различные ее характеристики по отношению к контексту использования системы. Профили могут быть следующими.
Обязанности — требования к знаниям (о предметной области, о самой системе и прочим), которым пользователь в данной роли, скорее всего, удовлетворяет.
Умения — уровень мастерства в работе с системой.
Взаимодействия — типичные варианты взаимодействия с системой, включая их частоту, регулярность, непрерывность, концентрацию, интенсивность, сложность, предсказуемость, управление взаимодействием.
Информация — источники, объем, направление передачи и сложность информации при взаимодействии с системой
Критерии удобства — специфические критерии удобства работы для данной роли (быстрота реакции, точность указаний, удобство навигации и пр.).
Функции — специфические функции, возможности и свойства системы, необходимые или полезные для данной роли.
Другие — возможные убытки от ошибок, риски и пр.
Модель задач.
Модель задач, которую можно использовать для проектированяи пользовательского интерфейса, строится на основе сценариев или вариантов использования (use cases), в которых остаются только цели и задачи пользователя в рамках данного варианта, и нет неявных предположений о наличии определенных интефейсов между пользователями и системой. Удобно описывать такие сценарии в виде двух наборов — устремлений пользователя (не действий, а задач которые он хочет решить) и обязательств системы в ответ на эти устремления.
Модель содержимого.
Модель содержимого пользовательского интерфейса описывает набор взаимосвязанных контекстов взаимодействия или рабочих пространств (представляемых экранами, формами, окнами, диалогами, страницами и пр.) с содержащимися в них данными и возможными в их рамках действиями.
При построении этой модели важно определить что войдет в состав интерфейса и не решать вопрос о том, как оно будет выглядеть.
На начальном этапе один контекст взаимодействия ставится в соответствие одному (не вспомогательному!) варианту использования или группе очень походих вариантов, для выполнения которых понадобится один набор инструментов.
Средства для поддержки вспомогательных расширяющих вариантов использования обычно удобно помещать в контексты расширяемых ими основных вариантов.
Сначала определяется, какая информация должна находится в заданном контексте для успешного решения задач соответствующего варианта использования, затем определяется список необходимых операций с этой информацией.
После определения набора контекстов и их информационного и функционального содержимого рисуется карта навигации между контекстами.
После разработки модели содержимого всякий основной вариант использования должен быть поддержан при помощи одного или нескольких контекстов.