Requirements Engineering and Management INFO 627

1
Requirements Engineeringand ManagementINFO 627

• Analyzing the Problem
• Glenn Booker

2
Problems and Opportunities

• We hinted that most systems are created for two
  reasons
• To solve problems ways in which the current
  system doesnt meet customer needs
• To take advantage of opportunities new product
  concepts, new features, new customer markets,
  etc.
• Well focus on problem solving for now

3
Problem Analysis

• Problem analysis is the process of understanding
  customer problems and user needs, and proposing
  solutions to fulfill those needs
• A problem is the gap between how things are, and
  how the customer wants them to be
• Hence changing expectations can make some
  problems go away!

4
Problem Analysis Steps

• Analyzing a problem can be done in five steps
• Agree on the problem definition
• Understand its root causes
• Identify stakeholders and users
• Define solution system boundary
• Identify solution constraints

5
Agree on the Problem Definition

• First need to gain agreement on the problem
  definition
• Write down what the problem appears to be, and
  see if everyone agrees
• Or have each type of stakeholder describe the
  problem, then compare their views
• Identify how fixing the problem will benefit the
  customer and users

6
Agree on the Problem Definition

• May help to describe problem using a standardized
  format
• Search for problem statement
• Some white papers describe problems, especially
  those from vendors
• Problem statement might include history,
  background, and motivation for solving the
  problem (example)(another)

7
Agree on the Problem Definition

• Basic problem statement outline is
• Describe problem
• Identify stakeholders affected by it
• Describe impact of problem on stakeholders and on
  business activities
• Describe proposed solution and key benefits
• In short, why should we care about solving this
  problem?

8
Understand its Root Causes

• Given the existence of a significant problem, now
  we need to solve it
• One way is root cause or causal analysis
  determine why the problem exists
• Can use fishbone diagram
• Start with the problem, on a horizontal line
• Look for causes of the problem
• Then look for causes of the causes repeat

1E p. 37
9
Understand its Root Causes

• If you have trouble finding causes, see if there
  are any in common types
• Data
• Communication
• Management
• Hardware
• Manufacturing
• Or whatever else may apply to your problem

10
Understand its Root Causes

• In the context of software defect analysis,
  causes can be things like
• Variables
• Data
• Design
• Documentation
• Interfaces
• And so on

11
Understand its Root Causes

• Then analyze which of the causes are most
  significant (does that mean frequent or
  severe?)
• Graph with a histogram or Pareto diagram
• See second half of lecture 4, INFO630

12
Identify Stakeholders and Users

• As discussed last week, we need to identify who
  will use the system, and who will be affected by
  its existence
• Many stakeholders are also users, but not all

13
Define Solution System Boundary

• At its simplest, every system takes in some form
  of inputs, and produces outputs
• The key at this point is to identify who or what
  creates or accepts those inputs and outputs

14
Define Solution System Boundary

• Most inputs and outputs are initiated by either
  an actor (user or stakeholder), or an external
  system
• So we need to imagine (postulate, for now) what
  will and wont be part of our system
• Focus attention only on those things that will
  interact directly with our system
• Do you use the cash register at the grocery store

15
Define Solution System Boundary

• Other systems might include
• Legacy systems which remain in your organization
  (human resources database, accounting system,
  etc.)
• Vendors systems (only if your system interacts
  directly with them, such as downloading updates)
• Sensors for system environment (temperature,
  power supply, UPS, etc.)

16
Define Solution System Boundary

• Anything obtained automatically from the Internet
  (search results, stock quotes, etc.)
• Include users of the system from remote locations
  (home, customer sites)
• Remember that the system boundary only includes
  things over which you have control
• If you cant specify its design eventually, then
  its outside your system

17
Define Solution System Boundary

• Show system as a box with its name
• Actors are stick figures
• External systems are little boxes with their
  names
• Arrows show direction of information flow

1E p. 43
18
Define Solution System Boundary

• If new system includes other (e.g. legacy)
  systems, show system boundary with dotted line
  or oval
• Please dont include users inside the system
  boundary! (think about it)

19
Identify Solution Constraints

• Constraints can be anything that limits how or
  when the system is provided
• Economic constraints, such as system development
  cost, or cost of the product
• Political, whether corporate, local, national, or
  international political issues or laws
• Technical, such as technology choices, platforms,
  new technology limits, etc.

20
Identify Solution Constraints

• System constraints, such as compatibility with
  existing systems or operating systems, installed
  size, or internationalization
• Environmental, such as legal, security,
  regulatory, emissions, or safety constraints

21
Identify Solution Constraints

• Schedule and resources are there predefined
  limits on completion date, what resources are
  available for the project, can we get outsourced
  people (hire temps)?
• Constraints can be added to the problem
  statement, with their rationale

22
Problem Analysis

• Make sure customer agrees with problem analysis
  and its resulting statement
• Now have a framework for defining the customers
  problem and needs, and started sketching the
  scope and constraints on the system well create
  to meet those needs
• This gives structure to begin defining
  requirements

23
Business Modeling

• The system boundary outline gave us a start on
  understanding who and what will use our system
• Now we want to expand on that and determine how
  they will use the system
• What kind of activities will users and systems
  need to perform?
• That forms the heart of business modeling

24
When to do Business Modeling

• Basic business modeling can help identify types
  of activities to be performed using the system
• Detailed business modeling is good for very
  complex systems, especially with many types of
  users and/or many interfaces

25
Business Modeling

• Business modeling helps answer higher level
  questions like
• Where should the system be located?
• What kind of activities are performed in
  different locations and facilities?
• Do we need to reorganize our organization?
• What processes need to be automated?

26
Modeling Techniques

• Many techniques can be used for business
  modeling
• Process modeling can help understand each
  activity in detail
• SAP uses scenarios to model activities
• Some aspects of UML directly support it
• Here we focus on use cases

27
Use Cases

• Use cases are simply names for activities which
  users need to perform using your system
• Each use case is a set of activities with a clear
  start and finish, which performs some significant
  function using your system
• Ship Order, Analyze Customer Trends, Process
  Returned Shipment, Create Invoice

28
Use Cases

• There are also trivial use cases, which are
  complete activities which arent very important
  by themselves
• Validate User, Print Mailing Labels, etc.
• Think of a new employee who will need to use your
  system what kind of activities would you need
  to teach them? Those might be use cases

29
Use Cases

• To decide between significant and trivial use
  cases
• Ask whether the user would brag to their boss how
  many times they performed that activity
• If they might brag about it, its a significant
  use case otherwise its probably trivial
• Also consider how to write a users job
  description or users manual each task described
  may be a use case

30
Use Cases

• To draw a use case diagram
• Each actor is a stick figure
• Each use case is labeled in an oval
• Each external system is labeled in a box
• Lines connect actors to use cases, and actors to
  external systems, to show lines of communication

31
Sample Use Case Diagram
Generally show only significant use cases.
32
Documenting Use Cases

• Many formats may be used to describe use cases
  see http//www.usecases.org/ for Alistair
  Cockburns template
• The use case description captures key aspects of
  the business process what happens, who does it,
  what is used or created as a result, when does it
  occur, etc.

The ck in his name is silent, BTW CO-burn
33
Systems Engineering of Software

• The systems engineering approach works well for
  software-based systems too
• How do you solve a big problem?
• Break it into little problems!
• Main emphasis is on breaking the system down into
  subsystems, and determining what each subsystem
  needs to do

34
Systems Engineering

• For example, a car has subsystems like
• Powertrain
• Engine, Transmission
• Axle, Differential
• Suspension
• Wheels
• Tires
• Shocks or Struts
• Springs

35
Systems Engineering

• Often applied for embedded (built-in) software
  systems
• See INCOSE for more info on this approach
• Or WWISA for software architecture
• Parts of a software system might be called
  configuration items, components, packages,
  modules, or units

36
Systems Engineering

• Several layers of subsystems can be designed to
  organize specific functions
• User Interface
• Shipping and Receiving Module
• Shipment Verification Screen
• Each subsystem can then have specific functions
  to perform using a specific set of inputs

37
Systems Engineering

• One person or small team can then design that
  subsystem in detail
• This approach can help allocate (assign)
  requirements to different parts of the system
• This leads to detailed requirements for each
  subsystem or interface between subsystems
• These detailed requirements are derived, as in
  derived from overall requirements

38
Systems Engineering

• For examples, derived requirements can be used to
  guide selection of commercial components for your
  system
• Servers
• Database vendor
• Networking hardware
• And so on

39
Systems Engineering

• Many industries have recently started
  incorporating software into things which didnt
  have any 20 years ago
• Hence they have to care about allocated software
  requirements
• Software is now the dominant cost in many
  systems, and controls whether it will succeed

40
Systems Engineering

• Another influence of the systems engineering
  approach has been greater emphasis on the entire
  life cycle cost for a system including
  maintenance and disposal costs
• Many had focused only on development costs
• Cost of upgrades and product evolution are harder
  to predict for software

41
Systems Engineering

• How can this help us define requirements?
• Consider how use cases might interact with
  subsystems
• Hide information that isnt needed to perform
  the task
• Isolate interfaces to external systems
• Plan for more features and capabilities than
  needed this minute