1. INFO 355Week #11 Systems Analysis II Overview and Requirements Gathering INFO 355 Glenn Booker

2. Review  The goal of systems analysis and design is to understand and specify (analysis) the needs of an information system, and then solve (design) how to make it happen  Usually this is in the form of a project that follows some flavor of Systems Development Life Cycle (SDLC) INFO 355Week #12

3. SDLC core processes  Within a typical SDLC we need to: Identify the problem Plan and monitor the project Clarify the problem (requirements) Design the components to solve it Build, test, and integrate those components Conduct system level testing and deploy the system INFO 355Week #13

4. Waterfall versus Agile  In the waterfall life cycle, each process is done once and fully before going to the next process Often the plan is set in stone  In the Agile development methods, we assume we don’t know the problem very well, so we expect the plan will change as the project unfolds iteratively INFO 355Week #14

5. Iterative development  In iterative development, the six processes of the SDLC are repeated over and over, first focusing more on early processes, later iterations doing more development and testing INFO 355Week #15

6. RMO?  The text uses Ridgeline Mountain Outfitters (RMO) as a running example of IS development I’m positive they aren’t based on REI I won’t focus on the RMO example INFO 355Week #16

7. Project Vision document  One way to propose a new project is to write a System Vision Document for it Problem description – why need this? System capabilities – high level functional requirements Business benefits – projected improvements in process speed and/or quality, customer base, etc. INFO 355Week #17

8. Project Planning  If the vision gets support, next develop and follow the project plan Identify major subsystems, interfaces Plan the first iteration in detail  Break tasks down in a WBS (work breakdown structure) Get user feedback Identify use cases Identify object classes INFO 355Week #18

9. Project Planning  Then develop a use case diagram and activity diagrams  Define screen layouts (input and output)  Define database structure (see INFO 210)  Design the structure of the system (architecture) INFO 355Week #19

10. Project Planning  Then refine the class diagram  Design subsystems in detail  Implement use cases through system testing  Deploy system when system test results are ‘good enough’ INFO 355Week #110

11. INFO 355 versus INFO 200  So in procedural development (INFO 200) you capture processes in the DFD and data structure in the ERD, but the details of implementation are missing  Here we define requirements in ‘use cases’ and capture more details of design in a class diagram and sequence diagrams INFO 355Week #111

12. INFO 355Week #112 What is an Object?  “An entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes and relationships, behavior is represented by operations, methods, and state machines. An object is an instance of a class.” (UML 1.5 spec)

13. INFO 355Week #113 Huh?  Attributes are the data contained by an object, if any  Relationships describe which objects are allowed to talk to each other  The operations and methods describe the ways objects can interact with each other  So objects are a set of data which can only be acted on in certain prescribed ways

14. INFO 355Week #114 What is a Class?  “A description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment.” (UML 1.5 spec)  Hence a class is a group of similar objects

15. INFO 355Week #115 What is Object Oriented?  The methods isolate the data, so that it can’t be manipulated directly  Only the methods can create, read, modify, or delete data Image from Apple, “Object-Oriented Programming and the Objective-C Language”

16. Investigating System Requirements  To understand an existing organization, determine their: Technology architecture – the hardware, networking, and system software in use Application architecture – the applications running on the technology architecture used to perform business processes and run their IS INFO 355Week #116

17. Systems Analysis  Five major activities within this process Gather detailed information Define requirements Prioritize requirements Develop user-interface dialogs Evaluate requirements with users INFO 355Week #117

18. Requirements  Functional requirements WHAT can someone do using the system?  Non-functional requirements HOW WELL can the system perform functional requirements? Usability, reliability, performance, security, maintainability, etc. INFO 355Week #118

19. FURPS+ Design constraints (OS, power, memory usage, etc.) Implementation constraints (prog language, tools used, IDE, etc.) Interface requirements (export XML files, get data from NYSE) Physical requirements (size, weight) Supportability requirements (autoupdate) INFO 355Week #119 FURPS = Functionality, Usability, Reliability, Performance and Supportability

20. Modeling  In analysis and design, modeling is critical for communicating the results of our work Some models are text, many are graphic, few mathematical  For object oriented A&D, UML is the graphic language used INFO 355Week #120

21. INFO 355Week #121 A Little History  While object oriented programming has existed since at least 1980 (Smalltalk), there were many ways to describe and diagram an object oriented system  Everybody had their own notation – Booch, Rumbaugh, Jacobson, etc.  Finally unified in 1997 with UML

22. INFO 355Week #122 What’s UML?  UML, the Unified Modeling Language, is essentially a drawing convention to express object oriented software structure and functionality Just like architects use blueprints to express different aspects of a building (e.g. plumbing vs. exterior), UML has different types of drawings

23. INFO 355Week #123 UML Standard  UML is defined by a standard from the Object Management Group (OMG!) Current version is 2.5, dated September 2013  Our goal is to focus on the most useful parts of UML English has 600,000 words, but you don’t need to know all of them

24. Stakeholders  To get complete requirements, need to identify and solicit all types of stakeholders in the project (p. 47) Internal stakeholders – employees, volunteers, students External stakeholders – suppliers, government agencies (regulators) INFO 355Week #124

25. Stakeholders Operational stakeholders – interact with the system Executive stakeholders – don’t interact with the system The client or sponsor pays for the project, may or may not actually use it Technical or support staff are also stakeholders, help maintain the system INFO 355Week #125

26. Information-Gathering Techniques  Interviewing stakeholders  Questionnaires  Review legacy system inputs, outputs, documentation  Observe and document existing business processes and procedures  Research vendor solutions  Collect user comments, suggestions INFO 355Week #126

27. INFO 355Week #827 Activity Diagrams  Activity Diagrams are a type of flowchart used to describe a business process or workflow They support parallel tasks, which a traditional flowchart can’t handle  They are derived from state diagram notation, so don’t be surprised by the similarities

28. INFO 355Week #828 Scope of Activity Diagrams  An activity diagram might show the logic for a complex use case (and all its extensions), or show the interaction among several use cases (such as when included use cases apply) An activity diagram can show the logical decisions of a process that the use case diagram can’t show

29. INFO 355Week #829 Activity Diagram Notation  Activity diagram notation includes The processes to be performed, which appear as boxes with rounded corners The processes are connected by lines with arrows, to show the direction of process flow  Arrows are always directional in an activity diagram  Use the Guard field for conditions Decisions are shown by diamonds

30. INFO 355Week #830 Activity Diagram Simple Example Same start shape as State Diagram Same end shape as State Diagram Transition line with Guard condition Process (same shape as a state) Decision Merge

31. INFO 355Week #831 Decisions  Notice that the diamond symbol is used to show a split in the process flow due to a decision  And the same symbol is used to show when the process flows merge afterwards

32. INFO 355Week #832 Concurrent Flow  Notice the implied assumption of time going forward down the page  Concurrent, or parallel flows can be shown by using a ‘fork’ symbol when the flows split, and a ‘join’ symbol when they reconnect

33. INFO 355Week #833 Uses for Concurrent Flow  Several parallel activities might take place after a single decision  For example, approval of a release might initiate parallel activities to Prepare a release description Start packaging the release Notify customer of impending release Lock the contents of the release

34. INFO 355Week #834 Concurrency Example Shows four concurrent activity threads to prepare for a new baseline release; this might all be part of a process called Prepare Release

35. INFO 355Week #835 Partitions  Notice that activities are often performed by different organizations within your project You could add the organization to the activity name, e.g. ‘Program Control Notifies Customer’ Or use the approach on the next slide Here is another variation on the “swimlane” approach (each organization has its own ‘lane’) Here

36. INFO 355Week #836 Partition Example

37. INFO 355Week #837 Adding Details - Decomposing  Each step in an activity diagram could correspond to (or be decomposed into) a process or procedure which is documented elsewhere For example, Prepare Release Description could follow a procedure to explain it in more detail

38. INFO 355Week #838 Adding Details - Decomposing  For that matter, the whole development process could be described in a single step, then broken down to any desired level of detail Becomes

39. INFO 355Week #839 Adding Details - Decomposing Which in turn becomes Notice similarity to the project schedule (WBS)

40. INFO 355Week #840 Timing and Signals  So far the sense of time has been pretty vague Time goes forward down the page Forks and joins indicate when concurrent processes collectively begin and end Decisions and merges reflect the start and end of conditional process paths  To be more precise, use signals

41. INFO 355Week #841 Signals  A Time Signal can be used to indicate when a process waits for a specific timed event before it begins E.g. end of month to start generating a report  The Time Signal is like an hourglass, labeled to show what event for which it waits (I made this one manually)

42. INFO 355Week #842 Signals  Send Signals are triggered by some process to start a timer  Receive Signals accept a signal as input, and usually sound like an event more than a process ‘Taxi arrives,’ ‘Itinerary confirmed,’ etc.

43. INFO 355Week #843 Signals  A signal can be split by a ‘fork’ symbol Fig 11.6, p. 123 (Send and receive labels overwritten manually)

44. INFO 355Week #844 Tokens  To help follow a process, it sometimes helps to imagine physical tokens being passed along the paths A fork creates two or more tokens to follow each path separately A join waits for all tokens to arrive before proceeding

45. Summary  So this week we: Reviewed basic concepts of system analysis and design Added how our perspective changes for object oriented A&D Introduced UML Showed how an activity diagram can be used to document business processes INFO 355Week #145