Глава 3

Введение

Эта секция:

• объясняет, что происходит во время требований инженерии;

• объясняет характер спецификации требований;

• объясняет, как использовать случаи использования при определении требования;

• объясняет, как рисовать диаграммы прецедентов;

• предлагает руководящие принципы и контрольные списки для написания хорошего технические характеристики.

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

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

Когда инженеры имеют дело с требованиями, они

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

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

Что касается пользователей, то они иногда известны в качестве клиентов или клиентов.

Мы будем использовать термин "пользователь".

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

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

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

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

Это, как правило, потребляет 33% усилий по разработке проекта.

Если мы не можем точно определить, что требуется, это бесполезно

реализовать его.

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

В реальном мире разработки программного обеспечения. Есть сильные

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

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

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

Спецификация требований имеет вторую важную роль. Это мерилом для оценки работает ли программное обеспечение правильно – что она свободна от ошибок.

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

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

Стоимость фиксации ошибки во время тестирования может быть в 200 раз стоимости ее фиксации во время спецификации.

Предполагается, что-то вроде 50% ошибок возникают из

бедные спецификация.

Средство, конечно, обнаружить (или предотвратить) ошибки рано,

есть, во время спецификации.

Легко писать плохие спецификации требований, предъявляемых к

программного обеспечения; трудно писать хорошие технические характеристики.

В этой главе мы рассмотрим принципы для написания

технические характеристики.

Помните, что спецификации обычно не пишется один раз

и затем замораживают.

Более типично, требования изменяются в течение программного обеспечения

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

Понятие требования

Задача анализа и определения требований для системы

не является новым или свойственный программным обеспечением.

В течение нескольких поколений, инженеры проведения этих

виды деятельности.

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

спецификация для железнодорожного локомотива:

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

до 100 тонн на уклоне до 30% с ускорением

по меньшей мере, 30 км / ч / ч.

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

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

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

Он ничего не говорит о форме или механизмов колес.

Одна из самых больших противоречий в вычислениях, является ли это

желательно (или даже возможно), чтобы указать, что система должна делать без учета того, как система будет делать это.

Это отношения между спецификацией и реализацией.

Теперь мы будем смотреть на обе стороны этого аргумента.

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

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

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

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

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

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

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

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

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

перемешаны.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

логичным.

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

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

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

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

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

возможное.

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

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

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

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

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

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

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

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

что нужно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

нуждается.

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

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

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

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

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

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

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

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

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

• это понятно.

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

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

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

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

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

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

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

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

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

Нечеткость является общей проблемой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как две характеристики однозначными и понятными

Связанный?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подводя итог, роль аналитика:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

машины.

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

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

Требования к данным имеют три компонента:

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

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

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

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

библиотека.

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

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

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

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

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

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

• стоимость;

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

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

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

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

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

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

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

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

ограничения

Это влияет на внедрение системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ориентиром обеспечивает полезное направление для реализации в

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

Стратегия.

Например:

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

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

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

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

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

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

требования.

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

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

случаи "

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

клавиатуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

шаги.

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

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

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

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

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

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

Заметка:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

и печать.

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

системы.

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

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

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

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

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

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

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

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

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

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

ATM.

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

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

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

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

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

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

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

резюме

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

что это:

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

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

• соответствует;

• однозначна;

• кратким;

• минимальна;

• понятно;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упражнения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Случаи:

1. банкомат;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

клавиатуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

документ.

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

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

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

Команды предоставляются:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. заглавие;

2. автор;

3. ISBN;

4. год;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это пример безопасности критичных системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оператор.

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

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