Страница разрабатывается

Страница разрабатывается

Классификация требований

Agile Requirements Modeling (Effective Practices for eXtreme Programming and the Unified Process)

• The context model
• Use case model
• Use case story board
• Supplementary specification

Этапы работ по сбору и анализу требований

Работа с изменениями требований
Преимущества метода или стандарта
Недостатки метода или стандарта
Техники выявления требований

Страница разрабатывается

Описание стандарта

Данный стандарт устанавливает порядок построения и оформления технического задания на разработку программы или программного изделия для вычислительных машин, комплексов и систем независимо от их назначения и области применения.

Классификация требований

1. Требования к программе или программному изделию:
1.1. Требования к функциональным характеристикам
В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т. п.
1.2. Требования к надежности
В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечения устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т.п.).
1.3. Условия эксплуатации
В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т.п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала.
1.4. Требования к составу и параметрам технических средств
В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их основных технических характеристик.
1.5. Требования к информационной и программной совместимости
В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования и программным средствам, используемым программой.
1.6. Требования к маркировке и упаковке
В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.
1.7. Требования к транспортированию и хранению
В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях.
1.8. Специальные требования

2. Требования к программной документации

Методы сбора требований

не описаны

Страница разрабатывается

Описание стандарта

ГОСТ 34.602-89 описывает рекомендуемые состав и структуру для технического задания по созданию, развитию или модернизации автоматизированных систем.

Классификация требований

Требования к системе
1. Требования к системе в целом:

• требования к структуре и функционированию системы;
• требования к численности и квалификации персонала системы и режиму его работы;
• показатели назначения;
• требования к надежности;
• требования безопасности;
• требования к эргономике и технической эстетике;<
• требования к транспортабельности для подвижных АС;
• требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;
• требования к защите информации от несанкционированного доступа;
• требования по сохранности информации при авариях;
• требования к защите от влияния внешних воздействий;
• требования к патентной чистоте;
• требования по стандартизации и унификации;
• дополнительные требования.

2. Требования к функциям (задачам), выполняемым системой
В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:
1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;
при создании системы в две или более очереди — перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;
2) временной регламент реализации каждой функции, задачи (или комплекса задач);
3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;
4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

3. Требования к видам обеспечения
В подразделе «Требования к видам обеспечения» в зависимости от вида системы приводят требования к математическому, информационному, лингвистическому, программному, техническому, метрологическому, организационному, методическому и другие видам обеспечения системы.

4. Общие требования к приемке работ по стадиям (перечень участвующих предприятий и организаций, место и сроки проведения), порядок согласования и утверждения приемочной документации;
5. Требования к документированию

Методы сбора требований

не описаны

Страница разрабатывается

Описание стандарта/книги

Документ, подготавливаемый комитетом Software Engineering Coordinating Committee, в который вовлечено сообщество IEEE Computer Society. Назначение SWEBOK — в объединении знаний по инженерии программного обеспечения (разработке программного обеспечения).

Классификация требований

Программные требования (Software Requirement)
Требования к продукту и процессу (Product and Process Requirements)

Группа функциональных требований (Functional Requirements)

• Бизнес-требования (Business Requirements) – определяют высокоуровневые цели организации или клиента (потребителя) – заказчика разрабатываемого программного обеспечения.
• Пользовательские требования (User Requirements) – описывают цели/задачи пользователей системы, которые должны достигаться/выполняться пользователями при помощи создаваемой программной системы.
• Функциональные требования (Functional Requirements) – определяют функциональность (поведение) программной системы, которая должна быть создана разработчиками для предоставления возможности выполнения пользователями своих обязанностей в рамках бизнес-требований и в контексте пользовательских требований.

Группа нефункциональных требований (Non-functional Requirements)

• Бизнес-правила (Business Rules) – включают или связаны с корпоративными регламентами, политиками, стандартами, законодательными актами, внутрикорпоративными инициативами (например, стремление достичь зрелости процессов по CMMI 4-го уровня), учетными практиками, алгоритмами вычислений и т.д.
• Внешние интерфейсы (External Interfaces) – часто подменяются “пользовательским интерфейсом”. На самом деле вопросы организации пользовательского интерфейса безусловно важны в данной категории требований, однако, конкретизация аспектов взаимодействия с другими системами, операционной средой (например, запись в журнал событий операционной системы), возможностями мониторинга при эксплуатации – все это не столько функциональные требования (к которым ошибочно приписывают иногда такие характеристики), сколько вопросы интерфейсов, так как функциональные требования связаны непосредственно с функциональностью системы, направленной на решение бизнес-потребностей.
• Атрибуты качества (Quality Attributes) – описывают дополнительные характеристики продукта в различных “измерениях”, важных для пользователей и/или разработчиков. Атрибуты касаются вопросов портируемости, интероперабельности (прозрачности взаимодействия с другими системами), целостности, устойчивости и т.п.
• Ограничения (Constraints) – формулировки условий, модифицирующих требования или наборы требований, сужая выбор возможных решений по их реализации. В частности, к ним могут относиться параметры производительности, влияющие на выбор платформы реализации и/или развертывания (протоколы, серверы приложений, баз данных, …), которые, в свою очередь, могут относиться, например, к внешним интерфейсам.

Потребности (needs) – отражают проблемы бизнеса, персоналии или процесса, которые должны быть соотнесены с использованием или приобретением системы.
Системные требования (System Requirements) – иногда классифицируются как составная часть группы функциональных требований (не путайте с как таковыми “функциональными требованиями”). Описывают высокоуровневые требования к программному обеспечению, содержащему несколько или много взаимосвязанных подсистем и приложений. При этом, система может быть как целиком программной, так и состоять из программной и аппаратной частей. В общем случае, частью системы может быть персонал, выполняющий определенные функции системы, например, авторизация выполнения определенных операций с использованием программно-аппаратных подсистем.
Независимые свойства (Emergent Properties) – требования, которые не могут быть адресованы тому или иному компоненты программной системы, но которые должны быть соблюдены, например, в контексте сетевой инфраструктуры или регламентов работы пользователей.
Требования с количественной оценкой (Quantifiable Requirements) – требования, поддающиеся количественному определению/измерению, например, система должна обеспечить пропускную способность “столько-то запросов в секунду”; в то же самое время, крайне важно понимать, что постановка вопроса (то есть формулирование требования) в форме “система должна обеспечить рост пропускной способности” без указания конкретных количественных характеристик является просто некорректно определенным требованием.
Системные требования и программные требования (System Requirements and Software Requirements) – данное разделение базируется на определении “системы”, данном INCOSE (International Council on Systems Engineering) “комбинация взаимодействующих элементов <созданная> для достижения определенных целей; может включать аппаратные средства, программное обеспечение, встроенное ПО, другие средства, людей, информацию, техники (подходы), службы и другие поддерживающие элементы”; таким образом, подразумевается, что система является более ёмким понятием, чем программное обеспечения и включает окружение, в котором функционирует ПО, как таковое; отсюда, естественным образом, вытекают требования к системе в целом и программному обеспечению (или программной системе), в частности. Часто в литературе по управлению требованиями встречается описание системных требований как “пользовательских требований” (user requirements), SWEBOK ограничивает применение понятия “пользовательское требование” требованиями к системе конечных пользователей/заказчиков. Системные требования по SWEBOK, в свою очередь, окружают пользовательские требования (или требования других заинтересованных лиц – stakeholders, например, регулирование полномочий) без указания идентифицируемого источника-человека.

Требования к качеству программного обеспечения (Software Quality Requirements)

• Факторы влияния (Influence factors)
• Гарантоспособность (Dependability)
• Уровни целостности программного обеспечения (Integrity levels of software)
• Характеристика дефектов (Defect Characterization)

Методы сбора требований

• Интервьюрирование – традиционный подход извлечения требований; не стоит забывать, что получение информации от пользователя “не равно” получению требований; информация должна быть проанализирована и трансформирована в требования, таким образом, информация от пользователя является “входом” в процессы сбора требований, а сами требования – “выходом” этих процессов;
• Сценарии – контекст для сбора пользовательских требований, определяющий ответы на вопросы “что если” и “как это делается” в отношении бизнес-процессов, реализуемых пользователями;
• Прототипы – отличный инструмент для уточнения и/или детализации требований; существуют разные подходы к прототипированию – от “бумажных” моделей до пилотных подсистем, реализуемых как самостоятельные (в терминах управления ресурсами) проекты или бета-версии продуктов; часто прототипы постепенно трансформируются в результаты проекта и используются для проверки и утверждения требований;
• “Разъясняющие встречи” — в оригинале звучит как “facilitated meetings”; достаточно емкий по смыслу термин, пришедший из общей практики менеджмента и базирующийся на идеях сотрудничества заинтересованных лиц для совместного анализа путей решения проблем, определения и предупреждения рисков и т.п. В отличие от “обычного”, с позволения сказать, “мозгового штурма”, как исключительной формы обсуждения тех или иных задач (часто в критические моменты работ над проектом), “запланированный мозговой штурм” – особая форма встреч участников проекта и заинтересованных лиц со стороны заказчика, посвященная обсуждению тех вопросов, ответы на которые не могут быть определены в результате обычных интервью и которые требуют вовлечения большего количества лиц, чем просто пары “пользователь-аналитик”; я позволили себе сконструировать на русском языке этот термин еще и как “запланированный мозговой штурм”, так как такого рода встречи действительно обычно планируются с заданной периодичностью для обеспечения однозначности интерпретации информации, значимой для проекта и, что очень важно – проведения таких встреч до того, как связанные с данными вопросами риски не превратились в реальные проблемы, требующие решения “вчера”, а, следовательно, и дополнительных (изначально незапланированных) ресурсов времени, денег и т.д.;
• Наблюдение (observation) – подразумевает непосредственное присутствие аналитиков и инженеров рядом с пользователем в процессе выполнения последним его работ по обеспечению функционирования бизнес-процессов: в определенной степени можно провести аналогию с практикой присутствия представителя заказчика в проектной группе исполнителя ( типовая практика в eXtreme Programming “on-site customer” – “присутствующий заказчик”); данная техника является достаточно затратной, но, в то же время, очень эффективной, а иногда – просто незаменимой, особенно, если речь идет о достаточно сложных и взаимосвязанных бизнес-процессах;

Страница разрабатывается

CMM. Различные области специализации

— SW-CMM (Capability Maturity Model for Software) — модель зрелости возможностей создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение.
— SE-CMM (Systems Engineering CMM) describes the essential elements of an organization’s systems engineering process that must exist to ensure good systems engineering. It does not specify a particular process or sequence. In addition, the SE-CMM provides a reference for comparing actual systems engineering practices against these essential systems.
— People CMM (Developing human talent) is a maturity framework that focuses on continuously improving the management and development of the human assets of an organization. It describes an evolutionary improvement path from ad hoc, inconsistently performed practices, to a mature, disciplined, and continuously improving development of the knowledge, skills, and motivation of the workforce that enhances strategic business performance. The People Capability Maturity Model (People CMMI) is a framework that helps organizations successfully address their critical people issues.
— SA-CMM (Software Acquisition CMM) is a model for benchmarking and improving the software acquisition process. The model follows the same architecture as the Capability Maturity Model for Software (SW-CMM), but with a unique emphasis on acquisition issues and the needs of individuals and groups who are planning and managing software acquisition efforts.
— TS-CMM (Trusted Software, tailored CMM) defined levels of trust, with lower trust levels emphasizing resistance to unintentional vulnerabilities and higher trust levels adding processes to counter malicious developers.
— IPD-CMM (Integrated Product Development)
— CMMI (CMM Integration) — набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определённых областей деятельности. Набор моделей CMMI включает три модели: CMMI for Development (CMMI-DEV), CMMI for Services (CMMI-SVC) и CMMI for Acquisition (CMMI-ACQ). Наиболее известной является модель CMMI for Development, ориентированная на организации, занимающиеся разработкой программного обеспечения, аппаратного обеспечения, а также комплексных систем.

Классификация требований

Requirement — (1) A condition or capability needed by a user to solve a problem or achieve an objective. (2) A condition or capability that must be met or possessed by a product, service, product component, or service component to satisfy a supplier agreement, standard, specification, or other formally imposed documents. (3) A documented representation of a condition or capability as in (1) or (2).

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

Nontechnical requirements — Requirements affecting product and service acquisition or development that are not properties of the product or service. Contractual provisions, commitments, conditions, and terms that affect how products or services are to be acquired. Examples include products to be delivered, data rights for delivered commercial off-the-shelf (COTS) nondevelopmental items (NDIs), delivery dates, and milestones with exit criteria. Other nontechnical requirements include training requirements, site requirements, and deployment schedules.
Technical requirements — Properties (attributes) of products or services to be acquired or developed.
Customer requirement — The result of eliciting, consolidating, and resolving conflicts among the needs, expectations, constraints, and interfaces of the product’s relevant stakeholders in a way that is acceptable to the customer.
Product component requirements — A complete specification of a product or service component, including fit, form, function, performance, and any other requirement.
Product requirements — A refinement of customer requirements into the developers’ language, making implicit requirements into explicit derived requirements.

Security Requirements

Методы сбора требований

Examples of techniques to elicit needs include the following:
Technology demonstrations — Демонстрация технологий
Interface control working groups
Technical control working groups
Interim project reviews
Questionnaires, interviews, and operational scenarios obtained from end users — Анкеты, интервью и сценарии операций, полученные от конечных пользователей
Operational walkthroughs and end-user task analysis — Операционные пошаговые руководства и анализ задач конечного пользователя
Prototypes and models — Прототипы и модели
Brainstorming — Мозговой штурм
Quality Function Deployment — Разработка функции качества
Market surveys — Исследования рынка
Beta testing — Бета-тестирование
Extraction from sources such as documents, standards, or specifications — Извлечение из источников, таких как документы, стандарты или спецификации
Observation of existing products, environments, and workflow patterns — Наблюдение за существующими продуктами, средой и шаблонами рабочих процессов
Use cases — Варианты использования
Business case analysis — Анализ бизнес-кейсов
Reverse engineering (for legacy products) — Реверсивное проектирование (для устаревших продуктов)
Customer satisfaction surveys — Исследования удовлетворенности клиентов

Examples of sources of requirements that might not be identified by the customer include the following:
Business policies
Standards
Business environmental requirements (e.g., laboratories, testing and other facilities, and information technology infrastructure)
Technology
Legacy products or product components (reuse product components)

Страница разрабатывается

Описание стандарта

IT Infrastructure Library — библиотека инфраструктуры информационных технологий, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий.

Классификация требований

Требование — Формальное заявление о необходимости чего-либо.

Требование к уровню услуг (SLR) — представляют собой детальное описание потребностей заказчика, они используются при разработке, модификации и инициировании услуг. Такие требования можно использовать в качестве прототипа (кальки) для разработки услуги и соответствующего ей Соглашения об Уровне Сервиса (SLA), а также как проектное задание (design assignment).
Service Level Requirements (SLR) — The Service Level Requirements document contains the requirements for a service from the client viewpoint, defining detailed service level targets, mutual responsibilities, and other requirements specific to a certain (group of) customers. As the service enters new stages of its life cycle, the SLR document evolves into a draft Service Level Agreement.

Detailed Requirements Specification:

• Functional requirements
  (the SLR document contains a summary description of the desired customer outcome; however, functional requirements may need to be specified in greater detail, especially if new applications/ systems are to be developed)
• Information security requirements
  (Information security requirements which are relevant for the service)
• Compliance requirements
  (Compliance requirements which are relevant for the service)
• Architectural constraints
  (e.g. specific technology or vendors)
• Interface requirements
  (e.g. if a new system needs to communicate with other systems)
• Migration requirements
  (e.g. if data are to be migrated from an existing to a new application)
• Operational requirements
  (e.g. requirements for backup and restore mechanisms, compatibility with existing system monitoring tools
• Required access rights
  (which users or user groups will require access to the service, and what levels of access must be provided)

Проектная документация услуги (SDP) должна содержать:
Требования бизнеса — Первоначальные согласованные и запротоколированные требования бизнеса.
Функциональные требования к услуге — Функциональность новой услуги или модернизированная функциональность измененной услуги, включая ее планируемые выходные значения и комплект поставки, в форме согласованного документа под названием «Набор требований» (Statement of Requirements, SoR).
Требования к уровням услуги — «Требования к уровню услуг» (SLR), переработанное или новое SLA, включая целевые значения показателей качества услуги.
Требования к управлению услугой и ее эксплуатации — Управленческие требования, необходимые для предоставления новой или измененной услуги и управления ее компонентами, включая все вспомогательные услуги и соглашения, методики контроля, эксплуатации, мониторинга, измерения и получения отчетности.

Требования в договорах:
Требования по безопасности
Требования по обеспечению непрерывности бизнеса

Типы требований из документа ITIL V3 2011 Service Design SD:
— Functional requirements. For a service these requirements are those necessary to support a particular business function, business process or to remove a customer or user constraint. These requirements describe the utility aspects of a service.
— Management and operational requirements (sometimes referred to as non-functional requirements). These define the requirements and constraints on the service and address the need for a responsive, available and secure service, and deal with such issues as ease of deployment, operability, management needs and security. These requirements describe the warranty aspects of a service.
— Usability requirements. These requirements are those that relate to how easy it is for the user to access and use the service to achieve the desired outcomes, including addressing the ‘look and feel’ needs of the user. This requirement type is often seen as part of management and operational requirements, but for the purposes of this section it will be addressed separately. Depending on the context, these requirements enable utility, support warranty and influence user perceptions of a service.

Методы сбора требований

Interviews — Интервью
Workshops — Семинары по сбору требований
Observation — Наблюдение
Protocol analysis — Анализ протоколов
Shadowing — «Слежка» за опытным сотрудником
Scenario analysis — Сценарный анализ
Prototyping — Прототипирование
Other techniques — Questionnaires, Special-purpose records, Activity sampling — Другие методы — Анкеты, записи специального назначения, разбор отдельных деятельностей

Страница разрабатывается

Описание стандарта

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

Классификация требований

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

Stakeholder Requirement

User requirements (within the context of the StRS) include required inputs/selections/information observations which users/operators/maintainers need to perform through the use of the system; any outputs they require from the system in order to perform these tasks; and any applicable conditions or constraints governing their interaction with (i.e., usability of) the system. These requirements are then used to describe the operational scenarios which specify how to meet these requirements when interacting with the system.

System Requirement

Functional requirements — Define functional requirements applicable to system operation.
Usability requirements — Define usability (quality in use) requirements. Usability requirements and objectives for the system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use.
Performance requirements — Define the critical performance conditions and their associated capabilities by including such considerations as
a) Dynamic actions or changes that occur (e.g., rates, velocities, movements, and noise levels).
b) Quantitative criteria covering endurance capabilities of the equipment required to meet the user needs under stipulated environmental and other conditions, including minimum total life expectancy. Indicate required operational session duration and planned utilization rate.
c) Performance requirements for the operational phases and modes.
System interfaces — Specify requirements for interfaces among system elements and with external entities. Interfaces among system elements should include interfaces with the human element. Interfaces with external entities should include other systems.
Human system integration requirements — Reference applicable documents and specify any special or unique requirements, e.g., constraints on allocation of functions to personnel and communications and personnel/equipment interactions. Define any specific areas, stations, or equipment that would require concentrated human engineering attention due to the sensitivity of the operation or criticality of the task (i.e., those areas where the effects of human error would be particularly serious).
Maintainability — Specify the quantitative maintainability requirements that apply to maintenance in the planned maintenance and support environment. Examples are as follows:
a) Time (e.g., mean and maximum downtime, reaction time, turnaround time, mean and maximum times to repair, mean time between maintenance actions)
b) Rate (e.g., maintenance staff hours per specific maintenance action, operational ready rate, maintenance time per operating hour, frequency of preventative maintenance)
c) Maintenance complexity (e.g., number of people and skill levels, variety of support equipment, removing/replacing/repairing components)
d) Maintenance action indices (e.g., maintenance costs per operating hour, staff hours per overhaul)
e) Accessibility to components within systems and to parts within components
Reliability — Specify the system reliability requirements in quantitative terms, including the conditions under which the reliability requirements are to be met. This may also include the reliability apportionment model to support allocation of reliability values assigned to system functions for their share in achieving desired system reliability.
System modes and states — If the system can exist in various modes or states define these and, as appropriate, use diagrams.
Physical requirements — Include constraints on weight, volume and dimension. Include the construction characteristics of where the system will be installed, requirements for materials to be used in the item or service covered by this specification, and requirements covering nameplates and system markings, interchangeability of equipment, and workmanship.
Adaptability requirements — Define requirements for growth, expansion, capability, and contraction. For example, if the system will require future network bandwidth, the applicable hardware should be specified with extra card slots to accommodate new network cards as demand increases.
Environmental conditions — Include environmental conditions to be encountered by the system. The following areas should be addressed: natural environment (e.g., wind, rain, temperature, flora, fauna, fungus, mold, sand, salt spray, dust, radiation, chemical, and immersion); induced environment (e.g., motion, shock, noise, electromagnetic, thermal); electromagnetic signal environment; self-induced environment (e.g., motion, shock, noise, electromagnetic, thermal); threat; and cooperative environment. Consideration should also be given to legal/regulatory, political, economic, social, and business environment.
System security — Define the system security requirements related to both the facility that houses the system and operational security requirements of the system itself. One example of security requirements might be to specify the security and privacy requirements, including access limitations to the system, such as existence of log-on procedures and passwords, and of data protection and recovery methods. This could include the factors that would protect the system from accidental or malicious access, use, modification, destruction, or disclosure. Especially in safety-critical embedded systems this might incorporate a distributed log or history of data sets, the assignment of certain functions to different single systems, or the restriction of communications between some areas of the system.
Information management — Define the requirements for the system’s management of information that it receives, generates, or exports. Examples include types and amounts of information the system is required to receive and store, any proprietary or other protections levied on the information the system deals with, and what backup and archiving requirements exist for the information.
Policies and regulations — Detail any relevant organizational policies that will affect the operation or performance of the system as well as any relevant external regulatory requirements, or constraints imposed by normal business practices. Examples of requirements include multilingual support, labour policies, protection of personnel information, and reports to a regulatory agency. Specify health and safety criteria, including those basic to the design of the system, with respect to equipment characteristics, methods of operation, and environmental influences such as toxic systems and electromagnetic radiation.
System life cycle sustainment — Outline quality activities, such as review, and measurement collection and analysis, to help realize a quality system. Life cycle sustainment also includes provision of facilities needed to provide operational- and depotlevel support, spares, sourcing and supply, provisioning, technical documentation and data, support-personnel training, initial cadre training and initial contractor-logistics support.
Packaging, handling, shipping and transportation — Define requirements imposed on the system to ensure that it can be packaged, handled, shipped and transported within its intended operational context.

Software Requirement

Specific requirements — Specify all of the software requirements to a level of detail sufficient to enable designers to design a software system to satisfy those requirements.
External interfaces — Define all inputs into and outputs from the software system. The description should complement the interface descriptions in 9.5.3.3.1 through 9.5.3.3.5, and should not repeat information there. Each interface defined should include the following content:
a) Name of item;
b) Description of purpose;
c) Source of input or destination of output;
d) Valid range, accuracy, and/or tolerance;
e) Units of measure;
f) Timing;
g) Relationships to other inputs/outputs;
h) Screen formats/organization;
i) Window formats/organization;
j) Data formats;
k) Command formats;
l) Endmessages.
Functions — Define the fundamental actions that have to take place in the software in accepting and processing the inputs and in processing and generating the outputs, including
a) Validity checks on the inputs
b) Exact sequence of operations
c) Responses to abnormal situations, including
1) Overflow
2) Communication facilities
3) Error handling and recovery
d) Effect of parameters
e) Relationship of outputs to inputs, including
1) Input/output sequences
2) Formulas for input to output conversion
It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does not imply that the software design will also be partitioned that way.
Usability requirements — Define usability (quality in use) requirements. Usability requirements and objectives for the software system include measurable effectiveness, efficiency, and satisfaction criteria in specific contexts of use.
Performance requirements — Specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole. Static numerical requirements may include the following:
a) The number of terminals to be supported;
b) The number of simultaneous users to be supported;
c) Amount and type of information to be handled.
Static numerical requirements are sometimes identified under a separate section entitled Capacity.
Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.
The performance requirements should be stated in measurable terms. For example, 95 % of the transactions shall be processed in less than 1 second. rather than, An operator shall not have to wait for the transaction to complete.
Logical database requirements — Specify the logical requirements for any information that is to be placed into a database, including:
a) Types of information used by various functions;
b) Frequency of use;
c) Accessing capabilities;
d) Data entities and their relationships;
e) Integrity constraints;
f) Data retention requirements.
Design constraints — Specify constraints on the system design imposed by external standards, regulatory requirements, or project limitations.
Standards compliance — Specify the requirements derived from existing standards or regulations, including:
a) Report format;
b) Data naming;
c) Accounting procedures;
d) Audit tracing.
For example, this could specify the requirement for software to trace processing activity. Such traces are needed for some applications to meet minimum regulatory or financial standards. An audit trace requirement may, for example, state that all changes to a payroll database shall be recorded in a trace file with before and after values.
Software system attributes — Specify the required attributes of the software product. The following is a partial list of examples:
a) Reliability — Specify the factors required to establish the required reliability of the software system at time of delivery.
b) Availability — Specify the factors required to guarantee a defined availability level for the entire system such as checkpoint, recovery, and restart.
c) Security — Specify the requirements to protect the software from accidental or malicious access, use modification, destruction, or disclosure. Specific requirements in this area could include the need to:
1) Utilize certain cryptographic techniques;
2) Keep specific log or history data sets;
3) Assign certain functions to different modules;
4) Restrict communications between some areas of the program;
5) Check data integrity for critical variables;
6) Assure data privacy.
d) Maintainability — Specify attributes of software that relate to the ease of maintenance of the software itself. These may include requirements for certain modularity, interfaces, or complexity limitation. Requirements should not be placed here just because they are thought to be good design practices.
e) Portability — Specify attributes of software that relate to the ease of porting the software to other host machines and/or operating systems, including:
1) Percentage of elements with host-dependent code;
2) Percentage of code that is host dependent;
3) Use of a proven portable language;
4) Use of a particular compiler or language subset;
5) Use of a particular operating system.

Методы сбора требований

• Structured workshops with brainstorming — Структурированные семинары с мозговым штурмом
• Interviews, questionnaires — Интервью, анкеты
• Observation of environment or work patterns (e.g., time and motion studies) — Наблюдение за окружающей средой или рабочими шаблонами (например, исследование времени и движения)
• Technical documentation review — Обзор технической документации
• Market analysis or competitive system assessment — Анализ рынка или оценка конкурентности системы
• Simulations, prototyping, modelling — Симуляция, прототипирование, моделирование
• Benchmarking processes and systems — Бенчмаркинг процессов и систем
• Organizational analysis techniques (e.g., Strength – Weakness – Opportunity — Threat analysis, product portfolio) — Метод организационного анализа (например, SWOT-анализ, анализ портфеля продуктов)

Страница разрабатывается

Описание стандарта

Профессиональный стандарт/свод знаний по бизнес-анализу, разрабатываемая международным институтом бизнес-анализа IIBA в Канаде.

Классификация требований

Требование — это:
1. Условие или возможность, необходимые заинтересованной стороне для решения проблемы или достижения цели.
2. Условие или возможность, которые должны быть выполнены или которыми должно обладать решение/компоненты решения для удовлетворения контракта, стандарта, спецификации или других официальных документов.
3. Документированное представление условий или возможностей, как в (1) или (2).

Бизнес-требования — это высокоуровневые формулировки целей, задач и потребностей предприятия. Они описывают причины, по которым был инициирован проект, задачи, которые будут достигнуты в ходе проекта, а также метрики, которые будут использоваться для измерения его успешности. Бизнес-требования описывают потребности организации в целом, а не группы или заинтересованных в нем сторон. Они разработаны и определены на основе анализа предприятия.

Требования заинтересованных сторон — это формулирование нужд конкретного заинтересованного лица или класса заинтересованных лиц. Эти требования описывают потребности, которые описывают что заинтересованная сторона имеет и как эта заинтересованная сторона будет взаимодействовать с решением. Требования заинтересованных сторон служит в качестве моста между бизнес-требованиями и другими классами требований к решению. Они разработаны и определены на основе анализа требований.

Требования к решению описывают характеристики к решению, которые соответствуют бизнес-требованиям и требованиям заинтересованных сторон. Они разработаны и определены на основе анализа требований. Их часто делят на подкатегории, особенно в случаях, когда требования описывают программное решение:

• Функциональные требования описывают поведение решения и информацию о том, чем оно будет управлять. Эти требования описывают возможности системы, которые доступны к выполнению, в части режимов работы или операций — действия или реакции конкретного ИТ-приложения.
• Нефункциональные требования фиксируют условия, которые напрямую не относятся к поведению или функциональности решения, а скорее описывают условия окружающей (внешней) среды, в условиях которой решение должно сохранять эффективность и качества, которыми система должна обладать. Они также известны как требования качества или дополнительные требования. Они могут включать в себя требования, связанные с мощностью (емкостью), скоростью, безопасностью, доступностью, информационной архитектурой и пользовательским интерфейсом.

Переходные требования описывают возможности, которыми решения должно обладать для осуществления перехода из текущего состояния предприятия к желаемому (требуемому) состоянию в будущем. Эти требования статут ненужными, как только этот переход завершится. Они отличаются от других типов требований, потому что они всегда носят временный характер и потому, что они не могут быть разработаны, пока оба решения, существующее и новое, не будут определены. Как правило, они охватывают преобразование данных из существующих систем, пробелы в знаниях и квалификации, которые должны быть решены, а также другие соответствующие изменения, необходимые для достижения желаемого будущего состояния. Их разрабатывают и определяют посредством проведения оценки и валидации (проверки) решения.

Методы сбора требований

Brainstorming — Мозговой штурм

Document Analysis — Анализ документов

Focus Groups — Фокус-группы

Interface Analysis — Анализ интерфейсов

Interviews — Интервью

Observation — Наблюдение

Prototyping — Прототипирование

Requirements Workshops — Семинары по сбору требований

Survey/Questionnaire — Анкетирование