Test - Revision history

Daniel Robbins: /* Subsection */

2015-07-26T21:03:33Z

‎Subsection

Daniel Robbins: /* Subsection */

2015-07-26T21:01:15Z

‎Subsection

Daniel Robbins: /* Subsection */

2015-07-26T21:01:01Z

‎Subsection

Daniel Robbins: /* Subsection */

2015-07-26T21:00:09Z

‎Subsection

Daniel Robbins at 20:51, 26 July 2015

2015-07-26T20:51:19Z

Daniel Robbins at 20:49, 26 July 2015

2015-07-26T20:49:47Z

Daniel Robbins at 20:49, 26 July 2015

2015-07-26T20:49:21Z

Daniel Robbins: /* Section 1 */

2015-07-26T20:48:58Z

‎Section 1

Daniel Robbins: /* Subsection */

2015-07-26T20:38:33Z

‎Subsection

Daniel Robbins: /* Subsection */

2015-07-26T20:37:56Z

‎Subsection

@@ Line 73: / Line 73: @@
 {{EndSection|title=Further Readings|body=
-For roughly three decades, Roger Pressman’s Software Engineering: A Practitioner’s Approach has been one of the world’s leading textbooks in software engineering. Notably, this complementary textbook to {{ReferenceLink|number=5}} comprehensively presents software design—including design concepts, architectural design, component-level design, user interface design, pattern-based design, and web application design.
+{{NoIndent|For roughly three decades, Roger Pressman’s Software Engineering: A Practitioner’s Approach has been one of the world’s leading textbooks in software engineering. Notably, this complementary textbook to {{ReferenceLink|number=5}} comprehensively presents software design—including design concepts, architectural design, component-level design, user interface design, pattern-based design, and web application design.
-}}
+}}}}
 {{EndSection|title=References|body=

@@ Line 63: / Line 63: @@
 {{NoIndent|1=
 This document (sometimes known as the user requirements document or concept of operations
-document) records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers (marketing may play these roles for market-driven software), so its content must be couched in terms of the domain. The document lists the system requirements along with background information about the overall objectives
+document) records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers (marketing may play these roles for market-driven software), so its content must be couched in terms of the domain. The document lists the system requirements along with background information about the overall objectives for the system, its target environment, and a statement of the constraints, assumptions, and nonfunctional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios, and the principal domain entities, aswell as workflows.}}
 for the system, its target environment, and a statement of the constraints, assumptions, and nonfunctional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios, and the principal domain entities, aswell as workflows.}}
 * requirements process coverage by process improvement standards and models;

@@ Line 62: / Line 62: @@
 {{NoIndent|1=
-This document (sometimes known as the user
+This document (sometimes known as the user requirements document or concept of operations
-requirements document or concept of operations
+document) records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers (marketing may play these roles for market-driven software), so its content must be couched in terms of the domain. The document lists the system requirements along with background information about the overall objectives
-document) records the system requirements. It
+for the system, its target environment, and a statement of the constraints, assumptions, and nonfunctional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios, and the principal domain entities, aswell as workflows.}}
 defines the high-level system requirements from
 the domain perspective. Its readership includes
 representatives of the system users/customers
 (marketing may play these roles for market-driven software), so its content must be couched
 in terms of the domain. The document lists the
 system requirements along with background
 information about the overall objectives for the
 system, its target environment, and a statement of
 the constraints, assumptions, and nonfunctional
 requirements. It may include conceptual models
 designed to illustrate the system context, usage
-scenarios, and the principal domain entities, as
-well as workflows.}}
 * requirements process coverage by process improvement standards and models;

@@ Line 61: / Line 61: @@
 {{RightSection|{{referenceLink|number=1|parts=c4, c4s1, c10s1, c10s4}}}}
-{{NoIndent|This document (sometimes known as the user
+{{NoIndent|1=
 requirements document or concept of operations
 document) records the system requirements. It

@@ Line 3: / Line 3: @@
 {{Acronym|name=eSATA|description=external Serial ATA}}
 }}
 {{IntroSection|title=Introduction|body=
 {{NoIndent|The Software Requirements knowledge area (KA)

@@ Line 5: / Line 5: @@
 {{IntroSection|title=Introduction|body=
 {{NoIndent|The Software Requirements knowledge area (KA)
-is concerned with the elicitation, analysis, specification, and validation of software requirements
+is concerned with the elicitation, analysis, specification, and validation of software requirements as well as the management of requirements during the whole life cycle of the software product.}}
 as well as the management of requirements during the whole life cycle of the software product.}}
 It is widely acknowledged amongst researchers

@@ Line 82: / Line 82: @@
 * improvement planning and implementation;
 * security/CIA improvement/planning and implementation.
 {{EndSection|title=Further Readings|body=