System engineering involves determining operational requirements and modeling relationships between elements like hardware, software, and people to accomplish goals. It can focus on business processes or product development. The engineering process follows a hierarchy from overall objectives to domain specifications to element implementations. It is iterative to adapt to changing needs. Business process engineering derives data, application, and technology architectures, while product engineering defines architectures and infrastructure for software, hardware, data, and people components.

1.  Software engineering occurs as a consequence of a
process called system engineering.

2. The overall objective of the system must be determined:
 The role of hardware, software, people, database,
procedures, and other system elements must be
identified.
 Operational requirements must be elicited/extracted,
analyzed, specified, modeled, validated, and managed.
These activities are the foundation of system engineering.

3.  Business process engineering: The system engineering
process is called business process engineering when the
context of the engineering work focuses on a business
enterprise.
 Product engineering: 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.

4. System engineering is a modeling process.
To construct a system model, the engineer should
consider a number of factors:
o Assumptions
o Simplifications
o Limitations
o Constraints
o Preferences

5. o Assumptions: Reduce the number of possible
permutations and variations.
o Simplifications: enable the model to be created in a
timely manner.
o Limitations: Help to bound the system.
o Constraints: Will guide the manner in which the
model is created and the approach taken when the
model is implemented.
o Preferences: Indicate the preferred architecture for
all data, functions, and technology.

6. We define a computer-based system as
A set or arrangement of elements that are
organized to accomplish some predefined goal by
processing information.

7. To accomplish the goal, a computer-based system makes use of
a variety of system elements.
Software: Computer programs, data structures, and related
documentation that serve to effect the logical method,
procedure, or control that is required.
Hardware: Electronic devices that provide computing
capability, the interconnectivity devices (e.g., network switches,
telecommunications devices) that enable the flow of data, and
electromechanical devices (e.g., sensors, motors, pumps) that
provide external world function.
People: Users and operators of hardware and software.

8.  Database: A large, organized collection of information
that is accessed via software.
 Documentation: Descriptive information (e.g.,
hardcopy manuals, on-line help files, Web sites) that
represents the use and/or operation of the system.
 Procedures: The steps that define the specific use of
each system element or the procedural context in which the
system resides.

9. THE SYSTEM ENGINEERING HIERARCHY

10. Regardless of its domain of focus, system engineering
encompasses a collection of top-down and bottom-up
methods to navigate the hierarchy.
The system engineering process usually begins with a
“world view.”
The world view is refined to focus more fully on
specific domain of interest. Within a specific domain,
the need for targeted system elements (e.g., data,
software, hardware, people) is analyzed.

11. The world view (WV) is composed of a set of domains
(Di), which can each be a system or system of systems
in its own right.
WV = {D1, D2, D3, . . . , Dn}

12. Each domain is composed of specific elements (Ej)
each of which serves some role in accomplishing the
objective and goals of the domain or component:
Di= {E1, E2, E3, . . . , Em}
Finally, each element is implemented by specifying the
technical components (Ck) that achieve the necessary
function for an element:
Ej= {C1, C2, C3, . . . , Ck}

13. BUSINESS PROCESS ENGINEERING

14. Three different architectures must be analyzed and
designed within the context of business objectives and
goals:
o data architecture
o applications architecture
o technology infrastructure

15. o The data architecture provides a framework for
the information needs of a business or business
function.
o The application architecture encompasses those
elements of a system that transform objects within the
data architecture for some business purpose.

16. o The technology infrastructure provides the
foundation for the data and application architectures.
The infrastructure encompasses the hardware and
software that are used to support the application and
data.

17. The product engineering hierarchy:

18. The goal of product engineering is to translate the
customer’s desire for a set of defined capabilities into a
working product.
To achieve this goal, product engineering—like business
process engineering—must derive architecture and
infrastructure.

19. o The architecture encompasses four distinct system
components: software, hardware, data (and databases),
and people.
o The infrastructure includes the technology required
to tie the components together and the information that
is used to support the components.

20. Like most engineering activities, business process
reengineering is iterative.
Business goals and the processes that achieve them
must be adapted to a changing business environment.
For this reason, there is no start and end to BPR—it is
an evolutionary process.

21. The model defines six activities:
1. Business definition: Business goals are identified
within the context of four key drivers: cost reduction,
time reduction, quality improvement, and personnel
development and empowerment.
2 . Process identification: Processes that defined in the
business definition are identified. They may then be
ranked by importance that is ssfor the reengineering
activity.

22. 3. Process evaluation: The existing process is
thoroughly analyzed and measured. Process tasks are
identified; the costs and time consumed by process
tasks are noted; and quality/performance problems are
isolated.
4. Process specification and design: Based on
information obtained during the first three BPR
activities, use-cases that are prepared for each process
that is to be redesigned.

23. 5. Prototyping: A redesigned business process must
be prototyped before it is fully integrated into the
business. This activity “tests” the process so that
refinements can be made.
6. Refinement and instantiation: Based on
feedback from the prototype, the business process is
refined and then instantiated within a business
system.

24. BPR model