Applied Systems Analysis Fall 2005 Douglas Low (315) 474 – 2774 (cell) 1 min question (315)...

Applied Systems Analysis

Fall 2005

Douglas Low(315) 474 – 2774 (cell) 1 min question(315) 456-3372 (work) 2 min question(315) 703-6297 (home) 5 min question

Email [email protected]

Class Notes 1

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

Faster DevelopmentIncreased quality

less re-workMore Re useEasier maintenanceBetter Human CognitionReduced Risk

$ Savings $ &

Customer Satisfaction

•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

Direct expression

Objects are natural metaphors for both physical objects andabstract entities. Expressing computations in terms of objectsreduces the gap between concept and program.

Malleability

Good programs evolve. Evolution is easiest when themodifications are local. Objects combine data with functions tomanipulate that data (allowing localization) and access to objects'data is restricted (enforcing localization).

Extensibility

Using inheritance, new objects and their behaviors can be definedas incremental modifications and extensions of existing objects.

Abstraction

Using polymorphism, similarities among objects can be expressedin the program, allowing us to write code in terms of the similaritieswithout regard to the differences. COBOLREPORT.com

LBVDS WLD-1 DD-21 V15

Customer -> Systems Analysis. -> Software

Systems Analysis

Customer

Test

Software /Hardware

Engineering

How do I test the Requirements?

How do I Implement the requirements?

• 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)What do I want?

Use Cases

•Customer helps define system behavior with Use Cases

Use Cases T

ests Cases

•Use cases become Test cases for all levels of decomposition (System, Segment, CI)

Objects / Classes/ Use Cases

•Define requirements in terms of objects and Use Cases

SpecialtyEngineering

SpecialtyRequirements

In a Nutshell (modified from Rosenberg)

Static

Dynamic

Becomes more DetailedAnd eventually

Domain Model

Class Diagram

Use CaseModel Sequence

Diagram

Requirements get mapped to logical and physical components – just as they always did (Use cases & Classes)

Each Use case becomesMultiple Scenarios

Which are detailed in

OO Process Steps Define requirements

Allocate and Derive requirements

Map requirements to use cases

Map requirements to classes

Define use casesDraw Diagrams

Write use case summary

Include requirements & External Interfaces

Define domain model class diagramAdd 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 diagramAdd 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.

Integration and Test

Requirements are done first,

then we do design.

Requirements Analysis

High Level Design

Detailed Design

Manufacture H/WCode S/W

MisconceptionsMisconceptions

If you believe this, I have a bridge I’d like to sell you

What Really Happens

#1 Problem with Requirements

Requirements are not glamorous

If you do a good job with requirements you will get

NO creditBecause Requirements are

boring – However?

RequirementsWhat

ArchitectureHow

You Must Get Organized in order to assure:•Complete, Accurate, Doable …

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

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 Information leads to bad Assumptions – Required to write good requirements

• Scope – needs, goals, constraints, budget, schedule

• Missions

• Operational Concept

• Lack of Know how– A Requirement is:

• Necessary

• Attainable

• Testable

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)

Document assumptions, lineage, verifiability

Coordinated effort with all stakeholders included e.g. Customer, Manufacturing, Specialty, Equipment eng, …

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

We should do more of th

is.

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

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.

• Stand-alone

• Unambiguous

• What not How• Forcing a design that is not needed

• Forcing a design does not meet the needs

Example: ‘ shall be stowed while underway’•This is an operational requirement not a system requirementsShould 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

Ugly and clear is better than beautiful and ambiguous

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

Requirements ShallFacts WillGoals Should

Beware of: Maximize, minimize, support, adequate, but not limited to, user friendly, easy, sufficient

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 want8.We already know what the users want 7.Who cares what the users want?6. We don’t have time to do requirements5. It’s too hard to do requirements4. My boss frowns when I write requirements3. The problem is too complex to write requirements2. 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 ExampleA 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.

Derived requirement

OriginalRequirement

Analysis

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 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 2Improving 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.


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


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


• 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 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 1Student 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 2Student Requirement Exercise 2Student Requirement Exercise 2Student Requirement Exercise 2

• Requirement: [AAA05350] The external markings shall be in accordance with the customer's requirements.

• Problems– –

• Better


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

• Problems– –

• Better


• 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


• 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


• 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


• Requirement: [SAF00870] Delicate equipment shall be located where it will not be damaged during maintenance.

• Problems– –

• Better


• Requirement: [SAF01060] New/modified air distribution and outlets shall be designed to minimize noise levels.

• Problems– –

• Better


• 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


• 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


• Requirement: [AAA04760] Safety critical equipment shall comply with the applicable performance standard when subjected to the specified lightning requirements.

• Problems– –

• Better


• 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


• 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


• Requirement: [AAAA0047] The Mission Computer shall issue an ACAWS message if unsafe ramp and cargo door operation is attempted.

• Problems– –

• Better


• 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


• 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


• 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


• 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


• 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


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

Date post:	20-Dec-2015
Category:	Documents
View:	221 times
Download:	3 times

Applied Systems Analysis Fall 2005 Douglas Low (315) 474 – 2774 (cell) 1 min question (315)...

Documents