Difference between revisions of "Chapter 2: Software Design"

From SWEBOK
Jump to: navigation, search
(Created page with "{{TOC}} {{Acronyms|{{Acronym|name=ADL|description=Architecture Description Language}} {{Acronym|name=CBD|description=Component-Based Design}} {{Acronym|name=CRC|description=Cl...")
 
Line 9: Line 9:
 
{{Acronym|name=OO|description=Object-Oriented}}
 
{{Acronym|name=OO|description=Object-Oriented}}
 
{{Acronym|name=PDL|description=Program Design Language}}
 
{{Acronym|name=PDL|description=Program Design Language}}
 +
}}
 +
 +
{{IntroSection|title=Introduction|body=
 +
{{NoIndent|The Software Requirements knowledge area (KA)
 +
is concerned with the elicitation, analysis, speci
 +
-
 +
fication, and validation of software requirements
 +
as well as the management of requirements dur
 +
-
 +
ing 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,  “require
 +
-
 +
ments 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 prod
 +
-
 +
uct-based  structure  (system  requirements,  soft
 +
-
 +
ware 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  Manage
 +
-
 +
ment, Software Engineering Process, Software
 +
Engineering Models and Methods, and Software
 +
Quality KAs.
 
}}
 
}}

Revision as of 20:17, 20 August 2015


Acronyms
ADL
Architecture Description Language
CBD
Component-Based Design
CRC
Class Responsibility Collaborator
DFD
International Council on Systems Engineering
ERD
Entity Relationship Diagram
IDL
Interface Description Language
MVC
Model View Controller
OO
Object-Oriented
PDL
Program Design Language

{{IntroSection|title=Introduction|body=

The Software Requirements knowledge area (KA)

is concerned with the elicitation, analysis, speci - fication, and validation of software requirements as well as the management of requirements dur - ing 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, “require - ments 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 prod - uct-based structure (system requirements, soft - ware 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 Manage - ment, Software Engineering Process, Software Engineering Models and Methods, and Software Quality KAs.