С[ра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] обеспечение по существу состоит из комбинации данных и действий.

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

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

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