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

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

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

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

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

• Это позволяет людям совместно работать над требованиями и делает этот аспект очень заметным;
• Это позволяет легко поддерживать требования в актуальном состоянии по мере продвижения проекта;
• Вы можете зайти и посмотреть историю в любое время, в случае спора «это не то, что мы договорились»;
• Большинство современных вики имеют приличные возможности форматирования, поэтому они выглядят почти так же хорошо, как 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» - это неправильный путь для удовлетворения требований по следующим причинам:

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

У меня нет альтернативного предложения, с которым у меня есть опыт, но я подумал о реструктурированном тексте 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

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

Удачи!