Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 36
Текст из файла (страница 36)
Отделом маркетинга, который выступает в качестве доверенного лица заказчика и пользователя и отвечает эа успех продукта после реализации. 2. Командой проекта, разрабатывающей приложение. 3. Руководством, которое несет ответственность за бизнес-результат попытки. Документ концепция является мощным средством, так как представляет все существенные аспекты продукта с различных точек зрения в краткой, абстрактной, доступной и управляемой форме.
Доауметп.концепция крайне важен на ранних фюах проекта, и все затраты, вложенные в процесс получения информации, принесут щедрые плоды на более поздних стадиях. Поскольку все программные проекты выиграют от наличия документа-концепции, мы собираемся описать его более подробно. Хотя наш пример ориентирован на программный продукт, его достаточно легко модифицировать, чтобы он отражал содержание лю. бого конкретного продукта. На рис. 17.1 представлена краткая схема документа-концепции, которая (с некоторыми настройками) использовалась для сотен программных продуктов и приложений. Полная версия данного документа приводится в приложении Б. 1. Введение В данном разделе предлагается общий обзор документа-концепции.
1.1. Назначение документа.концепции В данном документе фиксируются, анализируются и задаются высоктг уровневые потребности пользователей и функции продукта. 1.2, Краткое опнсанне продукта Формулируется цель приложения, версии и новые предоставляемые функции. 1.3, Ссылки Приводится полный список всех документов, упоминаемых в документеконцепцни.
2.Опнсанже пользователя Кратко представлены общие сведения о пользователях системы. 2.1. Данные о пользователе/рынке Глава 17. Документ концепция 179 целевойклнент [формулнровкапотребностивлв возмолгности] является [категория продукта) [формулировка осповпьпг превму- ществ, т.е. указание причин, по кото. рым продукт будет покупатьсв] [основнью конкурирующие альтерна- тивы] [формулнровкаосноввыхотлычвй] Который [Название продукта) Который В отлычие от Наш продукт 3.3. Характеристика возможностей Перечисляются основные возможности н функции, которые будут пре- доставлены продуктом.
Возможности клиеытов Поддерживающие функции Возможность! Возможность 2 Возможность 3 Функция Функция Функция 3.4. Предположения в завысимости 3.3. Затраты и цепы 4. Атрыбуты функций Описываются атрибуты функций, которые будут использоваться для оценки, отслеживания, задания приоритетов и управления функциями. Некоторые из них перечислены ниже. Ста с П едлагаемый, п инятый, включенный Приоритет Число голосов по результатам накопительного Кратко представлены основные данные о рынке, которые мотивируют решения относительно продукта. 2.2.
Типы пользователей Кратко описываются будущие пользователи системы. 2.3. Среда пользователя 2.4. Основные потребности пользователей Перечисляются основные проблемы или потребности пользователей. 2,3. Альтернативы ы конкуренты Выявляются все приемлемые (с точки зрения пользователя) альтернати- вы.
3. Краткое описаыые продукта 3.1. Общий вид продукта Предлагается блок-схема продукта или системы и ее интерфейсов с внешней средой. 3.2. Определение позиции продукта ва рынке Предлагается обобщенная краткая характеристика (на самом высоком уровне абстракции) уникальной позиции, которую должен занять продукт на рынке. Мур (Мооге) (1991) рекомендует использовать следующую форму. 180 Часть 3. Определение системы голосования или критический, важный, по лезный Низкая, средняя, высокая; командо.недели; человекомесяцы Низкий, средний, высокий Низкая, средняя, высокая Номер версии Фамилия Текстовое поле Трудоемкость Риск Стабильность Целеваяверсия Предназначен для П ичина рис.
1 7.1. Схема дахумеиюгохоииеикии некоего лрограммиоео лродуюиа Ь. Функции продукта В данном разделе перечисляются функции продукта. 3.1. Функция.3Й1 5.2. Функция М2 б. Ключевые прецеденты Описываются основные прецеденты, которые важны с точки зрения ар- хитектуры или наиболее полезны для того, чтобы помочь читателю псг нять, как будет использоваться система. 7. Друтне требования к продукту 7.1. Применяемые стандарты Перечисляютсв все стандарты, которым должен соответствовать продукт. 7.2.
Системные требования Задаются все системные требования, которым должно соответствовать приложение. 7.3. Лицензирование н установка Описываются все инсталляционные требования, которые оказывают влияние на создание программного кода или вызывают потребность в создании отдельного инсталляционного программного обеспечения. 7.4. Требовання к производительности Этот раздел используется для подробного описания требований к произ- водительности. 8.
Требования к документации Описывается, какую документацию необходимо разработать для успею- ного развертывания приложения. 8.1. Руководство пользователя Описывается цель и содержание руководства пользователя. 8.2. Интерактивные подсказки Требования к интерактивным подсказкам, средствам предупреждения и т.п. 8.3. Руководства по инсталляции, конфигурация н файлы "Кеаб Меи 8.4. Маркировка и упаковка 9. Глоссарий Глава 17.
Документ»концепция 181 Итак, документ-концепция кратко описывает все, что вы считастс наиболсс важным для продукта или приложения. Оп представляет собой достаточно подробное описание на естественном языке, поэтому основным участникам проекта легко с ним работать. Документ Эе1еа Омон Разработка документа-концепции и работа с ним, являясь центром приложения действий многих участников (заказчиков, пользователей, представителей руководства проекта и ьтарж" тинга), могут играть заметную роль в успехе (или неудаче) программного проекта. Зачастую к разработке и пересмотру этого документа привлекается даже дирекция компании.
Ведение дс» кумента-концепции является важным профессиональным приемом, который в состоянии значительно повысить общую производительность работы над проектом. к!тобы это было легче осуществить, нужно сделать документ-концепцию как можно более кратким, сжатым и "по существу". При создании перной версии документа это нс так уж сложно, так как практически все пункты в перечне будут новыми для данного проекта или, по крайней мере, должны быль переформулированы с учетом содержатптя данного приложения. Однако неэффективно в последующие версии повторно записывать вошедшие в предыдущие версии функции, а также прочую информацию, которзя нс претерпела изменений (описание пользователей и обслуживаемых рынков).
Для решения данной проблемы мы предлагаем использовать документ изменений конкелуии (Ве(та )йюя твюттлеттг). Однако перед тем, как заняться его разработкой, рассмотрим развитие докумепта-концепции на протяжении жизненного цикла нового проекта. Документ-концепция версии 1.0 Для нового продукта илн приложения необходимо разраоотать и исследовать практически все элементы документа-концепции. Если некий элемент не рассматривается, вы просто удаляете его иэ оглавления документа и ничего не пишете о нем. Обязательными элементами документа-концепции являются следующие (рис. 1712). ° Общая информация и введение ° Сведения о пользователях системы и описание обслуживаемых рынков, функций, которые предполагается реализовать в версии 1.0 ° Прочие требования (регуляторные и требования среды) ° Будущие функции, которые были выявлены, но не вошли в версию 1.0 Общая карвктвристигл Пользователи и рынки Функции версии 1.0 Другив требовании Будущие функции Рттс 17.2.
Документе конвенции версии 1.0 Данный документ служит основой версии 1.0 и разработки более подробных программных требований и прецедентов, которые будут более полно описывать систему. 182 Часть 3. Опредеяеине системы Документ. концепция версии 2.0 По мере развития проекта более четко определяются функции; это означает, что они будут более полно описаны в документе-концепции.
Кроме того, выявляются новые о функции и добавляются в него. Таким образом, документ разрастается, и одновременно возрастает его значение для команды. Приступая к разрабог ке версии 2.0, мы, безусловно, хотели бы сохранить документ, который так хорошо нам служил. В данной ситуации представляется логичным откопать будущие функции, которые включены в документ для версии 1.0, язажзэмчв0 по не Реализованы, и эапланиРовать их длЯ Реализации в веРсии 2.0. ДРУ- гимн словами, мы хотим найти и "раскрутить" некоторые будущие функции, представляющие интерес для версии 2.0.
Можно также запланировать проведение дополнительного совещания, посвященного требованияли или осуществление любого другого процесса выявления требований для обнаружения новых функций. эа. планированных для реализации в версии 2.0, а также тех, которые нужно будет внести в документ в качестве новых будущих функций. Некоторые из этих функций, основанные на обратной реакции закаэчика, уже будут очевидны, другие возникнут как следствие полученного командой опыта. В любом случае эти вновь обнаруженные функции следует записать в документ-концепцию версии 2.0 как запланированные для реализации в версии 2.0 или будущие функции.