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

Рисунок 4.6. Технические требования
Цели процесса идентификации требований состоят в том, чтобы понять работу, которую выполняют заинтересованные стороны, и то, как они могут использовать новую систему для поддержки этой работы. В процессе определения требований инженеры-программисты работают с заинтересованными сторонами, чтобы ­получить информацию о предметной области, производительности, службах и функциях системы, требуемых заинтересованными сторонами, требуемой производительности системы, аппаратных ограничениях и многом другом.
Система представляет собой сложный процесс для получения и понимания требований от заинтересованных сторон по нескольким причинам:

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

Рисунок 4.7 Процесс идентификации и анализа требований

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

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

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

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