Systems analysis ii overview and requirements gathering
1 / 45

Systems Analysis II Overview and Requirements Gathering - PowerPoint PPT Presentation

  • Uploaded on

Systems Analysis II Overview and Requirements Gathering. INFO 355 Glenn Booker. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Systems Analysis II Overview and Requirements Gathering' - emerald-bryant

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Systems analysis ii overview and requirements gathering

Systems Analysis IIOverview and Requirements Gathering

INFO 355

Glenn Booker

Week #1


  • 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

Sdlc core processes
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

Waterfall versus agile
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

Iterative development
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


  • 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

Project vision document
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

Project planning
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

Project planning1
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

Project planning2
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

Info 355 versus info 200
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

What is an object
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


  • 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

What is a class
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

What is object oriented
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

Investigating system requirements
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

Systems analysis
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


  • 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


  • 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


  • 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

A little history
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

What s uml
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

Uml standard
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


  • 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


  • 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

Information gathering techniques
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

Activity diagrams
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

Scope of activity diagrams
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

Activity diagram notation
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

Activity diagram simple example

Same start shape as State Diagram

Process (same shape as a state)


Transition line with Guard condition


Same end shape as State Diagram

Activity Diagram Simple Example

Week #8


  • 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

Concurrent flow
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

Uses for concurrent flow
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

Concurrency example
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


  • 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

Adding details decomposing
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

Adding details decomposing1


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

Adding details decomposing2
Adding Details - Decomposing

Which in turn becomes

Notice similarity to the project schedule (WBS)

Week #8

Timing and signals
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


  • 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


  • 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


  • A signal can be split by a ‘fork’ symbol

    • Fig 11.6, p. 123

    • (Send and receivelabels overwrittenmanually)

Week #8


  • 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


  • 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