IS 2510 Information Systems

1
IS 2510 Information Systems

• Lecture 2
• Analyzing The Problelm
• (Chps 5-8, 10)
• (Figures/Tables from Leffingwell Widrig Text)

2
Team Skill 1

• Analyzing the Problem

3
5 Steps In Problem Analysis

• Problem analysis goals
• Who are the users (a.k.a. actors)
• Understand user needs (or problems)
• Challenges to meeting those needs
• Understand challenges before development
• Propose solutions ??
• Hmmmmore properly a design activity!!

4
5 Steps In Problem Analysis

• A problem is the difference between whats
  perceived and whats desired
• Perceptions may not always be reality
• Needs may not always be realistic
• Problem Analysis
• Process of eliciting, understanding, documenting
  and validating user needs
• IMHO, it does NOT include proposing solutions
  (thats design!)

5
5 Steps In Problem Analysis

• Leffingwells 5 steps of problem analysis
• Gain agreement on problem definition
• Understand root causes
• Identify users stakeholders
• Define solution system boundary
• Identify constraints on solution

6
5 Steps In Problem Analysis

• Gaining agreement
• Document the problem and seek agreement
• Use accepted format
• Can be useful to assign a priority or urgency to
  the problem, too

7
5 Steps In Problem Analysis
8
5 Steps In Problem Analysis

• Understanding root causes
• Many problems have underlying causes that may not
  be immediately apparent
• Example
• Our e-commerce site is not profitable
• Why is it not profitable?
• Poor site design?
• Bad pricing?
• Poor customer management after the sale?
• Some or all of the above?

9
5 Steps In Problem Analysis

• In total quality management (TQM), fishbone
  diagram is used
• Simple diagram that depicts all root causes
  underlying the problem
• Underlying causes are sub-problems that may need
  further investigation
• Could also use simple bulleted list!

10
5 Steps In Problem Analysis
11
5 Steps In Problem Analysis

• Root causes dont have same impact
• Some may not be worth fixing, at least not now
• Pareto (bar) chart can be used to depict relative
  impacts of root causes
• Could also use simple table with percentages

12
5 Steps In Problem Analysis
13
5 Steps In Problem Analysis
14
5 Steps In Problem Analysis

• Could do another analysis to determine whats
  causing inaccurate sales orders
• Could be as simple as better user training on
  current system!

15
5 Steps In Problem Analysis
16
5 Steps In Problem Analysis

• Identifying stakeholders users
• Stakeholder is anyone materially affected by a
  system
• Users are a subset of stakeholders
• May not be obvious, for example
• Could be managers, customers, regulatory
  agencies, business partners, general public, etc.

17
5 Steps In Problem Analysis

• Useful questions for IDing stakeholders
• Who uses the system
• Whos the customer
• Who is affected by outputs
• Who evaluates/approves system
• Other external/internal users
• Who maintains system
• Anyone who cares? legal/regulatory, etc.

18
5 Steps In Problem Analysis
19
5 Steps In Problem Analysis

• Define system boundary
• Boundary between system and outside world

20
5 Steps In Problem Analysis

• Actor is someone or something that interacts with
  system

21
5 Steps In Problem Analysis

• Boundaries not always obvious, esp. wrt to
  external systems!
• Interfaces with external systems are often
  complex have major implications for system
  architecture

22
5 Steps In Problem Analysis

• Questions for discovering actors

23
5 Steps In Problem Analysis
24
5 Steps In Problem Analysis

• Identify constraints on system
• Constraints are restrictions on the solution
  space
• Usually non-functional requirements that impose
  major restrictions on the system
• Can be human resource, technological,
  policy/legal/regulatory, performance, usability,
  performance, supportability, etc.

25
5 Steps In Problem Analysis

• See p. 56 for table sources of system constraints

26
Business Modeling

• Defining system boundary usually raises major
  issues on how system fits into the IT environment
  of an enterprise
• Enterprise may need to modify policies,
  procedures, other systems, etc.
• Can precipitate enterprise-level modeling of the
  business

27
Business Modeling

• Purpose
• Understand structure/dynamics of enterprise
• Ensure stakeholders have common understanding of
  the organization
• Understand how to deploy new systems that affect
  enterprise
• A higher-level modeling perspective

28
Business Modeling

• Apply many of the same graphical techniques used
  in OO modeling
• Current standard is Unified Modeling Language
  (UML)
• for visualizing, specifying, constructing, and
  documenting the artifacts of a software intensive
  system

29
Business Modeling

• 2 kinds of business models
• Business use case model
• Main functions of the business
• IDs roles and deliverables
• Consists of actors use cases
• Use case is a sequence of events (think workflow)
  performed by actors to accomplish a task

30
Business Modeling

• Simple business use case diagram
• Each UC consists of an ordered series of steps
  needed to complete the task

31
Business Modeling

• Business object model
• Describes the entities within the enterprise and
  how they collaborate to perform tasks
• Business modeling useful for complex enterprises,
  esp. if not already done

32
Systems Engineering

• Well-suited for embedded systems
• Based on successive decomposition of a system
  into simpler subsystems
• Key principles
• Know the problem customer
• Use effectiveness criteria
• Manage requirements
• ID assess alternatives
• Verify validate reqs.
• Maintain system integrity
• Use a documented SW process
• Manage against a plan

33
Systems Engineering
34
Systems Engineering

• Key criteria for success
• Optimized distribution of functionality among
  subsystems
• Subsystem can be built by modest-sized team
• Subsystem can be reasonably manufactured
• Subsystem can be reliably tested
• Subsystem physically compatible with system

35
Systems Engineering

• Subsystems expose functionality via interfaces
  (much like objects)

36
Systems Engineering

• Computing environment maybe tightly constrained
  in terms of processing power, memory, I/O, etc.)
• Closely related to classic engineering fields
  (electrical, mechanical, etc.)
• Embedded systems evolving from mostly mechanical
  to mostly SW-based

37
Systems Engineering

• SW determines ultimate functionality
• SW is most of the cost of RD
• SW is on projects critical path
• SW accounts for most of the changes system
  absorbs
• SW accounts for most of the overall lifecycle
  cost

38
Systems Engineering

• Subsystems are subcontracts
• Each interface is a contract that must be
  fulfilled by subsystem
• Same as for Object interfaces
• Changes to the interface must be negotiated
  with other subsystems

39
Systems Engineering

• Best practices
• Manage system-level reqs so overall functionality
  is not lost within subsystems
• Use OO principles to partition functionality
• encapsulation, messaging, design by contract
• Dont overly partition SW among physical
  subsystems
• Over-engineer interfaces to accommodate change

40
Systems Engineering

• Review high-level problem statements on p. 79

41
Systems Engineering
42
Systems Engineering

• Review HOLIS constraints on p. 85

43
Team Skill 2

• Understanding User and Stakeholder Needs

44
Eliciting Requirements

• 3 major complications
• Users inability to provide get tangible
  experience with SW (yes but)
• Dont know how many reqs are yet to unearthed
  (Undiscovered ruins)
• Communications between techies and users

45
Eliciting Requirements

• Common user feedback styles
• Yes this is nice, but
• Wouldnt it be nice if
• Ill know it when I see it
• I thought it was going to
• This isnt what I expected
• Indicates need for early prototypes for user
  feedback to resolve problems asap

46
Eliciting Requirements

• Cant be sure all reqs have been discovered
• At some point, must agree enough have been
  discovered, the rest can wait

47
Eliciting Requirements
48
Interviewing

• Simple, direct highly useful
• Key is avoiding biases by the interviewer
• Dont want the question to influence the answer
• Ask context-free questions
• Good Who are the users?
• Bad Your current system is crummy, right?
• Also includes tone of voice, body language, etc.
  considerations

49
Interviewing

• Interviewing tips
• Prepare questions before interview
• Know the interviewee avoid questions they cant
  answer
• Repeat the answer back to the user for
  confirmation
• Be flexiblenew questions will be revealed during
  interview
• Take good notes elaborate on them asap after the
  meeting
• Use the list of questions to keep you on track
• Be prepared do your homework!!

50
Interviewing

• See interview template on p. 104
• Compiling interview info
• Build repository of reqs by listing the most
  important problems revealed by interviews
• Document these and review with stakeholders

51
Interviewing

• Questionnaires
• A very poor substitute for interviews
• Lack the free-form flow of information that
  interviews provide
• Inflexible, dont adapt to new information
• Hard to follow up on unclear responses
• Sometimes unavoidable, but use as last resort

52
Interviewing
53
Interviewing
54
Interviewing
55
Interviewing