System Analysis and Design

CSE 307 Sec 1

Lecture 00
Systems Engineering Lifecycles
 Objective
 To look at the process from the
perspective of the system analyst or
systems engineer - the “technical
coordinator” of the project

 To examine how software must fit into

the process for developing all of the
technical parts of a product
 What is a Lifecycle?
Lifecycle: the period of time during
which a process occurs. Generally,
this begins with an initial concept
and ends with a final termination.

Lifecycle: the context of a process

Lifecycle: the top level view of a process

 The Systems Engineering
Lifecycle is ...
• ... the highest level “technical” lifecycle
for a product or system being built
• It incorporates many disciplines
• It begins with a system concept and
ends with system integration
• Software engineering success is largely
dependent on successful execution of
this lifecycle
 General Model of a Lifecycle

Phase 1 Phase 2 Phase 3 Phase 4 .... Phase n

Milestone Milestone Milestone Milestone Milestone Milestone

• A sequence of phases or time periods

• Milestones mark the boundaries between
phases
 Example of a Lifecycle
Concept
Exploration
Gestation Childhood Adulthood ....

Meeting Conception Birth Puberty

• Not all phases are equal in length
• Not all boundaries are exact
• Not all details of each specific instance are
equal, even though the same general
lifecycle model may apply to each case
 Each Phase is a Miniature
Lifecycle in Itself

Concept
Exploration
Gestation Childhood Adulthood ....

Infancy
“Terrible
Twos”
.... Pre-Teen
 Alternative Lifecycle Concepts
Overlapping phases Imprecise Boundaries
Phase 1
Phase 2 Adulthood Senility
Phase 3
Phase 4

Phase 1
Phase 2 Parallel Repeated
Cycles
Phase 3 phases

Phase 4
 Typical Product Development
Lifecycle

Marketability Prototype Final

Research Production
Study Development Development

Milestone Milestone Milestone Milestone Milestone Milestone

(Most real developments have some

degree of overlap, not pure sequential)
 Elements of a Product
Development Lifecycle

 Phases: Distinct periods of time during

which development occurs
 Milestones: Events that mark phase
boundaries
 Goals: Objectives for each phase and for
the development as a whole -- what the
phase is intended to accomplish
… continued
 Elements of a Product
Development Lifecycle (continued)

 Entry Criteria: Conditions that must exist

before a phase can begin
 Exit Criteria: Conditions that must exist or
artifacts that must be produced in order
for the phase to be successfully
completed
 Evaluation Criteria: Conditions or standards
that will be used to determine if the
product is successful. (Often, these are
used to decide if we should start the next
phase.)
 The Systems Engineering
(or System Analysis) Lifecycle

Step 2
Step 1 Design the Step 3
Step 4
Analyze Architecture & Build
Integrate
Requirements Allocate the
& Test
Requirements System
To The Parts
First two steps are Step 3 occurs Final step
repeated for each level in separately for is repeated
the system architecture each part for each
(configuration level
item)
 Step 1 - Analyze the
Requirements of the System
 Determine what the customer really wants

 Produce verifiable specifications*

* Typically … continued
documented in the form of system specifications,
verification plans, simulations of expected behavior, use
cases and/or system requirements models

1 2 3 4
Desirable Characteristics of an
1
Engineering Requirement
 An engineering requirement is a documented
physical and functional need that a
particular product or service must perform
 A well documented requirement defines:
 Necessary attributes

 Necessary capabilities

 Necessary characteristics

 Necessary qualities

 How you will verify that the requirement

has been satisfied (usually, how you will
test it)
 Analyze the Requirements of
the System (continued)
1
 Confirm specifications with customer

 Will later use the specifications to test and evaluate the system, after
it is built

Note for U.S. Government Contracts: This activity occurs

(theoretically) during the concept exploration phase
 Software Notes 1

 Software can be used to support these activities

 Simulations
 Requirements Models
 Data Analysis
 The software needs for the final system are not
yet identified
 However, there is often a need to evaluate
potential algorithms for performance and
effectiveness
 Step 2 - Design the System

 Select/Design the architecture of the system << Synthesis,

not analysis
 Systems engineer and/or chief architect
 Software engineering expertise must be included in
the process
 Determine the major parts (functional decomposition into
sub-systems)
 Determine the interfaces between the subsystems
… continued

1 2 3 4
 2
Design the System
Step 1: Determine the Components and How
they Interface to Each Other

Acceleration:
0-60 in 6 Design the
seconds System
Braking: 200
yards at
60mph
…
Design
System Specifications;
Specifications Interface
Specifications
 Selecting the Component Parts (and how
they connect together) is a Major Task of
System Design

Typically documented in the form of system design

specifications, interface control documents, system
diagrams, and/or system design tools
 Design the System
Step 2: Allocate Requirements to 2
components

 Allocate requirements to the

components
 In other words, indicate which system
components accomplish which requirements
The software will
perform these
functions:
1) …
2) …
3) …

Allocation
Document
 Requirements Allocation
2
Documentation
 Allocation of requirements to subsystems or components may
be documented in:
 The system design documentation,

 A separate, “system segment design” document, or

 The requirements documentation for each subsystem

 Sometimes, the design process creates new requirements

(called derived requirements)
 These are requirements that come from the way the
system is designed, not from the original customer needs
 Design the System 2
Step 3: Specify the Requirements of Each
Component

Component X
Specify
Requirements Requirements

Design
Specifications;
Interface Requirements
Specifications; Specifications for
Allocation Each Component or
Subsystem
 How Many Levels of Detail?

You stop repeating when you have reached

enough detail to define the configuration
items -- the lowest level parts that you want to
manage at the system level
 How do you want to break the system into
parts?
 How do you want to manage the project?

 What are the most sensible logical

divisions?

Configuration
Item
 Software Note
 With object oriented design concepts,
selection of configuration items
becomes an even more difficult task
than it used to be
 and it has often been a difficult task
 More Software Notes

 A typical large system may have MANY software

configuration items

 Some designers may combine hardware and

software into a configuration item

 After identification of the software functions,

selection of configuration items is the next key
decision that software managers and technical
staff must participate in deciding
 Selection of Software Items
(Configuration Items)

 Ideally, a software item is something that will

be:
 Developed independently
 Tested independently (test cases, procedures,
etc.)
 Sold separately (part number, upgrades, price,
etc.)
 Maintained as a separate unit
 Supported with its own set of documentation
 Selection of Software Items
(continued)

 A software item may also

 Have a separate target processor
 Or a separate programming language

 Sometimes it is something that is so

important to system functionality that it is
separated out just to keep closer
management visibility
 Considerations when Selecting
Software Items (SIs)

 How many contractors will build / manage the SI?

 Ideally, one contractor per SI

 How many target processors?

 In many cases, there should there be one per SI?

 How many programming languages?

 Ideally, one per SI

… continued
 Considerations when Selecting
Software Items (continued)
 What are the schedules / delivery dates?
 Several releases of an SI vs. multiple SIs

 What is the best maintenance approach?

 Can you change one part without re-compiling
and re-testing many unrelated parts?

 How big will it be?

 If it is too big, perhaps it should be broken up

 Interfaces to other products?

 Keep them simple
 Step 3 - Build the System
 “Subcontract” the software, electrical,
mechanical, or other development tasks to
software engineers, electrical engineers, etc.
 Manage and maintain communication and
coordination during this period
 Example: controlling change to requirements
and interfaces
 Example: resolving differences of opinion
about interpretation of specifications

1 2 3 4
 Step 4 - Integrate the System
 Put the parts together
 This is the real test of whether the Systems
Engineer did the job right
1 2 3 4
 Step 3 - Subcontracting the
“Build the System” Process
Design the
Architecture
Analyze
& Allocate Build Integrate
Requirements
Requirements the System & Test
to
Parts

Electronics Packaging Software

Software
Development
Lifecycle
 Four Items Constitute a Good
Starting Point for a SW Project

 If you have these four, make sure they are as

complete and correct as you can get them
 If you do not have them, make them and then
confer with the customer(s) and systems
engineers to see if they agree with what they
say
 If equivalent information is available
elsewhere, make sure you have copies of the
equivalent information AND strong
communication with whomever is in charge of
changing things
 Four Key Items - The Starting Point for
Successful Software

1) Software Statement of Work

-- what to do and what to deliver
-- often the basis for a contract
-- the “requirements for the project”

2) Software Requirements Specification

-- the “requirements for the product”
-- specifically, what the software is required to
do and how you will test to see if it is correct
… continued
 Four Key Items - ...
(continued)

3) System Design Specification or

Description (and Allocation)
-- the parts of the system
-- how they interface
-- how requirements are allocated to the
component parts of the system

4) Requirements Trace
-- from software to system to customer
and back
 Some Important Considerations

 Make sure you include the views of all

“customers” relative to the four items in the
starting point
 Make sure you establish who controls changes
to each requirement, specification, statement
of work, etc.
 And make sure they are motivated to
inform the software manager of all changes
 Understand key dependencies on other parts
of the system
 Software Statement of Work
 Should clearly state all of the entry criteria for the
software effort

 Plus the specific tasks to be performed and

deliverables to be produced

 Constraints on schedule, resources, etc. (where

possible -- sometimes it is your job to determine
the needed schedule and resources)

 Plus applicable standards, etc

 Types of Software
There are many kinds of software, and
each of them may require a different
lifecycle model, a different process,
different kinds of specifications, and
different levels of support

Good software planning begins with an

analysis of ALL the software to be built
 Types of Software:

Demonstration or Requirements
Prototype

 Intended to demonstrate a concept and then be

thrown away.

 Goal is to get something working quickly and see

what it looks like.

 Usually found in early phases of system lifecycle

 Generally less emphasis on testing and quality

assurance
 Types of Software:

Evolutionary Prototype
 Intended to try a concept and then improve on
it until it is acceptable (but then throw away or
use?)

 Usually found in early phases of system lifecycle

 But sometimes this is the paradigm for

developing production software

 In which case we may need more formality and

more focus on testing and quality
 Types of Software:

Production Software
 Intended to be robust, easily maintained,
error free, reliable, etc.

 Generally the most expensive and slowest to

develop

 Generally found only in later phases of system

life cycle

 Beware of attempts to use prototypes as

production software
 Types of Software:

Test Software
 Intended to test some other software or
hardware.

 May be of “throwaway” or of
“production” quality

 Found in all phases of a system lifecycle

 Types of Software:

Simulation Software
 Intended to simulate some other system or
environment as part of a design or testing effort.

 Used throughout the system development

lifecycle

 It is important to keep changes under control so

that the simulation you test with corresponds to
the simulation you designed with
 Types of Software:

Debugging Software
 Used to find and fix errors in other software

 Used in all phases

 Needs to be robust but not usually safety or

time critical

 Good program planning includes up-front

planning of testing and debugging tools
 Types of Software:

Test Support Software

 Intended to support various forms of system
testing

 Generally developed late in the system life

cycle

 Generally viewed as temporary so not

usually developed with the same care as
application software

 Sometimes automatically generated via test

generation tools
 Types of Software:

Support Software
 Intended to support operation or maintenance
of a system

 Generally developed late in the system life

cycle

 Often not designed carefully as part of the

overall system

 But may be used for a long time

 What Types of Software Apply
to My Project?

 This is a key question that must be

determined by the systems engineering
and software engineering staff

 Each type may require its own analysis

of lifecycle and process requirements
 Deciding What Types of
Software Apply to Your Project
 Be careful to team the systems
engineering function with the software
engineering function to achieve the
most appropriate allocation of system
requirements to various software types
 END OF
Lecture 00