Примеры документов требований

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

Любые шаблоны/примеры будут замечательными.

Ответ 1

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

Шаблон отчета

Резюме:

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

Введение:

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

Фон:

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

Область и цель:

Описывает объем и цель предлагаемого продукта.

Методы и инструменты:

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

Ограничения, вопросы и проблемы:

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

Результаты:

Обозначает результаты; перечислить все определенные требования достаточно подробно для четкого понимания. Графы, диаграммы и статистические данные следует использовать везде, где это необходимо.

Рекомендации:

Представляет рекомендации для достижения Области и Цели на основе результатов с учетом ограничений, вопросов и проблем.

Ссылки:

Список источников, просмотренных или просмотренных во время анализа.

Приложения:

Дополнительные материалы для разъяснений, расширений и информационных целей.


Подробнее справочный материал в этом ответе.

Ответ 2

Это несколько глубокий вопрос, поэтому я не решаюсь дать короткий ответ. Хорошая идея - прочитать несколько хороших книг, описывающих различные подходы, такие как Заключенные забегают в убежище, в котором описывается функция на основе сценариев дизайн. Другой подход заключается в использовании высокоуровневых прецедентов, как описано в Написание эффективных случаев использования.

Некоторые рекомендации:

  • Напишите, что требуется, не ограничивая, как это будет сделано.
  • Сделайте для каждого требования отдельную нумерованную запись списка для перекрестной ссылки.
  • Разделить требования на отдельные элементы, пока каждый не станет "атомарным".
  • Включите раздел "Безопасность" и укажите, какая защита необходима.
  • Включите раздел "Нефункциональные требования" для ограничений, таких как производительность и доступность.
  • Включите раздел "Без требований", чтобы перечислять вещи, которые не являются требованиями, поэтому вы можете рассказать о различии между тем, что вы забыли, и тем, что вам не нужно.
  • Укажите внешние интерфейсы (для других систем), а также требования к пользовательскому интерфейсу.

Ответ 3

Информация, которую я нахожу важной при понимании требований к программной системе или компоненту, включает:

  • Контекст системы программного обеспечения.
    • Границы системы. Какова объем программного обеспечения, описанного в этих требованиях, в контексте более крупной системы? Что такое системы, с которыми это программное обеспечение должно взаимодействовать или обмениваться данными?
    • Функции верхнего уровня. Краткое резюме того, что система делает или должна достичь. Учитывая набор более подробных требований, какова цель этого набора функций и атрибутов?
    • Интерфейсы. Если пользователи взаимодействуют с этим программным обеспечением, как они это делают? Запускают ли они из командной строки аргументы? Есть ли текстовый интерфейс? Графический интерфейс? Как он взаимодействует с другими аппаратными средствами и программным обеспечением? Существуют ли требования для использования определенных физических интерфейсов (например, RS-232 или USB)? Имеются ли оптоволоконные соединения или Ethernet-соединения? Помимо аппаратного обеспечения, существуют ли какие-либо конкретные коммуникационные протоколы, необходимые при общении с другими системами?
    • Кто из пользователей? Каковы их характеристики, опыт, знания, обучение, знакомство с доменом или подобными системами? Рассматривайте не только ежедневных пользователей, но и людей, которые должны поддерживать программное обеспечение. Могут ли обновления управляться пользователями или профессиональными ИТ-специалистами?
    • Какие предположения сделаны в остальном документе требований? Какие зависимости существуют на другом программном обеспечении? Если несколько частей системы строятся параллельно, любая функция блокирует другие части от начала или окончания? Ограничены ли какие-либо требования до тех пор, пока функциональность не будет предоставлена ​​другим компонентом?
  • Конкретные требования.
    • Функциональные требования или функции, которые должна предоставить система.
    • Нефункциональные требования или атрибуты качества. Описания того, как должна себя вести система. Примеры включают доступность, отказоустойчивость, производительность, мобильность, удобство использования, безопасность и т.д.
    • Другие типы требований и ограничения проектирования. Примеры включают документацию и то, как она предоставляется пользователю (например, руководства пользователя и/или встроенная справка и поддержка), управление конфигурацией и условное депонирование, а также лицензирование или юридические проблемы.

Карл Вигерс, автор Требования к программному обеспечению и Подробнее о программном обеспечении Требования также имеют веб-сайт под названием Process Impact. Несмотря на то, что шаблоны продаются, вы должны проверить раздел Goodies, который имеет документы, выпущенные для номинальной суммы в $5.

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

Ответ 4

Ну, все может быть документом требований. Все, что описывает функциональность Thing [tm]. Возможно, вы хотите проверить http://joelonsoftware.com/articles/fog0000000036.html для программного обеспечения на основе графического интерфейса.

Ответ 5

Если вы ищете конкретный стандарт, вы можете ознакомиться с IEEE 820-1998 - Стандартами требований к программному обеспечению. есть шаблоны и т.д., если вы используете Google для них. есть даже основной шаблон на wiki: IEEE 830 - шаблон SRS

Вы также можете посмотреть на весь SWEBOK (Software Knowledge Body of Knowledge) из IEEE.

Ответ 6

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

Например, если вы идете с гибким процессом, вам может понадобиться несколько листов бумаги с несколькими историями на нем. (Это, конечно, очень просто)

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

Ответ 7

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

В этом случае лучше всего не делать документ с золотым покрытием, а сделать его доступным для редактирования. Это должно быть просто достаточно хорошо (TM), что вы, тестеры и клиенты, согласны с тем, что такое программное обеспечение, но не лучше; и он должен быть достаточно гибким, чтобы после того, как клиенты перестали соглашаться с тем, что программное обеспечение вы можете разместить в этом.

Ответ 8

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

  • Компания X продает хлеб в супермаркеты, используя работодателей, которые продают и доставляют хлеб из фургонов.

  • В настоящее время используются бумажные гнезда и хотят перейти в электронную систему.

  • Они хотят, чтобы эта система поступала в SAP, что автоматически обновляет учетные записи и генерирует все необходимые документы для клиента.

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

  • Система должна быть быстрее использована в поле, чем существующая система бумаги

  • Аппаратное обеспечение должно быть достаточно прочным для работы в суровых условиях в условиях низкой освещенности. например IP76 и с подсветкой.

  • Стоимость системы должна быть не более $5 тыс. за пользователя

и т.д...

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

Ответ 9

Заключенные прибегают к убежищу Аланом Купером. Эта книга высокого уровня предназначена для объяснения важности дизайна, ориентированного на пользователя, руководству и руководителям.

О Face 3.0 от Alan Cooper - это руководство для практиков, ориентированное на пользователя, и является отличным руководством для обеспечения соответствия продукта требованиям пользователей.

Лучшие ресурсы, которые я бы рекомендовал для создания документов требований, - это процесс освоения требований Robertson и Robertson и программные требования Сорен Лаусен. последний обеспечивает углубленное введение в ряд методов сбора и захвата требований.

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

Если вы прошли все это уже и сразу после шаблонов два наиболее часто используемых (или адаптированных) стандарта IEEE (1220-1998) и стандарта DoD MIL-STD-498. Из них стандарты MIL кажутся мне для того, чтобы предложить наибольшую ценность для наименьших издержек. Но все равно требуйте больших усилий, которые не могут напрямую повысить ценность вашего проекта.

Ответ 10

Скотт Амблер "Сайт Agile Modeling" содержит несколько хороших образцов. Там также много краткий, прагматичный совет по требованиям Agile в целом.

Стоит посмотреть!

Ответ 11

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

Процесс - это результат, главным образом, различных заинтересованных сторон проекта.

Информация о документации по требованиям также указана в словаре WBS, а требования высокого уровня также находятся в Хартии проекта/Заявлении о работе.

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

Ответ 12

Возможно, вам захочется изучить IEC29148 и соответствующий ISO12207. Еще один взлом, если вы используете Doors, попробуйте его шаблоны. Они организованы как скрипты DXL и создают для вас модули, включая все, начиная с SRS, SDD и т.д. IEEE, и т.д. До DoD490a, DoD498 и т.д. Также попробуйте http://www.letu.edu/people/jaytevis/Software-Engineering/MIL-STD-498/MIL-STD-498-documentation.html для дальнейших документов.