Applied Systems Analysis
Fall 2005
Class Notes 1
Douglas Low
(315) 474 – 2774 (cell) 1 min question
(315) 456-3372 (work) 2 min question
(315) 703-6297 (home) 5 min question
Email Douglas.a.low@lmco.com
Scope of Class
• System/Software Development Process
– Requirements
– Analysis
– Design
• OO Analysis and Design using UML
– How to develop use cases and associated artifacts
– How and When to use What diagrams
– What is and When to use OO vs. Functional
• What is architecture? How to not abuse it.
• Trade studies and feasibility analysis
• Linkage of requirements to design and analysis classes
– Useful during system sell off.
You will analyze and design a practical system
that will improve a real world situation.
Who the Heck is this Guy?
• Douglas Low
– MS in Computer science from SU
– Been with GE/ Martin Marietta/ Lockheed Martin for 23 years.
• Half in Software half in Systems engineering
• RADAR and SONAR
– Worked on OO extensively for DD-21
• From the beginning…Flailing… Formal courses… many Use cases
– Working with the OOSESWWG at the Corporate level
– Working with (not for) our local Process group to develop the
OO process
• SRS
• Architecture Document
Who the Heck are You?
What do you want from me?
MIS 375
• Read Assigned Chapters
• Attendance required
10%
10%
– Attendance required at the beginning and end of class
• Project
– Requirements Doc group
– System Analysis Doc group
– Design Doc and presentation
• UML Homework Assignments
• UML In class Exercises
40%
10%
20%
10%
30%
10%
No Computer Usage During a Lecture
Self Motivated Students will Likely Receive an “A”
Development Process
• Identify the problem (SOW)
• Analyze the problem (System Requirements)
• Design
– Identify Alternate, candidate approaches to solve the problem
– Design the chosen solution
• Build
– ..the chosen architecture pieces
– Put the pieces together (integration)
• Test
– ..the parts
– ..the system
What is UML?
• Unified Modeling Language
– Graphical Language
• An attempt to combine notation from many
analysis and design notations
– Booch, Rumbaugh, Jacobson ……
– Now is controlled by Object Management Group of
which LM is a member.
• Moving to UML 2
– Includes Codes from diagrams
UML is a Language Not a Process
Objects – UML – Use cases
• Object Oriented Software was invented by Xerox Parc in the 80’s.
– Partitioned software into objects that owned its data and kept it private as much as
possible.
– Data hiding, data encapsulation were concepts that were fundamental to OO
• Use Cases were invented by Ivar Jacobson in 1986
–
–
–
–
Use case model describes the interaction of system with the outside world.
Describes the behavior or functionality of a system from the outside in.
“use case model is intended for communicating with customers and users”
“A special sequence of transactions performed by a user and a system in dialogue.”
• UML – Unified Modeling Language
– A visual language designed to construct, visualize and document artifacts of
software systems
– Incorporates several elements of three major diagramming notations into one
language.
• Why OO?
Benefits of OO
•
Maintenance and evolution of a system cause changes,
but they are isolated to specific components, not the
entire system.
•
Object-oriented concepts provide a framework for
development according to effective systems and software
engineering principles
•
Application of reusable components is facilitated and
results in lower development costs across projects.
•
Object technology facilitates higher built-in quality, due
to improved understandability, usability, maintainability,
extensibility, modifiability, and reusability."
ACC
-reduced time to market
–greater product flexibility
–schedule predictability
–expressive power of OO
–encourages reuse
–resilience to change
–reduced risk
–appeals human cognition
Kåre Synnes
LBVDS WLD-1 DD-21 V15
Direct expression
•Faster Development
•Increased Quality
•Easier Maintenance
•Enhances Modifiability
•Easier reuse
•System more resilient to change
•Reduced development risks for
complex systems due to integration
spread out
•Appeals to human cognition
Colorado University
Objects are natural metaphors for both physical objects and
abstract entities. Expressing computations in terms of objects
reduces the gap between concept and program.
Malleability
Good programs evolve. Evolution is easiest when the
modifications are local. Objects combine data with functions to
manipulate that data (allowing localization) and access to objects'
data is restricted (enforcing localization).
Extensibility
Using inheritance, new objects and their behaviors can be defined
as incremental modifications and extensions of existing objects.
Abstraction
Faster Development
Increased quality
less re-work
More Re use
Easier maintenance
Better Human Cognition
Reduced Risk
Using polymorphism, similarities among objects can be expressed
in the program, allowing us to write code in terms of the similarities
without regard to the differences.
COBOLREPORT.com
$ Savings $
&
Customer Satisfaction
Customer -> Systems Analysis. -> Software
What do I want?
Customer
• What will the system do?
How do I test the
•Define the Requirements (Analyze)
Requirements?
• How will the system do it?
•Decompose the system (Design)
• Assure the best solution (Analyze - Trade offs)
Test
Use Cases
Systems
Analysis
Specialty
Requirements
•Customer helps define system behavior with Use Cases
•Use cases become Test cases for all levels of
decomposition (System, Segment, CI)
•Define requirements in terms of objects and Use Cases
Specialty
Engineering
Software /
Hardware
Engineering
How do I
Implement the requirements?
In a Nutshell (modified from Rosenberg)
Dynamic
Use Case
Model
Each Use case becomes
Multiple Scenarios
Which are detailed in
Sequence
Diagram
Requirements get mapped to logical and physical components
– just as they always did (Use cases & Classes)
Static
Becomes more Detailed
And eventually
Domain
Model
Class
Diagram
OO Process Steps

Define requirements
Allocate and Derive requirements
Map requirements to use cases
Map requirements to classes

Define use cases
Draw Diagrams
Write use case summary
Include requirements & External Interfaces

Define domain model class diagram
Add attributes when known

Review requirements

Define use case scenarios
Include a summary

Define first level decomposition class diagram
Take from domain class diagram
Include boundary objects, controllers and entities


Review Preliminary Design
Create a sequence diagram for each scenario
Use only objects in the class diagram
Update scenario documentation to include details

Update class diagram
Add methods to classes when known (Internal interfaces)


Update Documentation (interfaces etc.)
Review Design
R
Requirements
Requirements Are…..
• Specific, demonstrate-able, statements that exactly
specify what the system will do as well as a set of
constraints that the system will operate under.
• A contract with the customer
• Usually have the word “shall” in it. For example:
– The students shall do their homework.
– If the students do not do their homework they shall be
penalized.
• Penalization for missing homework assignments shall be a
zero entered for the homework assignment.
– If a student “instant messages” during class they shall
receive a zero for class attendance for that day.
Misconceptions
Requirements
Analysis
High Level
Design
Detailed
Design
Requirements
are done first,
then we do
design.
Manufacture H/W
Code S/W
Integration
and Test
If you believe this,
I have a bridge I’d like to sell you
#1 Problem with Requirements
Requirements are not glamorous
Architecture
How
Requirements
What
If you do a good job with
requirements you will get
NO credit
Because Requirements are
boring – However?
You Must Get Organized
in order to assure:
•Complete, Accurate,
Doable …
Effect of Requirements Definition on Program Costs –
Werner Gruhl NASA
If you have not done a good job
on requirements, you will
encounter a large # of changes
and the associated cost overruns
Poor Assumptions:
•Everyone knows how to write
requirements
•Requirements will take care of
themselves
•The Review process will fix all
problems
Proper Assumptions:
Requirements cost
•Everyone does not know how
to write good requirements
•The requirements definition
process is not well understood
•The review process cannot fix
all problems
•Bad Requirements will be a
major cost driver over the life of
the program
Types of Requirements Errors
•Requirements drive:
-complexity
-cost
-schedule
-verification
-operations
•Provide contractual basis for
verification and acceptance
Having requirements
in a set of books will
not allow you to
assure and quickly
update requirements.
Database is needed.
Problems with Requirements
• Lack of
Management Interest
– Everyone knows how to write
Requirements
• Lack of Know how
– A Requirement is:
• Necessary
• Attainable
• Testable
• Lack of Information leads to bad Assumptions
– Required to write good requirements
• Scope – needs, goals, constraints, budget, schedule
• Missions
• Operational Concept
Can be Circumvented in a Program Plan
The Requirements process is not well understood
• Requirements Process should be included in a well defined
program plan
• The owner of each requirement must Analyze:
– Is it Necessary - Not a wish list
• Prioritize & scrutinize
• Maintain its lineage
– Is it Verifiable - How will the requirement be tested?
– Is it Achievable – Technical and Cost
• If a question exists, place it on the risk plan
– Is it Clearly written
– Does the requirement apply to a single component?
– Is it at the proper level (system, subsystem, element, component)
Coordinated effort with all stakeholders included e.g. Customer,
Manufacturing, Specialty, Equipment eng, …
Document assumptions, lineage, verifiability
Raise issue to the program level – Cost Risk Assumptions…..
Is Each Requirement Necessary
• Examine (and Document?) each Requirement
–
–
–
–
–
Assumptions
Why it is necessary
What is the cost impact
Prioritize the requirement
Maintain the lineage
Is Each Requirement Achievable
• Technical, Schedule and Cost Considerations
• Get the facts right
• Place in a risk pool until fully analyzed
Remember 49% of requirement errors are due to
incorrect facts
Is each Requirement Verifiable
• Subjective requirements are not verifiable
– Look for words like: Maximize, minimize, support, adequate, but
not limited to, user friendly, easy, sufficient
• Determine how each requirements will be verified as it is
written
–
–
–
–
test, ‘shall be .3 seconds’
demonstrate, ‘shall be capable of simultaneous viewing’
analyze, ‘ MTBF shall be 1 day’
Inspect, ‘shall be green’
Subjective Requirements from the customer must be
converted into achievable and agreed to Requirements
Is Each Requirement Clearly Written
• Single Thought
• Concise
• Simple sentences
– One subject one verb one
object
• Stand-alone
• Unambiguous
• What not How
•
•
Forcing a design that is not needed
Forcing a design does not meet the needs
Example: ‘shall provide a Data base’
Ugly and clear is better than
Ask yourself - Why? Because:
beautiful and ambiguous
•I need traceability between requirement
levels
Example: ‘ shall be stowed while underway’
•I need to add capability to add
•This is an operational requirement not a system
attributes to requirements
requirements
Should be: ‘shall provide a stowage environment’
•I need to be able to sort the
requirements
•I need to be able to filter the
The system shall provide …
requirements
The system shall be capable of …
The Data Base becomes a program
element which has requirements
associated with it.
The system shall weigh …
The xyz subsystem shall provide … use acronyms
What Kinds of Requirements Are There?
•Contractual
•Management
•Regulatory
•Environmental
•Technical
•Operational
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Functional
Performance
EMC/EMI
Safety
Security
Test
Packaging
Reliability
Portability
Schedule
Interface
COTS/NDI
Cost
Data
–
–
–
–
–
–
–
–
–
–
–
–
–
Training
GFE/CFE
Physical
Characteristics
Design & Construction
Quality Assurance
Power/Grounding
Human Factors
Transportability
Maintainability
Supportability
Producibility
Availability
Disposal
Any particular requirement may be more than one type.
Requirement Database Types
All Requirements are defined in the requirements database as one
and only one of the following types:
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Ø
Functional “… shall automatically track airborne targets…”
Performance “…shall discriminate targets within 3 minutes…”
Capacity “…shall maintain 300 tracks in the …”
Constraint including cost, specific equipment, legacy components
etc.
Reliability “ MTBF shall be 100 days”
Interface “ … shall use RS-232 interface to … “
Test “… the system test shall stress the system …”
Safety “ “in accordance with SPCL-610 and BI-431
Data “…shall depict target range in meters…”
We should do this but we don’t.
It helps place the requirement in the proper section.
Right and Wrong Terms
• WRONG: The system shall support a training coordinator
in defining scenarios
• RIGHT: The system shall provide input screens for
defining training scenarios.
Or The system should support a training coordinator in
defining scenarios
Beware of: Maximize, minimize, support,
adequate, but not limited to, user friendly, easy,
sufficient
Requirements Shall
Facts Will
Goals Should
Requirements Beget Requirements
• Additional requirements are allocated or derived from
the original set.
• An allocated requirement is a system requirement that
is allocated in whole or in part to subsystems,
components, etc.
Example 1: “All software shall be written in Ada.”
 Direct Allocation: Allocated in whole to all software
components.
Example 2: “System MTBF shall be 100 hours.”
 Apportioned: Subsystem MTBFs allocated via reliability
analysis.
The top 10 Reasons for Not Doing Requirements
10. We don’t need requirements, we’re using objects/java/…
9. The users don’t know what they want
8.We already know what the users want
7.Who cares what the users want?
6. We don’t have time to do requirements
5. It’s too hard to do requirements
4. My boss frowns when I write requirements
3. The problem is too complex to write requirements
2. It’s easier to change the system later than to do
requirements up front.
1. We have already started writing code, an we don’t want
to spoil it.
www.Volere.co.uk
Requirements are Linked
• To higher level requirements derived and allocated
– Flow down
• To use cases > Test cases
• To objects
• To analyses
Linkage Example
A derived requirement results from analysis of a higher
level requirement.
Original
Requirement
Analysis
Derived
requirement
Examples:
High level requirement: “Door when closed shall
prevent outside air from entering the room at a rate
greater than 10 cc per hour.”
Derived requirement: “Tolerance between door and door
frame shall be no greater than .1 inches.”
 Linked to the original requirement and an analysis of the
door leakage.
Summary – Make it Better
• Program Plan – Goals, Objectives, Constraints,
Missions, Operational Concept
– Don’t start until you have these
• Necessary, Verifiable, Achievable
– The process includes tests for each of these
– Treat each requirement as if it were a change
• Accountability – Each requirement should have
an owner
– Owner should be willing to defend the need for each
requirement
Each Requirement should be treated as if it were going to
affect the program
Because it does
Improving Requirements, Case 1
• Requirement: “The pilot and/or co-pilot shall also be able to
hear or see a visible or audible caution/warning signal in case
of emergency, hazard, etc.”
• Problems
–
–
–
–
–
Multiple requirements. (Pilot/co-pilot see/hear)
What emergency, hazard, etc. conditions?
Defining a solution with visible or audible warning?
What are pilot/co-pilot able to see/hear?
What do you verify?
• Better
– 1. The system shall provide a caution/warning signal to the pilot in case
of emergency or hazard conditions defined in Appendix A. 2. Similar
for co-pilot.
– If we insist on specifying the type of signal: The system shall provide an
X dB audible (Y micron visible) caution/warning signal to the pilot in
case of emergency or hazard conditions defined in Appendix A. Similar
for co-pilot. Signal duration?
Improving Requirements, Case 2
• Requirement: “The user shall be notified with a low battery
warning lamp light when the voltage drops below 3.6 volts and
the current workspace or input data shall be saved.”
• Problems
– Multiple requirements. (Notify and save)
– Defining a solution with warning lamp light?
– What do you verify?
• Better
– 1. The system shall provide a signal when the voltage drops below 3.6
volts.
– 2. The system shall save the current workspace data when the voltage
drops below 3.6 volts.
Improving Requirements, Case 3
• Requirement: “The crew shall always hear the
smoke detector alarm when smoke is detected unless
the alarm is being tested or suppressed.”
• Problems
– Subjective wishful thinking - “always hear”
– Loophole for escape - “unless”
– What do you verify?
• Better
– 1. The smoke detector shall provide an alarm to the crew
when smoke is detected.
– 2. The crew shall be able to suppress the smoke detector
alarm when the detector is in the “Test” mode.
Improving Requirements, Case 4
• Requirement: “Provided that the designated input
signals from the specified devices are received in the
correct order where the system is able to differentiate
the designators, the output signal shall comply with
the required framework of section 4.4.5 to indicate the
desired input state.”
• Problems
– Rambling long sentence
– What do you verify?
• Better
– 1. The output signal shall comply with section 4.4.5.
– 2. The output signal shall provide the input state.
Improving Requirements, Case 5
• Requirement: “The user shall be provided with a
user-friendly front end for operating the system.”
• Problems
– Vague terminology
– What do you verify?
• Better
– 1. The system shall provide menus and dialog boxes to aid
the user in operating the system. Or,
– 2. The system shall provide step-by-step instructions to
guide users in starting operations.
Student Requirement Statement Exercises
• Review, comment on, and improve the requirement
statements on the following charts
• Do these statements
– Have the attributes of a “good” requirement? (Clear,
complete, consistent, correct, feasible, objective,
problematic, singular, succinct, verifiable)
– Satisfy style tips for “good” requirements? (Simple
sentence, correct grammar and spelling, avoids excess
modifiers, avoids subjective language, required or desired,
avoids abbreviations and acronyms, unique identifier,
independent of outside text, free of loopholes)
Student Requirement Exercise 1
• Requirement: [AAA05520] It shall be possible to check that the
software contains no unauthorized features. This will be done by
manual means and by use of such automatic aids as may be
available at the time.
• Problems
–
–
• Better
Student Requirement Exercise 2
• Requirement: [AAA05350] The external markings shall be in
accordance with the customer's requirements.
• Problems
–
–
• Better
Student Requirement Exercise 3
• Requirement: [SAF00200] Specify interlocks, shielding, safety
guards, barriers, and warning markings where a personnel hazard
can exist.
• Problems
–
–
• Better
Student Requirement Exercise 4
• Requirement: [SAF00670] New equipment, modifications,
rearrangements, or new interfaces for existing equipment shall be
designed to ensure the level of safety of the present system is
maintained. New systems will be designed with an absolute minimum
of connections and terminations.
• Problems
–
–
• Better
Student Requirement Exercise 5
• Requirement: [SAF00330] All energized light indicators shall be
legible when reviewed under actual or simulated bright sunlight
conditions or under a blackout enclosure (including NVIS) and shall
be easily readable by the aircrew.
• Problems
–
–
• Better
Student Requirement Exercise 6
• Requirement: [SAF00760] Equipment which retain high potential
after it has been turned off shall be located where personnel cannot
touch it and discharge circuits shall be provided to dissipate the
charge in the shortest possible time after the equipment is turned off.
• Problems
–
–
• Better
Student Requirement Exercise 7
• Requirement: [SAF00870] Delicate equipment shall be located
where it will not be damaged during maintenance.
• Problems
–
–
• Better
Student Requirement Exercise 8
• Requirement: [SAF01060] New/modified air distribution and outlets
shall be designed to minimize noise levels.
• Problems
–
–
• Better
Student Requirement Exercise 9
• Requirement: [SAF01090] The cockpit sensing portion of the air
conditioning temperature control system shall be located in the
cockpit to provide optimum temperature for the greatest number of
crew members.
• Problems
–
–
• Better
Student Requirement Exercise 10
• Requirement: [RMS00660] As a goal, single error correct/double
error detect code shall be used in large bulk semiconductor
memories. It should be considered in any application involving large
amounts of semiconductor memory, but may impose unacceptable
speed and complexity penalties in some applications (e.g., CPU).
• Problems
–
–
• Better
Student Requirement Exercise 11
• Requirement: [AAA04760] Safety critical equipment shall comply
with the applicable performance standard when subjected to the
specified lightning requirements.
• Problems
–
–
• Better
Student Requirement Exercise 12
• Requirement: [AAAA1080] A suitable means shall be provided for
extraction and conversion of the recorded data to a format that, when
using existing equipment, will readily permit analysis by ground
facilities.
• Problems
–
–
• Better
Student Requirement Exercise 13
• Requirement: [AAAA0630] Assuming the radar target is identifiable
to the operator and the position of the radar target is accurately
known, then the radar contribution to aircraft position accuracy shall
be less than 125 feet +/-10% plus the target position error (CEP) at 5
nm from 300 feet above ground level (AGL).
• Problems
–
–
• Better
Student Requirement Exercise 14
• Requirement: [AAAA0047] The Mission Computer shall issue an
ACAWS message if unsafe ramp and cargo door operation is
attempted.
• Problems
–
–
• Better
Student Requirement Exercise 15
• Requirement: [RMS00940] This concept shall be such that minor
repair and check out of the modules may be accomplished at the
intermediate maintenance level with the more extensive repair and
check out accomplished at depot level maintenance.
• Problems
–
–
• Better
Student Requirement Exercise 16
• Requirement: [RMS00340] Module retention techniques shall be
carefully designed to integrate the insertion mechanism, required
connector insertion force, thermal contact area, and extraction
mechanism. Heretofore, conventional electronics have required the same
considerations, but to a lesser degree because of their more conventional
housings.
• Problems
–
–
• Better
Student Requirement Exercise 17
• Requirement: [AAA05510] It shall be possible to inspect the
hardware from time to time for unauthorized modifications. To this
end, hardware construction will be as simple and as standard as
possible.
• Problems
–
–
• Better
Student Requirement Exercise 18
• Requirement: [AAA05190] The C-130J Aircraft System shall be
designed and constructed to minimize electromagnetic interference
and propagation from the subsystems in accordance with Mil-Std
1818.
• Problems
–
–
• Better
Student Requirement Exercise 19
• Requirement: [SDA00020] Minimum utilization of strategic
materials shall be observed in development of the airplane. Specified
materials shall be given preference over proprietary items and shall
conform to applicable specifications.
• Problems
–
–
• Better
Student Requirement Exercise 20
• Requirement: [AAA05720] The equipment will be as small and as
light as is practical and shall be capable of being easily handled.
• Problems
–
–
• Better
Homework 1 (by next week)
• Read
– Whitten Chap 1 & 3
– Answer 5 questions per chapter (see following
page)
– Come with questions
• Write requirements for your perfect spouse
– At least 20 requirements
– For each requirement, define the verification
type. (test, analyze, demonstrate, inspect)
– Keep it polite
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Chap 1
Define information system and name seven types of information system applications.
Define stakeholder and Identify different types of stakeholders who use or develop
information systems, give examples of each.
Define the unique role of systems analysts in the development of information systems.
Identify those skills needed to successfully function as an information system analyst.
Describe current business drivers that influence information systems development.
Describe current technology drivers that influence information systems development.
Briefly describe a simple process for developing information systems.
Differentiate between the waterfall and the iterative/incremental approaches to systems
development.
Chap 3
Describe the motivation for a system development process in terms of the Capability
Maturity Model (CMM) for quality management.
Differentiate between the system life cycle and a system development methodology.
Describe 10 basic principles of system development.
Define problems, opportunities, and directives—the triggers for systems development
projects.
Describe the PIECES framework for categorizing problems, opportunities, and directives.
Describe the essential phases of system development. For each phase, describe its purpose,
inputs, and outputs.
Describe cross life cycle activities that overlap multiple system development phases.
Describe typical alternative “routes” through the basic phases of system development.
Describe how routes may be combined or customized for different projects.
Describe various automated tools for system development.