Нумерация требований в документе




Главная   Форумы   Общие вопросы по работе с требованиями   Нумерация требований в документе

В теме 7 ответов, и 5 участников, последнее обновление сделано пользователем Аватар (Андрей В.) Андрей В. 6 г, 3 мес. назад.

Показано 8 ответов - от 1 до 8 (всего 8)
  • Автор
    Сообщения
  • 26.05.2011 в 10:41 # 5296
    На данный момент мне известны (спасибо Вигерсу) 3 основных способа нумерации:
    1. использование порядкового номера (Т-1, Т-2). Совсем примитивно и неэффективно.
    2. использование иерархической нумерации (3.3. Функциональные требования. => 3.3.1 требование 3.3.2 требование)

    В качестве улучшения добавляются идентификаторы требований (3.3. Функциональные требования. => ФТ-1, ФТ-2)
    Но здесь появляется сложность в их "упорядочивании", ведь если в процессе работы находятся новые требования к определенным частям системы, логично было бы прописывать их рядом с похожими требованиями (относящимися к соответствующим частям этой системы). Иначе список требований становится хаотичным, что не есть хорошо.

    3. иерархические текстовые теги ( например, есть группа требований, связанных с аккаунтом пользователя. одним из требований будет "После изменения пароля Система должна отправлять письмо с уведомлением на email пользователя". Соответственно, данному требованию можно приписать что-то вроде "Аккаунт.Пароль.Изм."

    В итоге должны получиться некие логические группы требований, которые не будут зависеть друг от друга в плане нумерации, что позволит совершенно свободно редактировать список требований.

    Кто-нибудь использует последний способ? Насколько существенен такой недостаток, как громоздкость, и так ли это эффективно, как кажется?

    Поделиться:

    Цитировать

    01.06.2011 в 23:07 # 5297
    Аватар (Сара Гиршфельд)
    Сара Гиршфельд
    Подписчик
    Мы используем модификацию последней. Обычно док ( я имею ввиду функц. спецификацию)разбит на секции, мы пишем требования для каждой секции отдельно. Чтобы они получали уникальный идентификатор, который будет легко отследить, то для каждого названия секции вводится аббревиатура: e.g. User Account (UA), после этого все требования в этой секции нумеруются FR_UA_001, FR_UA_002 etc.

    Мы писали сначала полное название, долго, громоздко. И вообще, очень интересно, если кто поделится каким-нибудь хорошим методом для нумерации функц. требований в спецификации.

    Поделиться:

    Цитировать

    02.06.2011 в 00:14 # 5298
    Этот метод и мне кажется довольно эффективным. Но последняя часть идентификатора (цифры) все же не позволяет свободно перемещать требования в списке, пусть даже и отдельно созданном для какой-то части системы.
    Конечно, логично возразить, что это и не нужно, ведь все требования относятся непосредственно к этой части системы. Но, согласитесь, что даже этот список будет выглядеть "неупорядоченным", если требования добавлялись непоследовательно и аналитику (особенно неопытному) приходилось постоянно его дополнять. А если были выделены секции достаточно большие (не "Аккаунт пользователя", а "Пользователи"), то эта хаотичность требований будет еще более заметна.

    Приведу пример. Спецификация имеет разделы: Пользователи, Посетители, Календарь и т.д. В каждом разделе описаны соответствующие бизнес-правила, требования, варианты использования. Понятно, что функциональные требования раздела "Пользователи" включают не только требования в отношении аккаунта, но и возможностей данных пользователей: управление информацией о посетителях, коммуникацию с другими пользователями и т.д. Все функциональные требования данного раздела содержатся в одном списке. В процессе работы молодой, амбициозный, но еще неопытный аналитик извлекает все новые и новые требования, и список становится похожим на это:
    ФТ-ПЗ-1 требование, касающееся аккаунта
    ФТ-ПЗ-2 требование, касающееся аккаунта
    ФТ-ПЗ-3 требование, касающееся встроенной системы сообщений
    ФТ-ПЗ-4 требование, касающееся встроенной системы сообщений
    ….
    ФТ-ПЗ-13 требование, касающееся встроенной системы сообщений
    ….
    ФТ-ПЗ-26 требование, касающееся аккаунта

    ….

    Ну и представим, что этот список довольно объемный, занимает несколько страниц. Таким образом ФТ-ПЗ-26 хоть и находится вроде бы в нужном списке, тем не менее его легко пропустить только потому, что большинство требований были извлечены давным давно и зафиксированы одно за одним. А уставший от напряженной работы разработчик, открыв спецификацию и пробежавшись взглядом по списку, визуально для себя выделил группу требований по аккаунтам и не обратил внимание на это злополучное ФТ-ПЗ-26. Велика вероятность того, что с течением времени он это требование заметит, но ведь к этому моменту уже может быть проделана большая работа, и что-то придется переделывать.

    Да, можно свести это к невнимательности того, кто читает спецификацию. Да, можно считать, что совесть аналитика чиста, а разработчику не повезло. Но с точки зрения эффективности документа это, на мой взгляд, недоработка.

    Естественно, мало кто согласится менять нумерацию требования и в результате изменять все гиперссылки в документе. Поэтому хотелось бы узнать, возможно ли отказаться от нумерации требований (имеется ввиду не отказ от автоматической нумерации списка (1. ФТ-ПЗ-1, 2. ФТ-ПЗ-1, 3. ФТ-ПЗ-1), а отказ от присваивания каждому требованию уникального номера: 1. ФТ-ПЗ-1, 2. ФТ-ПЗ-2 и т.д.)

    Возможно ли эффективно использовать именно текстовые теги, не "обремененные" необходимостью быть расположенными в определенном порядке?
    Например:
    ФТ-УПЗ-АКК.Добавить
    ФТ-УПЗ-АКК.Редактировать
    ФТ-УПЗ-СООБЩ.Сохранить.

    Или же все-таки громоздкость и затратность по времени являются более значимыми факторами по сравнению с увеличением вероятности всех требований быть замеченными вовремя?

    Поделиться:

    Цитировать

    02.06.2011 в 06:20 # 5299
    Возможные варианты:
    1) А что если молодому аналитику чуть больше времения потратить перед началом проекта, чтобы продумать чуууть больше деталей сперва и иерархию требований сделать более детальной: не просто ФТ-ПЗ-#, а ФТ-ПЗ-АКК-#, ФТ-ПЗ-СООБЩ-# и т.д.
    2) Воспользоваться не вордом, а инструментом, который полу-автоматически генерирует название элементов модели, и которая потом умеет выгружать модель в ворд
    3) При ссылке на требования в ворде вставлять не просто текст, а потом гиперссылку, а пользоваться переменными (Fields), тогда проще будет потом изменять по тексту документа изменившееся название требования
    Поделиться:

    Цитировать

    02.06.2011 в 08:51 # 5300
    Аватар (tilya)
    tilya
    Подписчик
    Мы используем следующий подход:

    Некоторая функциональность описывается на отдельной страничке (в wiki). Эта страничка имеет название и номер. Странички у нас организованы в виде дерева, уровень дерева отражается в номере странички (например, страничка 3-го уровня может иметь номер 01-01-01). Требования на страничке имеют номер странички и букву латинского алфавита (например, 01-01-01-A). Если новые требования — это целый кусок функционала, то это будет новая страничка (например, дочка с номером 01-01-01-01), а если это просто новое требование, касающееся этой страницы, то будет новая буква на странице (например, 01-01-01-B). Подробнее можно посмотреть здесь viewtopic.php?f=8&t=1441&start=15

    Самое интересное, что мы никогда еще не достигали буквы Z на страничке :). Поэтому я думаю надо просто дробить требования на разделы и подразделы. Тогда в примере с амбициозным аналитиком требований бы просто входили в два разных подраздела: Aккаунт и Встроенная система сообщений.

    Поделиться:

    Цитировать

    02.06.2011 в 17:47 # 5301

    2) Воспользоваться не вордом, а инструментом, который полу-автоматически генерирует название элементов модели, и которая потом умеет выгружать модель в ворд
    3) При ссылке на требования в ворде вставлять не просто текст, а потом гиперссылку, а пользоваться переменными (Fields), тогда проще будет потом изменять по тексту документа изменившееся название требования

    Можно более подробно описать эти варианты?

    Поделиться:

    Цитировать

    02.06.2011 в 18:10 # 5302
    Аватар (Сара Гиршфельд)
    Сара Гиршфельд
    Подписчик
    Мы дробим документ очень сильно, для каждого скрина отдельная секция, описания полей и рулы для полей, гридов, триггеров- это отдельные таблицы, содержащие все описания и валидации. Нотификации –отдельный документ со всеми требованиями (могу показать приблиз. пример, но, думаю, что они похожи у всех). Потому сам список требований у нас небольшой, он был большим только один раз, когда мы делали графический редактор, но большой-это 30 рекордов. Мы добавляем требования с номерами, в том месте, где оно логически принадлежит, например, требования 1-3 описывает пользователей в гриде, какие именно должны появляться, 4-6-как высчитывать для каждого испытательный срок. Если появилось новое требование, относящееся логически к группе пользователи в гриде, то requirement R_MU_007 появится вслед за R_MU_003 (MU for Manage Users). Для нас важно, что все требования уникально идентифицированы и логически размешены в одном месте.

    По поводу неиспользования цифровых обозначений, помимо громоздкости есть след недостатки
    1)есть требования, попадающие в обе области
    2) название взято слишком общее, далее вы заметите, что его надо было спец-ть
    3) если есть требования обшие и спец-ные, то придется девелоперам объснять, когда что смотреть.
    2) девелопер может читать только те требования, кторые относятся к его области ответсвенности, что не может быть хорошо

    Поделиться:

    Цитировать

    10.06.2011 в 16:21 # 5303
    Аватар (Андрей В.)
    Андрей В.
    Подписчик
    У меня пока так.
    Системные требования, которые делятся на функциональные и нефункциональные.

    Первое поле «ID» – уникальный номер. Например, СТ-13, СТ-69 и т.д.
    Второе поле «Наименование» – название поля с подпунктом 1.1,1.2 и т.д
    Третье поле «Важность» — число от 0 до 150. Чем выше число тем важнее требование.

    Пока так. Если есть какие то минусы в этом решении, то, пожалуйста, озвучьте. У меня пока все в процессе формирования ибо начинающий.

    Поделиться:

    Цитировать

Показано 8 ответов - от 1 до 8 (всего 8)

Вы должны авторизироваться для ответа в этой теме.