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

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/9371

Вопрос

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

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

Это было полезно?

Решение

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

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

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

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

Другие советы

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

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

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

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

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

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

  • их собственная квалификация
  • их доля в проекте
  • конфликты с другими требованиями
  • Пробелы в требованиях
  • расходы
  • любые технические соображения
  • и т.п.

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

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

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

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

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

Я поддерживаю отставание продукта (по одному на проект или продукт), который содержит Пользовательские истории. Анкет Их можно хранить в программном обеспечении для отслеживания ошибок, подобного тому, которое вы используете. Я использую персонажи Превзойти для отставания и Трака Для отставания спринта (вы, вероятно, используете инструмент, подобный этому инструменту).

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

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

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

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

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

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

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

Редактировать: одно предостережение; Скажите своему менеджеру ребрендинг программного обеспечения для отслеживания ошибок. В противном случае все в нем считается ошибкой. У меня была эта политическая проблема у моего последнего клиента, где я поместил задачи в трекер ошибок. Нехорошо.

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

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

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

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

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

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

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

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

Удачи!

Лицензировано под: CC-BY-SA с атрибуция
scroll top