- •Анализ требований
- •1. Введение
- •1.1. Цель
- •1.2. Область применения
- •1.3. Определения, термины и сокращения
- •1.4. Ссылки
- •2. Общее описание
- •2.1. Перспективы продукта
- •2.1.1. Концепции операций
- •2.1.2. Концепции пользовательского интерфейса
- •2.1.2.1. Концепция зоны в пользовательском интерфейсе
- •2.1.2.2. Концепция пользовательского интерфейса для установки значений характеристик
- •2.2.2. Вариант использования «Перейти в соседнюю зону»
- •2.2.3. Вариант использования «Встретить внешний персонаж»
2.2.2. Вариант использования «Перейти в соседнюю зону»
Действующее лицо: игрок игры Встреча. Вариант использования:
Игрок щелкает на гиперссылке, соединяющей показанную зону с соседней.
Система показывает соответствующую соседнюю зону вместе с персонажем игрока.
2.2.3. Вариант использования «Встретить внешний персонаж»
Действующее лицо: игрок Встречи. Вариант использования:
Система помещает внешний персонаж в зону нахождения персонажа игрока, или Игрок попадает в зону с внешним персонажем.
Система осуществляет контакт двух персонажей.
Система показывает результат контакта.
Если персонаж игрока или внешний персонаж имеет 0 очков-жизней, игра заканчивается.
В противном случае Система перемещает персонаж игрока в произвольную зону, отличную от той, где произошел контакт, и показывает его там.
2..3. Пользовательские характеристики
[Примечание для студентов. Покажите, какие люди будут типичными пользователями программы. Например: новичок, профессионал в программном обеспечении, бухгалтер с 5-летним компьютерным стажем и т. д.]
Ожидается, что пользователю будет 20-35 лет.
2.4. Ограничения
[Примечание для студентов. Все условия, которые могут ограничить возможности разработчика. Могут исходить из разных источников.]
Встреча будет работать на ПК с Windows 95 или более поздней с минимальной скоростью 100 МГерц. Языком разработки будет Java.
2.5. Предположения и зависимости
[Примечание для студентов. Могут быть сделаны любые допущения.]
Нет.
2.6. Распределение требований
[Примечание для студентов. Порядок, в котором требования будут выполняться.]
Требования, описанные в разделах 1 и 2 этого документа будут называться «С-требования», в разделе 3 — «D-требования». Основной аудиторией С-требова-ний будет сообщество заказчиков, вторичной — разработчиков. Для D-требований ситуация обратная. Эти два уровня требований должны быть согласованными. Несогласованности должны быть отмечены отдельно как дефекты. В случае, когда требование сформулировано в С-требованиях и D-требованиях, приложение будет разрабатываться согласно D-требованиям, поскольку они более подробны. Основные требования (упомянутые в разделе 3) должны быть реализованы в этой версии игры Встреча. Желательные требования должны быть по возможности осуществлены в этой версии, но не обязательны для разработчиков. Желательно, чтобы часть из них присутствовала в будущей версии. Необязательные требования будут добавлены по желанию разработчиков.