Difference between revisions of "Test"

From SWEBOK
Jump to: navigation, search
(Subsection)
 
(45 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
{{TOC}}
 
{{Acronyms|{{Acronym|name=GNU|description=GNU is not UNIX}}
 
{{Acronyms|{{Acronym|name=GNU|description=GNU is not UNIX}}
 
{{Acronym|name=eSATA|description=external Serial ATA}}
 
{{Acronym|name=eSATA|description=external Serial ATA}}
 
}}
 
}}
 +
 
{{IntroSection|title=Introduction|body=
 
{{IntroSection|title=Introduction|body=
The Software Requirements knowledge area (KA)
+
{{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
 
It is widely acknowledged amongst researchers
Line 23: Line 24:
 
a term which appears in some of the literature,
 
a term which appears in some of the literature,
 
will not be used either. Instead, the term “software
 
will not be used either. Instead, the term “software
engineer” or, in some specific cases, “require-
+
engineer” or, in some specific cases, “requirements specialist” will be used, the latter where
ments specialist” will be used, the latter where
+
 
the role in question is usually performed by an
 
the role in question is usually performed by an
 
individual other than a software engineer. This
 
individual other than a software engineer. This
Line 50: Line 50:
 
closely to the Software Design, Software Testing,
 
closely to the Software Design, Software Testing,
 
Software Maintenance, Software Configuration
 
Software Maintenance, Software Configuration
Management, Software Engineering Manage-
+
Management, Software Engineering Management, Software Engineering Process, Software
ment, Software Engineering Process, Software
+
 
Engineering Models and Methods, and Software
 
Engineering Models and Methods, and Software
 
Quality KAs.
 
Quality KAs.
Line 60: Line 59:
 
=== Subsection ===
 
=== Subsection ===
  
==== Sub-sub-section ====
+
{{RightSection|{{referenceLink|number=1|parts=c4, c4s1, c10s1, c10s4}}}}
  
__TOC__
+
{{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 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;
 +
* requirements process meaures and benchmarking;
 +
* improvement planning and implementation;
 +
* security/CIA improvement/planning and implementation.
  
 +
Inline text can be rendered in ''italics'' or '''boldface''', as needed.
 +
 +
{{EndSection|title=Further Readings|body=
 +
{{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=
 
{{reference
 
{{reference
 +
|number=1
 
|author=I. Sommerville
 
|author=I. Sommerville
 
|article=
 
|article=
Line 74: Line 87:
 
|part=
 
|part=
 
|link=
 
|link=
}}
+
}}{{reference
 
+
|number=2
{{reference
+
 
|author=INCOSE
 
|author=INCOSE
 
|article=
 
|article=
Line 86: Line 98:
 
|part=
 
|part=
 
|link=
 
|link=
 +
}}{{ReferenceList}}
 
}}
 
}}

Latest revision as of 21:03, 26 July 2015

Acronyms
GNU
GNU is not UNIX
eSATA
external Serial ATA
Introduction

The Software Requirements knowledge area (KA) 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.

It is widely acknowledged amongst researchers and industry practitioners that software projects are critically vulnerable when the requirements-related activities are poorly performed. Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem.

The term “requirements engineering” is widely used in the field to denote the systematic handling of requirements. For reasons of consistency, the term “engineering” will not be used in this KA other than for software engineering per se. For the same reason, “requirements engineer,” a term which appears in some of the literature, will not be used either. Instead, the term “software engineer” or, in some specific cases, “requirements specialist” will be used, the latter where the role in question is usually performed by an individual other than a software engineer. This does not imply, however, that a software engineer could not perform the function.

A risk inherent in the proposed breakdown is that a waterfall-like process may be inferred. To guard against this, topic 2, Requirements Process, is designed to provide a high-level overview of the requirements process by setting out the resources and constraints under which the process operates and which act to configure it.

An alternate decomposition could use a product-based structure (system requirements, software requirements, prototypes, use cases, and so on). The process-based breakdown reflects the fact that the requirements process, if it is to be successful, must be considered as a process involving complex, tightly coupled activities (both sequential and concurrent), rather than as a discrete, one-off activity performed at the outset of a software development project.

The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, Software Engineering Models and Methods, and Software Quality KAs.

1 Section 1

1.1 Subsection

[1, c4, c4s1, c10s1, c10s4]

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 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;
  • requirements process meaures and benchmarking;
  • improvement planning and implementation;
  • security/CIA improvement/planning and implementation.

Inline text can be rendered in italics or boldface, as needed.

Further Readings

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 [5] comprehensively presents software design—including design concepts, architectural design, component-level design, user interface design, pattern-based design, and web application design.

References

[1] I. Sommerville, Software Engineering, 9th ed., Addison-Wesley, 2011.

[2] INCOSE, Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, version 3.2.2, International Council on Systems Engineering, 2012.