Systems Analysis II Overview and Requirements Gathering

1. Systems Analysis IIOverview and Requirements Gathering INFO 355 Glenn Booker Week #1

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) Week #1

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 Week #1

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 Week #1

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 Week #1

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 Week #1

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. Week #1

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 Week #1

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) Week #1

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’ Week #1

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 Week #1

12. 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) Week #1

13. 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 Week #1

14. 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 Week #1

15. 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” Week #1

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 Week #1

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

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. Week #1

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) FURPS = Functionality, Usability, Reliability, Performance and Supportability Week #1

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 Week #1

21. 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 Week #1

22. 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 Week #1

23. 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 Week #1

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) Week #1

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 Week #1

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 Week #1

27. 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 Week #8

28. 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 Week #8

29. 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 Week #8

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

31. 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 Week #8

32. 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 Week #8

33. 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 Week #8

34. 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 Week #8

35. 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’) Week #8

36. Partition Example Week #8

37. 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 Week #8

38. Becomes 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 Week #8

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

40. 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 Week #8

41. 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) Week #8

42. 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. Week #8

43. Signals • A signal can be split by a ‘fork’ symbol • Fig 11.6, p. 123 • (Send and receivelabels overwrittenmanually) Week #8

44. 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 Week #8

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 Week #1