В чем разница между требованиями и спецификациями? [закрыто]

122

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

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

requirements specifications
источник

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

Шейн Веалти

1

Да, именно поэтому люди должны сказать «Бизнес-требования» и «Спецификация проекта» / «Техническая спецификация» или что-то в этом роде. Слова сами по себе довольно расплывчаты.

user606723

Думайте об этом так (грубо говоря): Требования = документация по требованиям и спецификации = документация по сценарию использования / разработке

кандидат наук

4

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

Яап

Эта статья предлагает исчерпывающий ответ: ece.cmu.edu/~koopman/des_s99/requirements_specs

Julien-L

129

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

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

Брайан Оукли
источник

4

Что / как звук прикус право, своего рода; но сбивает с толку, потому что вы также можете посмотреть на спецификацию программы как на описание того, что она должна делать, и на то, как она должна это делать. Другой - декларативный pl (например, пролог и SQL), в котором вы указываете, что не как . Одно из решений заключается в том, что они являются иерархическими абстракциями, где родитель указывает, что и дети указывают, как (снаружи или внутри). Я предпочитаю свой второй вид, который ближе к « что это за » против « что она является » , то есть преимущество по сравнению с функцией.

13рен

Я бы вообще с тобой согласился, но это просто «другое» мнение, а не правильный ответ. Например, взгляните на вики-страницу с требованиями ( en.wikipedia.org/wiki/Requirement ). Есть нефункциональные требования, которые по определению предназначены для технической команды. Или требования к архитектуре и ограничениям, опять же технические, но они не называют их «спецификациями». Я думаю, что нет правильного ответа, и он всегда будет «размытым» от компании к компании и от разработчика к разработчику.

Jeach

1

Посмотрите на ответ «Адам Вюрл» ниже, я думаю, что это наиболее точное утверждение к опубликованному вопросу.

Jeach

1

@Jeach: "ниже" [sic] является относительным. Возможно, в данный момент он находится ниже этого поста, но может перемещаться выше, что затрудняет понимание вашего комментария

Брайан Оукли,

1

Другая перспектива. Википедия определяет спецификации как «набор требований». Это означает, что спецификация может быть только 1 требованием, s: = {r1}. Похоже, что разговорные «требования» - это «высокоуровневые» требования, в то время как «технические характеристики» - это низкоуровневые требования, вещь LOD.

Лэнс Поллард

38

Требования документируют то, что необходимо - они должны указывать не как, а как.

Спецификации документируют, как выполнить требования - они должны указать, как.

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

Одед
источник

2

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

Джорджио

16

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

Спецификация является документом , который определяет систему или продукт, например , спецификации разработки прайм-элемента для F-14. В спецификации много разделов / контента: требования, определения, справочные документы, глоссарий, информация о проверке и т. Д.

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

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

Адам Вюрл
источник

4

Как я сказал в другом комментарии, это очень размыто для всех и, вероятно, всегда будет. Но, основываясь на моих ОЧЕНЬ обширных исследованиях по этому конкретному вопросу, я бы сказал, что ваш ответ является наиболее точным из моих собственных выводов / заключений.

Jeach

2

Всегда полезно узнать мнение настоящего инженера. Спасибо!

LeWoody

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

Брайан 'BJ' Хоффпауир младший

1

@ Bryan'BJ'Hoffpauir Я уверен, что есть случаи, когда документы помечены спецификациями и в них нет требований, но я бы поспорил с тем, что это неправильное использование этого термина. Спецификация - это документ с требованиями - конец истории. Это общепринятый термин «искусство» во многих областях, таких как аэрокосмическая и оборонная промышленность, и он не подлежит обсуждению в рамках системного проектирования, которое является дисциплиной, отвечающей за требования и проверку. Даже в том случае, если вы описываете, что термин применяется: BRD - это спецификация, техническая спецификация звучит так же, только с различными типами требований.

Адам Вюрл

13

Требования:

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

Характеристики:

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

Цитата из "Основы системного проектирования ^* ".

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

_{* Defense Acquisition University Press, 2001. PDF-версия текста.}

talabes
источник

Я думаю, что важно, чтобы ваше определение гласило, что спецификации определяют ПРОБЛЕМУ. Таким образом, спецификация ПРОБЛЕМА является требованием. Спецификация SOLUTION или DESIGN является частью дизайна.

LeWoody

6

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

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

Следовательно, одним из основных моментов является то, что Требования должны быть на первом месте, прежде чем можно будет написать Спецификацию.

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

архиватор ARJ
источник

1

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

13рен

1

Я понимаю вашу точку зрения, но я думаю, что любой угол адекватно описывает ситуацию. Я придерживался мнения, что покупатель будет покупать товар, как вы делаете это, когда идете в магазин. Поставщик программного обеспечения будет предлагать свое решение основной проблемы. Если бы я пошел за покупками, чтобы найти решение своей проблемы, я бы подумал: «Мне нужен продукт, который делает xyz», а не «Мне нужно решение моей проблемы abc». Я думаю, это просто вопрос предпочтений.

Ардж

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

13рен

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

13рен

[объясняет, почему два комментария]: SO комментарии являются такой болью - нажатие «return» отправит комментарий, даже если это многострочная текстовая область. И если после этого у вас уйдет более 5 минут, редактирование не будет принято. Таким образом, вы должны представить его в качестве второго комментария. Я редактировал только для того, чтобы он соответствовал длине. Вздох . В следующий раз я просто расскажу два комментария, во-первых ... [в любом случае, я согласен, что точка зрения - покупатель / продавец - это главное различие. Меня беспокоит ваша терминология, но я думаю, что это углубляет мое понимание, чтобы попытаться сформулировать, почему.]

13рен

4

Требование - что должна делать (должна) система или подсистема.

Спецификация - что такое компонент, подсистема или система.

Это имеет решающее значение в отрасли производства медицинского оборудования, так как вы должны провести проверку в соответствии с вашими требованиями (входы), чтобы продемонстрировать, что у вас есть действительные спецификации (выходы). Типичные подводные камни в этой отрасли: компании (1) забывают определять требования (потому что они не понимают разницы между требованиями и спецификациями); (2) Проведите проверку только на соответствие спецификациям и (3) Не гарантируйте, что Требования точно переведены в спецификации узлов и компонентов.

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

Пол Бахус
источник

3

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

Пример шаблона SRS IEEE

Я также слышал, что термины « технические условия» более неформально относятся к техническим спецификациям, которые объясняют проектные решения и план реализации.

РЕДАКТИРОВАТЬ: я только что заметил, что ссылка неправильная ... Я скоро опубликую правильную ссылку.

maple_shaft
источник

1

Хорошая точка зрения на срок SRS!

LeWoody

2

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

3

Спецификация - это требование, которое прошло технико-экономическое обоснование и готово к реализации. Это требование, которое дошло до стадии проектирования.

Другими словами:

Требование - это поведение (или не поведение) «как запланировано» или «как пожелано»
Спецификация - это поведение (или не поведение), которое «должно быть построено» или «как построено»

Пример:

требование: 1. пользователь нажимает кнопку ОК 2. система печатает счет
спецификация: 1. пользователь нажимает кнопку ОК 2. система печатает счет

Как видите, содержание обоих может быть одинаковым. Разница в том, что требование является артефактом анализа. Спецификация является артефактом дизайна.

В окончательной готовой документации вы обычно найдете слово «спецификация» вместо «требование», поскольку требования были преобразованы в спецификации.

Примечание: пример выше содержит элементы дизайна из-за ограничений дизайна.

fox.bailey
источник

0

Требования - это то, что делает приложение

Спецификации, КАК приложение делает то, что оно делает.

Они должны быть ортогональны!

Менеджеры по продукту пишут требования, главные инженеры пишут спецификации.

jayunit100
источник

2

Я не уверен, что они полностью ортогональны, по крайней мере, на практике. К сожалению, много серого.

LeWoody

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

Брайан 'BJ' Хоффпауир младший

0

Один из способов, возможно, не правильный, посмотреть на это:

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

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

berad
источник

это только ваше мнение или вы можете как-то это подтвердить?

комнат

2

@gnat, я думал, что это было решено в первой строке? Конечно, это из опыта, и я не претендую ни на что другое - из того, что я понял, это довольно субъективный вопрос на довольно субъективном форуме, и этот пост предполагает, что вопросы должны быть как можно более объективными, но в них мало упоминаются ответы , Но у меня есть один по имени, и у вас есть намного больше, поэтому я открыт для

обучения

0

В своих исследованиях я нашел спецификации, которые будут использоваться для патентов и строительства домов (как часть контракта).

Определение требования из словаря Вебстера (3-й новый международный изд.):

a) что-то, что требуется или необходимо: необходимость b) что-то требуемое или требуемое: обязательное или существенное условие: требуемое качество, курс или вид обучения

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

LeWoody
источник

0

В предыдущей компании, создававшей коммерческие продукты, у нас было следующее отличие:

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

Спецификации - это те вещи, которые на самом деле выполняет система. Например, у вас может быть требование, согласно которому система должна вести себя как X при –10 ° C. Фактическая спецификация системы может заключаться в том, что система выполняет X при –5 ° C; это будет в листе, разосланном потенциальным клиентам, когда они захотят купить систему.

Примечание: в этом случае спецификация не соответствует требованию.

Royd
источник

-1

Думаю, вы собираетесь построить высотное здание на земле.

Теперь вам нужно рассмотреть Требования перед началом работы, такие как:

Инженер архитектуры или дизайна
Инженер-испытатель грунтов
Команда тестирования давления ветра
разрушитель
экскаватор
Сила человека
Водоснабжение
Рабочая зона проживания / отдыха
Достаточно фонда
Управление проектом
Управление качеством
Контроль безопасности

И т.п.

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

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

Вышеуказанный пункт будет частью справочника, который вы можете назвать Технической спецификацией.

Мохаммед Хок
источник

1

Я думаю, что вы путаете требования с ресурсами ( en.wikipedia.org/wiki/Resource_%28project_management%29 ).

Джей Элстон

В чем разница между требованиями и спецификациями? [закрыто]

Ответы: