Программные проекты можно разбить на три группы: управляемые пользователем, контролируемые пользователем и независимые от пользователя [2]. Последние в данном учебном пособии рассматриваться не будут. Наиболее оптимален проект, контролируемый пользователем. Но, безусловно, желательно и участие в этом процессе организации-разработчика ПО. Если в управляемом пользователем проекте разработчик ПО не привлечен к определению требований, это увеличивает его шансы неправильно понять или неправильно интерпретировать требования. И управляемые пользователем, и не зависимые от пользователя проекты должны планироваться таким образом, чтобы обеспечить участие обеих сторон.
Требования к системе должны разрабатываться небольшой группой. Один участник этой группы должен быть основным представителем организации-пользователя, наделенным достаточными полномочиями, чтобы принять решения. Отметим, однако, что он обычно не является настоящим пользователем системы. Поэтому вторым членом группы должен быть человек, который действительно будет пользоваться системой. Например, при разработке требований к системе резервирования авиабилетов им должен быть опытный кассир. Организация-разработчик также должна быть представлена в этой группе. Одним из ее представителей должен быть человек, который, в конечном счете, будет играть главную роль в процессе внешнего проектирования. Другим членом группы должен быть тот, кто будет играть ключевую роль в одном из процессов внутреннего проектирования. Что касается надежности, здесь ставится цель обеспечить максимально возможную аккуратность и точность в определении требований пользователя, чтобы организация-разработчик ПО могла транслировать эти требования в проект с минимальным числом ошибок.
О методах проверки правильности требований можно сказать, что пользователь несет ответственность за проверку требований на полноту и точность, а разработчик – на проверку осуществимости и понятности. В процессе проверки требований желательно установить приоритеты для каждого из них, чтобы помочь разработчику ПО принимать компромиссные решения на следующих этапах проектирования.
Разработка лабораторной работы, описанной в подразд. 3.2., относится к проектам, контролируемым пользователем, причем в качестве пользователя выступают преподаватели, которые будут использовать данную лабораторную работу в своих курсах.
