System Engineering

INDEX
01 WHAT IS SYSTEM ENGINEERING ?
REQUIREMENT ENGINEERING
02 Requirements Elicitation
Requirements validation
Requirements analysis and negotiation.

WHAT IS SYSTEM ENGINEERING?
Software engineering occurs as a
consequence of a process called system
engineering. Instead of concentrating
solely on software, system engineering
focuses on a variety of elements,
analyzing, designing, and organizing
those elements into a system that can
be a product, a service, or a technology
for the transformation of information or
control.
The system engineering process is called
business process engineering when the
context of the engineering work focuses
on a business enterprise.
When a product is to be built, the process
is called product engineering.
Both business process engineering and
product engineering attempt to bring order
to the development of computer-based
systems. Although each is applied in a
different application domain, both strive to
put software into context.
REQUIREMENT ENGINEERING
Requirements engineering provides the
appropriate mechanism for understanding
what the customer wants, analyzing need,
assessing feasibility, negotiating a
reasonable solution, specifying the
solution unambiguously and managing
the requirements as they are transformed
into an operational system.
Elicitation
Analysis
and Management
Negotiation
REQUIREMENT
ENGINEERING
Specification Validation
System
Modelling
REQUIREMENT ELICITATION
It certainly seems simple enough—ask the customer, the users, and others what the
objectives for the system or product are, what is to be accomplished, how the system
or product fits into the needs of the business, and finally, how the system or product
is to be used on a day-to-day basis. But it isn’t simple—it’s very hard, and here are a few
reasons:
• Problems of scope. The boundary of the system is ill-defined or the customers/

users specify unnecessary technical detail that may confuse, rather
than clarify, overall system objectives.
• Problems of understanding. The customers/users are not completely sure of

what is needed, have a poor understanding of the capabilities and limitations
of their computing environment, don’t have a full understanding of the problem
domain, have trouble communicating needs to the system engineer, omit
information that is believed to be “obvious,” specify requirements that conflict
with the needs of other customers/users, or specify requirements that
are ambiguous or untestable.
• Problems of volatility. The requirements change over time.

• Identify the people who will help specify requirements and understand their
organizational bias.
• Define the technical environment (e.g., computing architecture, operating

system, telecommunications needs) into which the system or product will be
placed.
• Define one or more requirements elicitation methods (e.g., interviews, focus

groups, team meetings).
• Ask participation from many people so that requirements are defined from
different points of view; be sure to identify the basis for each requirement
that is recorded.
• Identify ambiguous requirements as candidates for prototyping.

REQUIREMENT ANALYSIS AND
NEGOTIATION.
Analysis categorizes requirements and organizes them
into related subsets; explores each requirement in relationship to others; examines
requirements for consistency, omissions, and ambiguity; and ranks requirements
based on the needs of customers/users.
As the requirements analysis activity commences, the following questions are
asked and answered:
• Is each requirement consistent with the overall objective for the

system/product?
• Is the requirement really necessary or does it represent an add-on feature

that may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will house

the system or product?
• Is each requirement testable, once implemented?

It isn’t unusual for customers and users to ask for more than
can be achieved, given limited business resources. It also is
relatively common for different customers or users to propose
conflicting requirements,
arguing that their version is “essential for our special needs.”
The system engineer must reconcile these conflicts through a

process of negotiation.
Customers, users and stakeholders are asked to rank
requirements and then discuss conflicts in priority. Rough
guestimates of development effort are made and used to
assess the impact of each requirement on project cost and
delivery time.
Using an iterative approach, requirements are eliminated,
combined, and/or modified so that each party achieves some
measure of satisfaction.
REQUIREMENT
VALIDATION
Assume for a moment that you have been asked to specify all requirements for the
construction of a gourmet kitchen. You know the dimensions of the room, the
location of doors and windows, and the available wall space. You could specify all
cabinets and appliances and even indicate where they are to reside in the kitchen.
Would this be a useful specification?
The answer is obvious. In order to fully specify what is to be built, you would need
a meaningful model of the kitchen, that is, a blueprint or three-dimensional
rendering that shows the position of the cabinets and appliances and their
relationship to one another. From the model, it would be relatively easy to assess
the efficiency of work flow (a requirement for all kitchens), the aesthetic “look” of the
room (a personal, but very important requirement).
We build system models for much the same reason that we would develop a blue-
print or 3D rendering for the kitchen. It is important to evaluate the system’s
components in relationship to one another, to determine how requirements fit into
this picture, and to assess the “aesthetics” of the system as it has been conceived.
The work products produced as a consequence of requirements
engineering (a system specification and related information) are
assessed for quality during a validation step. Requirements validation
examines the specification to ensure that all system requirements
have been stated unambiguously; that inconsistencies, omissions,
and errors have been detected and corrected; and that the work
products conform to the standards established for the process, the
project, and the product.
The primary requirements validation mechanism is the formal
technical review. The review team includes system engineers,
customers, users, and other stakeholders who examine the system
specification looking for errors in content or interpretation, areas
where clarification may be required, missing information,
inconsistencies (a major problem when large products or systems are
engineered), conflicting requirements, or unrealistic (unachievable)
requirements.
Although the requirements validation review
can be conducted in any manner that
results in the discovery of requirements errors,
it is useful to examine each requirement
against a set of checklist questions. The
following questions represent a small
subset of those that might be asked:
• Are requirements stated clearly? Can they be
misinterpreted?
• Is the source (e.g., a person, a regulation, a document) of

the requirement identified? Has the final statement of the
requirement been examined by or against the original
source?
• Is the requirement bounded in quantitative terms?
• Does a requirement stand on its own or do you have to

examine other requirements to understand what it means?
• Does the requirement violate any domain constraints?
• Is the requirement testable? If so, can we specify tests

(sometimes called validation criteria) to exercise the
requirement?
• Is the requirement traceable to any system model that has

been created?
• Is the requirement traceable to overall system/product

objectives?
• Is the system specification structured in a way that leads

to easy understanding, easy reference, and easy
translation into more technical work products?
A key concern during requirements validation is consistency.
Use the system model to ensure that requirements have been consis
tently stated.
Thank you.

System Engineering

Uploaded by

Copyright:

Available Formats

System Engineering

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Engineering

Uploaded by

Copyright:

Available Formats

INDEX

01 WHAT IS SYSTEM ENGINEERING ?

Requirements analysis and negotiation.

• Problems of scope. The boundary of the system is ill-defined or the customers/

• Problems of understanding. The customers/users are not completely sure of

• Problems of volatility. The requirements change over time.

• Define the technical environment (e.g., computing architecture, operating

• Define one or more requirements elicitation methods (e.g., interviews, focus

• Identify ambiguous requirements as candidates for prototyping.

• Is each requirement consistent with the overall objective for the

• Is the requirement really necessary or does it represent an add-on feature

• Is each requirement bounded and unambiguous?

• Do any requirements conflict with other requirements?

• Is each requirement achievable in the technical environment that will house

• Is each requirement testable, once implemented?

The system engineer must reconcile these conflicts through a

• Is the source (e.g., a person, a regulation, a document) of

• Is the requirement bounded in quantitative terms?

• Does a requirement stand on its own or do you have to

• Is the requirement testable? If so, can we specify tests

• Is the requirement traceable to any system model that has

• Is the requirement traceable to overall system/product

• Is the system specification structured in a way that leads

You might also like