CMPT 370: Information Systems Design

1
CMPT 370 Information Systems Design
Lecture Topic Underpinnings of Requirement
Analysis Class Exercise Use Cases

• Instructor Curtis Cartmill, Simon Fraser
  University Summer 2003

2
Objectives

• This lecture introduces Requirements
  Determination
• Concept of system requirements
• Techniques to solicit requirements
• Elaboration of use case diagrams
• Organization and documentation of system
  requirements in the form of Use Cases
• Stakeholders (customers and end users) have goals
  (also known as needs) and want computer systems
  to help them meet them. There are several ways to
  capture these goals and system requirements, the
  better ones are simple and familiar because they
  make it easier especially for users and
  customers to contribute to their definition or
  evaluation.

3
Context of requirements analysis

• Build the right product
• Build the product right

Requirements ( Analysis)
Design
What
How
SMOP
-fuzzy-
4
Why requirements?

• Gap between stakeholders
• Users have the vision
• Developers need the specifications
• Analysis and Design span the gap
• Understand user needs
• Transform needs into specifications
• This is the creative part of software development
• This is the area where projects fail

Stakeholders
??

• interpreting reality ? Vision/Requirements
• constructing reality ? Product

Developers

• Remember to Observe Bricks Mortar Business to
  determine system behaviour

5
What is a requirement?

• A capability needed by the user to solve a
  problem to achieve an objective
• A capability that must be met or possessed by the
  system to satisfy a contract, standard,
  specification or other formally imposed
  documentation
• A requirement may range from a high-level
  abstract statement of a service or of a system
  constraint to a detailed functional specification

6
Evolution of requirements

• It is inevitable that requirements will evolve
  over the course of the Software Development
  process
• Some requirements may be well known and
  understood at the onset of the project
• Some requirements may not be well fully defined
  until the project is well underway
• Some requirements may not be identified or
  discovered until later on in the Software
  Development project
• Requirements can be volatile
• Why projects fail w.r.t. bad requirements
• miscommunications and misunderstandings lead to
  increased costs of a software process
• Requirements drive
• Assumptions, and Decisions
• Which Affect System Development
• And Information/Tool/Data Design Architecture
  (Soln.)

7
What is a goal?

• Goal
• A general intention of the use of the system
• ease of use
• Verifiable non-functional requirement
• A statement using some measure that can be
  objectively tested (e.g. number of users put onto
  a system, or reduce costs of process by X
  dollars)
• An overall objective of a stakeholder (any person
  or organization interested in the the success of
  the system)
• Increase profit by Increasing revenue and/or
  Decreasing costs/expenses
• Goals are helpful to developers as they convey
  the intentions of the system stakeholders

8
Goals and requirements

• Goals are the essence of success
• We could meet the requirements in the development
  of the project, however if we have not recognized
  and thus met the goals the stakeholders will be
  unsatisfied by the end result
• It is then paramount that as we solicit and
  develop requirements that we keep in mind the
  goals necessary for success

9
Types of requirements

• Functional requirements
• Statements of functionality or services the
  system should provide, how the system should
  react to particular inputs and how the system
  should behave in particular situations.
• Non-functional requirements
• Constraints on the services or functions offered
  by the system such as performance constraints,
  standards, reliability, availability (e.g. 24x7,
  short Transaction Time)
• Domain requirements
• Requirements that come from the application
  domain of the system and that reflect
  characteristics of that domain

10
Where do requirements come from?

• Functional requirements come from users
• Current processes (as-is) Past or Present
• Desired processes (to-be) Future
• Non-functional requirements come from the
  technical environment
• Current operational environment
• Desired operational environment
• Domain requirements come from subject matter
  experts (SMEs)/domain experts
• Business environment constraints
• Expressed in domain terminology

11
Functional requirements considerations

• Wants versus Needs (Priority)
• A want may be a feature of the system or
• A want may be counter to a need
• Statement of problem or solution
• Users tend to think of requirements in the form
  of solutions ... Without truly acknowledging the
  need
• Users tend to think in terms of automation of
  current processes (as-is) without recognizing
  that creating a system can also result in changes
  in process (to-be) (e.g. What processes changed
  when Air Canada implemented self-service kiosks?)
• What is the impact of the system
• Other roles, users, other systems, other
  processes

12
Non-Functional requirements considerations

• Measurability
• Requirements are stated in ways that are
  difficult to measure such that at the end of the
  project it is not clear if the requirement has
  been satisfied or not
• In terms of Usability, measurable items may
  include clicks, screens to complete a task.
• In terms of e-commerce websites, perhaps
  transactions per minute or per hour are measured
  (temporal)
• Source
• It is sometimes imperative that the software
  development team themselves introduce and nurture
  the non-functional requirements among the
  stakeholders

13
Domain requirements considerations

• Understandability
• Requirements need to be expressed in the language
  of the application domain (terminology)
• These requirements may not be understood by
  software engineers developing the system
• Example Airline Industry
• Actors include Passengers, Customers, Stewards,
  Cleaning Crew, Maintenance Crew, Pilots
• Business Terminology Tickets, Fare, Booking,
  Reservation, Comp Tickets, Class of Fare (B, M,
  X, Z)
• Implicitness
• Domain specialists understand the area so well
  that they do not think of making the domain
  requirements explicit
• If you are not a domain specialist, how can you
  become one to work
• Documents describing Business or Biz Problem
  (e.g. RFP)
• Focus on observing bricks mortar operation
  (actors and interaction to accomplish tasks)

14
Problem analysis

• Gain agreement on the problem definition
• A problem may also be an opportunity
• Understand the root causes
• The problem behind the problem
• Identify the stakeholders and users
• Define the system boundary
• Identify the constraints to be imposed
  (assumptions)
• The goal of problem analysis is to gain a better
  understanding of the problem being solved before
  attempting to solve it

15
1. Problem statement

• The problem of
• Affects
• The result of which
• The benefits of

• Describe the problem
• Identify the stakeholders affected by the problem
• Describe the impact of this problem on
  stakeholders and business activity
• Indicate the benefits of a solution

Write the problem down and see if everyone agrees
16
1. Problem statement example

• The problem of
• Affects
• The result of which
• The benefits of

• Inaccuracies in sales orders
• Sales order personnel, customers, manufactoring,
  shipping and customer service
• Is increased scrap, excessive handling costs,
  customer dissatisfaction, and decreased
  profitability
• A new system to address the problem include
• Increased accuracy of sales orders at point of
  entry
• Improved reporting of sales data to management
• Ultimately higher profit

17
2. Root cause

• What is the problem behind the problem
• What are the factors that contribute to the
  problem
• Many times people know the root cause
• But no one has asked before
• May required an impact analysis to quantify the
  impact and contribution to the root cause
• Results can identify the which root causes are
  the ones to be concerned about
• Some may not be worth fixing
• This justifies thinking about potential solutions

18
3. Identify stakeholders and users

• Stakeholder anyone who could materially be
  affected by the implementation of the system
• Stakeholders may be
• Users of the system needs are easy to focus on
• May be indirect, or only affected by the business
  outcomes
• Involved in the solution development and / or
  maintenance of the system (i.e. requirements from
  day one)
• Will evaluate and bless the system once
  developed and delivered (acceptance testing)

19
4. Define the system boundary

• This is a transition state as we take our
  understanding of the problem and start to
  consider potential solutions
• The system boundary defines the border between
  solution and the elements outside the system that
  surround the system
• Our system
• Things that interact with our system (actors)

20
5. Constraints on the solution

• Constraint a restriction on the degree of
  freedom that we have in providing the solution
• Potential system constraints
• Economic budget considerations
• Political interdepartmental issues
• Technical choice of technologies
• System existing standards or systems
• Environmental regulatory constraints
• Schedule and Resource timing and use of labour,
  resources can be considered computing resources
  too (dynamic on-demand world)

21
Techniques to solicit requirements

• The task of the requirements determination phase
  is to determine, analyze and negotiate
  requirements with the stakeholders
• The task involves various techniques of gathering
  information from the customers. It is concept
  exploration through structured and unstructured
  interviews of users , questionnaires, study of
  documents and forms, etc.
• Requirements negotiation and validation is done
  in parallel, with reviews and walkthroughs
  together with stakeholders

22
Common Issues in Requirements Gathering

• Anomalies in nomenclature
• Synonyms same object to have two different
  names (e.g. cost in Inventory, wholesale price in
  Accounting)
• Homonyms same attribute name to have two
  different meanings (e.g. price retail or
  wholesale)
• Inconsistencies (date formats)
• Find Business Rules
• Large Projects require decomposition into smaller
  sub-requirements
• For terminology, perhaps have a glossary which
  contains information such as Name, Description,
  Ranges, Units, Accuracy, Precision

23
Traditional techniques

• Traditional methods of requirements elicitation
  include
• Interviews
• Questionnaires
• Observation
• Study of business documents

24
Interviews

• Primary technique of fact finding and information
  gathering.
• Interviews with domain experts are frequently a
  simple knowledge transfer, but may be done with
  different levels of granularity (i.e. management
  vs. operational staff different roles).
  Interviews with customers are more complex.
• There are two kinds of interviews, structured and
  unstructured. A structured interview is prepared
  in advance, has a clear agenda and many questions
  are pre-determined.
• Consider multiple interviews or meetings (i.e.
  clarifications once more is understood re
  domain).
• Listening and documenting are key.
• Allow diagram drawing to understand the
  interviewees view of the relationships and
  dependencies in a problem domain.
• Recognize different personality types may
  contribute information willingly at different
  levels

25
Questionnaires

• Efficient way of gathering information from many
  customers. Less productive since we cannot get
  clarification (unless collecting personal/private
  information not always allowed)
• Types of Questions
• Multiple-choice Questions
• Rating Questions
• Ranking Questions

26
Observation

• Business Process
• Bricks Mortar business operations to observe
  actors and actions that are valid
• Passive vs. Active Observation
• Raw Observation vs. Re-enactments
• Does the Presence of Observation make people act
  differently?
• Existing computing systems already exists
• Observe users through their interactions and
  frustrations with the system

27
Study of Business Documentation

• Initial Requests for Proposals (RFPs)
• Operations Manual
• For training new staff, with information on the
  lingo and Business Rules
• Existing computing systems already exists
• Documentation from the previous design phase
  (requirements document)
• Documentation for users (user manual)
• Paper-Trail Forms
• Processes and Terminology already well thought
  through and designed
• Signatures for approval, or carbon copies
  suggesting workflow relationships exist (Patterns)

28
Newer techniques

• Methods
• Rapid Prototyping
• Joint Application Design (JAD)
• Rapid Application Development (RAD)
• Higher Cost and Effort
• Useful when project has higher risk
• Unclear objectives
• Undocumented processes
• Unstable requirements
• Inexperienced developers
• Insufficient user commitment

29
Rapid prototyping

• Use the concept of prototyping to discover
  requirements
• Real-world Web Applications develop static HTML
  Mockups to look at scenarios and answer data
  questions
• Clarify difficult requirements and avoid
  misunderstandings in terms of problem domain
• Misunderstandings can occur if customer does not
  understand the difference between static mockups
  and a live fully-functioning complex dynamic
  system
• Two prototyping methodologies
• Throw-Away Quick Dirty
• Evolutionary Targets speedy delivery, so care
  put into developing prototype as it will live
  throughout software lifecycle

30
Joint Application Design (JAD)

• Newer Technique, but has been around since 1970s.
• Group synergy is likely to produce better
  requirements, increase productivity, learn
  faster, make more educated judgments, eliminate
  errors, take riskier decisions, focus in
  important issues brought up in group environment
• Participants
• Leader (communication skills)
• Scribe
• Customers (users and managers)
• Developers
• Disaster at Ford with Edsel car design by
  committee

31
Rapid Application Development (RAD)

• An approach to software development as a whole,
  with focus on quick results
• Five-step approach
• Evolutionary Prototyping
• CASE tools with code generation and round-trip
  engineering
• Specialists with Advanced Tools (SWAT) the A
  Team of designers, and developers
• Interactive JAD (with Scribe swapped with SWAT)
• Timeboxing project management method of fixing
  development time period to avoid scope creep
• Problems encountered with RAD (since we are going
  so rapidly fast)
• Inconsistent GUI Designs
• Specialized (not Generalized) Solution inhibits
  reuse
• Deficient Documentation (Just Do It)
• Software difficult to maintain or scale up

32
Requirements determination

• Requirements analysis includes negotiations
  between developers and customers.
• This step is necessary to avoid and eliminate
  contradicting and overlapping requirements and
  also to conform to the project budget and
  timeline
• The product of the requirements determination
  phase is a requirements document.
• This is mostly a narrative text document,
  normally in the format of use cases

33
Requirements Document Template

• Project Preliminaries
• Purpose and Scope
• Business Context
• Stakeholders
• Ideas for Solutions
• Document Overview
• System Services
• Scope of the System
• Functional Requirements
• Data Requirements
• System Constraints
• Interface Requirements
• Performance Requirements
• Security Requirements
• Operational Requirements
• Political and Legal Requirements
• Other Constraints
• Project Matters
• Open Issues

34
Use Case Diagrams revisited

• Use Case specification includes representation of
  actors, use cases and four kinds of
  relationships
• Association
• Include
• Extend
• Use Case generalization

35
Association relationship

• The association relationship establishes the
  communication path between an actor and a use
  case

36
ltltIncludesgtgt

• The includes relationship allows the factoring
  out of common behaviour in the included Use
  Case(s)
• the included use case is necessary for the
  completion of the use case (HAS TO BE
  COMPLETED)

37
ltltExtendsgtgt

• The extends relationship provides a controlled
  form of extending the behaviour of a use case by
  activating another use case at specific extension
  points
• the extended use case is optional for the
  completion of the use case (COULD BE COMPLETED)

38
ltltGeneralizationgtgt

• The generalization relationship provides a form
  of specialization to a base use case
• the specialized use case is a replacement for
  the generalized use case

39
Use Diagrams in Practice

• In practice projects can put too much effort into
  discovering includes and extends type
  relationships.
• When doing Use Case Documents (more later) Go
  for simplicity, flexibility and understandability
  by stakeholders. The important aspect of use
  cases is the descriptive text and not the
  diagram.

40
Use cases

• A use case is a prose description of a system's
  behavior when interacting with the outside world
• Among the various schools of thought people have
  suggested and recommended almost all combinations
  and permutations of answers to the basic
  questions
• Is a use case a requirement or just a story?
• Is a scenario just another name for a use case?
• Is a use case a formal, semi-formal, or informal
  structure?
• Is there a linking structure for use cases, or do
  they just come in piles?

41
Use case formality

• The happy medium for use cases
• Use cases really are requirements and need a
  basic structure, and also
• Allow people to write whatever they want when
  they need to.
• a use case describes an actor trying to achieve a
  goal by using the system
• Linking use cases to actors' goals is significant
  because it shifts the use case writer's attention
  away from the function lists that most developers
  worry about and puts it back on the users
• Note that goals sometimes fail

42
Use case granularity

• Goals come in different sizes.
• How do we know what the right size is?
• No easy answer, look for natural goals in terms
  of business value
• Look for enforcement of the contract between
  stakeholders and the system
• All stakeholders must be satisfied in terms of
  their interests

43
Use case formats

• Narrative
• The use case brief consists of two to four
  sentences summarizing the use case. It fits well
  in a spreadsheet cell, and allows the other
  columns in the spreadsheet to record business
  priority, technical complexity, release number,
  and other planning information.
• The casual use case consists of a few paragraphs
  of text, covering the items mentioned above.
• Scenario ( most popular)
• The fully-dressed use case features the long
  template with fields for stakeholders, minimum
  guarantees, post-conditions, business rules,
  performance constraints, and so on.
• Conversational
• The conversational use case follows a table -
  labeled with the set of actors in the first row.
  The columns are filled one cell per row, and
  going down in a timeline fashion, with
  information about the behaviour(s) of one of the
  actors through specific points of the conversation

44
Use case format

• A use case format is really just a stylized way
  of writing, a form of prose having two sections.
• The first section describes a basic scenario
  containing actions and interactions.
• The second section presents a set of scenario
  fragments, describing how the behavior differs
  under varying circumstances.
• A use case treats the system as a black box
• the user does this the system does that the
  system talks to another system something goes
  wrong the system now does this instead and so
  on

45
Use case limitations

• Use cases describe behavioural requirements. They
  don't take care of system design, UI design,
  feature lists, or testing (even though many
  people wish they would).
• A use case is normally intended as a requirements
  document, and the UI design is a design created
  by trained people after being told what the
  system should do. UI design is brittle, changing
  often.
• Use cases have a basic mismatch with feature
  lists. The same system feature is likely to show
  up as a line item in multiple use cases
• Use cases are not test plans or test cases. They
  are missing the data values needed for test
  cases.

46
Use case common mistakes

• The two most common mistakes and most costly to
  the project are including too many details and
  including UI specifics.
• Both make the use cases long, hard to read, and
  brittle.
• It requires effort to learn how to write in a
  technologically neutral way
• System presents the options. User selects an
  activity.
• The greatest value of the use case does not lie
  in the main scenario, but in alternative
  behaviors.
• The main scenario may occupy a quarter to
  one-tenth of the total length of the use case,
  because there are so many alternatives to handle.

47
Use case example

• Example Template
• Template
• CP Rail examples
• UC007 View BOL Status
• UC005 Complete Shipping Instructions
• Leads Mgmt System Example (Insurance)
• Manage Agency Profile

48
Use Case impact of Associations, Includes,
Extends and Generalizations

• Use cases that are referenced through include,
  extend and generalization relationships should be
  indicated in the use case itself
• Extension Points
• ltIf the use case has extension points, list them
  here.gt
• Related Use Cases
• lt If the use case include other use cases, list
  them here.gt
• Within the steps of the use case itself indicate
  transfer of control to another use case

49
Textbook Information

• Section 3.1 Principles of Requirements
  Determination
• Section 3.2 Requirements Elicitation
• Traditional Techniques Interviews,
  Questionnaires, Observation, Business Docs
• Newer Techniques Prototyping, JAD, RAD
• Section 3.3 Requirements Negotiation and
  Validation
• Scoping, Requirements Dependency Matrix, Risks
  and Priorities
• Section 3.4 Requirements Management
• Classification, Identification, Hierarchies,
  Change Management
• Section 3.6 Requirements Document
• Template (pg. 100), System Constraints, Project
  Matters, Appendices

50
Exercise

• Video (approximately 1 Hour Long)
• Suggest you take notes on the Video
• Apologize in Advance for the Bad Camera
  Techniques
• Group Yourselves into Two or Three only
• Homework, hand in 2 next week in-class for
  credit
• Setup Business Scenario, Purpose, Processes for
  Resort Property Sales, Locations for Business