Какой стандарт заменил 830-1998?

Я изучал способы более формального документирования программных проектов и узнал о IEEE 830-1998: рекомендуемая практика для спецификаций требований к программному обеспечению . Однако, как видно из этой ссылки, она была заменена.

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

Стоит отметить, что:

1. Самый последний стандарт при поиске «Спецификации требований к программному обеспечению» или «Требования к программному обеспечению» на веб-сайте Ассоциации стандартов IEEE - 830-1993,
2. Версия SWEBOK 2004 года (текущая) ссылается на 830-1993 ( пункт 2.5 ),
3. Статья Wikipedia в документе не упоминает, что стандарт был заменен.

TLDR: Как ты находишь, какой стандарт заменил другой, а какой занял место 830-1998?

Краткий ответ : 830-1998 - это не стандарт, это рекомендуемая лучшая практика написания SRS в стиле 1998 года.

Я не могу найти, как это было заменено (даже с расширенным поиском IEEE :()

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

Итак, теперь я пытаюсь ответить на немного измененный вопрос:

Каковы лучшие отраслевые практики / Каковы рекомендуемые лучшие практики написания SRS в стиле 2012 года?

По классическим методам:

Обычно я использую рекомендации IEEE 1471 для документации программного обеспечения, хотя это также недавно было заменено ISO / IEC 42010. Это очень сложный вид документации, он в основном используется для передачи обслуживания, хотя он содержит требования в основном (это глава 7 в новый документ в стиле ISO)

Умеренно хорошая книга по формальной документации - Документирование программных архитектур , удивительно хорошая книга - старая книга iconix , а старая классика - «Примеры эффективного использования Кокберна» .

О том, как это на самом деле делается в отрасли сегодня:

По правде говоря, формальная проектная документация, особенно документация по требованиям, была уничтожена в основном в эпоху Agile , так как Agile Manifesto не одобряет формальную документацию. Единой, большой формальной спецификации не существует, но вместо этого существуют так называемые пользовательские истории , журналы о продуктах и тому подобное. Это из-за итеративной разработки, только несколько функций неформально определены для каждого цикла 2-4 недели. Известная книга « Прикладные истории» .

Существуют так называемые «исполняемые» спецификации, которые являются формальными , поскольку они по существу являются языками, специфичными для предметной области (DSL), для тестирования. Они не лучше и не хуже, чем OCL UML , но их легче понять, но они менее научны. Большинство из них называются BDD-фреймворками, и примеры включают в себя FitNesse , Cucumber , Jasmine - вы найдете много таких. Есть также известные книги по BDD и TDD в целом.

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

Но что, если вы хотите придерживаться старых методов, например. для работы в университете?

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

Почему вы рекомендуете книги? Почему бы вам не показать мне стандарты вместо этого?

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

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

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

Я нашел это на сайте IEEE: http://standards.ieee.org/findstds/standard/29148-2011.html

Стандарт 29148: 2011 предназначен для замены IEEE 830: 1998.

Этот стандарт заменяет IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

ISO / IEC / IEEE 29148: 2011 содержит положения о процессах и продуктах, связанных с разработкой требований к системам, программным продуктам и услугам на протяжении всего жизненного цикла.

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