Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 21
Текст из файла (страница 21)
В своей статье Лора Шерер (1дша ЯсЬагег, 1981) описывает эту проблему и предлшзет некие рекомендации по ее смягчению. В табл. 7.1 представлены некоторые аспекты данной проблемы и предлагаемые решения. 104 Часть 2. Понимание потребностей пользователей Окончание жаба. 7.1 Решение Проблема Пользователи думают, что они знают, чего хо Как можно раиьше предлагать альтернативные тят.
до тех пор, пока разработчики ие предос- методы выявления: раскадровку, ролевые игры, тзвят им то, что они якобы хотели прототипы и т,п. Аналитики думают, что они понимают пробле- Постаэизь аналитика иа место пользователя. мы пользователя лучше его самого Провести ролевую игру в течение часа или все.
го дня Все считают, что др1тие руководствуются в<» Такова человеческая натура, поэтому пусть все литическими мотивами остается как есть Мы надеемся, что лучше понимая природу этих проблем и некоторые подходы по их смягчению, разработчики будут лучше подготовлены к дальнейшей работе. Методы выявления требований Для достижения лучглего понимания потребностей пользователя нам нужно переместиться из области битов и байтов, где многие разработчики чувствуют себя более комфортно, в область, где нужно общаться с реальными людьми и понимать проблемы реального мира. Существует множество методов, которые можно использовать для анализа и проектирования программных решений. Аналогично существует множество методов для понимания требований пользователей н заинтересованных лиц.
В главах 4-6 мы начали свой путь с анализа проблемы, рассмотрели ряд вопросов, которые можно задать относительно налагаемых на систему ограничений, описали моделирование бизнес-процесса, которое можно использовать для многих приложений, а также ознакомились с методами системной инженерии, которые можно применить к сложным системам со встроенным программным обеспечением. В следующих главах будут описаны метолы, доказавшие свою эффективность в преодолении трех перечисленных вьнвс синдромов.
° Интервьюирование и анкетирование ° Совещания, посвященные требованиям ° Мозговой штурм и отбор идей ° Раскадровки ° П ре цеденты ° Обыгрывание ролей ° Создание прототипов Выбор конкретного метода будет зависеть от типа приложения, опыта и уровня подготовки команды разработчиков, заказчика, масштаба проблемы, критичности приложения, используемой технологии и уникальности приложения. Глава 8 Функции продукта или системы Основные полоакепия ° Команда разработчиков должна играть более активную роль в выявлении требований к системе.
И Функции системы нли продукта являются высокоуровневым выражением желаемого поведения системы. , ° Количество функций системы должно находиться в пределах 25-99: пред- почтительно, чтобы оно не превышало 00. ° Атрибуты обеспечивают дополнительную информацию о функции. В предыдущих главах мы описали ряд проблем, приводящих к тому, что команда разработчиков практически никогда не получает совершенной или, по крайней мере, достаточно хорошей спецификации, которую можно использовать в качестве основы для разработки системы. Один из выводов, который из этого следует, состоит в том, что если нам не дают хороших определений, мы должны сами пойти и добыть их.
Другими слова. ми, чтобы добиться успеха, команда разработчиков должна играть гораздо более активнуто роль в процессе выявления требований, Мы увидим, что хотя и можно возложить основную часть этой ответственности на руководителя, аналитика или менеджера продукта, в конечном итоге вся команда будет вовлечена в тот или иной этап ланного процесса. Потребности заинтересованных лиц и пользователей Очевидно, что команда разработчиков может создать хорошую систему только в том случае, если она понимает реальные потребности заинтересованных лиц, Эта ин<~юрмация необходима команде для принятия правильных решений при определении и реализации системы, Совокупность исходных данных, которые мы называем гютРебиоонлми заинвмРесоеанныхлиц или иользоелтелпк представляет собой критически вюкиый фрагмент собираемой картины.
Зачастую эти потребности пользователя будут иеоднозначпымп и размытымн. Закаэчик люасет сказать: "Мне нужны простые способы, позволяющие узнать состояние моих складских запасов" илп "Мпе бы хотелось, чтобы существенно возросла производительность ввода заказов на покупку". Но, несмотря на нечеткость формулировки, именно эти высказывания создают основу для всех последующих действий. раз они 106 Часть к. Понимание потребностей пользователей так важны, мы направим свои усилия иа то, чтобы как следует понять их. Мы определим потребность заинтересованного лица следующим образом.
Отразсспив явкой личной, рабочей пли бизнес-проблемы (мли вимозсности), резинке кото)юй оправдывавсп замысел, покупку или использование новой сясякмы. ФУНКЦИИ Интересно, что, говоря о своих потребностях или требованиях к новой системе, заинтересованные лица, как правило, описывают их ие так, как в приведенных вьсше высказываниях.
Они часто называют вам не свою реальную потребность (" Если я не повышу производительность этого отдела, то не получу премию за этот год" или "Я хочу иметь возможность затормозить эту машину как можно быстрее без пробуксовки") и не реальное требование к системе ("Я должен снизить время обработки ввода заказов на покупку на 00 процентов" или "Автомобиль должен иметь систему компьютерного контроля для каждого колеса"). Вместо этого они описывают некую абстракцию, чтото вроде "Мне нужен новый экран на основе СШ для ввода заказов на покупку" или "Я хочу, чтобы машина была оснащена антиблокировочной тормозной системой". Мы называем эти высокоуровневые выражения желаемого поведения системы Япккалмсс ()саситез) продукта или системы.
Эти функции часто не очень хорошо определены и могут даже противоречить друг другу. "Я хочу увеличить скорость обработки заказов" и "Я хо гу обеспечить более дружественный пользователю интерфейс, чтобы помочь нашим новым служащим изучить систему", ио так или иначе они являются отражением реальных потребностей. Что происходит при обсуждеиииу Пользователь уже преобразовал реальную потребность (производительность или безопасность) в поведение системы, которое, по его мнению, будет служить реальной потребности (рис. 8.1). При этом что ("Мне нужно" ) незаметно заменилось на как ("что, по моему мнению, должна делать система, чтобьс удовлетворить данную потребность" ).
Это неплохо, так как он имеет реальный опыт в данной предметной области и реальное понимание значения функции. Кроме того, такие функции легко обсуждать и документировать на обычном языке. а также объяснять их другим. что существенно обогащает схему требований. Использование функций — удобный способ описания возможностей без лшяних подробностей. Но такой подход имеет недостаток. Если команда при обсуждении не поймет, какая потребность стоит за функцией, это может привести к неприятным последствиям. Если по какой-либо причине функция ие служит реальной потребности, то система может потерпеть неудачу в удовлетворении целей пользователя. несмотря на то что в ней будет реализована запрашиваемая функция.
Тем не менее мы считаем этот высокий уровень абстракции, эти фупкмии, весьма полезным и удобным способом описания функциональных возможностей новой системы без излишних подробностей. Данные функции будут служить основой нашей деятельно. сти по разработке требований. Глава 8. Функции продукта нли системы 107 крашения 1Ъс. 8.1. 71эебоевккл к фукянкк вкесно еэвкмосаианы Ранее мы определили функцию следующим образом. Ойауэпмаике, предоставляемое сисжемой длл выполнения одной цеп нескольких пошребкосямй заказчика.
В таком определении описываемые пользователями Янкции не мокуг быть столь уж далеки от их яиллрсбкюплей„так что у нас есть удобный способ, чтобы начать определять систему, Основным при понимании нужд пользователя является выявление и организация повлкб кослмй и 1буикцкй предлагаемой системы. Иногда мы будем получать все потребности и ни одной функции, а в других случаях нам будут указаны все функции и ни одной потребности. По.
рой мы не сможем отделить их друг от друза. Но, помня о различии между ними, кгьл в любом случае должны выделять информацию о том, что система должна делать Функции легко описать на обычном языке. Их описания состоят из коротких фраз (табл. 8.1), липка изредка функции раэрабатывзются более подробно. Они представляют собой очень полезные конструкции для управления масштабом продукта на ранних этапах взаимных согласований и поиска компромиссов. Формулировка функций не требует значительных инвестиций; их легко описать и перечислить. Таблица 8.1. Примеры функций Прикладная область Пример функции Осуществляемое вручную управление дверью при угрозе пожара Предоставлять свежую информацию о состоянии всех инвентарных единиц Обеспечивать текущие данные лля оценки качества продукции Система управления элеватором Система управления запасами Система обнаружения неисправностей 108 Часть 2. Понимание потребностей пользователей Окончание табл.
8.1 Прикладная область Пример функции Система обработки платензьых ведомостей Сообщать текущие начисления по категориям Аэтоыатическая система дольашнего осэеще. пня (НО1.Б) Установка специзлыюго режима на период длительного отсутствия Система контроля вооружений Требуется, как минимум, две незаэисиные конфигурации авторизации для запуска Совместимость с ллььпдотл 2000 Готовое приложение Управление сложностью путем выбора уровня абстракции Систему произвольной сложности можно определить с помощью списка из 25 — 99 функций. Атрибуты функций продукта Чтобы было легче оперировать этой информацией, мы будем рассматривать атРибупьы функций — элементы данных, которые обеспечивают дополнительгг)ю информацию о каждой функции. Атрибуты используются для того, чтобы связать функции или требовюьия с другой информацией проекта.
С помощью атрибгтов можно отслеживать ф)ткции (имя или уникальный идентификатор, состояние, исторические данные, распределен из, трасснруется к и т.д.), задавать их приоритет (поле приоритета), а также управ- Количество функций, которое мы позволяем себе рассматривать, будет существенно влиять на уровень абстракции определения. Для того чтобы справиться со сложностью разрабатываемой системы, мы ртомендуен описываньь валножносьььи каждой новогь аизьнмы или дотинения к улье суьцествующей сислмме хак можно более абстраюлно, чтобы в регул лпьате палуч ить не более 25-99 функций, причен желательно, чтобы их число не превлпколо 50. При этом относительно иеболыпой обьсм информации обеспечивает всестороннюю и полную основу для определения продукта, общения с заказчиками, управления масштабом н проектом.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
