Как правильно создать документы с требованиями?

24

Прямо сейчас мой руководитель создает документацию / спецификации требований для меня, используя программное обеспечение для отслеживания ошибок. Это кажется мне ужасной идеей, все требования предъявляются к этим маленьким билетам, и мне нужно щелкнуть эту тупую веб-форму, чтобы получить требования. Что такое нормальное программное решение для требований / спецификаций программного обеспечения?

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

Патрик
источник

Ответы:

18

Я довольно удивлен, что до сих пор никто не рекомендовал использовать вики для отслеживания требований.

Я обнаружил, что это почти идеальная система, потому что:

  • Это позволяет людям совместно работать над требованиями и делает этот аспект очень заметным;
  • Это позволяет легко поддерживать требования в актуальном состоянии по мере продвижения проекта;
  • Вы можете зайти и посмотреть историю в любое время, в случае спора «это не то, что мы договорились»;
  • Большинство современных вики имеют приличные возможности форматирования, поэтому они выглядят почти так же хорошо, как Word doc;
  • Вы можете гиперссылку непосредственно из ваших требований в фактическую документацию
  • Вам никогда не придется беспокоиться о людях, работающих с разными / устаревшими копиями;
  • Требования могут начать рассматриваться как итеративный процесс, как проектирование / реализация;
  • Если требования начинают становиться действительно большими / сложными, их легко разделить по страницам / темам.
  • Большинство вики принимают HTML, поэтому, если вам действительно нужно расширенное форматирование, вы можете использовать такой инструмент, как Windows Live Writer .

Учитывая выбор, я почти всегда выбираю вики-метод в наши дни, он действительно довольно безболезненный по сравнению со старомодными документами Word или попыткой втиснуть все это в багтрекер.

Aaronaught
источник
Я обнаружил, что вы можете относительно легко встраивать данные из вашей системы отслеживания в вашу вики, и если вы настраиваете некоторые иерархические ошибки, вы можете сгруппировать их в требования, тогда вехи проекта имеют вики-страницы, как и проекты, и клиенты, и все легко понять. Вики - это клей, но все еще используется багтрекер. Изучите способность вашего трекера ошибок указывать на веб-страницу в вики!
Тим Уиллискрофт
Безусловно, вики не является заменой системы отслеживания ошибок, это дополняет. Планирование проекта и сотрудничество лучше всего делать в вики; проблемы по-прежнему необходимо отслеживать в IMS или очереди приоритетов.
Aaronaught
6

Я всегда использую 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 - это живой, развивающийся документ. Он будет продолжать меняться и расти в течение некоторого времени. Не только важно, чтобы все заинтересованные стороны имели доступ к СГД, но также важно иметь полную историю изменений и возможность откатить эти изменения, если это необходимо. Таким образом, система контроля версий отлично подходит для этой цели. Удачи!

Другой
источник
5

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

Без вынесения суждения о каком-либо конкретном методе:

  • если вы собираетесь использовать водопад, вам нужны хорошо структурированные, точные, многостраничные документы (а не один абзац, который многие люди обычно вводят в качестве описания ошибки). Эти документы также невозможно написать и поддерживать на должном уровне качества, если маркетологи / продавцы (которые создают требования) не работают вместе с инженерным персоналом.
  • если вы собираетесь использовать один из гибких методов, то одна единица требований - это пользовательская история, представленная карточкой истории. Сама карта не является обязательным требованием, а лишь отправной точкой разговора.

(Краткий) опыт одного из моих прошлых работодателей с использованием баг-трекера для требований заключался в том, что он давал многим людям очень простой способ полностью прекратить общение. Люди просто пишут пожелания, помещают его в баг-трекер и предполагают, что оно в конце концов сбудется.

Конечно, они сделали это без учета:

  • их собственные квалификации
  • их доля в проекте
  • противоречит другим требованиям
  • пробелы в требованиях
  • расходы
  • любые технические соображения
  • и т.п.
azheglov
источник
НО ... как только будет введено неполное требование, оно будет назначено, и кому бы он ни был нужен, чтобы разрешить любую неполную информацию, не так ли? Я имею в виду, как только он в системе, предполагая, что люди не сбрасывают предметы, разве это не должно быть решено? Я не предполагаю, что полный специалист по программному обеспечению должен вводить элементы, но даже если они это сделали ... это в системе и должно обрабатываться. Пример: бизнес добавляет требование «распечатать квитанцию» в трекер ошибок и назначает его аналитику шины, аналитик шины обрабатывает его, заполняя отверстия (посредством большего количества сообщений, если необходимо), затем dev получает его.
Джон Макинтайр
Не будет ли какое-либо нарушение связи признаком проблемы процесса? (подразумевается искренность)
Джон Макинтайр
@JohnMacIntyre (1): результат - пинг-понг, а не сотрудничество. Правопреемник не всегда правильный человек, редкие вопросы могут быть решены только одним человеком; там, где требуется больше людей, цессионарий редко имеет полномочия указывать им, что делать, редко видит все зависимости (требования редко бывают независимыми); потеряны преимущества самоорганизации, расстановки приоритетов по ROI или затратам на задержку и т. д.
ажеглов
@JohnMacIntyre (2): нарушение связи - это, конечно, признак того, что их процесс не работает или что у них нет никакого процесса или что у них просто нет здоровой культуры общения и совместной работы в их компании. Моя позиция заключается в том, что они должны устранить эти коренные причины.
ажеглов
@asheglov - Я полагаю, что это может быть проблемой, если цессионарий является исполнителем и ему не разрешено переназначать или разговаривать с кем-либо. Но моя позиция заключается в том, что это не инструмент, и что это случится с лучшими инструментами, не так ли?
Джон Макинтайр
2

Я считаю, что документы «Word» - это неправильный путь для удовлетворения требований по следующим причинам:

  1. Нет возможности «разнести» два документа, чтобы увидеть, что изменилось.
  2. Пользовательский интерфейс не поощряет использование последовательного стиля повсюду. Да, использование стилей может быть сделано, но большинство людей не могут быть обеспокоены из-за сложности.
  3. Формат документа по сути скрыт. Конечно, есть спецификация для OLE-файлов, которая, как я полагаю, есть в документах Word, но Microsoft похоронила все полезное под кучей болтовни, поэтому никто не знает об этом. Рано или поздно ваше новое «Слово» не откроет документ.
  4. Не подходит для других форматов. То есть, если вы не используете Windows и IE, вам не повезет, если кто-то организует документы проекта в файлы HTML со ссылками на файлы формата «Word». Нажмите на неправильную ссылку, и вам придется пройти долгий период загрузки и запуска Word, прерывая поток мыслей. Гиперссылки из документов Word на другие могут работать, а могут и не работать.
  5. «Слово» в основном для написания документов, предназначенных для печати на бумаге. Замечательная цель, но она делает ее менее чем полезной для онлайн-просмотра.

У меня нет альтернативного предложения, с которым у меня есть опыт, но я подумал о реструктурированном тексте Python или Markdown в качестве альтернативы.

Брюс Эдигер
источник
1
Я думаю, что большинство этих аргументов звучат как FUD. Word, возможно, не лучший выбор, но он не так уж и плох: 1. Он имеет довольно приятные функции редактирования и совместной работы для отслеживания и принятия / отклонения изменений, что намного удобнее для пользователя, чем любые инструменты vcs + diff. 2. Стили стали более заметными с ленточного интерфейса 2007 года. Объяснить, почему следует использовать стили, вероятно, проще, чем объяснить совершенно новое программное обеспечение 3. Последняя версия Word может читать / сохранять файлы Word 97, созданные 16 лет назад. Word 2003 может читать / сохранять файлы 2010 с помощью пакетов совместимости. Я согласен с 4. и 5. хотя pdf может быть вариантом для просмотра онлайн.
Kapex 29.12.12
@kapep - мои аргументы не FUD в классическом смысле «Страх, Неопределенность и Сомнение», возможно, вы используете «FUD» по-другому. На каждый из моих аргументов можно ответить. Например, вы можете сказать «Do control-shift- @» в меню «Вставка», чтобы получить построчную разность текущего документа с другим документом ». Это невозможно сделать, потому что все, что вы предлагали, было встречным мнением. У Microsoft есть история отказа от форматов документов или, по крайней мере, из-за того, что использование старых форматов делает их дорогостоящими или сложными, что, по-моему, увеличивает продажи обновлений.
Брюс Эдигер
Хорошо, я должен исправить меня, только 3. кажется аргументом FUD, который часто используется, когда дело доходит до избиения слова / документа за его частную собственность. Конечно, Microsoft отказался от форматов - но файлы документов существовали очень давно, поэтому «рано или поздно» применимо только к архаичным версиям прошлого века, если они решат отказаться от поддержки в> 2016 году или когда будет выпущено следующее слово. Я также просто хотел отметить, что существует простой способ «разглядеть» документы. Конечно, это не сравнивает построчно, что не имеет особого смысла в формате, не основанном на строках. Это больше похоже на встроенный diff здесь на SE.
kapex
2

Обычно мы используем Word, но на самом деле то, как вы создаете их в программном обеспечении, менее важно, чем то, как вы собираете данные для их создания, и знает ли человек, собирающий информацию, достаточно, чтобы знать, когда требование слишком сложное и будет намного дороже, чем более простое требование, но при этом никому не добавляет никакой реальной ценности (например, когда они хотят, чтобы идентификационные номера всегда назначались в порядке, в котором они никогда не пропускались), или когда это будет конфликтовать с существующим требованием или другой запланированной функцией. Часто с реальными пользователями никогда не общаются, и есть много неожиданностей, когда их менеджеры не знают чего-то, что абсолютно необходимо сделать, и это не относится к новой версии программного обеспечения.

Мы также можем использовать различные файлы PDF, Excel или Visio. Все они для проекта собраны и отредактированы из SharePoint, поэтому мы можем увидеть более ранние версии, если это будет необходимо.

HLGEM
источник
1

Я веду журнал невыполненных работ (один на проект или продукт), который содержит истории пользователей . Они могут храниться в программном обеспечении для отслеживания ошибок, например, используемом вами. Я лично использую Excel для отставания и Trac для отставки спринта (вы, вероятно, используете такой инструмент).

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

Небольшие пользовательские истории проще в управлении (включая оценку)

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

Конечно, каждая пользовательская история подробно объясняется в сеансе оценки и планирования спринта, и я всегда готов ответить на дополнительные вопросы, когда разработчик решит поработать над этим. Частые отзывы, использующие спринт-рецензии, не позволяют разработчикам делать что-то не так, как того требует владелец продукта.


источник
1

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

Мне даже не приходило в голову использовать инструмент отслеживания ошибок, но это имеет смысл.

Из любопытства, что тебе в этом не нравится?

РЕДАКТИРОВАТЬ: одна оговорка; скажите своему менеджеру, чтобы он обновил программное обеспечение для отслеживания ошибок. В противном случае все в нем считается ошибкой. У меня была эта политическая проблема на моем последнем клиенте, где я помещал задачи в баг-трекер. Не хорошо.

Джон Макинтайр
источник
1

Я написал базу данных требований 6 или 7 лет назад, чтобы справиться с этим. Каждая запись требований имеет краткое описание, памятку «определения» и заметку «заметки» (как форматированный текст, с возможностью вставки снимков экрана и т. Д.). Есть и другие поля: проект, результат, порядковый номер (чтобы их можно было упорядочить логически), вариант использования / особенность, к которой он относится, оценка времени, поле для лица, которое его обрабатывает, если кто-то выбрал его для реализации, и т.п.

Также есть «Статус» - «Введено», пока мы разрабатываем функции; «Утверждено», устанавливается после того, как группа требований рассмотрена и определена как готовая к выполнению; «Реализовано», устанавливается программистом, когда они считают, что требование выполнено, и «Утверждается», когда технический специалист по контролю качества соглашается с программистом. (Если технический специалист по контролю качества не согласен, он может установить для него значение «Утверждено», чтобы программист получил его обратно.) Требования также могут быть «Отложено», «Отклонено» или «Опрошено» (то есть Совет по контролю за изменениями должен рассмотреть это .)

Уловка, чтобы сделать это хорошо, является разумной детализацией. Иногда может иметь смысл иметь требования одного предложения (например, «проблема, описанная в выпуске 12345, исправлена»), но в целом требования должны описывать все важные аспекты целой функции (или большой части одного). Например, типичная функция «новый отчет» будет иметь требование к формату отчета (как выглядит вывод) и требование к диалоговому окну параметров (объяснение полей, проверка и т. Д.). Возможно, даже третья есть сложный генератор, который обрабатывает данные, а не просто запрос или что-то в этом роде. Кроме того, мы создадим требование «Справка» для соответствующего раздела справки.

Есть огромное преимущество хранения этого материала в записях базы данных, а не в большом документе. Несколько программистов могут работать над требованиями одновременно. Отдельные записи заблокированы, поэтому только один человек может редактировать одновременно, но их можно открывать и читать, пока кто-то другой редактирует. Самым большим преимуществом является то, что он обеспечивает легкий поиск документации как требований, так и примечаний о том, как они были реализованы. Сейчас у нас более 25 000 требований, и мы можем легко найти все требования с определенными словами во всех областях, или с определением, или с примечаниями, или с чем угодно, менее чем за 10 секунд. (Попробуйте это с документами Word на 6+ лет.)

Я могу понять, почему люди могут сказать, что плохая идея - выполнять требования в «трекере ошибок», но я думаю, это потому, что инструменты отстой, а не потому, что хранение требований в базе данных с возможностью поиска - плохая идея.

SESummers
источник
1
Доступно коммерческое программное обеспечение для отслеживания требований, такое как DOORS.
М. Дадли
1

Я использовал один раз http://www.pivotaltracker.com/, но в моей нынешней компании мы используем .doc в качестве основного источника спецификации и Lighthouse в качестве комбинированного списка пожеланий и отслеживания проблем. Мне трудно заставить других людей в команде начать использовать любые другие инструменты, когда они так сильно привыкли к Word.

Юлия К Сзопа
источник
0

Если вы можете следовать методологии Agile, следующие ссылки помогут вам выбрать хороший инструмент управления проектами Agile:

А если серьезно, попробуйте методологию Agile - она ​​проповедует простой, элегантный, без излишеств, не джазовый, общий чувственный подход во всем, что вы делаете, так, чтобы каждый член команды понимал и ценил роль и усилия каждого другого члена.

Удачи!

karthiks
источник