Я довольно удивлен, что до сих пор никто не рекомендовал использовать вики для отслеживания требований.
Я обнаружил, что это почти идеальная система, потому что:
- Это позволяет людям совместно работать над требованиями и делает этот аспект очень заметным;
- Это позволяет легко поддерживать требования в актуальном состоянии по мере продвижения проекта;
- Вы можете зайти и посмотреть историю в любое время, в случае спора «это не то, что мы договорились»;
- Большинство современных вики имеют приличные возможности форматирования, поэтому они выглядят почти так же хорошо, как Word doc;
- Вы можете гиперссылку непосредственно из ваших требований в фактическую документацию
- Вам никогда не придется беспокоиться о людях, работающих с разными / устаревшими копиями;
- Требования могут начать рассматриваться как итеративный процесс, как проектирование / реализация;
- Если требования начинают становиться действительно большими / сложными, их легко разделить по страницам / темам.
- Большинство вики принимают HTML, поэтому, если вам действительно нужно расширенное форматирование, вы можете использовать такой инструмент, как Windows Live Writer .
Учитывая выбор, я почти всегда выбираю вики-метод в наши дни, он действительно довольно безболезненный по сравнению со старомодными документами Word или попыткой втиснуть все это в багтрекер.
Я всегда использую IEEE Std 830-1998 (рекомендуемая практика IEEE для требований к программному обеспечению) в качестве шаблона для моего документа SRS. См. Http://standards.ieee.org/reading/ieee/std_public/description/se/830-1998_desc.html.
Конечный документ SRS обычно представляет собой один документ OpenOffice.org, но обычно в него входит много составных частей, включая электронные таблицы и диаграммы.
Я обычно собираю все эти документы в хранилище, которое помещаю в систему контроля версий , такую как SVN или CVS. Все остальные бизнес-аналитики, дизайнеры, разработчики, тестировщики, менеджеры проектов и клиенты имеют доступ к этому хранилищу, поэтому они могут читать его и вносить изменения.
Помните, SRS - это живой, развивающийся документ. Он будет продолжать меняться и расти в течение некоторого времени. Не только важно, чтобы все заинтересованные стороны имели доступ к СГД, но также важно иметь полную историю изменений и возможность откатить эти изменения, если это необходимо. Таким образом, система контроля версий отлично подходит для этой цели. Удачи!
источник
Использование системы отслеживания ошибок для управления требованиями имеет тенденцию скрывать отсутствие сотрудничества и коммуникации внутри компании.
Без вынесения суждения о каком-либо конкретном методе:
(Краткий) опыт одного из моих прошлых работодателей с использованием баг-трекера для требований заключался в том, что он давал многим людям очень простой способ полностью прекратить общение. Люди просто пишут пожелания, помещают его в баг-трекер и предполагают, что оно в конце концов сбудется.
Конечно, они сделали это без учета:
источник
Я считаю, что документы «Word» - это неправильный путь для удовлетворения требований по следующим причинам:
У меня нет альтернативного предложения, с которым у меня есть опыт, но я подумал о реструктурированном тексте Python или Markdown в качестве альтернативы.
источник
Обычно мы используем Word, но на самом деле то, как вы создаете их в программном обеспечении, менее важно, чем то, как вы собираете данные для их создания, и знает ли человек, собирающий информацию, достаточно, чтобы знать, когда требование слишком сложное и будет намного дороже, чем более простое требование, но при этом никому не добавляет никакой реальной ценности (например, когда они хотят, чтобы идентификационные номера всегда назначались в порядке, в котором они никогда не пропускались), или когда это будет конфликтовать с существующим требованием или другой запланированной функцией. Часто с реальными пользователями никогда не общаются, и есть много неожиданностей, когда их менеджеры не знают чего-то, что абсолютно необходимо сделать, и это не относится к новой версии программного обеспечения.
Мы также можем использовать различные файлы PDF, Excel или Visio. Все они для проекта собраны и отредактированы из SharePoint, поэтому мы можем увидеть более ранние версии, если это будет необходимо.
источник
Я веду журнал невыполненных работ (один на проект или продукт), который содержит истории пользователей . Они могут храниться в программном обеспечении для отслеживания ошибок, например, используемом вами. Я лично использую Excel для отставания и Trac для отставки спринта (вы, вероятно, используете такой инструмент).
Только при необходимости я создаю документ Word, который описывает пользовательскую историю с более подробной информацией, и присоединяю ее к пользовательской истории. Но я стараюсь избежать этого, разбивая пользовательскую историю на более мелкие.
Мне нравится документ Word, потому что он позволяет мне размещать ссылки, форматировать тексты, ставить таблицы, снимки экрана и многое другое, и каждый может его прочитать.
Конечно, каждая пользовательская история подробно объясняется в сеансе оценки и планирования спринта, и я всегда готов ответить на дополнительные вопросы, когда разработчик решит поработать над этим. Частые отзывы, использующие спринт-рецензии, не позволяют разработчикам делать что-то не так, как того требует владелец продукта.
источник
Лично, в прошлом я использовал документы Word, но в будущем решил найти инструмент для управления этим для меня ... особенно с возможностью устанавливать ошибки в требованиях, потому что в большинстве случаев ошибка заключается в том, что в требованиях, а не отклонение между спецификациями и реализацией.
Мне даже не приходило в голову использовать инструмент отслеживания ошибок, но это имеет смысл.
Из любопытства, что тебе в этом не нравится?
РЕДАКТИРОВАТЬ: одна оговорка; скажите своему менеджеру, чтобы он обновил программное обеспечение для отслеживания ошибок. В противном случае все в нем считается ошибкой. У меня была эта политическая проблема на моем последнем клиенте, где я помещал задачи в баг-трекер. Не хорошо.
источник
Я написал базу данных требований 6 или 7 лет назад, чтобы справиться с этим. Каждая запись требований имеет краткое описание, памятку «определения» и заметку «заметки» (как форматированный текст, с возможностью вставки снимков экрана и т. Д.). Есть и другие поля: проект, результат, порядковый номер (чтобы их можно было упорядочить логически), вариант использования / особенность, к которой он относится, оценка времени, поле для лица, которое его обрабатывает, если кто-то выбрал его для реализации, и т.п.
Также есть «Статус» - «Введено», пока мы разрабатываем функции; «Утверждено», устанавливается после того, как группа требований рассмотрена и определена как готовая к выполнению; «Реализовано», устанавливается программистом, когда они считают, что требование выполнено, и «Утверждается», когда технический специалист по контролю качества соглашается с программистом. (Если технический специалист по контролю качества не согласен, он может установить для него значение «Утверждено», чтобы программист получил его обратно.) Требования также могут быть «Отложено», «Отклонено» или «Опрошено» (то есть Совет по контролю за изменениями должен рассмотреть это .)
Уловка, чтобы сделать это хорошо, является разумной детализацией. Иногда может иметь смысл иметь требования одного предложения (например, «проблема, описанная в выпуске 12345, исправлена»), но в целом требования должны описывать все важные аспекты целой функции (или большой части одного). Например, типичная функция «новый отчет» будет иметь требование к формату отчета (как выглядит вывод) и требование к диалоговому окну параметров (объяснение полей, проверка и т. Д.). Возможно, даже третья есть сложный генератор, который обрабатывает данные, а не просто запрос или что-то в этом роде. Кроме того, мы создадим требование «Справка» для соответствующего раздела справки.
Есть огромное преимущество хранения этого материала в записях базы данных, а не в большом документе. Несколько программистов могут работать над требованиями одновременно. Отдельные записи заблокированы, поэтому только один человек может редактировать одновременно, но их можно открывать и читать, пока кто-то другой редактирует. Самым большим преимуществом является то, что он обеспечивает легкий поиск документации как требований, так и примечаний о том, как они были реализованы. Сейчас у нас более 25 000 требований, и мы можем легко найти все требования с определенными словами во всех областях, или с определением, или с примечаниями, или с чем угодно, менее чем за 10 секунд. (Попробуйте это с документами Word на 6+ лет.)
Я могу понять, почему люди могут сказать, что плохая идея - выполнять требования в «трекере ошибок», но я думаю, это потому, что инструменты отстой, а не потому, что хранение требований в базе данных с возможностью поиска - плохая идея.
источник
Я использовал один раз http://www.pivotaltracker.com/, но в моей нынешней компании мы используем .doc в качестве основного источника спецификации и Lighthouse в качестве комбинированного списка пожеланий и отслеживания проблем. Мне трудно заставить других людей в команде начать использовать любые другие инструменты, когда они так сильно привыкли к Word.
источник
Если вы можете следовать методологии Agile, следующие ссылки помогут вам выбрать хороший инструмент управления проектами Agile:
А если серьезно, попробуйте методологию Agile - она проповедует простой, элегантный, без излишеств, не джазовый, общий чувственный подход во всем, что вы делаете, так, чтобы каждый член команды понимал и ценил роль и усилия каждого другого члена.
Удачи!
источник