Advanced Information Systems

Analysis and Design

Class 3: Requirements, Specification, and
Architecture

Alan R. Hevner
University of South Florida

September 6, 2018 Copyright © 2018 Alan R. Hevner 1

Class 3 Outline
 Cleanroom Software Engineering
 Requirements Definitions and Properties
 Quality Attributes
 Quality Attributes for a Telemedicine System (LeRouge et al. 2004
paper)
 Software System Specification
 Formal Specification Languages
 Model-Driven Specification
 Architecture-Centric Specification
 Component-Based Software Development
 Hybrid Specification Approaches

September 6, 2018 Copyright © 2018 Alan R. Hevner 2

Cleanroom Software Engineering
 A philosophy of developing software that
emphasizes high-quality, defect-free products
 Cleanroom software engineering is a team-
oriented process and methods that makes
development more manageable and predictable
because it is done under statistical quality
control.
 Formal, yet practical, approach to develop zero-
defect software.
 Ref: R. Linger, “Cleanroom Process Model,”
IEEE Software, 1994.
September 6, 2018 Copyright © 2018 Alan R. Hevner 3
Cleanroom Technologies
 Incremental Development
 Usage Specification
 Box Structure Specification and Design
 Correctness Verification
 Statistical Testing
 Software Certification

September 6, 2018 Copyright © 2018 Alan R. Hevner 4

Incremental Development
 Provides intellectual control over complex
system development
 Each Increment:
 Isan End-to-End System
 Adds Functionality to Previous Increment
 Provides Early and Continuous Quality
Assessment and Customer Feedback

September 6, 2018 Copyright © 2018 Alan R. Hevner 5

V-Model with Incremental Development
Evolved Software Development Process Model
(with Incremental Development)

Customer Acceptance
Requirements Analysis Test Scripts Field Test

System Test Scripts

Software Architecture System Integration

Incremental Dev. Plan System Test

Subsystem

Software Design Test Scripts Subsystem Integration

Subsystem Test

Incremental Implementation
Development Cycle
Unit Test
Figure 2

September 6, 2018 Copyright © 2018 Alan R. Hevner 6

Three-Increment Project
Increment Planning

Test Preparation
Design and Build
for Increment 1
Increment 1 Certify
Increment 1
Test Preparation
Design and Build
for Increment 2
Increment 2 Certify
Increment 2
Test Preparation
Design and Build
for Increment 3
Increment 3
Certify
Increment 3

Deploy
Solution

September 6, 2018 Copyright © 2018 Alan R. Hevner 7

Usage Specification
 Usage Specification formally defines the
usage of the system in a real-world
environment.
 Usage models define all possible
scenarios of use and probabilities of
occurrence.
 Statistical system testing is based upon
usage distributions.
September 6, 2018 Copyright © 2018 Alan R. Hevner 8
Box Structure Specification and Design
 Box Structures are abstract system modules
viewed as mathematical functions:
 Black Box: Stimulus - Response Behavior
 Object-oriented view

 State Box: Design Internal State into Behavior

 Data-oriented view

 Clear Box: Design Procedure among Internal Black

Boxes
 Procedure-oriented view
 System is designed as a top-down decomposition
of box structures.

September 6, 2018 Copyright © 2018 Alan R. Hevner 9

V-Model with Usage Specification
Evolved Software Development Process Model
(with Inc. Dev. and Functional/Usage Specifications)

Customer Acceptance
Requirements Analysis Test Scripts Field Test
Functional Usage
Specification Specification
Box Structure
Representations
Software Architecture System Test Scripts System Integration

Incremental Dev. Plan System Test

Box Structure
Representations Subsystem

Software Design Test Scripts Subsystem Integration

Subsystem Test
Box Structure
Representations
Incremental Implementation
Development Cycle
Unit Test
Figure 3

September 6, 2018 Copyright © 2018 Alan R. Hevner 10

Correctness Verification
 Formal Inspections are performed on:
 Requirements
 Design
 Test Cases
 Box Structure specification and design supports
function-theoretic correctness verification.
 Focuses attention on essential system structures
 Scales up linearly with number of control structures, not
exponentially with number of execution paths

September 6, 2018 Copyright © 2018 Alan R. Hevner 11

Statistical Testing and
Software Certification
 Formal testing experimental design is
based upon system usage distributions.
 Valid statistical measures of system
quality are produced by the testing.
 Mean Time To Failure (MTTF)
 The software system is certified for fitness-
for-use based upon customer or industry
defined quality levels.
September 6, 2018 Copyright © 2018 Alan R. Hevner 12
V-Model with Cleanroom Testing
Evolved Software Development Process Model
(with Inc. Dev., Func./Usage Spec., and Correctness Verification/Statistical Testing)

Customer Acceptance
Requirements Analysis Test Scripts Field Test
Functional Usage
Specification Specification
Box Structure
Representations System Test Scripts
Software Architecture

Incremental Dev. Plan

Box Structure System Integration
Representations
Statistical Testing
Software Design
Software Certification
Correctness Verification

Box Structure
Representations
Incremental Implementation
Development Cycle

Figure 4

September 6, 2018 Copyright © 2018 Alan R. Hevner 13

Requirements Engineering

 It is hard to get started in a software development

project.
 Getting good requirements is the most difficult part
of software development.
 After getting started, the problem is knowing when
we have enough requirements, the right
requirements, and some confidence that we have
nearly all of the needed requirements.

September 6, 2018 Copyright © 2018 Alan R. Hevner 14

Requirements Describe a
Software Function
 A Software System takes a set of inputs, and
transforms those inputs into a set of outputs
(the transformation notion of software).
 A software program is a mathematical
function.
 To get started, remember what requirements
are: a description of what outputs should be
expected, given a set of inputs.
September 6, 2018 Copyright © 2018 Alan R. Hevner 15
Identification of Software System
Inputs and Outputs
 What are the outputs that the software needs
to produce? (What does the user need to
accomplish?)
 What are the inputs that are needed to
produce the outputs the user needs?
 What are the acceptable values the outputs
can take on?
 What are acceptable values for the inputs?

September 6, 2018 Copyright © 2018 Alan R. Hevner 16

Exploring Relationships
between Inputs and Outputs
 When looking at the requirements, relationships
begin to emerge between sets of inputs and
outputs.
 These relationships are good places to continue
exploration of requirements.
 For instance, a paycheck (a system output) is likely
dependent upon a pay date, since the check will be
dated. Are there other requirements that can be
deduced from that relationship?

September 6, 2018 Copyright © 2018 Alan R. Hevner 17

Properties of Good Requirements
 Good requirements must satisfy all system
stakeholders:
 Technical stakeholders – developers, testers
 Management stakeholders
 Customers
 End Users

 Stakeholder Needs vs. System

Requirements
 What makes a good requirement?
September 6, 2018 Copyright © 2018 Alan R. Hevner 18
Understandable by End Users
 End-users are not often software engineers.
 Terminology used must agree with end-
user’s understanding (for instance, standard
accounting terminology.)
 End-users understanding must agree with
ours. Everyone must understand the same
thing!

September 6, 2018 Copyright © 2018 Alan R. Hevner 19

Non-Prescriptive
 Non-prescriptive means that the requirement
must stipulate what must be done, but not
how it must be done.
 Requirements are “what”, and the design
activity is “how”
 Data structures and algorithms belong in the
design documents, not the requirements!

September 6, 2018 Copyright © 2018 Alan R. Hevner 20

Correct
 Obviously, the behavior specified must be the
proper behavior.
 Correct implies “completely correct”. For instance,
the requirement must indicate the fullest possible
conditions. While a requirement to support “at least
3” terminals can be considered correct, if the user
expects to eventually expand to 300, the
requirement should reflect it!

September 6, 2018 Copyright © 2018 Alan R. Hevner 21

Complete
 Complete is a quality that can apply to both
the individual requirement and the sum of the
requirements.
 The requirements set should be considered
complete only if it is not missing any
requirements that would separate an
acceptable system from one that isn’t
acceptable!
September 6, 2018 Copyright © 2018 Alan R. Hevner 22
Concise (Succinct)
 Run-on requirements (and prose) can
confuse the requirement reader.
 Requirements should consist of only the
necessary information!
 Occam’s Razor: William of Occam, the
philosopher, said that argument should be
made “without unnecessary ornament”, and
that applies to requirements as well.

September 6, 2018 Copyright © 2018 Alan R. Hevner 23

Precise
 The bounds of the requirement should be evident
and unambiguous. In the case of numerical
bounds, it ought to be evident whether the end-
points are included or not.
 A great contributor to precise requirements is
consistency in the means used to represent
bounds. Words such as “inclusively” and
“exclusively” should be used with care so they are
consistent.

September 6, 2018 Copyright © 2018 Alan R. Hevner 24

Clear and Unambiguous
 This is the stumbling block for some mathematical
specification methods because end-users are not
always mathematically adept.
 However, even natural language specifications can
be unclear if they use words with a ‘high level’ of
abstraction.
 Natural language is inherently ambiguous. Use it
as precisely as you can while keeping it
understandable.

September 6, 2018 Copyright © 2018 Alan R. Hevner 25

Consistent
 Requirements should agree with each other:
one requirement should not stipulate
something that is in conflict with other
requirements.
 In addition, writing requirements in the same
‘form’ provides the reader with a consistent
appearance and (hopefully) understanding.

September 6, 2018 Copyright © 2018 Alan R. Hevner 26

Traceable
 Ultimately code ought to be traceable to the
requirement(s) that the code supports. We ought
to be able to answer the question “why is this
code here?” by tracing the code back through the
design to a set of requirements.
 We ought to also be able to find the code that
supports a requirement quickly, if the requirement
should change late in the development cycle.
 Support for traceability starts during requirements
specification. Each requirement should have a
unique identifier.
September 6, 2018 Copyright © 2018 Alan R. Hevner 27
Modifiable
 It’s a reality that requirements can change
(sometimes frequently.)
 The form used to write requirements should support
easy modification of the requirement.
 Avoid using “magic numbers” in the requirements.
Instead specify “symbolic” values, and define the
values elsewhere.

September 6, 2018 Copyright © 2018 Alan R. Hevner 28

Testable (Verifiable)
 Requirements ought to be something that
can be verified. In short, they ought to
provide outputs that are measurable based
on a given set of inputs.
 Sometimes, the testing process might
impose requirements on the system that
must be considered part of the requirements!
This is called “design for testability”.
September 6, 2018 Copyright © 2018 Alan R. Hevner 29
Feasible
 “When the start button is pressed, the system shall
transmute an ounce of lead into a ton of gold”: This
is a clear, unambiguous, testable, modifiable, and
even correct requirement, but it is not feasible.
 Feasible means that the requirement has a sound
basis for design. That is, we probably know at least
one way to accomplish this. (If we aren’t sure, we
have should be given an opportunity to prototype a
solution to find out.)

September 6, 2018 Copyright © 2018 Alan R. Hevner 30

Summary: How to write good
requirements?
 Requirements describe what outputs we should expect
given a set of inputs.
 In my experience the best format for writing good
requirements is Structured English.
 Our requirements could have the following form:
If some set of values appear at the inputs
Then some set of values appear at the outputs.
 For instance:
If the student id number is negative
Then an error message is printed at the console: “Student ID is out
of bounds”

September 6, 2018 Copyright © 2018 Alan R. Hevner 31

System Quality Attributes
 Requirements and Specifications must include consideration
of critical Quality Attributes as well as Functional Behaviors.
 Requirements for:
 Performance
 Usability
 Security
 Reliability
 Availability
 And many other software system –ilities
 Define requirements for all system qualities that are
essential for system effectiveness and success.
 Case Study – Telemedicine System (LeRouge et al. 2004)

September 6, 2018 Copyright © 2018 Alan R. Hevner 32

Quality Attributes in Telemedicine
 “Telemedicine involves the use of modern information technology,
especially two-way interactive audio/video communications,
computers, and telemetry, to deliver health services to remote
patients and specialists at some distance from each other”
(Darkins and Carey 2000 p. 2)

September 6, 2018 Copyright © 2018 Alan R. Hevner 33

Research Questions
 What quality attributes contribute to medical video
conferencing success?
 Do the quality attributes of various users (patients and
providers) differ? If so, where do the perspectives
converge and diverge?
 Is there a difference in relative importance among
attributes from the perspective of patients? Providers? If
such a difference exists, which quality attributes are
considered most relevant from the perspective of
providers? Patients?
 How can we measure the identified quality attributes of
medical video conferencing?

September 6, 2018 Copyright © 2018 Alan R. Hevner 34

Socio-Technical Systems
 “The unity of software Telemedicine: Virtual Collaboration
including graphical user
interface (GUI), the hardware,
embedded systems for
control and regulation of Technology
peripherally technical
processes for communication
Support Provider
with other IS and, last but not
least, the associated social
action system of persons who
are interacting with the Patient
technology and with other
people” (Magenheim 2001).

September 6, 2018 Copyright © 2018 Alan R. Hevner 35

Telemedicine System Qualities
 System (Technology) Quality
 Information Quality
 Service (Support) Quality
 Use Quality

September 6, 2018 Copyright © 2018 Alan R. Hevner 36

September 6, 2018 Copyright © 2018 Alan R. Hevner 37
Motion Handling
 Controlled by:
 Codec
 Transmission
speed
 Poor Motion
Handling Results
in :
 Pixelization
 Blurriness
 “Mosquitoing”
(edges)
September 6, 2018 Copyright © 2018 Alan R. Hevner 38
September 6, 2018 Copyright © 2018 Alan R. Hevner 39
 Motion Handling: The degree to which the technology provides image
refreshing at a rate that depicts comparatively real-time movement. Motion
handing involves a smooth transition as images are updated. Pixelization,
motion artifacts, and frame dropping that occur during an encounter
compromise motion handling quality.
Importance Mean (4
When Most Controllable:
Point scale, 4 highest)
Before the Encounter Encounter Encounter After the
Provider Patient Encounter Start Body End Encounter

3.5 3.10
* *
Stat. Sig. @ p-value .10
Who can Exert Most Control:

Provider Roles Consumer Technical Roles Organizational Roles External

Role

Physician In-Room Patient Equipment Tech. Mgt. Telemedicine Scheduler Environment

Clinician Manufacturer Support Coordinator

*
September 6, 2018
* *
Copyright © 2018 Alan R. Hevner 40
 Telepresence (Consultant)
“You have to learn how to interact with the patients in a different
way.You have to make the patient feel comfortable, not let him be
intimidated, smile at them, acknowledge that the TV is there, and
perhaps say something to make the patient feel at ease and then
you can go on an do your exam.”

September 6, 2018 Copyright © 2018 Alan R. Hevner 41

 Telepresence: The degree to which the remote consultant is able to
convey a ubiquitous, virtual presence (e.g. eye contact, warm atmosphere,
congenial atmosphere, interactive atmosphere) as well as medical expertise
and authority. Telepresence may be thought of as warm and confident
“virtual bedside manner”.
Importance Mean (4
When Most Controllable:
Point scale, 4 highest)
Before the Encounter Encounter Encounter After the
Provider Patient Encounter Start Body End Encounter

3.33 3.48
* * * *
Who can Exert Most Control:

Provider Roles Consumer Technical Roles Organizational Roles External

Role

Physician In-Room Patient Equipment Tech. Mgt. Telemedicine Scheduler Environment

Clinician Manufacturer Support Coordinator

* *
September 6, 2018 Copyright © 2018 Alan R. Hevner 42
Contributions to Research
 Identify and provide indications of importance of quality
issues that affect success of a mission critical system
from the perspective of multiple stakeholders
 Provide some insight into the control related to quality
issues
 Telemedicine quality taxonomy (definition, attributes)
 Introduce new construct, use quality.
 One of a few studies of the nature of work in emerging,
situated contexts needed to facilitate understanding of
the changing patterns of work and to develop modern
organizational theory
 Exemplify using field study approach to examine
success and to ground instrument development
September 6, 2018 Copyright © 2018 Alan R. Hevner 43
Contributions to Practice
 Common reference to facilitate communication and
understanding
 Guide for decision making (budgeting, staffing, training,
system design, equipment development and system
maintenance )
 Means to recognize and assess telemedicine quality
standards
 Provide a foundation for quality control and quality
assurance by exploring control issues
 Requirements while balancing constraints
 Basis for “Scorecard” to assess quality in telemedicine
encounters

September 6, 2018 Copyright © 2018 Alan R. Hevner 44

Software System Specification
 Specifications provide the link between user requirements
and the implementation of a system
 Requirements are typically more “fuzzy” than specifications
 Specifications lend themselves to systematic analysis
 Requirements are written for end-user understanding
 Specifications are written for developer guidance
 Specifications include system details (e.g., quality
attributes) that the end-user may not care about

September 6, 2018 Copyright © 2018 Alan R. Hevner 45

Specifications Verify Requirements
 This process of specification allows
developers to check the requirements.
 Decomposition and organization of
requirements into a formal specification can
help “double check” the requirements.
 In addition, analysis allows developers to look
“forward” to the design phase to begin
identifying design issues.

September 6, 2018 Copyright © 2018 Alan R. Hevner 46

Specification Approaches
 Formal Specification Languages
 Model-Driven Specification
 Architecture-Centric Specification
 Component-Based Software Development
 Hybrid Specification Approaches
 Ref: Y. Zheng and R. Taylor, “A Rationalization of Confusion,
Challenges, and Techniques in Model-Based Software
Development,” ISR Tech Report #UCI-ISR-11-5, Univ. of Cal, Irvine,
August 2011.

September 6, 2018 Copyright © 2018 Alan R. Hevner 47

Formal Specification Languages

September 6, 2018 Copyright © 2018 Alan R. Hevner 48

The Uses of Formalism
 Formalism can avoid certain problems such as
ambiguity, and help enforce correctness,
conciseness, and preciseness.
 Formalism can be used to allow automation of:
 Consistency checking
 Test generation
 Value checking (inputs and outputs)
 Design

September 6, 2018 Copyright © 2018 Alan R. Hevner 49

Uses of Formal Specification Languages
 Safety Critical Systems
 Medical Systems (e.g. Insulin delivery)
 Nuclear Power Plants
 Avionics Systems
 All High-Risk and Vulnerable Systems

 Examples:
 Cleanroom Box Structures
 Sequential Modeling Languages (e.g. Z, VDM)
 Concurrent Modeling Languages (e.g. CSP, Petri Nets)

September 6, 2018 Copyright © 2018 Alan R. Hevner 50

Black Box Specification
 External, user-visible behavior in all possible
circumstances of use.
 System transitions ordered by timing subscript i
 Stimulus – Si
 Stimulus History – Si*
 Response – Ri
 Stimulus to Response Functional Behavior –
f(Si*)  Ri
 Example: Running Yearly Average

September 6, 2018 Copyright © 2018 Alan R. Hevner 51

State Box Specification
 Identify the elements of stimulus history that must
be retained as state data between system
transitions.
 State (T) design is a creative activity.
 Each state box transition has two parts:
 Produce the Response
 Update the State
 State box function – g(S,T)  (R,T’)
 Verify the correctness of the State Box by deriving
its Black Box
 Example: Running Yearly Average

September 6, 2018 Copyright © 2018 Alan R. Hevner 52

Clear Box Specification
 Create a procedure to implement the transition
function.
 Use control structures:
 Sequence
 Alternation (If-Then-Else)
 Iteration (While-Do)
 Concurrency
 Use abstraction to identify embedded Black Boxes
at the next level of system specification.
 Example: Running Yearly Average

September 6, 2018 Copyright © 2018 Alan R. Hevner 53

Z example – Patient Records
STATE ::= patients | fields | setup | ready | beam_on
EVENT ::= select_patient | select_field | enter | start | stop | ok | intlk
FSM == (STATE x EVENT) STATE

no_change, transitions, control: FSM

control = no_change transitions

no_change = { s: STATE; e: EVENT (s, e) s}

transitions = { (patients, enter) fields,

(fields, select_patient) patients, (fields, enter) setup,
(setup, select_patient) patients, (setup, select_field) fields, (setup, ok)
ready,
(ready, select_patient) patients, (ready, select_field) fields, (ready, start)
beam_on, (ready, intlk) setup,
(beam_on, stop) ready, (beam_on, intlk) setup }

September 6, 2018 Copyright © 2018 Alan R. Hevner 54

Model-Driven Specification

September 6, 2018 Copyright © 2018 Alan R. Hevner 55

Model-Driven Development (MDD)
 Initial work by OMG in early 2000’s
 PIM – Platform Independent Model
 PSM – Platform Specific Model
 DSM – Domain Specific Model

 Dominant Modeling Approach – Unified

Modeling Language (UML)

September 6, 2018 Copyright © 2018 Alan R. Hevner 56

Evolution of Unified Modeling
Language (UML)
 Object-Oriented Programming
 Object-Oriented Analysis and Design
 MultipleOOAD methods
 Booch – Rumbaugh – Jacobson at Rational
 1995 – Unified Modeling Language at OOPSLA
 OMG ownership of UML circa 1998
 UML Version 1 (Design by committee)
 UML Version 2 (Extensions)
 Tool support by various vendors

September 6, 2018 Copyright © 2018 Alan R. Hevner 57

Introduction to UML
 Martin Fowler, UML Distilled, 3rd Edition,
Addison-Wesley, Inc., 2004.
 OMG Tutorial
http://www.omg.org/gettingstarted/what_is_uml.
htm
 Embarcadero Hands-On Tutorial at
http://dn.codegear.com/article/31863
 LucidChart Tutorial
https://www.lucidchart.com/pages/uml

September 6, 2018 Copyright © 2018 Alan R. Hevner 58

UML Version 2.0 Extensions
 New Concepts:
 Nested Classifiers
 Improved Behavioral Modeling
 Improved Relationships between Structural and Behavioral Models
 New Diagrams:
 Interaction Overview – Combination of Sequence Diagrams and Activity
Diagrams
 Composite Structure – Show sub-structure of Classes (Decomposition)
 Timing – Adding timing to Interaction Diagrams
 Changes to Existing Diagrams:
 Collaboration Diagrams are now Communication Diagrams
 Class Diagrams – Properties
 Sequence Diagrams – Interaction Frame Notation
 Class Diagrams – Stereotypes, Instance Specifications, Interfaces
 State Machine Diagrams – Do Activities (Long Lived)
 Activity Diagrams – Token Flows (Petri Nets)

September 6, 2018 Copyright © 2018 Alan R. Hevner 59

How Do I Get Started with UML?
 Select a Process and Set of Methods
 Agile
vs. Plan-Driven Process
 UML Methods that Fit Process

 Select a UML Development Tool Suite

 ArgoUML and many others
 Get Training
 UML Methods Training
 Tool Suite Training
September 6, 2018 Copyright © 2018 Alan R. Hevner 60
Architecture-Centric Specification

September 6, 2018 Copyright © 2018 Alan R. Hevner 61

Software Architecture
 Overarching design templates that guide the
high-level design decisions for the software
system
 Architecture Styles - A particular codification
of design elements that are formal
arrangements. An architectural style:
 constrains design elements and arrangements
 has coherence
 describes system-wide organizational properties
 is affected by available materials.

September 6, 2018 Copyright © 2018 Alan R. Hevner 62

Architecture Elements
 Components are the locus of computation and data storage
 filters, databases, objects, processes, servers, etc.
 Connectors define the interactions between components
 procedure calls, pipes, messages, events, etc.
 Configurations are collections of interacting components
and connectors
 diagrams of boxes and arrows, formal mathematical models, etc.
 Constraints provide semantic understanding of the style
requirements
 what makes the style correct, legal, efficient, secure, reliable, etc.
 Coordination is the glue that binds separate activities into an
ensemble (as distinguished from computation)
 enables process creation, communication, synchronization, deletion,
etc.
September 6, 2018 Copyright © 2018 Alan R. Hevner 63
Taxonomy of Architecture Styles
 Data Flow
 Pipes and Filters
 Batch Sequential
 Call/Return
 Main Programs and Subroutines (Von Neumann architectures)
 Client-Server
 Object-Oriented (Abstract Data Types)
 Layered
 Independent Components
 Communicating Processes
 Event Systems (Implicit Invocation)
 Data Centered
 Repository (Databases)
 Blackboard
 Virtual Machines
 Interpreters
 Knowledge-Based Systems (Rule-Based Systems)
 Many systems are comprised of mixtures and combinations of these styles.
September 6, 2018 Copyright © 2018 Alan R. Hevner 64
Architectural Issues
 Process Control Paradigms
 open-loop systems
 closed-loop systems with feedback and feed-forward controls
 Distributed Processes
 can be involved in many architectural styles
 Domain-Specific Architectures
 customized architectures for functional domains
 made up of the above standard styles
 State Transition Systems
 an extension of state machines
 views systems as made up of states and transitions between
states
 any architecture can be viewed in terms of state transitions

September 6, 2018 Copyright © 2018 Alan R. Hevner 65

Component-Based Software
Development (CBSD)

September 6, 2018 Copyright © 2018 Alan R. Hevner 66

Component-Based Methods
 Dominant approach for the current
development of software systems
 CBSD provides the foundations for
Service-Oriented Architectures (SOA) and
Cloud Computing
 Will be covered in detail in design lecture

September 6, 2018 Copyright © 2018 Alan R. Hevner 67

Summary of Specification Approaches

September 6, 2018 Copyright © 2018 Alan R. Hevner 68

Hybrid Specification Approaches
 The development of software systems often
combines several of the specification
approaches
 For example:
 Architectures are used to support model-based
specification or component-based development
 Safety critical components are often spec’ed in
formal languages

September 6, 2018 Copyright © 2018 Alan R. Hevner 69

Specification Challenges
 Multi-Aspect Modeling
 Structural Models
 Behavioral Models
 Quality (Non-functional) Models

 Design and Code Generation

 Can design and code be automatically generated from specification
models? How much manual effort is needed?

 Consistency Management
 How are changes managed to ensure consistency among
requirements, specifications, design, and code?

September 6, 2018 Copyright © 2018 Alan R. Hevner 70

 Class 3 Discussion Question

 The quality attributes of systems are often

overlooked during the requirements phase. How
can a project team ensure that all critical quality
attribute requirements are defined?

September 6, 2018 Copyright © 2018 Alan R. Hevner 71