Список - требование
Cтраница 1
Список требований не является исчерпывающим. Каждый отдельный случай проектирования и исполнения трубопроводов высокого давления должен быть тщательно изучен для принятия наиболее правильного, удобного и экономичного решения. Это решение должно быть проверено опытом аналогичных производств. [1]
Список требований следует разделить на несколько секций: по одной на каждый глобальный уровень проекта и на каждую его подсистему. Подсистема проекта ( project subsystem) состоит из модулей, на которые традиционно разделяется проект при распределении работ. Различие между уровнями проекта и подсистем для требований состоит в том, что требования на уровне проекта применяются ко всему проекту, например требования к аппаратному обеспечению, общие бизнес-требования и рекомендации по пользовательскому интерфейсу. Однако большинство требований располагается в списке для уровня модулей. Такой список определяет специфические требования для каждой подсистемы, например подсистем продажи и производства. Многие требования могут попадать в области различных подсистем. [2]
 |
Рейтинг потребительских требований. [3] |
Для этого следует упорядочить список потребительских требований по степени важности. В результате получится еще один столбец с числами, указывающими, какое место по важности занимает в этом ряду каждое из требований. Естественно, проставление рейтингов во многом субъективно и не всегда отражает реальную степень важности отдельных требований. Но производитель не может удовлетворить абсолютно все требования, поэтому ему приходится выбирать. [4]
Процедура опроса позволяет аналитику разработать список требований и показать его каждому пользователю, чтобы узнать их мнение. Аналитик получает документ, который может вернуть обратно каждому пользователю. [5]
Отбор может стать затруднительным, если список требований к работнику со стороны организации будет слишком велик, или неправильным, если требований вообще нет. [6]
Массивы информации означают: Ml - список требований, предъявляемых к ТР: М2 - список методов выявления недо-статкоп в ТР; МЗ - фонд физических эффектов ( ФЭ); М4 - фонд ТР. При решении определенного класса задач, относящегося к группе областей техники и тем более к одной из них, авт т i i рекомендуют составлять частные алгоритмы, отличающиеся от обобщенного меньшим количеством процедур. [7]
 |
Инженерные характеристики. [8] |
В результате выполнения трех предыдущих этапов проектировщики получили ранжированный список потребительских требований, составленный на языке потребителя, и инженерных характеристик, сформулированных на профессиональном жаргоне. Для успешной разработки изделия нужно составить что-то вроде словаря-перевода потребительских требований в инженерные характеристики. [9]
На третей неделе ноября в Вашингтон для передачи списка требований прибыл японский дипломат. [10]
При сборе информации на фазе анализа необходимо объединить собранные сведения и создать полноценный список требований к системе. Информация поступает из различных источников: заметки об опросе, предварительная диаграмма ERD, функциональная иерархия, аудит отчетов и требования, извлеченные из старой системы. В этой массе сведений нужно выявить согласованную модель данных и функциональную архитектуру, поддерживающую требования к системе. Традиционный метод CASE явным образом не рассматривает документ о требованиях, что может привести к неудовлетворению пользователей новой системой или полному краху всего проекта. Решением проблемы может стать привлечение пользователей к участию в разработке документа о требованиях, который должен содержать описание потоков процессов, аналитическую ERD и функциональную иерархию. Этот документ является главной законченной частью фазы анализа. [11]
На компьютере с системой Windows NT совместный доступ может быть открыт к любой папке. В следующей таблице содержится список требований, предъявляемых к группам и операционным системам, выполнение которых необходимо для открытия совместного доступа к папкам. [12]
Другой способ предполагает создание отчета, который показывает ассоциации между требованиями к функциям и модулями. Если в этот отчет добавить список требований к функциям для всех реализованных в модулях функций, получится полная картина того, где выполнены конкретные требования. Независимо от способа обработки требований для ассоциации с модулями, будет возможна проверка существования функции для модуля, который следует добавить на основе дальнейших потребностей пользователей. Такой подход документирует, что имеется определенное количество постоянных требований к разработке системы, которые нужно обрабатывать, и это в целом поможет предотвратить потерю требований, обнаруженную пользователями. [13]
Требования, отображенные на функциональную иерархию. Функциональная иерархия считается законченной, если все запросы из списка требований отображены на нее. Любые функции, не отвечающие требованиям пользователя, должны быть исследованы повторно и в большинстве случаев удалены. Требования, которые не могут быть отображены на существующие функции, приводят к созданию новых функций. [14]
Может показаться, что вследствие большого числа типов производимых батарей выбор подходящего источника питания затруднителен. Однако задачу можно облегчить, если, прежде чем выбирать батарею, предварительно составить примерный список требований, которым она должна удовлетворять. Ниже приводится список тех предварительных данных, которыми необходимо располагать, прежде чем приступить к выбору соответствующего типа батареи. [15]
Страницы: 1 2