Краткий ответ : 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 году.