SE 616 –
Introduction to Software Engineering
Engineering (Chapter 6)
Definition of System:
Webster's Dictionary :
1. a set or arrangement of
things so related as to form a unity or organic whole.
set of facts, principles, rules, etc., classified and arranged in an orderly
form so as to show a logical plan linking the various parts.
method or plan of classification or arrangement.
established way of doing something; method; procedure.
Definition of Computer-based
A set or arrangement of elements that are organized to
accomplish some predefined goal by processing information.
Components of a
- 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
- 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 portrays 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
Defines the elements for a specific computer-based system in the context of
the overall hierarchy of systems (macro elements).
- Top-down and Bottom-Up Approaches
to System Engineeing
- System engineer narrows
the focus of work as it moves downward in the hierarchy
engineering is a modeling process. It
- Defines the processes that serve the needs of the
view under consideration.
- Represents the behavior of the processes and the
assumptions on which the behavior is based.
- Explicitly defines both exogenous and endogenous
input to the model.
- Represents all linkages (including output) that will
enable the engineer to better understand the view.
System Modeling Restraints
- Assumptions that reduce the number of possible permutations and
- Simplifications that enable the model to be created in a timely
- Limitations that help to bound the system.
- Constraints that guide the manner in which the model is created.
- Preferences that indicate the preferred architecture for all
data, functions, and technology.
- Modeling and simulation
tools enable a system engineer to "test drive" a specification
of the system
Process Engineering (BPE)
to define architectures that will enable a business to use information
- Kinds of Architectures
- data architecture
- framework for the information
needs of a business or business function
- Building Blocks - Data Objects
with attributes and relationships
- applications architecture
- those elements of a system that
transform objects within the data architecture for some business purpose
- technology infrastructure
- the foundation for the data and
application architectures encompassing hardware and software
Business Process Engineering
Hierarchical Activity Structure - information strategy planning (ISP)
Information Strategy Planning
- define strategic business
- isolate critical success factors
- conduct analysis of technology
- perform analysis of strategic
- create a top-level data model
- cluster by
- refine model and clustering
Objectives and Goals
- Objective—general statement of
- Goal—defines measurable
objective: “reduce manufactured cost of our product”
§ decrease reject rate by 20% in first 6
- gain 10% price concessions from
- re-engineer 30% of components
for ease of manufacture during first year
- Objectives tend to be strategic
while goals tend to be tactical
in Business Process Engineering (BPE)
Business Area Analysis (BAA)
- Concerned with
- identifying detail data (in the
form of entity [data object] types)
- identifying function
requirements (in the form of processes) of selected business areas
[domains] identified during ISP
- ascertaining their interactions
(in the form of matrices)
- specifying what is required in a
- Outcome of BAA
- Isolation of areas of
opportunity in which information systems may support business area
Business System Design (BSD)
- Modeling the basic requirements of a specific
- Requirements are translated into data architecture,
applications architecture, and technology infrastructure.
- a.k.a ... software engineering
- modeling applications/procedures
that address (BAA) and constraints of ISP
Construction and Integration
- Focuses on implementation detail
- Architecture and infrastructure are implemented by:
- constructing an appropriate
database and internal data structures
- building applications using
- by selecting appropriate
elements of a technology infrastructure to support the design created
- Each system component integrated to form a complete
information system or application.
- Translate the customer's desire for a set of defined
capabilities into a working product
- Derive architecture and
- Architecture encompasses:
software, hardware, data, and people
- Establish a support
- Structure includes:
technology to tie the components together and the info that supports the
- Overall requirements of the product are elicited
from the customer.
- information and control needs
- product function and behavior
- overall product performance
- design and interfacing
- other special needs
- Allocate function and behavior to each of the four
- Begin system component engineering
- concurrent activities
- software engineering
- hardware engineering
- human engineering
- database engineering
- establish interfacing mechanisms
- Each 3-D box depicts a hardware
element that is part of the physical architecture of the system
- Represent procedural aspects of a
- Represent system level elements
in terms of the data that describe the element and the operations that
manipulate the data
Engineering (Chapter 7)
· Ensure that a system that properly
meets the customer's needs and satisfies the customer's expectations has been
Inception—ask a set of questions that establish
- basic understanding of the
o the people who want a solution
- the nature of the solution that
is desired, and
- the effectiveness of preliminary
communication and collaboration between the customer and the developer
Elicitation—elicit requirements from all
Elaboration—create an analysis model that
identifies data, function and behavioral requirements
Negotiation—agree on a deliverable system that is
realistic for developers and customers
Specification—can be any one (or more) of the
- A written document
- A set of models
- A formal mathematical
- A collection of user scenarios
- A prototype
Validation—a review mechanism that looks for
- errors in content or
- areas where clarification may be
- missing information
- inconsistencies (a major problem
when large products or systems are engineered)
- conflicting or unrealistic
- “who else do you think I should
multiple points of view
The first questions
- Who is behind the request for
- Who will use the solution?
- What will be the economic benefit
of a successful solution
- Is there another source for the
solution that you need?
- Issues in defining requirements
- Problems of scope.
- Problems of understanding.
- Problems of volatility.
- Guidelines for requirements elicitation
- Assess the business and
technical feasibility for the proposed system.
- 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.
- Identify "domain
constraints" (i.e., characteristics of the business environment
specific to the application domain) that limit the functionality or
performance of the system or product to be built.
- Define one or more requirements
elicitation methods (e.g., interviews, focus groups, team meetings).
- Solicit participation from many
people so that requirements are defined from different points of view; be
sure to identify the rationale for each requirement that is recorded.
- Identify ambiguous requirements
as candidates for prototyping.
- Create usage scenariosto help
customers/users better identify key requirements
- Work Products Produced
- A statement of need and
- A bounded statement of scope for
the system or product.
- A list of customers, users, and
other stakeholders who participated in the requirements elicitation
- A description of the system's
- A list of requirements
(preferably organized by function) and the domain constraints that apply
- A set of usage scenarios that
provide insight into the use of the system or product under different
- Any prototypes developed to
better define requirements.
collection of user scenarios that describe the thread of usage of a system
scenario is described from the point-of-view of an “actor”—a person or device
that interacts with the software in some way
scenario answers the following questions:
o Who is the primary actor, the
secondary actor (s)?
o What are the actor’s goals?
o What preconditions should exist before
the story begins?
o What main tasks or functions are
performed by the actor?
o What extensions might be considered as
the story is described?
o What variations in the actor’s
interaction are possible?
o What system information will the actor
acquire, produce, or change?
o Will the actor have to inform the
system about changes in the external environment?
o What information does the actor desire
from the system?
o Does the actor wish to be informed
about unexpected changes?
of the analysis model
o Functional—processing narratives for
o Use-case—descriptions of the
interaction between an “actor” and the system
o Implied by scenarios
o State diagram
o Data flow diagram
name: A descriptor that captures the essence of the
Intent: Describes what the pattern
accomplishes or represents
Motivation: A scenario that illustrates how the pattern
can be used to address the problem.
context: A description of external issues
(forces) that can affect how the pattern is used and also the external issues
that will be resolved when the pattern is applied.
A description of how the pattern is applied to solve the problem with an
emphasis on structural and behavioral issues.
Addresses what happens when the pattern is applied and what trade-offs
exist during its application.
Discusses how the analysis pattern can be achieved through the use of
known design patterns.
uses: Examples of uses within actual systems.
One or more analysis patterns that are related to
the named pattern because
- it is commonly used with the named
- it is structurally similar to the named
- it is a variation of the named pattern.
Requirements Analysis and Negotiation
- Analysis - (CheckList)
- categorizes requirements and
organizes them into related subsets
- Explores each requirement in
relationship to others
- Examines requirements for
consistency, omissions, and ambiguity
- Ranks requirements based on the
needs of customers/users
- Questions asked and Answered (Checklist)
- Is each requirement consistent
with the overall objective for the system/product?
- Have all requirements been
specified at the proper level of abstraction?
some requirements provide a level of technical detail that is inappropriate at
- 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
- Does each requirement have
a source (generally, a specific individual) noted for each requirement?
- 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,
- Final work product produced by the system and
- Foundation for hardware engineering, software
engineering, database engineering, and human engineering.
- Describes the function and performance of a
computer-based system and the constraints that will govern its development
- Bounds each allocated system element
- Attempts to create a meaningful model of the system
- Examines the specification to ensure:
- that all system requirements
have been stated unambiguously
- that inconsistencies, omissions,
and errors have been detected and corrected
- that work products conform to
the standards established for the process, the project, and the product.
- Formal technical review: primary requirements
- Review Team:
- system engineers
- other stakeholders
- Examine the system specification:
- errors in content or
- areas where clarification may
- missing information
- conflicting requirements
- unrealistic (unachievable)
- Examine each requirement against
a set of checklist questions:
- 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
- What other requirements relate
to this requirement? Are they clearly noted via a cross-reference matrix
or other mechanism?
- 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?
- Has an index for the
specification been created?
- Have requirements associated
with system performance, behavior, and operational characteristics been
clearly stated? What requirements appear to be implicit?
- Set of activities that help the project team to
identify, control, and track requirements and changes to requirements at
any time as the project proceeds.
- Identifies each requirement and assigns it a unique
<requirement type><requirement #>
type> takes on values such as
F = functional requirement
D = data requirement
B = behavioral requirement
I = interface requirement
P = output requirement
a requirement identified as F09 indicates a functional requirement assigned
requirement number 9.
- Traceability tables are then developed