Обсуждение:Требования к программному обеспечению

есть ли конкретные Требования, отличимые от таковых к прочей конструкторсой разработке, или же - конкретный ОРИСС, и, соответственно....... ? --Tpyvvikky 23:26, 9 июля 2013 (UTC)Ответить[ответить]

Требования vs Спецификация Править

Чем можно объяснить наличие двух статей: Требования к программному обеспечению и Спецификация программного обеспечения ? В том же SWEBOK есть «Спецификация требований (Requirements Specification)». Так одно это понятие или два? Например, Функциональные требования и Функциональная спецификация — ведёт на одну страницу. РоманСузи 18:57, 5 октября 2012 (UTC)Ответить[ответить]

Старое определение функ.требований Править

Убрал вот это:

• Функциональные требования — определяют «как» ((Ошибка! Не как, а что - "define what a system is supposed to accomplish" (см. англ. статью Functional_requirement)) - Здесь нет ошибки. Функциональные требования отвечают на вопрос "Как", это спецификация (пользовательские или бизнес-требования) отвечает на вопрос "Что", следует исправить Англ. статью.) реализовать продукт.

Без каких либо ссылок на источники разводить в статье дискуссию подобным образом недопустимо. РоманСузи 04:15, 11 сентября 2012 (UTC)Ответить[ответить]

Типы и уровни требований Править

Сейчас коллега Евгений Мирошниченко проставил требования ссылок на источники. Было бы интересно узнать, а как вообще в этой теме свести несколько источников к одному результату без орисса? Возьмем ли мы сюда SEI или IIBA? Или может гуру от Agile? Я тут последнее время начал понимать одну замечательную вещь: всегда найдется несколько альтернативных стандартов, "body of knowledge", одни и те же вещи разные специальности видят немного по-своему. И все это к тому же в постоянном движении (а как иначе? Появляются новые знания, но и делать деньги на сертификации тоже нужно). В общем довольно творческий подход требуется, чтобы в энциклопедической статьи об этой теме написать с учетом ВП:ВЕС и т.п. Скажем, в Software Requirements by Karl E Wiegers and Joy Beatty Published by Microsoft Press, 2013 даются три уровня требований: бизнес-требования, пользовательские и функциональные. Соответственно, разные специалисты участвуют в их разработке от менеджеров до разработчиков. Это пойдет? РоманСузи (обс.) 19:05, 20 ноября 2018 (UTC)Ответить[ответить]

Ничего нового выдумывать нет нужды, правила нам предписывают при наличии разных точек зрения описывать их все сообразно весомости. То есть сводить всё в какую-то ориссную "единую концепцию" не понадобиться. Разумеется, основой должен быть наиболее авторитетный источник, на данный момент это международный стандарт ISO/IEC/IEEE 29148:2011 Systems and software engineering -- Life cycle processes -- Requirements engineering. На втором месте свежий стадарт от IEEE: IEEE 29148-2018 - ISO/IEC/IEEE Approved Draft International Standard - Systems and Software Engineering -- Life Cycle Processes --Requirements Engineering. На третьем месте свод знаний по программной инженерии SWEBoK (Guide to the Software Engineering Body of Knowledge) от IEEE, сейчас он в редакции 2004 года. Затем идут другие хорошие источники, в частности, монографии отдельных авторов, тех же Виггерса и Битти. Понятно, что в каждом источнике свои особенности и свои плюсы с минусами. У тех же Виггерса и Битти много хорошего, но вот та же их классификация уровней на бизнес-требования, пользовательские и функциональные -- бред сивой кобылы, так как деление требований на функциональные и нефункциональные существует на каждом уровне требований: бизнес-требований и системных требований, и никакого отдельного уровня функциональных требований не существует. Но это не значит, что их классификацию нельзя будет привести в статье. Евгений Мирошниченко 09:27, 21 ноября 2018 (UTC)Ответить[ответить]

P.S. Про «Возьмем ли мы сюда SEI» я не понял, что имеется в виду, а про бизнес-анализ упомянуть можно, но только упомянуть, т.к. данная статья конкретно про требования к программному обеспечению. Евгений Мирошниченко 09:35, 21 ноября 2018 (UTC)Ответить[ответить]

• Спасибо. Стандарты в данном случае - милое дело. Посмотрю как время будет. А бизнес-анализ или скажем product management - довольно смежные темы. Без их упоминания понятие будет в воздухе висеть. РоманСузи (обс.) 19:10, 23 ноября 2018 (UTC)Ответить[ответить]