Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 22
Текст из файла (страница 22)
С помощью 25 — 99 функций, удобным образом разбитых на категории и упорядоченных, мы сможем описывать и оосуждать самые разнообразныс систсльы, будь то космический корабль многоразового использования или программное средство (ььаприльер, автоматическое обнаружение неисправностей). В части 5 эти функции будут преобразованы в детальные требования, достаточно конкретные, чтобы их можно было реализовать. Мы будем называть их лфебованиями к программьюму обетнчению, или ьфо г)юммььымьь т(мбоваььььяиьь (гоуйваге геь)иьгенмььгг), в отличие от высокоуровневых функций.
1.1еобходимость в дополнительной конкретизации возникнет позднее. На данном этапе нам достаточно рассуждать на уровне функций. После того как возможные функции перечислены, можно приступить к принятию решений вида "отложить до следующей версии, "реализовать немедленно", "полностью огвергнугь" или "исследовать дополнительно". Этот процесс коРРекгььн)ловки масштаба лучше проводить на уровне функций, а не на уровне требований, иначе можно просто )чьязььуть в деталях. Мы рассмотрим проблему маспьтаба более подробно в части 4, "Управление масштабом".
Глава 8. Функции продукта или системы 109 Таблица 8.2. Атрибуты функций Атрибут Описание Отслеживает ход процесса определения базового уровня проекта и последующей разработки. Призм(с функция может иметь статус предлагаемая, утвсржденцая, вклюЧенная Функции не одинаковы по своей важности. Определение относи. тельных приоритетов нли полезности дла конечного пользователя открывает путь к диалогу между заинтересованнымп лицами н членами команды разработчиков. Этот атрнб)т используется нрн управлении масяпабом н определении очередности. ууримсуз определение функции как критической, важной, полезной Оценка количества командо- или человеко-недель, строк кода нлн общего уровня трудоемкости помогает определить, что можно, а что нсльза осуществить за определенный период времени. Пршм(с низкий, средний нлн высокий уровень трудоемкости Вероятность того, что данная функция вызовет нежслателызые последствия, такие мзк увеличение расходов, отставание от графика илн даже закрытие проекта.
Прела)г. высокий, средний н низкий уровень риска Вероятность того, что будет меняться данная функция нлн ес понимание командой. Исполыуется для того, чтобы помочь при определении приоритетов разработки н выявлении тех заеме~нов, дла которых следующим действием должно стать дополнительное исследование Указание версии продукта, в которой впервые появится реализация данной функции. Комбинирование зтого атрибута с полем статуса даст команде возможность предлагать, записывать и обсуждать различные функции, пс принимая их к разработке Во многих проектах фу пиши будут предназначаться "ф)нмшоналы~ым командам", отаетственныл» за дальнейш)зо нх доработку, нщшсанне п)югрзммньпс требований, а также, возможно, нх реалиюцню Используется для отслеживания источника запрашиваемой функ.
цни. Например, ссылка может указывать на страницу нлн номер строки спсцифнюиши продукта нлн временной маркер пз вндсоза. пнси важного интервью с клиентом. Статус Приоритет/Полезность Трудоемкость Риск Стабильность Целевая версия Назначение Обоснование Итак, давайте перейдем к некоторым профессиональным приемам, которые помогут нам получить необходимую информацию. Начнем с интервьюирования (глава 9). лять (статус) функциями, предложенными для реализации.
Например, атрибут ггуиифи. жет люжно использовать для хранения результатов накопительного голосования во время "мозгового штурма"; атрибут номеуз аерснн — для фиксации конкретной версии про. грачмпого обеспечения, в которой предполагается реализовать данную функцию. Присваивая функциям различные атрибуты, можно более успешно управлять сложностью информации. Хотя атрибуты могут быть самыми разнообразными, опыт свидетельствует, что существуют некие общеупотребительные атрибуты, которые применяются в большинстве проектов (табл.
8.2). Далее в данной книге мы будем использовать эти атрибуты при работе с функциями и требованиями, а также отношениями между различными типами системных требований. Глава 9 Интервьюирование 'М;,'~',~~' '„!'4,! * очФ~скзднсщв,"з)осйросы йомэогбюст:цослучить свободнйе от предуашп)ьзелзребпвания можно искать путем объяснения решений; 1 йщюторьш'общих потребностшс положит начало "архиву требо-, фФ))фд(р";"'агугорь)йбудет испольэоватьсл прй дальнейшей разработке проекта. уВ,~4~зззщуйзроноавие не мржет'замейнть интервьюирование: ' Одним из наиболее важных и понятных методов получения требований является инямрвью с клиеняюн; это метод, который можно использовать практически в любой ситуации. В данной главе описывается процесс интервьюирования н предлагается общая схема проведения интервью с пользователем или заказчиком.
Однако данный процесс не так прост, как может показаться на первый взгляд, в нем мы оказываемся лицом к лицу с синдромом "пользователя и разработчика". Кроме того, одна из основных задач интервьюирования — сделать все возможное, чтобы предубеждения н предпочтения интервьюируемых не повлияли на свободный обмен информацией. Это сложная проблема. Социология (еще один предмет, который мы в свое время пропустили!) учит нас, что нееозчож во воспринимать окружающий мир, не фильтруя его в соответствии со своим происхождением и накопленным опытом.
Поскольку решать проблемы — наша профессия, мы редко оказываемся в ситуации, когда у нас иет идей по поводу того, какой тип решений будет соответствовать конкретной проблеме. Действительно, в большинстве случаев мы работаем в некой определенной предметной области или среде, где определенные элементы решения очевидны или.
по крайней мере, кажутся таковыми. ("Мы решили подобную про. блему ранее и полностью уверены, что наш опыт будет применим и в этом случае.") Конечно, это неплохо, так как наши представления являются частью того, за что нам платят. Но мы не должны позволить, чтобы они оказывали влияние на понимание реальной проблемы, которую следует решить. 112 Часть 2. Понимание потребностей пользователей Контекст интервью Контекстно-свободные вопросы Контекстпосвободные вопросы помогают достичь понимания реальной проблемы, не оказывая влияния на ответы пользователя. Как же избежать предубеждения пользователя при ответах на наши вопросы? Для этого необходимо задавать вопросы о природе проблемы пользователя, никак ие связывая их с возможным решением. Для решения данной проблемы Гаус (Самке) и Вайнберг (Юе(пбегб) (1989) ввели понятие конямксюносвободнмй вопрос.
Рассмотрим примеры таких вопросов. ° Кто является пользователем? ° Кто является клиентом? ° Отличаются лн их потребности? ° Где еще можно найти решение данной проблемы? Эти вопросы заставляют иас выслушать заказчика, прежде чем пьпаться предложить или описать потенциальное решение. Это позволяет нам лучше понять проблему заказчика и все проблемы, стоящие за ней. Такие проблемы влияют на мотивацию или поведение заказчика, и их необходимо учесть, прежде чем мы сможем предложить успешное решение.
Контекстно-свободные вопросы аналогичны вопросам, которые учатся задавать продавцы, когда осваивают метод, получивший называние "продажа решений". Используя этот метод, продавец задает ряд вопросов, чтобы получить реальное представление о проблеме клиента, а также о том, какие решения, если такие существуют, предлагает сам клиент. Это позволит ему предложить успешные решения и сравнить их достоинства. Данный процесс иллюстрирует вклад продавца в предложение исчерпывающего решения проблемы, стоящей перед клиентом. Добавление контекста После того как заданы контекстно.
свободные вопросы, можно исследовать предложенные решения. После ответов на контекстно свободные вопросы, чтобы найти еще не обнаруженные требования, полезно "сместить" вопросы в область исследования решений. Как правило, от нас требуется пе только понять проблему, но и предложить подходящие решения. Обсуждение предлагаемых решений поможет пользователю углубить или даже изменить взгляд на проблему. И конечно, наши пользователи зависят от того, владеем ли мы предметоч; в противном случае они должны научить нас всему, что они знают о нем. Чтобы полючь команде разработчиков овладеть данным приемом, мы объединили вопросы в "обобщенное практически контекстно свободное интервью".
Это структуриро. ванное интервью можно испольэовать при выявлении требований пользователей или заинтересованных лиц практически для любых программнык приложений. Образец интервью представлен на рис. 9.1. В нем содержатся как контекстно.свободные, так и не. Глава 9. Интервьюирование ) 13 контекстно-свободные вопросы. Кроме того, в интервью предлагаются вопросы, предназначенные для исследования таких аспектов требований, как надежность, возможность сопровождения и т.д. Часть 1. Определение профиля закаэчика нля пользователя Имя: Компания: Отрасль: Должность: (Выше приведенная информация, как правило, может быть внесена заранее.) Каковы ваши основные обязанности? Что вы в основном производите? Для кого? Как измеряется успех вашей деятельности? Какие проблемы влияют на успеглность вашей деятельности? Какие тенденции, если такие существуют, делают вашу работу проще или сложнее? Часть 11.
Оценка проблемы Для каких проблем (прикладного типа) вы ощущаете нехватку хороших решений? Назовите их. (Замечание. Не зябывайьи сярамивашес "А пяег.) Для каждой проблемы выясняйте следующее. ° Почему существует эта проблема? ° Как она решается в настоящее время? ° Как заказчик (пользователь) хотел бы ее решать? Часть 111. Понимание пользовательской среды Ктотакие пользователи? Какое у них образование? Каковы их навыки в компьютерной области? Имеют ли пользователи опыт работы с данныл» типом приложений? Какая платформа используется? Каковы ваши планы относительно будущих платформ? Используются ли дополнительные приложения, которые имеют отновгение к данному приложению? Если да, то пусть о них немного рассказсут. Каковы ожидания заказчика относительно практичности продукта? Сколько времени необходимо для обучения? В каком виде должна быть представлена справочная информация для пользователя (в интерактивном или в виде печатной копии)? Часть1У.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
