Основы основ, или главная терминология

В теме 4 ответа, и 4 участника, последнее обновление сделано пользователем Юлия Шамрей 11 г назад.

В книге К. Вигерса "Разработка требований к ПО" автор упоминает такой аспект функциональных требований, как Системные требования (System requirements). Как вы понимаете данный термин? И, если можно, приведите небольшой пример, отражающий различия между непосредственно функциональными и системными требованиями.

P.S. Так же хотелось бы узнать ваше мнение о том, есть ли смысл в дальнейших вопросах подобного типа.

На данном форуме уже поднимался вопрос о том, как бы вы определили понятие "требование". Могу ошибаться, но, вероятно, разъяснение других понятий может оказаться нелишним.

В книге К. Вигерса "Разработка требований к ПО" автор упоминает такой аспект функциональных требований, как Системные требования (System requirements). Как [b]вы[/b] понимаете данный термин? И, если можно, приведите небольшой пример, отражающий различия между непосредственно функциональными и системными требованиями.

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

Операционная система Windows Vista/XP/7 Процессор Intel Core2 Duo E6600/AMD Phenom X3 8750 или лучше Оперативная память — 2GB 12GB на жестком диске Видеокарта поддерживающая пиксельные шейдеры версии 3.0: NVIDIA GeForce 8600GT/ATI Radeon X1950Pro с 256MB оперативной памяти или лучше Звуковая карта совместимая с DirectX 9.0c DirectX: 9.0c

С другой стороны, мне так кажется, что это может быть требование к тому, какие компоненты должна использовать проектируемая/документируемая/создаваемая вами система. Например, "система должна быть написана на фреймворке .NET 3.5".

Как-то так сложилось, что системные требования лично я не часто документировал и куда-то ложил на этапе создвания SRS, но могу сказать, что они всё-таки существуют (:. И вот места, где я их чаще всего видел — это "Request for Proposal", "Proposal", приложение к контракту и маркетинговая информация о продукте/системе на упаковке, на сайте, в буклете.

Хотя, может, я всё забыл и коллеги меня сейчас поправят.

Что касается вот этого

P.S. Так же хотелось бы узнать ваше мнение о том, есть ли смысл в дальнейших вопросах подобного типа.

то ответ несомненно "да" (:, отчасти для этого данный форум и существует.

CRUDL матрица. Буду рад, если хотя бы в общих чертах рассмотрим Create, Read, Update, Delete, List на примере, приведенном в книге Вигерса (attached) 1.Что это за зверь?

"Зверь" помогает оценить достаточность описанных use cases системы, в ходе которых над объектами системы происходят действия.

2.Каким образом этот метод позволяет выявить недостающие требования? After creating a CRUDL matrix, see whether any of these five letters do not appear in any of the cells in a column. If a business object is updated but never created, where does it come from?

Ответ на вопрос содержится в цитате выше Для того, чтобы работать с объектом, он должен каким-то образом появиться, т.е. как минимум в одном use case с ним должно производиться действие Create. Так и с другими действиями RUDL. Если, к примеру, отсутствует действие R или L, то стоит задуматься — а не пропустили ли мы какой-то use case, который его использует? И если не пропустили — то может быть объект лишний, если он не нужен в других use cases?

В приведенной таблице есть еще один хороший пример: мы видим, что для объекта Vendor Catalog доступны лишь действия Read и List, это значит что система использует список, который поддерживается сторонней системой, т.е. вендор производит с ним действия CRUDL, а наша система лишь R и L.

Мои размышлизмы на тему…

Системное требование — это определение необходимого (требуемого) состояния, в котором должны находиться система (аппарат, продукт) и окружающие ее среда или контекст. Вот такое определение я себе придумала, посоветовавшись с господами Jackson и Neil Maiden.

Юра выше привел самый распространенный пример системных требований в наше время

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

Пример из жизни может быть такой.

Функциональное требование: секретарь Аня хочет, чтобы отсканированные документы автоматически раскладывались согласно распознанным метаданным каждого документа по соответствующим папкам в хранилище документов.

Системные требования: 1. Документ при сканировании должен быть расположен определенным образом, чтобы у сканирующего и распознающего модуля была возможность выполнить свою функцию. 2. Метаданные документа должны располагаться в определенном месте на документе. 3. Если в ходе распознавания произошла ошибка, и система не может определить целевую папку, то документ должен быть сохранен в промежуточной папке для последующей ручной обработки. Хотя вот это требование может быть и функциональным, если пользователь его озвучил аля "Хочу, чтобы все документы, сканирование и распознавание которых произошло с ошибкой складывались в одно место". 4. Ну и вплоть до брутального. Для того, чтобы документ был корректно сохранен в хранилище, пользователь должен инициализировать процесс сканирования и распознавания документа, и убедиться в его успешном завершении.

По моему опыту, чаще системные требования всплывают, когда система строиться на базе какой-либо готовой платформы. Системные требования носят чаще всего ограничивающий характер. Это как в браке, когда жена готовит ужин, если муж добыл мамонта. Ну а если мамонта нет, то и ужина нет Т.е. системные требования — это необходимые входы (inputs) для системы, чтобы она могла произвести нужный пользователю результат.

📎📎📎📎📎📎📎📎📎📎