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 [email protected] Scope of Class. System/Software Development Process Requirements Analysis Design
Applied Systems AnalysisFall 2005
Class Notes 1
(315) 474 – 2774 (cell) 1 min question
(315) 456-3372 (work) 2 min question
(315) 703-6297 (home) 5 min question
Email [email protected]
You will analyze and design a practical system that will improve a real world situation.
Who the Heck are You?
What do you want from me?
No Computer Usage During a Lecture
Self Motivated Students will Likely Receive an “A”
UML is a Language Not a Process
Benefits of OO
LBVDS WLD-1 DD-21 V15
Objects are natural metaphors for both physical objects and
abstract entities. Expressing computations in terms of objects
reduces the gap between concept and program.
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).
Using inheritance, new objects and their behaviors can be defined
as incremental modifications and extensions of existing objects.
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.
More Re use
Better Human Cognition
$ Savings $
Objects / Classes/ Use Cases
Use Cases Tests Cases
How do I test the
What do I want?
How do I
Implement the requirements?
Each Use case becomes
Which are detailed in
Requirements get mapped to logical and physical components – just as they always did (Use cases & Classes)
Becomes more Detailed
OO Process Steps
What Really Happens
If you believe this,
I have a bridge I’d like to sell you
are done first,
then we do
Requirements are not glamorous
If you do a good job with requirements you will get NO credit
Because Requirements are boring – However?
If you have not done a good job on requirements, you will encounter a large # of changes and the associated cost overruns
Having requirements in a set of books will not allow you to assure and quickly update requirements. Database is needed.
Can be Circumvented in a Program Plan
Document assumptions, lineage, verifiability
Raise issue to the program level – Cost Risk Assumptions…..
We should do more of this.
Remember 49% of requirement errors are due to incorrect facts
Subjective Requirements from the customer must be converted into achievable and agreed to Requirements
Ugly and clear is better than beautiful and ambiguous
The system shall provide …
The system shall be capable of …
The system shall weigh …
The xyz subsystem shall provide … use acronyms
What Kinds of Requirements Are There?
Any particular requirement may be more than one type.
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.
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
Example 1: “All software shall be written in Ada.”
Example 2: “System MTBF shall be 100 hours.”
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.
A derived requirement results from analysis of a higher level requirement.
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.”
Each Requirement should be treated as if it were going to affect the program
Because it does
Improving Requirements, Case 1
Improving Requirements, Case 2
Improving Requirements, Case 3
Improving Requirements, Case 4
Improving Requirements, Case 5
Student Requirement Statement Exercises
Student Requirement Exercise 1
Student Requirement Exercise 2
Student Requirement Exercise 3
Student Requirement Exercise 4
Student Requirement Exercise 5
Student Requirement Exercise 6
Student Requirement Exercise 7
Student Requirement Exercise 8
Student Requirement Exercise 9
Student Requirement Exercise 10
Student Requirement Exercise 11
Student Requirement Exercise 12
Student Requirement Exercise 13
Student Requirement Exercise 14
Student Requirement Exercise 15
Student Requirement Exercise 16
Student Requirement Exercise 17
Student Requirement Exercise 18
Student Requirement Exercise 19
Student Requirement Exercise 20