Applied Systems Analysis Fall 2005

1
Applied Systems AnalysisFall 2005
Class Notes 1

• Douglas Low
• (315) 474 2774 (cell) 1 min question
• [phone] (work) 2 min question
• [phone] (home) 5 min question
• Email Douglas.a.low_at_lmco.com

2
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.
3
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 beginningFlailing 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?
4
MIS 375

• Read Assigned Chapters 10
• Attendance required 10
• Attendance required at the beginning and end of
  class
• Project 40
• Requirements Doc group 10
• System Analysis Doc group 20
• Design Doc and presentation 10
• UML Homework Assignments 30
• UML In class Exercises 10

No Computer Usage During a Lecture Self Motivated
Students will Likely Receive an A
5
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

6
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
7
Objects UML Use cases

• Object Oriented Software was invented by Xerox
  Parc in the 80s.
• 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.

8

• Why OO?

9
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

LBVDS WLD-1 DD-21 V15
Direct expression 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
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

• 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

• -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

Faster Development Increased quality less
re-work More Re use Easier maintenance Better
Human Cognition Reduced Risk
Savings Customer Satisfaction
10
Customer -gt Systems Analysis. -gt Software

• What will the system do?
• Define the Requirements (Analyze)
• How will the system do it?
• Decompose the system (Design)
• Assure the best solution (Analyze - Trade offs)

How do I test the Requirements?
Test
What do I want?
Customer
Systems Analysis
Specialty Engineering
Specialty Requirements
Software / Hardware Engineering
How do I Implement the requirements?
11
Classical Systems engineering vs. Object Oriented
Analysis
Introducing Neo-Classical Systems Analysis
12
Classical Systems Engineering Process
What Does the Customer want?
Obligation
Commitment
What will the system do?
OOA performs all this except internal functional
interfaces
How will the system do it?
13
Syracuse As-Is
What Does the Customer want?
What Does the Customer want?
3.3 Perform Functional / Use Case Analysis
What will the system do?
How will the system do it?
14
Neo-Classical Systems Engineering
Obligations

• What will the system do?
• Functional Analysis
• Use Case Analysis

• What does the customer want?
• Requirements Analysis

• How will the system do it?
• Synthesis / Architecture Design
• Object Oriented Analysis

Commitments
Control and Balance
15
Software Analysis Steps
Needs Analysis
Conops
System/subsystem Analysis
CI Analysis
Element Analysis
Build Elements
Integrate and test
Object Oriented Analysis is an evolutionary step
as opposed to a complete new generation
16
In a Nutshell (modified from Rosenberg)
Dynamic
Each Use case becomes Multiple Scenarios Which
are detailed in
Use Case Model
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
17
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
18
OO Software Requirements Spec. (SRS) Contents

• Normal SRS type stuff
• Scope, Referenced Documents, Ilities., Trace
  table.
• Use cases How the system is used.
• Class model or first level decomposition of the
  CI
• Functional and Performance Requirements
• Assigned to Use Cases instead of functions
• Additionally assigned to classes
• New kinds of traceability
• Interfaces
• Actors (always external to the CSCI)
• Methods (internal or external )

19
What is in and OO SRS?

• Terms
• Packages
• Actors
• Inheritance
• Relationships
• Interaction
• Behavior
• Scenarios
• Stereotypes

• Diagrams
• Use Cases diagrams
• Sequence Diagrams
• Domain Model
• Class / Object diagram
• Classes / objects
• Methods / operations
• Hidden/private data
• Deployment diagram
• State diagram

20
OO Interface Between S/W and Systems Engineering
Use Cases -
Test cases
Needs Test Engineering Involvement
CI Domain Model -
S/W Design
Needs S/W Engineering Involvement
Traceability
Integrated Product Teams should Be applied to the
SE/SW activities
21
IEP Requirements Flow-down Process
Represents a Minor Deviation from LMIEP Standard
V1.3
22
Personnel View One Engineering Process with
Multiple Groups Responsible for Specific Products
Systems Engineers
Integrated Product Leads Lead Systems Eng Lead
Software Eng Lead Test Eng
S/W H/W Engineers
Test Engineers
Generate
OCD S/SS, PIPS/PIDS, SRS, CIPS/CIDS, IRS
Updated Specifications, ICD
SSDD System IVV Plans System IVV
Procedures Trade Study/ Analysis
Reports Architecture Design Specification
(ADS) Design docs, unit test docs System
Integration Reports, System VV Reports
Has Responsibility For Specific Products
Systems Engineering
S/W H/W Engineering
Test Engineering
Requirements Architecture
Design Develop
Integrate Test
23
Program / Document View
Analyze Stakeholders Needs
Analyze System Requirements
OO Phases
Design System
Implement System Elements
Integrate Systems
Validate and Verify the System
ADS
CIPS/CIDS
OCD
S/SS
SRS,
System VV Reports
IRS,
IDD / ICD
Technical
Products
System IVV Plans System IVV Procedures
System Integration Reports
Trade Study/ Analysis Reports
SSR
SRR
SDR/
PDR
CDR
TRR
FCA
PCA
HSR
SFR
Milestones
Product
Baseline
Integrate System
Determine customer needs
Validate and Verify System
Develop Requirements
Develop Architecture
Activities
Develop S/W
Develop H/W
Support Systems Engineering
Manage Configuration Items
24
Requirements
25
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.

26
Requirements are done first, then we do design.
Integration and Test
27
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

28
Effect of Requirements Definition on Program
Costs Werner Gruhl NASA

• Poor Assumptions
• Everyone knows how to write requirements
• Requirements will take care of themselves
• The Review process will fix all problems
• Proper Assumptions
• 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

If you have not done a good job on requirements,
you will encounter a large of changes and the
associated cost overruns
Requirements cost
29
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.
30
(No Transcript)
31
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
32
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..
33
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

We should do more of this.
34
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
35
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
36
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
• Ask yourself - Why? Because
• I need traceability between requirement levels
• I need to add capability to add attributes to
  requirements
• I need to be able to sort the requirements
• I need to be able to filter the requirements
• The Data Base becomes a program element which has
  requirements associated with it.

Ugly and clear is better than beautiful and
ambiguous

• Example shall be stowed while underway
• This is an operational requirement not a system
  requirements
• Should be shall provide a stowage environment

The system shall provide The system shall be
capable of The system shall weigh The xyz
subsystem shall provide use acronyms
37
What Kinds of Requirements Are There?

• 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

• Contractual
• Management
• Regulatory
• Environmental
• Technical
• Operational

Any particular requirement may be more than one
type.
38
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 dont. It helps place
the requirement in the proper section.
39
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
40
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.

41
The top 10 Reasons for Not Doing Requirements
10. We dont need requirements, were using
objects/java/
9. The users dont know what they want
8.We already know what the users want
7.Who cares what the users want?
6. We dont have time to do requirements
5. Its too hard to do requirements
4. My boss frowns when I write requirements
3. The problem is too complex to write
requirements
2. Its easier to change the system later than to
do requirements up front.
1. We have already started writing code, an we
dont want to spoil it.
www.Volere.co.uk
42
Requirements are Linked

• To higher level requirements derived and
  allocated
• Flow down
• To use cases gt Test cases
• To objects
• To analyses

43
Linkage Example

• A derived requirement results from analysis of a
  higher level 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.

Analysis
Original Requirement
Derived requirement
44
Summary Make it Better

• Program Plan Goals, Objectives, Constraints,
  Missions, Operational Concept
• Dont 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
45
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?

46
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.

47
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.

48
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.

49
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.

50
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)

51
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

52
Student Requirement Exercise 2

• Requirement AAA05350 The external markings
  shall be in accordance with the customer's
  requirements.
• Problems
• Better

53
Student Requirement Exercise 3

• Requirement SAF00200 Specify interlocks,
  shielding, safety guards, barriers, and warning
  markings where a personnel hazard can exist.
• Problems
• Better

54
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

55
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

56
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

57
Student Requirement Exercise 7

• Requirement SAF00870 Delicate equipment
  shall be located where it will not be damaged
  during maintenance.
• Problems
• Better

58
Student Requirement Exercise 8

• Requirement SAF01060 New/modified air
  distribution and outlets shall be designed to
  minimize noise levels.
• Problems
• Better

59
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

60
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

61
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

62
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

63
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

64
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

65
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

66
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

67
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

68
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

69
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

70
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

71
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

72

• 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
  directivesthe 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.