В теме 7 ответов, и 5 участников, последнее обновление сделано пользователем 
Андрей В. 12 г, 10 мес. назад.
-
Сообщения
-
На данный момент мне известны (спасибо Вигерсу) 3 основных способа нумерации:
1. использование порядкового номера (Т-1, Т-2). Совсем примитивно и неэффективно.
2. использование иерархической нумерации (3.3. Функциональные требования. => 3.3.1 требование 3.3.2 требование)В качестве улучшения добавляются идентификаторы требований (3.3. Функциональные требования. => ФТ-1, ФТ-2)
Но здесь появляется сложность в их "упорядочивании", ведь если в процессе работы находятся новые требования к определенным частям системы, логично было бы прописывать их рядом с похожими требованиями (относящимися к соответствующим частям этой системы). Иначе список требований становится хаотичным, что не есть хорошо.3. иерархические текстовые теги ( например, есть группа требований, связанных с аккаунтом пользователя. одним из требований будет "После изменения пароля Система должна отправлять письмо с уведомлением на email пользователя". Соответственно, данному требованию можно приписать что-то вроде "Аккаунт.Пароль.Изм."
В итоге должны получиться некие логические группы требований, которые не будут зависеть друг от друга в плане нумерации, что позволит совершенно свободно редактировать список требований.
Кто-нибудь использует последний способ? Насколько существенен такой недостаток, как громоздкость, и так ли это эффективно, как кажется?
Мы используем модификацию последней. Обычно док ( я имею ввиду функц. спецификацию)разбит на секции, мы пишем требования для каждой секции отдельно. Чтобы они получали уникальный идентификатор, который будет легко отследить, то для каждого названия секции вводится аббревиатура: e.g. User Account (UA), после этого все требования в этой секции нумеруются FR_UA_001, FR_UA_002 etc.Мы писали сначала полное название, долго, громоздко. И вообще, очень интересно, если кто поделится каким-нибудь хорошим методом для нумерации функц. требований в спецификации.
Этот метод и мне кажется довольно эффективным. Но последняя часть идентификатора (цифры) все же не позволяет свободно перемещать требования в списке, пусть даже и отдельно созданном для какой-то части системы.
Конечно, логично возразить, что это и не нужно, ведь все требования относятся непосредственно к этой части системы. Но, согласитесь, что даже этот список будет выглядеть "неупорядоченным", если требования добавлялись непоследовательно и аналитику (особенно неопытному) приходилось постоянно его дополнять. А если были выделены секции достаточно большие (не "Аккаунт пользователя", а "Пользователи"), то эта хаотичность требований будет еще более заметна.Приведу пример. Спецификация имеет разделы: Пользователи, Посетители, Календарь и т.д. В каждом разделе описаны соответствующие бизнес-правила, требования, варианты использования. Понятно, что функциональные требования раздела "Пользователи" включают не только требования в отношении аккаунта, но и возможностей данных пользователей: управление информацией о посетителях, коммуникацию с другими пользователями и т.д. Все функциональные требования данного раздела содержатся в одном списке. В процессе работы молодой, амбициозный, но еще неопытный аналитик извлекает все новые и новые требования, и список становится похожим на это:
ФТ-ПЗ-1 требование, касающееся аккаунта
ФТ-ПЗ-2 требование, касающееся аккаунта
ФТ-ПЗ-3 требование, касающееся встроенной системы сообщений
ФТ-ПЗ-4 требование, касающееся встроенной системы сообщений
….
ФТ-ПЗ-13 требование, касающееся встроенной системы сообщений
….
ФТ-ПЗ-26 требование, касающееся аккаунта
….Ну и представим, что этот список довольно объемный, занимает несколько страниц. Таким образом ФТ-ПЗ-26 хоть и находится вроде бы в нужном списке, тем не менее его легко пропустить только потому, что большинство требований были извлечены давным давно и зафиксированы одно за одним. А уставший от напряженной работы разработчик, открыв спецификацию и пробежавшись взглядом по списку, визуально для себя выделил группу требований по аккаунтам и не обратил внимание на это злополучное ФТ-ПЗ-26. Велика вероятность того, что с течением времени он это требование заметит, но ведь к этому моменту уже может быть проделана большая работа, и что-то придется переделывать.
Да, можно свести это к невнимательности того, кто читает спецификацию. Да, можно считать, что совесть аналитика чиста, а разработчику не повезло. Но с точки зрения эффективности документа это, на мой взгляд, недоработка.
Естественно, мало кто согласится менять нумерацию требования и в результате изменять все гиперссылки в документе. Поэтому хотелось бы узнать, возможно ли отказаться от нумерации требований (имеется ввиду не отказ от автоматической нумерации списка (1. ФТ-ПЗ-1, 2. ФТ-ПЗ-1, 3. ФТ-ПЗ-1), а отказ от присваивания каждому требованию уникального номера: 1. ФТ-ПЗ-1, 2. ФТ-ПЗ-2 и т.д.)
Возможно ли эффективно использовать именно текстовые теги, не "обремененные" необходимостью быть расположенными в определенном порядке?
Например:
ФТ-УПЗ-АКК.Добавить
ФТ-УПЗ-АКК.Редактировать
ФТ-УПЗ-СООБЩ.Сохранить.
Или же все-таки громоздкость и затратность по времени являются более значимыми факторами по сравнению с увеличением вероятности всех требований быть замеченными вовремя?Возможные варианты:
1) А что если молодому аналитику чуть больше времения потратить перед началом проекта, чтобы продумать чуууть больше деталей сперва и иерархию требований сделать более детальной: не просто ФТ-ПЗ-#, а ФТ-ПЗ-АКК-#, ФТ-ПЗ-СООБЩ-# и т.д.
2) Воспользоваться не вордом, а инструментом, который полу-автоматически генерирует название элементов модели, и которая потом умеет выгружать модель в ворд
3) При ссылке на требования в ворде вставлять не просто текст, а потом гиперссылку, а пользоваться переменными (Fields), тогда проще будет потом изменять по тексту документа изменившееся название требованияМы используем следующий подход:Некоторая функциональность описывается на отдельной страничке (в 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ккаунт и Встроенная система сообщений.2) Воспользоваться не вордом, а инструментом, который полу-автоматически генерирует название элементов модели, и которая потом умеет выгружать модель в ворд
3) При ссылке на требования в ворде вставлять не просто текст, а потом гиперссылку, а пользоваться переменными (Fields), тогда проще будет потом изменять по тексту документа изменившееся название требованияМожно более подробно описать эти варианты?
Мы дробим документ очень сильно, для каждого скрина отдельная секция, описания полей и рулы для полей, гридов, триггеров- это отдельные таблицы, содержащие все описания и валидации. Нотификации –отдельный документ со всеми требованиями (могу показать приблиз. пример, но, думаю, что они похожи у всех). Потому сам список требований у нас небольшой, он был большим только один раз, когда мы делали графический редактор, но большой-это 30 рекордов. Мы добавляем требования с номерами, в том месте, где оно логически принадлежит, например, требования 1-3 описывает пользователей в гриде, какие именно должны появляться, 4-6-как высчитывать для каждого испытательный срок. Если появилось новое требование, относящееся логически к группе пользователи в гриде, то requirement R_MU_007 появится вслед за R_MU_003 (MU for Manage Users). Для нас важно, что все требования уникально идентифицированы и логически размешены в одном месте.По поводу неиспользования цифровых обозначений, помимо громоздкости есть след недостатки
1)есть требования, попадающие в обе области
2) название взято слишком общее, далее вы заметите, что его надо было спец-ть
3) если есть требования обшие и спец-ные, то придется девелоперам объснять, когда что смотреть.
2) девелопер может читать только те требования, кторые относятся к его области ответсвенности, что не может быть хорошоУ меня пока так.
Системные требования, которые делятся на функциональные и нефункциональные.Первое поле «ID» – уникальный номер. Например, СТ-13, СТ-69 и т.д.
Второе поле «Наименование» – название поля с подпунктом 1.1,1.2 и т.д
Третье поле «Важность» — число от 0 до 150. Чем выше число тем важнее требование.Пока так. Если есть какие то минусы в этом решении, то, пожалуйста, озвучьте. У меня пока все в процессе формирования ибо начинающий.
Вы должны авторизироваться для ответа в этой теме.
