Understanding System Analysis and Design: Frameworks, Models, and Success Factors

1. Overview • What is system analysis and design? • Tools and models • Methodologies

2. Information Systems • What is a system? • Why do systems fail? • What is systems analysis and design? • How do we do systems analysis?

3. What is a system? • A collection of parts • that work together • to achieve a goal/task

4. What is an information system? • Parts? • Usually on of the parts is a computer • Task? • The difficulty is getting the parts to work together

5. Complexity in Systems • IS are needed for large/complex tasks • Solve complexity by partitioning • More parts  More interaction • More interaction  Complexity

6. Bad Systems • Fail to meet requirements • Poor performance • Poor reliability • Unusability

7. Badly Produced Systems • Not to schedule • Not to budget • Runaway = 100% over budget or schedule

8. Reasons for Failure • Complexity • Shifting requirements • Bad estimation • Bad management • New technology

9. Need for Structure • Must tackle complexity • Structure partitioning of problem • Organised interaction of parts • Ensure you achieve the task

10. System Development Life Cycle • An ordering of a set of system development activities/phases. • Can be either sequential (serial) or non-sequential (e.g. contingent). • Contains guidance on how to progress from one phase to the next

11. Generic development phases: Initiation Development Implementation Operation & Maintenance

12. Links between phases: Problem statement; “vision” scenario, requirements Initiation Executables, user documentation etc Development Changes in scope, schedule, etc. An operational IS Implementation Design or programming errors Operation & Maintenance Implementation glitches: e.g. missing requirements

13. Standard System Life-cycle Problem Definition Feasibility Study System Analysis System Design Physical Design Implementation Maintenance

14. System Development Life-Cycle • Stages  Milestones • Output/product/deliverable • Waterfall technique • Distilled experience

15. Systems Analysis and Design • Central to the life-cycle • Analysis: defining the problem • From requirements to specification • Design: solving the problem • From specification to implementation

16. Models • Representations • Simplify reality • Require training • Appropriate to problem

17. Models in Analysis and Design • Focus ideas • Aid communication with user • Highlight omissions and errors • Blueprint for the system

18. Good Models • Maintainable and disposable • CASE tools • Graphics v. Text • Understandable

19. The Main Models • Entity relationship diagram • Data-flow diagram • Entity life-history

20. Some Remarks • All three models represent the same system • There is no unique correct model • Need more than one attempt

21. Case Studies • Replace requirements • Informal • Ambiguous • Realistic! (Nearly) • Estate Agent System in handbook

22. Entity Relationship Diagrams • Centrality of data • DBA and DA • Represents structure of data • Shows relationships within data

23. Focus in ER diagrams • Structured • Logical • Process independent • Minimal

24. Components of ER Diagram • Entities with lists of attributes • Occurrences as set of values • Relationships • two directions - two sentences • degree • optionality

25. Entity • Block of information • Represents a type of thing • Occurrences are instances of the entity Student

26. Attributes • Belong to an entity • Simple item of data • Values are the data for an occurrence • Candidate keys and primary keys

27. Entities as Tables

28. Relationships • Show how entities affect each other • Two directions - two sentences

29. Degree • Number of occurrences in relationship • Remember two directions • Three types: • one to one • one to many (or many to one) • many to many

30. Resolving Many-to-manys • Hide information • Difficult to physical represent

31. Resolving Many-to-manys

32. Optionality • Optional - relationship MAY hold • Mandatory - relationship MUST hold • Two directions

33. Components of ER Diagram • Entities with lists of attributes • Occurrences as set of values • Relationships • two directions - two sentences • degree • optionality

34. Building ER Models • Based entirely on requirements • Process must be repeated several times • Alternative to normalisation

35. Steps to ER modelling • Identify entities • List attributes • Identify relationships • Repeat several times

36. Identify Entities • One or two obvious ones • Use nouns in case study • entity or attribute • Not the whole system!

37. List Attributes • Again obvious ones for some entities • Use nouns in case study • complex attributes might be entities • Use imagination • for deliveries need addresses • for phone calls need phone numbers

38. Identify Relationships • Consider each pair of entities • Begin drawing • Consider degree • Consider optionality • Resolve many-to-manys

39. Repeat • Is there enough data to do the job? • Identify new entities and attributes • Fit them to existing model • Do it again!

40. Representing Relationships • Each entity needs a primary key • Use a foreign key for many-to-one • The “many” entity has a foreign key attribute • One-to-ones are rare or incorrect!

41. Validation • Is there any repetition of data or relationships? • Are all attributes and entities relevant? • Are all many-to-manys resolved? • Are the one-to-one relationships sensible?

42. The Data-Dictionary • Description of ALL information on EVERY item of data • Precisely defines the diagrams • Adds new detail • Backbone uniting all diagrams

43. ERD and Dictionary • Description of every entity • Lists of attributes & descriptions • Volumetrics • Description of relationships

44. DD Notation • = consists of; + sequence • { } repetition; ( ) optional • [ ] selection between alternatives • | alternative separator • *….* comments

45. Example DD entry • CustomerDetails = • Title + {initial} + Surname + Address + (CustomerPhone) • Title = [Mr|Mrs|Ms|Dr|Rev] • Address = [Number|Name] + Street + {District} + (PostCode)

46. Data-flow Diagrams • Clarify requirements • Represent processes • Interaction between processes • Non-technical yet formal

47. Focus in DF diagrams • Data input to the system • Data output from the system • Movement of data between processes • Storage of data within system • Top-down decomposition

48. Customer Customer External Entities • Provides inputs, receives outputs • Different from Logical Data Structure • Represent types of things

49. StockInventory Data-flows • Movement of data between processes • No change of data during flow • One end MUST attach to a process

50. Processes • Main feature of DF diagrams • Change data • Appear as boxes: