CS615 – Software Engineering I |
Lecture 3 |
System Engineering (Chapter 10)
Definition of System:
Webster's Dictionary :
1. a set or arrangement
of things so related as to form a unity or organic whole.
2. a set of facts,
principles, rules, etc., classified and arranged in an orderly form so
as to show a logical plan linking the various parts.
3. a method or
plan of classification or arrangement.
4. an established way
of doing something; method; procedure.
Definition of Computer-based System:
A set or arrangement of elements that are organized
to accomplish some predefined goal by processing information.
Components of a Computer-based System:
-
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.
-
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 system resides.
System Engineer:
Defines the elements for a specific computer-based system in the
context of the overall hierarchy of systems (macro elements).
System Engineering Hierarchy:
-
Top-down and Bottom-Up Approaches to System Engineeing
-
System engineer narrows the focus of work as it moves downward in the
hierarchy
System Modeling
System 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 variations.
-
Simplifications that enable the model
to be created in a timely manner.
-
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.
System Simulation
-
Modeling and simulation tools enable a system engineer to "test drive"
a specification of the system
Business Process Engineering (BPE)
-
Goal: to define architectures that
will enable a business to use information effectively
-
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 Modeling
Hierarchical Activity Structure - information
strategy planning (ISP)
Steps in Business Process Engineering (BPE)
1. 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 business
area
-
Outcome of BAA
-
Isolation of areas of opportunity in which
information systems may support business area
2. Business System Design (BSD)
-
Modeling the basic requirements of a specific
information system
-
Requirements are translated into data architecture,
applications architecture, and technology infrastructure.
3. Construction and Integration
-
Focuses on implementation detail
-
Architecture and infrastructure are implemented
by:
-
constructing an appropriate database and internal
data structures
-
building applications using software components
-
by selecting appropriate elements of a technology
infrastructure to support the design created during BSD.
-
Each system component integrated to form a
complete information system or application.
Product Engineering
Goal:
-
Translate the customer's desire for a set
of defined capabilities into a working product
Process: Requirements Engineering
-
Derive architecture and
infrastructure
-
Architecture encompasses: software, hardware,
data, and people
-
Establish a support infrastructure
-
Structure includes: technology to tie
the components together and the info that supports the components.
Execution:
-
Overall requirements of the product are elicited
from the customer.
-
Encompasses:
-
information and control needs
-
product function and behavior
-
overall product performance
-
design and interfacing constraints
-
other special needs
-
Allocate function and behavior to each of
the four system components
-
Begin system component engineering
-
concurrent activities encompassing
-
software engineering
-
hardware engineering
-
human engineering
-
database engineering
-
establish interfacing mechanisms among systems
Requirements Engineering
Goal
Ensure that a system that properly meets the
customer's needs and satisfies the customer's expectations has been specified
Process
-
Requirements elicitation
-
Requirements analysis and negotiation
-
Requirements specification
-
System modeling
-
Requirements validation
-
Requirements management
Requirements Elicitation
-
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 feasibility.
-
A bounded statement of scope for the system
or product.
-
A list of customers, users, and other stakeholders
who participated in the requirements elicitation activity.
-
A description of the system's technical environment.
-
A list of requirements (preferably organized
by function) and the domain constraints that apply to each.
-
A set of usage scenarios that provide insight
into the use of the system or product under different operating conditions.
-
Any prototypes developed to better define
requirements.
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?
Do some requirements provide a level of
technical detail that is inappropriate at this stage?
-
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?
-
Does each requirement have attribution?
Is 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, once implemented?
Requirements Specification
-
Final work product produced by the system
and requirements engineer
-
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
System Modeling
-
Attempts to create a meaningful model of the
system
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
-
that work products conform to the standards
established for the process, the project, and the product.
-
Formal technical review: primary requirements
validation mechanism
-
Review Team:
-
system engineers
-
customers
-
users
-
other stakeholders
-
Examine the system specification: look for
-
errors in content or interpretation
-
areas where clarification may be required
-
missing information
-
inconsistencies
-
conflicting requirements
-
unrealistic (unachievable) requirements.
-
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 quantitative
terms?
-
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?
Requirements Management
-
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 identifier
e.g. <requirement type><requirement
#>
where
<requirement type> takes on values
such as
F = functional requirement
D = data requirement
B = behavioral requirement
I = interface requirement
P = output requirement
Hence, a requirement identified as F09 indicates
a functional requirement assigned requirement number 9.
-
Traceability tables are then developed
Analysis Concepts and Principles (Chapter 11)
Requirements Analysis
-
Software engineering task that bridges the
gap between system level requirements engineering and software design.
-
Provides software designer with a representation
of system information, function, and behavior that can be translated to
data, architectural, and component-level designs.
-
Expect to do a little bit of design during
analysis and a little bit of analysis during design.
Software Requirements Analysis Phases
-
Begins with System Specification and
Software
Project Plan
-
Five Areas of effort
-
Problem recognition
-
Evaluation and synthesis (focus is on what
not how)
-
Modeling
-
Specification
-
Review
-
Goal: recognition of the basic problem elements
as perceived by the customer/users.
Software Requirements Elicitation
Process Initiation
-
Customer meetings are the most commonly used
technique.
-
Use context free questions to find
out:
-
customer's goals and benefits
-
identify stakeholders
-
Who is behind the request for this work?
-
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?
-
gain understanding of problem
-
How would you characterize "good" output that
would be generated by a successful solution?
-
What problem(s) will this solution address?
-
Can you show me (or describe) the environment
in which the solution will be used?
-
Will special performance issues or constraints
affect the way the solution is approached?
-
determine customer reactions to proposed solutions
-
assess meeting effectiveness
-
Are you the right person to answer these questions?
Are your answers "official"?
-
Are my questions relevant to the problem that
you have?
-
Am I asking too many questions?
-
Can anyone else provide additional information?
-
Should I be asking you anything else?
-
Ensure that a representative cross section
of users is interviewed.
Facilitated Action Specification Techniques
(FAST)
-
Creates a joint team of customers and developers
to:
-
identify the problem
-
propose elements of the solution
-
negotiate different approaches
-
specify a preliminary set of solution requirements
-
General Procedure
-
Meeting held at neutral site, attended by
both software engineers and customers.
-
Rules established for preparation and participation.
-
Agenda suggested to cover important points
and to allow for brainstorming.
-
Meeting controlled by facilitator (customer,
developer, or outsider).
-
Definition mechanism (flip charts, stickers,
electronic device, etc.) is used.
-
Goal is to identify problem, propose elements
of solution, negotiate different approaches, and specify a preliminary
set of solution requirements.
Quality Function Deployment (QFD)
-
QFD emphasizes an understanding of what is
valuable to the customer and then deploys these values throughout the engineering
process
-
Translates customer needs into technical software
requirements.
-
Uses customer interviews, observation, surveys,
and
historical data for requirements gathering.
-
Customer voice table (contains summary of
requirements)
-
Normal requirements (must be present
in product for customer to be satisfied)
-
Expected requirements (things like
ease of use or reliability of operation, that customer assumes will be
present in a professionally developed product without having to request
them explicitly)
-
Exciting requirements (features that
go beyond the customer's expectations and prove to be very satisfying when
they are present)
-
Function deployment (used during customer
meetings to determine the value of each function required for system)
-
Information deployment (identifies data objects
and events produced and consumed by the system)
-
Task deployment (examines the behavior of
product within it environment)
-
Value analysis (used to determine the relative
priority of requirements during function, information, and task deployment)
Use-Cases
-
Scenarios that describe how the product will
be used in specific situations.
-
Written narratives that describe the role
of an actor (user or device) as interaction with the system occurs.
-
Use-cases are designed from the actor's point
of view.
-
Not all actors can be identified during the
first iteration of requirements elicitation, but it is important to identify
the primary actors before developing the use-cases.
-
Questions that should be answered by the use-case:
-
What main tasks or functions are performed
by the actor?
-
What system information will the actor acquire,
produce, or change?
-
Will the actor have to inform the system about
changes in the external environment?
-
What information does the actor desire from
the system?
-
Does the actor wish to be informed about unexpected
changes?
Analysis Principles
Operational principles:
-
The information domain of the problem must
be represented and understood.
-
The functions that the software is to perform
must be defined.
-
Software behavior must be represented.
-
Models depicting information, function, and
behavior must be partitioned in a hierarchical manner that uncovers detail.
-
The analysis process should move from the
essential information toward implementation detail.
Guiding principles:
-
Understand the problem before
you begin to create the analysis model.
-
Develop prototypes that enable a user to understand
how human/machine interaction will occur.
-
Use multiple views of requirements.
Building data, functional, and behavioral models provide the software engineer
with three different views.
-
Rank requirements.
-
Work to eliminate ambiguity.
Information Domain
-
Encompasses all data objects that contain
numbers, text, images, audio, or video.
-
Information content or data model (shows the
relationships among the data and control objects that make up the system)
-
Information flow (represents the manner in
which data and control objects change as each moves through the system)
-
Information structure (representations of
the internal organizations of various data and control items)
Modeling
-
Types:
-
Data model (shows relationships among system
objects)
-
Functional model (description of the functions
that enable the transformations of system objects) - input - processing
- output
-
Behavioral model (manner in which software
responds to events from the outside world)
-
Importance:
-
Aids the analyst in understanding the information,
function, and behavior of a system
-
Becomes the focal point for review and, therefore,
the key to a determination of completeness, consistency, and accuracy of
the specifications
-
Foundation for design, providing the designer
with an essential representation of software that can be "mapped" into
an implementation context
Information Flow
How data and control change as each moves
through a system
Partitioning
-
Process that results in the elaboration of
data, function, or behavior.
-
Establish a hierarchical representation of
function or information
-
Partition the uppermost element by
-
(1) exposing increasing detail by moving vertically
in the hierarchy or
-
(2) functionally decomposing the problem by
moving horizontally in the hierarchy.
-
Types:
-
Horizontal partitioning is a breadth-first
decomposition of the system function, behavior, or information, one level
at a time.
-
Vertical partitioning is a depth-first elaboration
of the system function, behavior, or information, one subsytem at a time.
Software Requirements Views
-
Essential view - presents the functions
to be accomplished and the information to be processed without regard to
implementation.
-
Implementation view - presents the
real world manifestation of processing functions and information structures.
Software Prototyping
-
Prototyping Paradigm
-
Throwaway prototyping - prototype only
used as a demonstration of product requirements, finished software is engineered
using another paradigm
-
Evolutionary prototyping - prototype
is refined to build the finished system
-
Issues
-
Customer resources must be committed to evaluation
and refinement of the prototype.
-
Customer must be capable of making requirements
decisions in a timely manner.
-
Which Paradigm?
Prototyping Methods and Tools
-
Fourth generation techniques - 4GT
tools allow software engineer to generate executable code quickly
-
Reusable software components - assembling
prototype from a set of existing software components
-
Formal specification and prototyping environments
- can interactively create executable programs from software specification
models
Specification Principles
-
Separate functionality from implementation.
-
Develop a behavioral model that describes
functional responses to all system stimuli.
-
Define the environment in which the system
operates and indicate how the collection of agents will interact with it.
-
Create a cognitive model rather than an implementation
model.
-
Recognize that the specification must be extensible
and tolerant of incompleteness.
-
Establish the content and structure of a specification
so that it can be changed easily.
Specification Representation
-
Representation format and content should be
relevant to the problem.
-
Information contained within the specification
should be nested.
-
Diagrams and other notational forms should
be restricted in number and consistent in use.
-
Representations should be revisable.
Specification Review
-
Conducted by customer and software developer.
-
Once approved, the specification becomes a
contract for software development.
-
The specification is difficult to test in
a meaningful way.
-
Assessing the impact of specification changes
is hard to do.