Коротка відповідь : 830-1998 - це не стандарт, це рекомендована найкраща практика щодо того, як писати SRS у стилі 1998 року.
Я не можу знайти, як це було замінено насінням (навіть при розширеному пошуку IEEE :()
Але я думаю, це тому, що весь метод того, як ми визначаємо вимоги, різко змінився за останні роки.
Отже, відтепер я намагаюся відповісти на трохи змінене запитання:
Що таке найкраща промислова практика / Які найкращі рекомендації щодо написання СРС у стилі 2012 року?
Про класичні методи:
Зазвичай я використовую рекомендації IEEE 1471 для документації на програмне забезпечення, хоча це також було замінено останнім часом ISO / IEC 42010. Це дуже складний вид документації, він в основному використовується для передачі вручну, хоча в основному містить вимоги (це глава 7 в новий документ у стилі ISO)
Помірно хороша книга офіційної документації - це Documenting Software Architectures , напрочуд хороша книга - стара книга iconix , а стара класика - це випадки ефективного використання написання Кокберна .
Про те, як це відбувається насправді в галузі сьогодні:
По правді кажучи, формальна проектна документація, особливо документація на вимоги, була знищена здебільшого в епоху Agile , оскільки Agile Manifesto відлякує від офіційної документації. Немає жодної, єдиної, великої формальної специфікації, але натомість є так звані історії користувачів , відставання продуктів та інше . Це пов'язано з ітераційним розвитком, лише кілька функцій визначаються неофіційно для кожного циклу 2-4 тижні. Відома книга - Приклади користувачів .
Існують так звані "виконувані" специфікації, які є формальними , оскільки вони є по суті специфічними для домену мовами (DSL) для тестування. Вони не кращі чи гірші за OCL UML , але вони легше зрозуміти, мабуть, але й менш наукові. Більшість з них називається рамки BDD, і приклади включають FitNesse , Огірок , жасмин - ви знайдете великий букет з них. Є також відомі книги про BDD та TDD загалом.
Крім того, специфікація інженерів програмного забезпечення була заміщена UX-дизайном , включаючи інформаційну архітектуру та дизайн взаємодії, тому це не робиться людьми, які насправді кодують сьогодні, що іноді може призвести до конфлікту. Це не дуже поганий приклад того, як це виглядає (це не стандарт!), Але ви знайдете набагато більше всередині спільноти UX / взаємодії, але є навіть цілий окремий сайт stackexchange для них. Вони мають свої стандарти, рекомендовані найкращі практики тощо.
Але що робити, якщо ви хочете дотримуватися старих методів, наприклад. на роботу в університеті?
Загалом, спробуйте дотримуватися IEEE 830 (не можу знайти на своїй веб-сторінці, з чим це було замінено, хоча IEEE ніколи не був у цьому хороший, я думаю, що це, на жаль, вже не має значення), і переконайтеся, що ви спробуйте для запису корисної інформації (наприклад, я не думаю , що одна цифра актор палиці -> один міхур з дієсловом-суб'єктом вважається корисним) , з яких загальних цілей цих користувачів, загальний діапазон користувачів і загальні методи по використання можна відновити будь-коли.
Чому ви рекомендуєте книги? Чому ти мені не покажеш стандартів?
Знову ж таки, я думаю, що цей документ був "заміщений", тому що сьогодні у нас є трохи хаосу навколо специфікації вимог: існує багато-багато поглядів на те, як це потрібно зробити.
Немає жодного органу, який міг би вам сказати: "саме так слід робити технічні характеристики" . Існують найкращі практики , і я намагався надати вам репрезентативний перелік документів та вказівок , хоч ні в якому разі не повний і, можливо, особисто упереджений.
Зрештою, важливіше, чим створений вами документ здатний виконати всі цілі, які мають усі люди, які його коли-небудь читали : що люди хочуть бачити, що люди повинні знати, щоб зрозуміти вимоги вони досить добре описані в цих книгах, і це найкращі практики самі по собі, хоча і в набагато менших спільнотах, ніж єдине, нерозділене ІТ-співтовариство, яке ми мали, можливо, у 1998 році.