commit - ac26fd08856eb09fe1babd88852586d46886c009
commit + bc6d0de8abf55343c514222aa6d01c6c2737ef31
blob - b21b56a9c8eefffa0a0c13212009f3af5bd76303
blob + 36124af1029c7ae91334f75503439d005a4e48b9
--- 10_software_quality.md
+++ 10_software_quality.md
@@ -133,7 +133,7 @@ failure cost).
 такого рода решений должно приниматься процессе работы с требованиями (см.
 область знаний SWEBOK “Программные требования”), однако эти вопросы могут (и
 должны) подниматься на протяжении всего жизненного цикла программного
-обеспечения. Не существует каких-то “стандартных” правил того, как именно
+обеспечения. Не существует каких-то стандартных правил того, как именно
 необходимо принимать такие решения. Однако, инженеры должны быть способны
 представить различные альтернативы (в достижении различного уровня качества) и
 их стоимость. Здесь SWEBOK приводит некоторые источники, в которых более
@@ -144,7 +144,7 @@ failure cost).
 
 В различных источниках (таксономиях и моделях) терминология характеристик
 качества программного обеспечения отличается. Каждая модель включает различное
-число уровней иерархии и общее число ”распознанных” характеристик качества.
+число уровней иерархии и общее число распознанных качества.
 Различные авторы создали разные модели качества со своим набором характеристик
 и атрибутов (в частности, Барри Боэм, автор спиральной модели жизненного цикла
 разработки программного обеспечения, которая рассматривается в отдельной
@@ -742,7 +742,7 @@ SQM обеспечивает сбор информац
 выглядят следующим образом:
 
 - Ошибка (error): “Отличие … между корректным результатом и вычисленным
-результатом полученным с использованием программного обеспечения”
+результатом, полученным с использованием программного обеспечения”
 - Недостаток (fault): “Некорректный шаг, процесс или определение данных в
 компьютерной программе”
 - Сбой (failure): “Некорректный результат, полученный в результате
blob - b59eabc79ca26ddb193b1fe6ebdf1e99242f895b
blob + cf447c9adce42706f7be7524d32a070d45cbf091
--- 1_software_requirements.md
+++ 1_software_requirements.md
@@ -223,7 +223,7 @@ agile-техниках, например, FDD – Feat
 Вигерс, описывает feature как “множество логически связанных функциональных
 требований, которые предоставляют определенные возможности для пользователя и
 удовлетворяют бизнес-целям организации”. С точки зрения маркетинга
-программного обеспечения, как отмечает Вигерс, feature  это «группа требований,
+программного обеспечения, как отмечает Вигерс, feature это «группа требований,
 узнаваемая заинтересованными лицами, которые вовлечены в процесс принятия
 решения по приобретению ПО – это список отличительных особенностей или
 возможностей, характеристик, присутствующий в описании продукта». В то же
@@ -323,7 +323,7 @@ kshell (популярной командной обо
 
 Данное разделение базируется на определении “системы”,
 данном INCOSE (International Council on Systems Engineering) “комбинация
-взаимодействующих элементов созданная для достижения определенных целей;
+взаимодействующих элементов, созданная для достижения определенных целей;
 может включать аппаратные средства, программное обеспечение, встроенное ПО,
 другие средства, людей, информацию, техники (подходы), службы и другие
 поддерживающие элементы”; таким образом, подразумевается, что система является