С[РА60] другой стороны, некоторые люди утверждают, что это невозможно

спецификация развод и осуществление.

Действительно, в ряде крупных подходов к спецификации они

перемешаны.

При таком способе, первая задача состоит в том, чтобы понять и

документировать разработки существующей системы. (Это может быть

ручной или компьютерной системе на основе или некоторой комбинации.)

Это исследование служит в качестве прелюдии к развитию

новая компьютерная система.

Таким[РА61] образом, реализация одной системы (старый) выступает в качестве одной из основных ингредиентов в спецификации для новой системы.

Например, предположим, что мы хотели бы разработать компьютер

система для библиотеки, которая в настоящее время не используют компьютеры.

Один из подходов будет расследовать и документировать все

текущие ручные процедуры для покупки книг, каталогизация, стеллажи, суживающий и т.д.

Выполнив эту задачу, следующий шаг должен решить,

Какие сферы деятельности при помощи компьютера (например,

система кредитов).

Наконец[РА62] , спецификация новой системы происходит от

дизайн (реализация) старой системы.

Такой подход к развитию кажется очень привлекательным и

логичным.

Тем не менее, это не означает, что реализация и спецификации

переплетаются между собой.

Есть несколько, дополнительные и мощные причины, по которым

Аналитик должен думать о реализации в процессе спецификации.

Во-первых, они должны проверить, что требование технически

возможное.

Например, можно ли достичь время отклика 0,1 секунды?

Во-вторых, важно рассмотреть вопрос о реализации в целях

оценить стоимость и дата поставки программного обеспечения.

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

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

Но это не всегда практично.

качества спецификации

Мы[РА63] видели, что, в идеале, спецификация должна ограничиваться

что нужно.

Приведем список желательных качеств для спецификации.

Хорошая спецификация должна обладать следующими характеристиками:

· реализация бесплатно - то, что нужно, не так, как это достигнуто;

· Полная - нет ничего не хватает;

· соответствие - ни один человек требование не противоречит любой другой;

· однозначна - каждое требование имеет единственную интерпретацию;

· кратким - каждое требование указывается только один раз, без дублирования;

· минимальный - нет ненужных ингредиентов;

· понятно - обоими клиентами и разработчиками;

· достижимо - требование технически осуществимо;

· проверяемые - это может быть продемонстрировано, что требования был встречен.

Этот[РА64] перечень желательных признаков может быть использован в качестве контрольного листа, когда спецификация составляется.

Кроме того, он может быть использован в качестве контрольного списка для проверки и

улучшить существующую спецификацию.

Спецификация требования должны также быть в состоянии обеспечить

четкие указания относительно того, как проверить, что система отвечает своим пользователям "

нуждается.

В спецификации для локомотива, приведенного выше есть

много количественной информации, которая позволила бы объективно

суждение успеха локомотива с помощью измерения

инструменты, такие как секундомеры.

Мы[РА65] рассмотрим некоторые общие недостатки в спецификации.

Мы видели, что локомотив спецификация имеет

следующие положительные характеристики:

· он определяет требования, а не реализации

· это проверяемо

· это понятно.

Тем не менее, спецификация страдает, по меньшей мере, один недостаток: он неполным.

Например, нет никакого упоминания о стоимости или срока.

Давайте[РА66] теперь посмотрим на спецификации требований для простой кусок программного обеспечения:

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

По[РА67] вопросу о реализации, спецификация говорит, что

Программа должна быть написана на Java, который, безусловно, делать с "Как" реализации.

Во-вторых, спецификация не дает никаких деталей о деталях эти две функции; она является неполной.

Часто требование просто неясно, или восприимчивых к

альтернативные интерпретации, и это, конечно, вполне может быть связано с использованием естественного языка в спецификации.

Нечеткость[РА68] является общей проблемой.

Таким образом, требование, чтобы обеспечить удобный интерфейс

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

Некоторые слова являются неточными, и поэтому следует избегать

в пределах спецификации.

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

Иногда[РА69] требования противоречат друг другу, так как в этих двух:

· данные будут храниться на магнитной ленте;

· система будет реагировать менее чем за 1 секунду.

потому что магнитная лента не может обеспечить время отклика в одну секунду.

Пропуски или неполнота может быть трудно идентифицировать.

Типичная область спецификации, которая опущена является то, что, как

иметь дело с разломами, например, ошибок ввода пользователем системы.

В[РА70] общем и целом, построения успешной спецификации является сложной деятельности, которая нуждается в ярчайшие мышления.

Она нуждается в эффективной коммуникации между клиентом и разработчиком.

Она нуждается в наиболее точное использование естественного языка.

Обзор спецификации по количеству людей, может помочь улучшить его.

Как[РА71] две характеристики однозначными и понятными

Связанный?

как выявить требования

Активность[РА72] продуцировать требования включает аналитиков и пользователей говорить вместе, с первыми пытаются понять последнего.

Это требует ясной форме общения.

Навыки, вовлеченные со стороны аналитика не обычный,

технические навыки, связанные с разработкой программного обеспечения.

Это выходит за рамки данного вопроса, чтобы изучить вопросы

человеческого общения, которые участвуют, и мы будем в основном

сосредоточиться на обозначения и формат спецификаций.

Мы, однако, коснемся вопроса точек зрения.

Можно[РА73] выделить три вида деятельности, которые приводят к требованиям спецификации:

1. прослушивания (или требования извлечение)

2. мышление (или анализ требований)

3. письменной форме (или определение требований).

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

Анализ[РА74] требований является этапом, когда инженер-программист

просто думает!

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

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

Определение требований является написание четкое заявление, часто на естественном языке, то, что система, как ожидается, обеспечить для его пользователя.

Эта информация называется спецификации требований.

Как[РА75] и в любом сложном процессе общения и переговоров, эти

три вида деятельности (слушание, мышление, письмо), как правило, имеют место и повторно спорадически.

Разговор между клиентами и аналитиков часто будет долгим и сложным.

Существует, прежде всего, необходимо четко и затем общаться записывать требования четко.

Но тогда есть также переговорный компонент, в течение которого

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

В[РА76] конце концов, мы надеемся, может быть достигнуто соглашение об окончательном

Технические требования.

С самого начала любого проекта есть по крайней мере два

- точки зрения, что пользователей и разработчиков.

Как мы увидим, существуют культурные различия между

эти две группы, но и часто будут различия зрения

в группе пользователей.

Например, рассмотрим компьютерную систему, которая будет использоваться

кассиры в банке.

Кассиры могут быть обеспокоены с предоставлением хорошего клиента

обслуживание, удовлетворенность работой и обогащать свои рабочие места.

Они[РА77] могут негодовать на любые попытки ускорить или усилить свою работу.

Они могут возразить против каких-либо объектов в системе для мониторинга скорость их работы.

Управления в банке, однако, вероятно, будет касается затрат, производительности и эффективности.

Там вполне может быть конфликт интересов между кассирами и менеджеры.

Это рисует крайнюю картину, но показывает, что пользователям

не обязательно представляют собой единый, однородный вид.

Другой[РА78] пример возможного разрыва между пользователями и аналитиков является делать с уровнем ожидания пользователей.

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

Другие, возможно, наивные в противоположном направлении, и

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

Подводя[РА79] итог, роль аналитика:

· чтобы выявить и уточнить требования от пользователей.

· чтобы помочь устранить возможные различия зрения среди пользователей и клиентов.

· чтобы сообщить пользователям о том, что это технически возможно и невозможно.

· документировать требования (смотрите следующий раздел).

· вести переговоры и получить согласие пользователей и

· клиенты в спецификации (окончательный) требованиям.

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

Конечный[РА80] продукт выявления требований и анализа требования к программному обеспечению спецификации.

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

Если мы не можем точно утверждать, что система должна делать, то

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

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

Последующее развитие оценивается.

Три важных фактора, которые[РА81] необходимо учитывать:

1. уровень детализации;

2. кому адресовано документ;

3. обозначение используется.

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

Как мы уже видели, спецификация должна быть в идеале пользователи '

вид системы, а не что-нибудь о том, как система должна

быть реализован.

Второй[РА82] фактор возникает потому, что спецификация должна быть

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

Люди в этих двух наборов имеют различные фоны, экспертиза и жаргон.

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

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

К[РА83] сожалению, в то время как естественный язык отлично подходит для поэзии и любовные письма, это плохой автомобиль для достижения точной, последовательной и недвусмысленной спецификация.

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

Это подводит нас к вопросу о нотации.

Несколько нотации доступны для написания спецификаций:

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

Несколько[РА84] нотации доступны для написания спецификаций: продолжение

· формальной, используя математические обозначения, с строгостью и лаконичность. Этот подход выходит за рамки данной книги. Формальные методы, как правило, используются только в безопасности критически важных систем.

· полуформальные, используя сочетание естественного языка вместе с различными схематические и табличном нотаций. Большинство из них условные обозначения имеют свои истоки в методах разработки программного обеспечения, что есть, в способах реализации программного обеспечения. Таким образом, существует потенциальная проблема, включая информацию о реализации. Эти обозначения будут рассмотрены далее в этой книге и включают в себя псевдокод, диаграммы потоков данных и диаграммы классов.

В[РА85] настоящее время большинство спецификаций требований написано

на естественном языке, при помощи диаграмм вариантов использования.

Один из подходов заключается в разработке двух документов:

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

пользователи, описывающие представление данных пользователями системы и

выраженный на естественном языке. Это вещество из

контракт между пользователями и разработчиками.

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

Разработчики, выраженное в некоторой более формальной и обозначениях

описывая только часть информации, содержащейся в полной мере

Технические требования.

структура спецификации требований

Если[РА86] этот подход будет принят, то тогда проблема обеспечения

что эти два документа совместимы.

Принимая во внимание, что спецификация требований 3, как правило,

написанный на естественном языке, полезно планировать общий

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

Мы можем также определить те ингредиенты, которые, возможно,

не должны быть включены на всех, потому что они связаны с

реализация, а не требование.

Остальная часть этого раздела представляет один из способов

структурирования спецификаций.

Один из подходов к предоставлению четкой структуры в соответствии со спецификацией является разделение его на части.

Программное[РА87] обеспечение по существу состоит из комбинации данных и действий.

В спецификации, соответствующие элементы называются

функциональные и данные требования.

Одним из главных дискуссий в вычислениях о какой из

эти два основных элемента - данные или функции - первична.

Некоторые подходы к развитию, в частности, объект

ориентированный подход, целостны, рассматривая функции и данные с

равное значение.

Тем не менее, наша забота здесь со спецификацией, а не с

подходы к развитию.

Тем[РА88] не менее, формат спецификации будет иметь тенденцию отражать систему метод разработки получить работу.

Контрольный список для содержимого требований спецификации:

1. функциональные требования;

2. требования к данным;

3. Требования к эксплуатационным характеристикам;

4. ограничения;

5. руководящие принципы.

Теперь мы будем смотреть на них, в свою очередь.

функциональные требования

Функциональные[РА89] требования являются реальной сущности требований

Спецификация.

Они утверждают, что система должна делать.

Примерами могут служить:

Система отобразит заголовки всех книг, написанных

указанный автором.

Система будет непрерывно отображать температуры всех

машины.

Функциональные требования характеризуются глаголов, которые выполняют действия.

требования к данным

Требования[РА90] к данным имеют три компонента:

1. Данные пользователей, что поступает на вход или выходиз системы через

экран, клавиатура или мышь.

2. Данные, которые хранятся в системе, как правило, в файлах на диске,

например, информацию о книгах, которые проводятся в общественном

библиотека.

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

Например, для сервера.

Требования к производительности

Это[РА91] меры производительности, некоторые из которых являются

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

Примерами могут служить:

· стоимость;

· дата доставки;

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

· объемы данных (например, система должна быть способна хранить информация о 10000 сотрудников)

Это[РА92] меры производительности, некоторые из которых являются

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

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

· требования к надежности (например, система должна иметь среднее время наработки на отказ шести месяцев);

· требований безопасности.

ограничения

Это[РА93] влияет на внедрение системы.

Примером может служить:

Система должна быть написана на Java.

Ограничения иметь дело с такими статьями, как:

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

· объем доступной памяти;

· количество имеющихся в наличии магазина подложки;

· язык программирования для использования;

· совместимость ограничения (например, программное обеспечение должно работать под последней версией Windows).

Ограничения[РА94] часто обращаются реализации (например, спецификация

языка программирования) и, следовательно, должны быть включены

с осторожностью.

Например, это может быть излишне сдерживающим:

Поиск должен использовать бинарный метод отбивной.

методические рекомендации

Ориентиром[РА95] обеспечивает полезное направление для реализации в

ситуация, при которой может быть более одной реализации

Стратегия.

Например:

Время отклика системы на щелчки мыши должны быть

сведено к минимуму.

Или, в качестве альтернативы:

Использование основной памяти должно быть как можно меньше.

Много спецификаций перепутать областей, определенных выше, так что,

Например, принципы дизайна иногда путают с функциональными

требования.

случаи использования

Один[РА96] широко используемый подход к документированию требований является "использование

случаи "

Это текстовое описание, которое может быть дополнено

UML диаграмм вариантов использования.

Прецеденты принять точку зрения пользователя или пользователей

система. Пользователь, выполняющий определенную роль, называется актером.

Прецедент является задачей, которую актер нуждается в системе передавать вне.

Например[РА97] , в системе ATM (Приложение Al: АТМ), один из

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

В рамках снятия наличных, пользователь должен будет выполнять

подзадачи, такие как предлагая карту и ввести ПИН-код, но

эти меньшие задачи не использовать случаи.

Это общая задача пользователя, который представляет собой вариант использования.

Приложение Al: Банкомат:

Банкомат имеет экран, устройство для чтения карт, маленький принтер, дозатор наличных и клавиатуру.

Клавиатура[РА98] имеет цифровые кнопки, клавишу ввода и кнопку сброса.

На левой и правой части экрана расположены три кнопки, которые

позволяют выбрать любые настройки, отображаемые на экране.

Банкомат подключен к банку через телефонную линию.

Банкомат предоставляет средства для:

· выдаче наличных денежных средств;

· отображения текущего баланса.

Пользователь[РА99] должен сначала предложить свою карту к считывателю.

Дисплей затем просит пользователя ввести свой PIN-код, с помощью

клавиатуры.

Если это успешно, дисплей представляет собой набор опций.

Система должна быть очень надежной, так как она будет использоваться

неподготовленных клиентов банка в общественных местах.

Прецедент[РА100] как определяет то, что пользователь делает и то, что система делает, но ничего не говорит о том, как система выполняет свои задачи.

В системе ATM, случай использования для снятия наличных:

снимать наличные деньги: Пользователь предлагает свою карту. Система

запрашивает PIN-код. Пользователь вводит PIN-код. Система проверяет

Контактный. Если карта и PIN действительны, система побуждает

Пользователь по своему выбору функции. Пользователь выбирает выдаче наличных денежных средств.

Пользователь запрашивает сумму. Пользователь вводит сумму.

Система выталкивает карту. Когда пользователь отозванной

карта, система распределяет денежные средства.

Мы[РА101] видим, что задача пользователя требует целый ряд подробных

шаги.

Иногда цель пользователя не достигается, например,

если PIN-код является неправильным.

Тем не менее, общее название использования описывает то, что

обычно бывает.

Другие случаи использования для банкомата являются проверка баланса и передача денег.

Написать[РА102] случай использования для проверки баланса.

Заметка:

Трудоустроить проводить само-

тестовый вопрос для проверки баланса банковского счета лица путем

с помощью банкомата.

Вы[РА103] увидите, что иногда различные варианты использования имеют части в распространенным явлением.

Это не проблема.

В приведенном выше примере, и в большинстве случаев, актер является

человек, но актер может быть любым, который взаимодействует с системой.

Это может быть, например, другая система программного обеспечения или другой компьютер общения через Интернет.

Например, на веб-сервере (программы), актер является веб

Программа браузер, работающий на другом компьютере.

Иногда[РА104] трудно определить отдельные случаи использования.

В банкомате, например, ввод и проверка ПИН

использовать случай?

Ответ будет не потому, что она не является полезной функцией от

Точка зрения пользователя, в то время как снятие наличные.

Предположим, что человек выполняет ряд операций,

вставить свою карту, снятие наличных, проверка их баланс и

затем переводить деньги.

Является ли эта коллекция один случай использования?

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

Один[РА105] из способов определить различные варианты использования заключается в определении цели, что актер хочет достичь.

Другая точка зрения заключается в определении какой-то исход значение для

Пользователь.

Задача правильного ввода PIN-кода не является ни целью, ни

ценный результат.

Это лишь часть некоторой полной и полезной функции. это

поэтому не является допустимым использование случай сам по себе.

Для большой системы будет много случаев использования. Чтобы

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

Каждый[РА106] пакет содержит набор соответствующих прецедентов.

Например, текстовый процессор имеет много команд, но

Команды находятся в группах, таких как подачи, редактирования текста, настройки стилей

и печать.

Множество вариантов использования представляет собой функциональную спецификацию

системы.

Это само по себе является ценным, но, как мы увидим, случаи использования может

также могут быть использованы для:

· получаем структуру программного обеспечения;

· создание тестовых случаев;

· помощь написать инструкцию;

· предсказать стоимость программного обеспечения.

В некоторых подходах к развитию, такие как методы Проворных

и Унифицированный процесс (как описано ниже в этом разделе), использование случаи являются движущей силой процесса развития.

Мы[РА107] можем документировать случаи использования, например, те, кого мы встретили, как UML

диаграмма прецедентов. Рисунок 4.1 показывает диаграмму вариантов использования для

ATM.

Существует[РА108] единственный актер, показанный как фигурку.

Название роли пользователя, показан ниже.

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

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

Тем не менее, это действительно дает общую картину актеров и

случаи использования.

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

резюме

Идеальные[РА109] характеристики спецификации требований

что это:

· осуществление бесплатно;

· в комплекте;

· соответствует;

· однозначна;

· кратким;

· минимальна;

· понятно;

· достижимыми;

· проверяемым.

Ряд[РА110] обозначений и подходов доступны для выполнения

Технические требования.

Обозначения варьируются от неформальных (использование диаграмм прецедентов)

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

Полезный перечень для ингредиентов спецификации является:

1. функциональные требования;

2. требования к данным;

3. Требования к производительности;

4. ограничения;

5. методические рекомендации.

Основным[РА111] средством для описания функциональных требований являются случаи использования и UML использования диаграммы вариантов.

Прецедент является текстовое описание небольшой, но полный пользователь задачей.

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

Основная проблема с спецификациями хорошая связь,

как в дискуссиях и в письменной форме.

Упражнения

1. Приложение[РА112] A дает спецификации для нескольких систем. Для каждого спецификация идентифицировать функциональные, данные и производительность компоненты спецификации. Использование руководящих принципов и контрольных списков приведенные выше переписывать и тем самым улучшить спецификацию.

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

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

4. Групповые упражнения. Один из способов понимания более четко

трудности выполнения требований заключениях является осуществить

ролевые упражнения. Студенты могут разделить на группы по четыре

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

Пользователям потратить десять минут при принятии решения, что они вместе

хотеть. В то же время аналитики проводят десять минут решить, как

они собираются идти о выявлении требований от пользователей.

Пользователи и аналитики затем проводят 15 минут вместе,

в ходе, которого аналитики пытаются выявить требования.

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

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

Возможные сценарии являются системы уже указанные в Приложении А.

Позже можно найти ниже.

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

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

6. Кто должен проводить консультации при сборе требованиям

Компьютерная система для замены существующей информационной системы?

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

8. Определение терминов полноты и согласованности в Спецификация. Как мы можем их достичь?

9. Каковы навыки, необходимые для сбора, анализа и записи Требования к программному обеспечению?

10. Объясните трудности, связанные с использованием естественного языка для описания требования.

11. Почему разработка требований так важно и почему его так трудно?

4.1 Если[РА113] что-то неоднозначное оно не может быть четко

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

4.2 Прецедент для проверки баланса с помощью банкомата:

1) Пользователь предлагает свою карту.

2) Система запрашивает PIN-код.

3) Пользователь вводит PIN-код.

4) Система проверяет PIN-код.

S) Если карта и PIN действительны, система предложит пользователю

для их выбора функции.

6) Пользователь выбирает проверить баланс.

7) Система отображает текущий баланс.

Приложение A: тематические исследования

Используются[РА114] тематические исследования в этой книге для иллюстрации

объяснения. Они также используются в качестве основы для некоторых из упражнения в конце глав.

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

Случаи предназначены для захвата интереса читателя и чтобы быть типичным для целого ряда применений. Они также являются приложения

которые знакомы большинству читателей.

Дела могут также выступать в качестве проектов, которые могут быть осуществлены в параллельно с изучением книги.

Случаи[РА115] :

1. банкомат;

2. текстовый процессор;

3. компьютерную игру;

4. библиотека;

5. система мониторинга пациента.

Каждое приложение представлено в виде программного обеспечения контура технические требования (SR5).

Обратите внимание, что они не предлагается в качестве спецификации модели.

Напротив, они представлены в виде спецификаций

обзора и критики, в частности, в качестве упражнения для главы 4

на технические требования.

Обзор является официальная оценка чего-то с

Намерение о возбуждении изменения в случае необходимости.

Критика действие, осуждающую что-то или кто-то.

Критика представляет собой заявление, которое выражает неодобрение.

Приложение A: АТМ

Банкомат[РА116] имеет экран, устройство для чтения карт, маленький принтер, банкомат и клавиатуры.

Клавиатура имеет цифровые кнопки, клавишу ввода и кнопку сброса.

На левой и правой части экрана расположены три кнопки, которые позволяют выбрать любые настройки, отображаемые на экране.

Банкомат подключен к банку через телефонную линию.

Банкомат[РА117] предоставляет средства для:

· выдаче наличных денежных средств;

· отображения текущего баланса.

Пользователь должен сначала предложить свою карту к считывателю.

Дисплей затем просит пользователя ввести свой PIN-код, с помощью

клавиатуры.

Если это успешно, дисплей представляет собой набор опций.

Система должна быть очень надежной, так как она будет использоваться

неподготовленных клиентов банка в общественных местах.

Приложение A: Word

Это[РА118] пример программного обеспечения общего назначения, который будет используется большим количеством различных людей.

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

Текстовый процессор отображает пустую панель, которая отображает

текст, введенный с клавиатуры.

Пользователь может:

· сохранить документ в указанный файл;

· извлечения документа из указанного файла;

· распечатать документ.

Документ[РА119] состоит из предложений, заканчивающихся в период символа.

Параграф состоит из нуля или несколько предложений заканчивается в

специальный истекшим пункта характер.

Новый разрыв страницы может быть вставлен в любом месте в пределах

документ.

Часть текста может быть выбран щелчком непосредственно перед

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

Клип плата является временным хранилищем, которое не видно.

Команды[РА120] предоставляются:

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

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

· вставка текста в позиции курсора из клипа борту.

Документ может отображаться в качестве исходного текста или как отформатированный

текст подходит для печати.

Приложение A: Пришельцы из космоса

Киберпространство[РА121] оккупанты является разновидностью игры, которая была популярна в первые дни компьютерных игр.

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

Кроме того, легко видеть связь между визуальным

Внешний вид и структура программного обеспечения.

Спецификация выглядит следующим образом.

Окно отображает защитника и чуждой (рисунок А.1).

Иностранец[РА122] движется боком. Когда она попадает в стену, он меняет свое

направление. Иностранец случайно запускает бомбу, которая движется

вертикально вниз.

Если бомба попадает в защитника, пользователь теряет жизнь. В игре корабль защитника перемещается влево или вправо в соответствии с мышью движения.

При щелчке мыши, защитник запускает лазер что движется вверх.

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

Кнопка предоставляется, чтобы начать новую игру.

Приложение A: библиотека

Это[РА123] приложение является типичной информационной системы. Программное обеспечение

необходимая для поддержания информации о книгах, проводимых в библиотеке.

Система предназначена для использования сотрудниками библиотеки.

Программное обеспечение должно работать на стандартных сетевых компьютерах. Там

может быть до 20 компьютеров в сети библиотек.

Для каждой книги, следующая информация хранится в компьютере:

1. заглавие;

2. автор;

3. ISBN;

4. год;

5. идентификация заемщика (если на кредит);

6. дата выдачи (если на правах аренды).

Компьютер[РА124] должен иметь возможность хранить информацию о до

100000 книг. Компьютерная система должна обеспечивать средства для:

· выпустить книгу заемщику;

· получить книгу, возвращаемую заемщику;

· создавать информацию о недавно приобретенной книги;

· отображение списка книг по кредиту для конкретного заемщика.

Средства должны быть доступны через GUI (графический пользовательский

Интерфейс). Компьютер должен ответить в течение одной секунды до любой запрос.

Система[РА125] должна обеспечивать возможность поиска, чтобы выяснить, является ли библиотека обладает определенной книге.

С помощью соответствующих мер безопасности, система будет

инициализировать библиотечную информацию таким образом, что она содержит ноль книги.

Когда книга становится просроченной, система должна отображать

соответствующая информация.

Система должна обеспечивать безопасный доступ лишь сотрудники библиотеки.

Программное обеспечение должно быть поставлено на такой-то даты и не стоить не более $ 100 000.

Он должен быть полностью документированы и просты в обслуживании.

Приложение A: cистема мониторинга пациента

Это[РА126] пример безопасности критичных системы.

Другие подобные системы включают в себя систему управления мощностью станция и система проходит по проводам для самолета.

Компьютерная система контролирует жизненно важные признаки пациента в больнице.

Датчики, прикрепленные к пациенту, непрерывно посылают информацию

к компьютеру:

· частота сердечных сокращений;

· температура;

· кровяное давление.

Некоторые[РА127] из этих показаний обязательный переход к полезным

единицы измерения (например, микровольтах в градусах Цельсия).

Компьютер отображает информацию на экране.

Он также записывает информацию в файл, который может быть получен

и отображается.

Если какой-либо из жизненно важных признаков превышают безопасные пределы, экран мигает предупреждение и звучит сигнал тревоги.

Установки имеют значения по умолчанию, но также может быть изменен

Оператор.

Если датчик выходит из строя, экран мигает предупреждение и

звучит сигнал тревоги.

[РА1]Презентация 1, Слайд 3

[РА2]Презентация 1, Слайд 4

[РА3]Презентация 1, Слайд 5-9

[РА4]Презентация 1, Слайд 10

[РА5]Презентация 1, Слайд 11

[РА6]Презентация 1, Слайд 12

[РА7]Презентация 1, Слайд 13

[РА8]Презентация 1, Слайд 14

[РА9]Презентация 1, Слайд 15

[РА10]Презентация 1, Слайд 16

[РА11]Презентация 1, Слайд 17

[РА12]Презентация 1, Слайд 18

[РА13]Презентация 2, Слайд 6

[РА14]Презентация 2, Слайд 6

[РА15]Презентация 2, Слайд 7-8

[РА16]Презентация 2, Слайд 9

[РА17]Презентация 2, Слайд 10

[РА18]Презентация 2, Слайд 11

[РА19]Презентация 2, Слайд 12

[РА20]Презентация 2, Слайд 13

[РА21]Презентация 2, Слайд 14

[РА22]Презентация 2, Слайд 15

[РА23]Презентация 2, Слайд 16

[РА24]Презентация 2, Слайд 18

[РА25]Презентация 2, Слайд 19

[РА26]Презентация 2, Слайд 20

[РА27]Презентация 2, Слайд 21

[РА28]Презентация 2, Слайд 22

[РА29]Презентация 2, Слайд 23

[РА30]Презентация 2, Слайд 24

[РА31]Презентация 2, Слайд 25

[РА32] [РА32]Презентация 2, Слайд 26

[РА33]Презентация 2, Слайд 27

[РА34]Презентация 2, Слайд 28

[РА35]Презентация 2, Слайд 29

[РА36]Презентация 2, Слайд 30

[РА37]Презентация 2, Слайд 31

[РА38]Презентация 2, Слайд 32

[РА39]Презентация 2, Слайд 33

[РА40]Презентация 2, Слайд 34

[РА41]Презентация 2, Слайд 35

[РА42]Презентация 2, Слайд 36

[РА43]Презентация 2, Слайд 37

[РА44]Презентация 2, Слайд 38

[РА45]Презентация 2, Слайд 39

[РА46]Презентация 2, Слайд 40

[РА47]Презентация 2, Слайд 41

[РА48]Презентация 3, Слайд 5

[РА49]Презентация 3, Слайд 6

[РА50]Презентация 3, Слайд 7

[РА51]Презентация 3, Слайд 8

[РА52]Презентация 3, Слайд 9

[РА53]Презентация 3, Слайд 10

[РА54]Презентация 3, Слайд 11

[РА55]Презентация 3, Слайд 12

[РА56]Презентация 3, Слайд 13

[РА57]Презентация 3, Слайд 14

[РА58]Презентация 3, Слайд 15

[РА59]Презентация 3, Слайд 16

[РА60]Презентация 3, Слайд 17

[РА61]Презентация 3, Слайд 18

[РА62]Презентация 3, Слайд 19

[РА63]Презентация 3, Слайд 21-22

[РА64]Презентация 3, Слайд 23

[РА65]Презентация 3, Слайд 24

[РА66]Презентация 3, Слайд 25

[РА67]Презентация 3, Слайд 26

[РА68]Презентация 3, Слайд 27

[РА69]Презентация 3, Слайд 28

[РА70]Презентация 3, Слайд 29

[РА71]Презентация 3, Слайд 30

[РА72]Презентация 3, Слайд 31

[РА73]Презентация 3, Слайд 32

[РА74]Презентация 3, Слайд 33

[РА75]Презентация 3, Слайд 34

[РА76]Презентация 3, Слайд 35

[РА77]Презентация 3, Слайд 36

[РА78]Презентация 3, Слайд 37

[РА79]Презентация 3, Слайд 38

[РА80]Презентация 3, Слайд 39

[РА81]Презентация 3, Слайд 40

[РА82]Презентация 3, Слайд 41

[РА83]Презентация 3, Слайд 42

[РА84]Презентация 3, Слайд 43

[РА85]Презентация 3, Слайд 44

[РА86]Презентация 3, Слайд 45

[РА87]Презентация 3, Слайд 46

[РА88]Презентация 3, Слайд 47

[РА89]Презентация 3, Слайд 48

[РА90]Презентация 3, Слайд 49

[РА91]Презентация 3, Слайд 50

[РА92]Презентация 3, Слайд 51

[РА93]Презентация 3, Слайд 52

[РА94]Презентация 3, Слайд 53

[РА95]Презентация 3, Слайд 54

[РА96]Презентация 3, Слайд 55

[РА97]Презентация 3, Слайд 56

[РА98]Презентация 3, Слайд 57

[РА99]Презентация 3, Слайд 58

[РА100]Презентация 3, Слайд 59

[РА101]Презентация 3, Слайд 60

[РА102]Презентация 3, Слайд 61

[РА103]Презентация 3, Слайд 62

[РА104]Презентация 3, Слайд 63

[РА105] [РА105]Презентация 3, Слайд 64

[РА106]Презентация 3, Слайд 65-66

[РА107]Презентация 3, Слайд 67

[РА108]Презентация 3, Слайд 68

[РА109]Презентация 3, Слайд 69

[РА110]Презентация 3, Слайд 70

[РА111]Презентация 3, Слайд 71

[РА112]Презентация 3, Слайд 72-76

[РА113]Презентация 3, Слайд 77

[РА114]Презентация 3, Слайд 81

[РА115]Презентация 3, Слайд 82

[РА116]Презентация 3, Слайд 84

[РА117]Презентация 3, Слайд 85

[РА118]Презентация 3, Слайд 86

[РА119] [РА119]Презентация 3, Слайд 87

[РА120]Презентация 3, Слайд 88

[РА121]Презентация 3, Слайд 89

[РА122]Презентация 3, Слайд 91

[РА123]Презентация 3, Слайд 92

[РА124]Презентация 3, Слайд 93

[РА125]Презентация 3, Слайд 94

[РА126]Презентация 3, Слайд 95

[РА127]Презентация 3, Слайд 96