Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 87
Текст из файла (страница 87)
4. Е Статус Задается в результате переговоров и рассмотрения руководством проекта. Информация о статусе отражает ход процесса определения базового уровня проекта, Атрибут статуса функции может иметь следующие значения. ° Предложена. Используется для описания обсуждаемых функций, которые еще не рассмотрены и не приняты "официальным органол~" — рабочей группой, состоящей из представителей команды проекта, руководства и пользователей или заказчиков. ° Принята. Возможности, которые "официальный орган" признал полезнымн и достижимыми и принял к реализации. ° Включена.
Функции, включенные в базовый уровень на данный момент времени. 4.2. Приоритет Приоритеты функций продукта задаются представителями маркетинга, менеджером продукта или аналитиком базового уровня. Упорядочение функций по их относительной важности для конечного потребителя открывает диалог между заказчиками. аналитиками и членами команды разработчиков. Приоритеты используются для управления масщтабом и определения очередности разработки. Ниже предложена одна из возможнык скем задания приоритетов.
° Критический. Основные функции. Если их не удастся реализовать, система не будет удовлетворять потребности заказчика. В версии должны быть реализованы все критические функции, в противном случае график является нереальным. ° Важный. Ф)пкции, важные для успещной и эффективной работы системы в болыпипстве приложений. Данные функциональные возможности нельзя легко обеспечить иным способом. Если важные функции не войдут в реализацию, это может повлиять на удовлетворение пользователя или заказчика результатом работы или даже иа доходы от продаж, но выпуск версии не должен задерживаться ижза нехватки некой важной функции.
408 Приложения 4.3. 4.4. 4.5. 4.6. 4.7. ° Полезный. Функции, которые нужны в менее распространенных приди женияк, будут использоваться ие так часто или их можно достаточно эффективно заменить другими действиями. Если они не войдут в реализацию, это не окажет заметного воздействия на отношение заказчика или доходы.
Уровень трудозатрат Определяется командой разработчиков и используется для управления масппабом и определения очередности разработки. Поскольку некоторые функции требуют больше времени и ресурсов, чем другие, оценка количества командс» или человекс»недель, строк кода или функциональных единиц помогает соразмерить сложность и оценить, что можно, а что нельзя осуществить за определенный период времени. Риск Задается командой разработчиков иа основе вероятности того, что данная функция вызовет нежелательные последствия для проекта, такие как превышение средств, отставание от графика или даже закрьггие проект».
Большинство менеджеров про. дукза считают достаточным деление рисков на категории яилсий, фгдний, высокий, хотя возможна и более тонкая градация. Иногда риск можно оценить, измеряя меру неопределенности (шгаиазон) оценок времени работы командьь Стабильность Определяется аналитиком и командой разработчиков, исходя из вероятности того, что может измениться данная функция или понимание командой этой функции. Эта информация используется для того, чтобы помочь при определении приоритетов разработки и выявить те элементы, для которых следующим действием должно стать дополнительное исследование. Целевая версия Записывается. в кзкой версии продукта предполагается впервые реализовать данную функцию. Это поле можно использовать, чтобы поместить функции в базовый уровень конкретной версии. Козюинируя этот атрибут с полем стату са, команда может предлагать, записывать и обсуждать для версии различные функции, не приступая к их разработке.
Будут реализовываться только функции, имеющие статус "Включенная", для которых определена целевая версия. При необходимости сокращения масштаба номер целевой версии может быть увеличен, так что элемент остается в документе-концепции, но его реализация будет отложена на более поздний срок. Кому предназначена Во многих проектах функции будут предназначаться "функциональным группам", ответственным за их дальнейшее исследование, написание прогрззсчных требований, а также, яозможно, реализацию. Это помогает членам команды разработчиков лучше понять свои обязанности. Обоснование Данное текстовое поле используется для отслеживания источника запрашиваемой функции.
В этом поле записывается объяснение причины существования данной функции или ссылка на него. Например, ссылка может указывать иа страницу, номер строки спецификации требований к продукту или времен. ной маркер на видеозаписи важного интервью с клиентам. Приложение Б. Образец документа. концепции 409 б. Функции продукта В данном разделе документируются функции продукта, которые обеспечивают необходимыс возможности для удовлетворения потребностей пользователей. Каждая функция выполняет некую потребность пользователя, Например, функцией системы отслеживания состояния задачи может быть способность "предоставлять отчеты о выполнении".
Отчеты о выполнении, в свою очередь, помогают пользователю "лучше понять состояние задачи". 6. Основные прецеденты Следует описать несколько основных прецедентов, которые важны для архитектуры или лучше всего помогут читателю понять, как предполагается использовать систему. 7. Дру 7.1. гие требования к продукту 11римспясмыс стандарты Перечисляются все стандарты, которым должен соответствовать продукт, та. кпе как законы н инструкции (Р1>Л, ГСС), коммуникационные стандарты (ТСР/11', 151>М), стандарты совместимости платформ (Ъйпдомз, (>Х1Х), а также стандарты качества и безопасности (Ш, 15О, СММ). Систсмныс требования Определяются все снстсмпыс требования, необходимые для поддержки приложения.
Среди шзх могут быть поддерживаемые хостом операционные системы и сетевые платформы, конфнг>рации, память, периферические устройства и сопутствующее программное обеспечение. Лицензирование и инсталляция Вопросы лицензирования и инсталляции также могуг оказывать непосредственное воздействие на трудоемкость разработки. Например, необходимость обеспечения серийного выпуска продукта, поддержки системы безопасности иа основе паролей нли сетевого лицензирования будет создавать дополнительные систсмныс требования, которые следует учитывать при разработке.
Инсталляционные требования но~ус также влиять на кодирование илн вызывать по. требность в отдсльпом инсталляционном программном обеспечении. 7.2. 7.3. Поскольку документ-концепция из>чается широким кругом причастных к проекту лиц и служит основой для достижения соглашения, функции должны описываться на естественном языке пользователя. Описание функции должно быть кратким и ясным, как правило, одно-два предложения. Для аффективного управления сложностью приложения мы рекомендуем, чтобы описание возможностей любой новой системы (или усовершенствования существующей) производилось на достаточно высоком уровне абстракции и состояло из 25-99 функций. Эти функции составляют основу для определения продукта, а также управления масштабом и проектом в целом.
Каждая из них будет описана более подробно в последующих спецификациях, Каждая функция данного раздела должна описывать внешнее поведение системы, которое ощущается пользователямн, операторами или другими внешними системами. 5.1. Функция 1 5.2. Функция 2 410 Приложения 7.4. Требования производительности К вопросам производительности относятся фактор нагрузки, создаваемой пользователем, ширина коммуникационного канала, пропускная способность, точность, надежность нли время ответа при различных условиях загрузки. 8. Требования к документации В данном разделе описывается, какую документацию необходимо разработать для поддержки успешного внедрения приложения. 8.К Руководство пользователя Нужно описать цель и содержание руководства пользователя, рассмотреть его же.
лаемый объем, уровень детализации, потребность в индексе и глоссарии, а также, должно ли оно служить учебным пособием или скорее справочником и т.д. Следует также указать ограничения, связанные с форматированием и печатью. 8.2. Интерактивная подсказка Многие приложения предлагают для помощи пользователю систему интерак.
тивиых подсказок. Подобные системы имеют уникальную природу: они сочв. тают в себе моменты программирования (такие, как создание гиперссылок) с моментами написания технических текстов (такими, как организация и презентация). Многие считают, что разработка системы интерактивных подсказок является проектом внутри проекта, который весьма выиграет от предварительно проведенного ограничения масштаба и планирования действий. 8.3.
Руководства по инсталляции, конфигурация и файл Кеаб Ме Данный документ, содержащий инструкции по инсталляции и руководства по конфигурированию, важен для предложения всеобъемлющего решения, В качестве стандартного компонента обычно включается файл Кеэл Ме. Он может содержать раздел "Что нового в данной версии" и обсуждение совместимости с более ранними версиями. Большинство пользователей также приветствуют наличие в данном файле документации, где указаны все известные недоработки. 8.4. Маркировка и упаковка Современные приложения должны иметь соответствующее внешнее оформление, которое начинается с упаковки продукта и его самообъявления в инсталляционных меню, открывающихся экранах, системах подсказок, СШ-диалогах и т.п. Примерами являются отметки об авторском праве и патентовании, а также логотипы компании, стандартизованные пиктограммы и другие графические элементы и т.д. 9.
Глоссарий Глоссарий описывает все присущие данному проекту термины, в том числе все аббревиатуры, которые могут быль непонятны пользователю или другим читателям данного документа. Приложение В Образец пакета Мооегп ЯКИ Расйа~е Ниже приводится схема пакета Мог)егп Ьо()ваге ко<(в)гсщсп~ Ьрсс)6сайоп (ВКВ), в ко. тором используются как тралициоииыс методы документирования.
так и методы моделироваипя прсцсдеитов. Для круппомасщтабпых систем рскомсцлустся дополпительыая упаковка иа г ровне фуикций (или иа другом подходящем уровпе группировки подсистем). Например, если используется упаковка па уровне функций, спецификация будет содержать все относящиеся к реализации двиной функции требования к программному обеспечению (или ссылки ца иих).