Правильная классификация требований клиента для диаграмм UML?

Question

Мне нужно было классифицировать следующие RQ как

• Проектная задача,
• Проектные решения,
• Функциональный запрос,
• НеФункциональный запрос

(поэтому я могу сделать диаграмму классов и использовать диаграмму прецедентов, основываясь на них позже).

Я хотел знать, нахожусь ли я на правильном пути (жирный шрифтлицо - мое предположение для каждого требования):

Документ с требованием Система обязательств по закупкам.

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

2. Программное обеспечение должно быть написано на языках программирования C ++ или Java на компьютере IBM PC. (проектное решение)

3. Количество продуктов должно быть равно 4. (Нефункциональное требование)

4. Общей целью при разработке программного обеспечения является улучшение переносимости программного обеспечения. (Нефункциональный запрос)

5. Система должна принимать в качестве входных данных (сделать в виде текстового файла) данные о количестве, количестве и цене детализации для каждоготип продукции. (Функциональное требование)

6. Количество деталей для каждого типа продуктов должно быть не менее 5.

7. Первый и второй тип продукции должны иметь две одинаковые детали.Второй и четвертый тип товаров должен иметь одну и ту же деталь.Третий тип товаров должен иметь 2 одинаковые детали с четвертым типом и одну деталь с первым типом товаров. (Цель проекта)

8. Оператор должен войти в систему и выйти из системы по логину и паролю. (Цель проекта)

9. В начале оператор должен предоставить следующие элементы данных (должна быть обеспечена проверка входных данных):

   • Количество продуктов каждого типа, которые будут производиться на заводе в течение 3 месяцев. (Функциональное требование)

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

    • Общая стоимость каждой детали.
    • Общая стоимость всех деталей

Answer 1

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

Дизайн программного обеспечения - это структура и поведение программного обеспечения.Если какое-то утверждение кажется произвольным, и вы думаете, что программное обеспечение может выполнить все требования, но по-другому, то есть вероятность, что это скорее дизайн, чем требования.Цель проекта говорит о том, что проект должен обеспечить (неоднозначно: на стадии требований трудно провести различие между нефункциональными требованиями и целью дизайна).Проектное решение - это решение о поведении или структуре программного обеспечения.

Имея это в виду, приведем анализ:

1. Что должно делать программное обеспечение ==> Функциональные требования (FR)Если мы изменим это, программное обеспечение больше не будет делать то, что ожидается, поэтому это не может быть дизайнерским решением.
2. Каким должно быть программное обеспечение ==> Нефункциональное требование (NFR)Не совсем о структуре или поведении программного обеспечения.Язык не повлияет ни на вариант использования, ни на модель класса, так что на самом деле это не дизайнерское решение.
3. Произвольное решение о количестве элементов в модели объекта ==> Проектное решение (DD)
4. "Цель в проекте" ==> Цель проекта (DO)
5. Что такое программное обеспечениедолжен делать ==> FR
6. Произвольное ограничение на объектную модель ==> DDЕсли оно будет не менее 3 или не менее 10, программное обеспечение будет по-прежнему соответствовать функциональным требованиям.Однако это зависит от контекста.Если окажется, что программное обеспечение не будет соответствовать цели, если эти ограничения не будут соблюдаться, то это может быть FR.
7. Произвольное ограничение на объектную модель ==> DDЦель этого заявления неясна.Похоже, некоторые произвольные ограничения, которые могут позволить обобщить некоторые категории.
8. Что должно делать программное обеспечение ==> FR
9. Произвольное решение о взаимодействии ==> DDЯ думаю, что данные могут быть введены в другой момент или другим способом (3 раза в 1 месяц).Поэтому я думаю, что это DD.Однако можно утверждать, что система должна предлагать трехмесячное планирование.Таким образом, FR не может быть исключен, хотя я ожидаю, что он будет выражен по-другому.
10. Что должно делать программное обеспечение ==> FR

Answer 2

Я помню длинные дискуссии в прошлом о RQ, независимо от того, был ли конкретный не F или F. Однако, Википедия имеет простое определение.

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

Таким образом, ваша классификация выглядит не плохо.Хотя мне интересно, какими должны быть ваши первые две классификации.Выглядит немного как MoSCoW , но, опять же, это не так.Дизайнерские решения (по крайней мере для меня) ничего не найти в требованиях.Это, как следует из названия, решения, исходящие из процесса проектирования.Кроме того, целью проекта является подкатегория NF.Еще более важным является тот факт, что ваши национальные федерации не классифицируются.Там должно быть по крайней мере несколько подклассов (юридические, производительность и т. Д.).См. Википедия для довольно полного списка.