Функциональные и нефункциональные инженерные требования

Технико-экономическое обоснование
Технико-экономическое обоснование — это краткое целенаправленное исследование, которое необходимо провести в начале процесса ВИЭ. Он должен отвечать на три ключевых вопроса: (1) Способствует ли система достижению общих целей организации? (2) Можно ли внедрить систему в рамках графика и бюджета с использованием современных технологий? и (3) Можно ли интегрировать систему с другими используемыми системами?
Если нет ответа ни на один из этих вопросов, вам, вероятно, не стоит продолжать проект.
http://softwareengineering-book.com/web/feasibility-study/ _
подтверждение приемлемости системы. Например, для системы Mentcare к заинтересованным сторонам системы относятся:

1. 
   Пациенты, данные которых зарегистрированы в системе, и родственники этих пациентов.
   
2. 
   Врачи, ответственные за оценку и лечение пациентов.
   
3. 
   Медсестры, координирующие консультации с врачами и выполняющие некоторые процедуры.
   
4. 
   Медицинские приемные, которые ведут прием пациентов.
   
5. 
   ИТ-персонал, отвечающий за установку и обслуживание системы.
   
6. 
   Менеджер по медицинской этике ­должен убедиться, что система соответствует текущим этическим принципам ухода за пациентами.
   
7. 
   Менеджеры здравоохранения, которые получают управленческую информацию из системы.
   
8. 
   Медицинский персонал, ответственный за ведение и поддержание системной информации и обеспечение надлежащего выполнения процедур ведения документации.
   

Разработка требований обычно представляется как первый шаг в процессе создания программного обеспечения. Однако может возникнуть необходимость в некотором понимании системных требований, прежде чем принимать решение о покупке или разработке системы. Этот начальный RE устанавливает высокий уровень видимости того, что система может сделать, и преимущества, которые она может предоставить. Затем ­их можно рассматривать на основе осуществимости, которая направлена на оценку того, является ли система технически и финансово осуществимой. Результаты этого исследования помогут руководству принять решение о продолжении покупки или развитии системы.
Я даю «традиционный» взгляд на требования, а не на требования быстрых процессов, которые я выполняю. Для многих ­крупных систем все еще существует этап разработки требований, которые можно четко определить. начинается внедрение системы. Результатом является документ с требованиями, который может быть частью контракта на разработку системы. Конечно, требования будут изменены, а требования пользователей могут быть расширены более подробно . Системные Требования. Иногда быстрый подход к определению требований одновременно с разработкой системы может быть использован для добавления деталей и улучшения пользовательских требований.
Системные требования к программному обеспечению часто классифицируются как функциональные или нефункциональные требования:
Функциональные требования — это услуги, которые должна предоставлять система, утверждения о том, как система должна реагировать на определенную информацию и как система должна вести себя в определенных ситуациях. В некоторых случаях функциональные ­требования могут также указывать, чего система не должна делать.
Нефункциональные требования Это ограничения на услуги или функции, предлагаемые системой. К ним относятся временные ограничения, ограничения на ­процесс разработки и ограничения, налагаемые стандартами. Нефункциональные требования часто относятся к системе в целом, а не к отдельным функциям или службам системы.
На самом деле разница между различными типами требований ­не так очевидна, как предполагают эти четкие определения. Пользовательский запрос, связанный с безопасностью, например, заявление об ограничении доступа для авторизованных пользователей, может показаться неработающим требованием. Однако при более подробной разработке это требование может привести к другим требованиям, явно функциональным, таким как необходимость добавления в систему средств аутентификации пользователей.
Это указывает на то, что требования не являются независимыми и что одно требование часто порождает или ограничивает другие требования. Таким образом, системные требования отражают не только услуги или функции, требуемые от системы; они также определяют функциональные возможности, необходимые для обеспечения эффективного предоставления этих услуг/функций.
Функциональные требования
Функциональные требования к системе описывают, что система должна делать. Эти требования зависят от типа разрабатываемого программного обеспечения, пользователей, ожидаемых от программного обеспечения, и общего подхода, используемого организацией при написании требований. При выражении в виде пользовательских требований функциональные требования ­должны быть написаны на естественном языке для понимания пользователями системы и менеджерами. Функциональные системные требования расширяют требования пользователей и написаны для разработчиков системы. Они должны подробно описывать системные функции, их входы и выходы, а также исключения.
Функциональные системные требования варьируются от общих требований к тому, что система должна делать, до очень конкретных требований, которые отражают местные методы работы или существующие системы организации. Например, вот функциональные примеры