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