Presentation material is based on notes from Bernd Bruegge

1
System Analysis and Design II

• Requirements Development

2
Objectives

• Understand how to create a requirements
  definition.
• Become familiar with requirements analysis
  techniques.
• Understand when to use each requirements
  analysis technique.
• Understand how to gather requirements using
  interviews, JAD sessions, questionnaires,
  document analysis, and observation.
• Understand when to use each requirements-gatheri
  ng technique.

3
Processes and Deliverables
4
Key Ideas

• The goal of the analysis phase is to truly
  understand the requirements of the new system and
  develop a system that addresses them.
• The first challenge is collecting and integrating
  the information
• The second challenge is finding the right people
  to participate.

5
Requirements Engineering

• a systematic approach to eliciting, organizing,
  and documenting the requirement of the system,
  and a process that establishes and maintains
  agreement between the customer and the project
  team on the changing requirements of the system.
  (Leffingwell Widrig 1999)

6
Requirements Engineering
Requirements specification (the document
that describes what has to be built, not how)
Requirements development (the process of creating
the requirements spec)
Idea of a new product (to solve some problem in
the real world)
7
Why software projects fail?
8
Communication problems...
9
Subareas of Requirements Engineering
Requirements Engineering
Requirements Development
Requirements Management
Specification (System proposal) - spec document -
templates - quality
Validation - reviews - prototyping - acceptance
test
Elicitation - sources - techniques
Analysis - req. types - modeling - negotiation
10
Purposes ofa requirements spec documents

• A requirements spec document is used by many
  different stakeholder for different purposes
• Customer - part of a formal contract
• Manager - basis for the project plan
• Developer - basis for the design and
  implementation
• Tester - document to test the system against
• Maintainer - starting point for understanding the
  system

11
What is a good requirement?
12
Necessary properties of requirements

• Unambiguous
• the meaning should be clear
• Consistent
• one requirement must not contradict another
• Complete
• E.g. The process is terminated if the wrong PIN
  has been entered more than a certain number of
  times. (What is that number?)
• Verifiable (possible to test)
• a requirement that cannot be tested is not a
  requirement
• E.g. The system should work in real-time mode.
  (What is real time here?)

13
A desirable property of requirements

• Free of implementation bias
• What vs. how
• Specification vs. solution
• E.g.,
• The system shall accept a password when data is
  accessed.
• This has a requirement to use password
• The system shall ensure that the data can be
  accessed only by authorized users.
• This gives you an opportunity to search for
  alternatives

14
Analysis Phase (Requirements Development)

• This phase takes the general ideas in the system
  request and
• refines them into a detailed requirements
  definition functional models
• structural models and
• behavioral models
• This becomes the system proposal
• Includes revised project management deliverables,
• feasibility analysis and
• workplan.

15
Requirement Specification

• a statement of what
• the system must do or
• characteristics it must have
• Written from businessperson perspective (what
  of system)
• Later requirements become more technical (how
  of system)

16
Functional vs. Nonfunctional

• A functional requirement relates directly to a
  process the system has to perform or information
  it needs to contain.
• Expresses business needs (business requirements)
• Or technical requirements( not too often)
• Nonfunctional requirements refer to behavioral
  properties that the system must have, such as
  performance, security, usability, etc...

17
Functional Requirements
18
Some types of non-functional requirements

• Look and feel
• Usability
• Performance
• speed, memory and other resources, accuracy,
  volumes, range of values, reliability,
• Operational
• e.g., The product will be used by mobile
  technicians.
• Maintainability
• e.g., Readily portable to Linux.
• Security
• Cultural and political
• Acceptable solutions, unacceptable solutions,
  political correctness, spelling, and so on.

19
Nonfunctional Requirements
20
Your turn

• Assume you build a web system to sell plants
• List 4 functional requirements
• 1.
• 2.
• 3.
• 4.
• List 4 non-functional requirements
• 1
• 2
• 3
• 4

21
Your turn

• For the plants web system, what type of
  requirements are those
• Be accessible to web users
• Include the company logo
• Provide management reports
• Includes pictures of the plants
• Print the page
• Restricts access to profitability information

22
Summary so far.

• A Requirement is a simple statement about what
  the system must do or what characteristics must
  have
• Requirements focus on what the system does not
  on how it does it
• Functional requirements relates to a process the
  system has to perform
• Non-functional requirements refer to the quality
  of the system

23
Summary so far

• Requirements development
• Elicitation (sources, techniques)
• Analysis
• Functional models scenarios, use cases
• Behavioral models
• Structural models
• Specifications
• Templates documents
• Used by customers, managers, developers, project
  managers, testers, maintainer

24
Requirements elicitation

• Requirements Elicitation activities
• Understanding the as-is system
• Identifying the improvements to be made
• Gathering requirements for the to-be system
• Techniques for identifying improvements to be
  made (business analysis techniques in the text
  book)
• Business process automation
• Business process improvements
• Business process reengineering

25
Business Process Automation

• Characteristics
• Doesnt change basic operations
• Automates/improves some operations
• BPA Techniques
• Problem Analysis
• Addresses ease of use and efficiency
• Monetary benefits are hard to identify
• Root Cause Analysis
• Treats the root cause, not the symptom

26
Business Process Improvement

• Characteristics
• Changes the way an organization operates
• Changes operation with new techniques
• Can improve efficiency
• Can improve effectiveness

27
BPI Components

• Duration Analysis
• Time to perform each process
• Identify idle times, overlapping, excessive
  serialization
• Process integration and parallelization
• Activity-Based Costing
• Examines major process costs
• Labor, material, rent, depreciation
• Informal Benchmarking
• Studies how other organizations perform business
  processes

28
Business Process Reengineering

• Changes how the organization does certain
  operations
• Consists of
• Outcome Analysis
• Focuses on outcomes (user satisfaction,
  profitability), not on means
• Ex a car insurance company should focus on
  providing the repaired car quickly
• Technology analysis
• What a re the new trends, what are the benefits
  of those
• Business on demand, autonomic computing, service
  oriented architecture
• Activity Elimination

29
Select Appropriate Technique

• Assess Potential Business Value
• Determine Project Cost
• Specify Breadth or Scope of Analysis
• Determine Risk of Failure

30
Business Process Analysis Characteristics
31
Your turn

• Describe what business process anlysis technique
  are you using for your project
• Why?

32
Requirements Gathering

• Techniques
• Interviews
• JAD sessions
• Questionnaires
• Document analysis
• Observation
• Stakeholders
• People and organizations interested in the
  product
• Customers, users, regulators, developers,
  architects, domain experts, analysts, marketing
  people, sales people, management, etc.

33
Interviews -- Five Basic Steps

• Selecting interviewees
• Designing interview questions
• Preparing for the interview
• Conducting the interview
• Post-interview follow-up

34
Selecting Interviewees

• Based on information needed
• Often good to get different perspectives
• Ideally, from all key stakeholders
• Practically, key stakeholders
• Managers, users
• People are sensitive to being excluded
• Be prepared to expand the list
• Schedule interviews

35
Types of Questions
36
Designing Interview Questions

• Unstructured interview
• Broad, roughly defined information
• Structured interview
• More specific information

37
Questioning Strategies
38
Interview Preparation Steps

• Prepare general interview plan
• List of question
• Anticipated answers and follow-ups
• Confirm areas of knowledge
• Set priorities in case of time shortage
• Prepare the interviewee
• Schedule
• Inform of reason for interview
• Inform of areas of discussion

39
Conducting the Interview

• Appear professional and unbiased
• Record all information
• Check on organizational policy regarding tape
  recording
• Be sure you understand all issues and terms
• Separate facts from opinions
• Give interviewee time to ask questions
• Be sure to thank the interviewee
• End on time

40
Conducting the InterviewPractical Tips

• Dont worry, be happy
• Pay attention
• Summarize key points
• Be succinct
• Be honest
• Watch body language

41
Post-Interview Follow-Up

• Prepare interview notes
• Prepare interview report
• Look for gaps and new questions

42
Interview Report
43
Your turn

• For your project, who do you interview?

44
Joint Application Development

• Allows project managers, users, and developers to
  work together
• May reduce scope creep by 50
• Avoids requirements being too specific or too
  vague

45
Joint Application Design (JAD) Important Roles

• Facilitator
• sets the meeting agenda and guides the discussion
• Scribe
• assist the facilitator by recording notes, making
  copies, etc.
• Project team, users, and management

46
Joint Application Design (JAD) Setting

• U-Shaped seating
• Away from distractions
• Whiteboard/flip chart
• Prototyping tools
• e-JAD

47
JAD Meeting Room
JPEG Figure 5-5 Goes Here
48
The JAD Session

• Tend to last 5 to 10 days over a three week
  period
• Prepare questions as with interviews
• Formal agenda and groundrules
• Facilitator activities
• Keep session on track
• Help with technical terms and jargon
• Record group input
• Help resolve issues
• Post-session follow-up

49
Managing Problems in JAD Sessions

• Reducing domination
• Encouraging non-contributors
• Side discussions
• Agenda merry-go-round
• Violent agreement
• Unresolved conflict
• True conflict
• Use humor

50
Questionnaire Steps

• Selecting participants
• Using samples of the population
• Designing the questionnaire
• Careful question selection
• Administering the questionnaire
• Working to get good response rate
• Questionnaire follow-up
• Send results to participants

51
Good Questionnaire Design

• Begin with non-threatening and interesting
  questions.
• Group items into logically coherent sections.
• Do not put important items at the very end of
  the questionnaire.
• Do not crowd a page with too many items.
• Avoid abbreviations.
• Avoid biased or suggestive items or terms.
• Number questions to avoid confusion.
• Pretest the questionnaire to identify confusing
  questions.
• Provide anonymity to respondents.

52
Your Turn

• Each project team writes a one page
  questionnaire for their project and handles it to
  members of another teams
• Compares the expected and the actual results

53
Document Analysis

• Provides clues about existing as-is system
• Typical documents
• Forms
• Reports
• Policy manuals
• Look for user additions to forms
• Look for unused form elements

54
Observation

• Users/managers often dont remember everything
  they do
• Checks validity of information gathered other
  ways
• Behaviors change when people are watched
• Careful not to ignore periodic activities
• Weekly Monthly Annual

55
Selecting the Appropriate Techniques
56
Summary

• Requirement engineering
• Requirements development ( this lecture)
• Requirements specification (next lecture)
• System analysis techniques
• BPA, BPI, BPR
• Systems analysts use these techniques
• Interviews,
• JAD,
• Questionnaires,
• Document Analysis, and
• Observation.