Presentation material is based on notes from Bernd Bruegge

1
System Analysis and Design II

• Analysis
• (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
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)
5
Communication problems...
6
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

7
What is a good requirement?
8
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?)

9
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...

10
Functional Requirements
11
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.

12
Nonfunctional Requirements
13
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

14
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

15
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

16
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.

17
Interviews -- Five Basic Steps

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

18
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

19
Types of Questions
20
Designing Interview Questions

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

21
Questioning Strategies
22
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

23
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

24
Conducting the InterviewPractical Tips

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

25
Post-Interview Follow-Up

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

26
Interview Report
27
Your turn

• For your project, who do you interview?

28
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

29
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

30
Joint Application Design (JAD) Setting

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

31
JAD Meeting Room
JPEG Figure 5-5 Goes Here
32
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

33
Managing Problems in JAD Sessions

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

34
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

35
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.

36
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

37
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

38
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

39
Selecting the Appropriate Techniques
40
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.