The Software Process

1
CHAPTER 10
REQUIREMENTS PHASE
2
Overview

• Requirements elicitation
• Requirements analysis
• Rapid prototyping
• Human factors
• Rapid prototyping as a specification technique
• Reusing the rapid prototype
• Management implications of the rapid prototyping
  model
• Experiences with rapid prototyping

3
Overview (contd)

• Techniques for requirements elicitation and
  requirements analysis
• Testing during the requirements phase
• CASE tools for the requirements phase
• Metrics for the requirements phase
• Object-oriented requirements?
• Air Gourmet case study Requirements phase
• Air Gourmet case study Rapid prototype
• Challenges of the requirements phase

4
Requirements Phase

• Misconception
• Must determine what client wants
• I know you believe you understood what you think
  I said, but I am not sure you realize that what
  you heard is not what I meant!
• Must determine clients needs

5
Requirements Analysis Techniques

• Interviewing (primary technique)
• Structured versus unstructured interviews
• structured use specific, preplanned,
  close-ended questions
• example ask client how many salespeople the
  company employs
• or ask how fast a response time is required
• unstructured open-ended questions
• example why is the current product
  unsatisfactory?
• need both types of questions

6
Requirements Analysis Techniques

• Questionnaires
• useful if have hundreds of individuals to
  question
• can get well thought out answers
• but only get what you ask for cannot uncover new
  problems.

7
Requirements Analysis Techniques

• Forms analysis
• look at forms currently being used
• Video cameras
• record people at work
• takes a long time to analyze
• often seen as invasion of privacy

8
Requirements Analysis Techniques

• Scenarios
• Story boards
• Trees
• Rapid prototyping

9
Requirements Analysis

• two types of requirements
• functional requirements.
• example Royalties for each artist shall be
  computed from the playlist data using the May
  1998 CMS formula.
• non-functional requirements.
• specify properties of the target software
• example reliability and maintainability
• or relate to the environment in which the
  software must run
• example all bar codes shall be read using the
  Mach/Zor ASRCA input device.

10
Requirements Analysis

• Software must be traceable.
• must be possible to trace each statement in the
  requirements document through the specifications,
  design, and code.
• Allows SQA group to check that every statement in
  the requirements has been implemented correctly.
• Thus each statement in the requireemnts document
  needs to be numbered.

11
Requirements Analysis

• Client must rate each requirement
• essential, highly desirable, desirable, etc.
• requirements must be corrected as rest of process
  is done.
• next a rapid prototype is built.

12
Rapid Prototyping

• Hastily built (rapid)
• Key functionality

13
Rapid Prototyping

• Example apartment management software
• requires input screen that allows user to enter
  details of a new tenant and print an occupancy
  report for each month.
• These aspects must be included in the RP
• Do not include error-checking, file-updating
  routines, and complex tax computations.

14
Rapid Prototyping

• Rapid prototype reflects the functionality that
  the client sees
• eg, screens and reports
• omits hidden aspects such as file updating.

15
Rapid Prototyping

• Client experiments with prototype
• Developers watch and take notes.
• Users relate what works and what is missing.
• Developers change prototype until it meets client
  needs.

16
Rapid Prototyping

• Prototype does not have to work perfectly.
• Prototype must reflect the users view of the
  software.
• Prototype must be easy to change.
• Prototype is thrown away after it is used.

17
Human Factors

• Client and intended users must interact with the
  user interface
• Human-computer interface (HCI)
• Menu, not command line
• Point and click
• Windows, icons, pull-down menus

18
Human Factors

• Human factors must be taken into account
• Lengthy sequence of menus every choice leads to
  yet another choice.
• this is frustrating for a user.
• must also allow a user to change a previous menu
  without going all the way back to the top-level
  menu.
• Expertise level of interface
• if users have different levels of expertise, must
  provide different sets of interfaces or a single
  interface that can be modified by users.

19
Human Factors

• Uniformity of appearance
• all menus follow a similar pattern
• Rapid prototype of HCI obligatory

20
Rapid Prototyping as Specification Technique

• No specification phase
• Rapid prototype replaces specification document

21
Rapid Prototyping as Specification Technique

• Specifications
• use the prototype to determine what has to be
  done
• add a list of additional features that the client
  wants
• Advantages
• Speed
• No ambiguities, omissions, contradictions that
  arise from a specifications document

22
Rapid Prototyping as Specification Technique

• Disadvantages
• Specification document is contract prototype is
  not. Could have legal problems
• Testing requires specifications
• Maintenance requires specifications, otherwise
  will not know what the original software was to
  do.
• Conclusion Do not use rapid prototype as
  specifications

23
Reusing the Rapid Prototype

• Similar to Build-and-fix
• Becomes expensive since it is expensive to change
  working software.
• Built rapidly, so many possible faults.

24
Reusing the Rapid Prototype

• No specifications, no design done.
• Quality declines.
• Maintenance difficult.
• Real-time constraints.
• prototype does not emphasize performance

25
Reusing the Rapid Prototype

• Expensive option
• Reuse rapid prototype
• Cheap option
• Discard rapid prototype
• Should use different language for prototype and
  final product.
• Guarantees prototype will be thrown away.

26
Reusing the Rapid Prototype

• Can safely retain (parts of) rapid prototype if
• Prearranged
• Passes SQA inspections
• This is not classical, ie, can no longer be
  rapid if code must meet such high standards.
• Can safely reuse parts of the prototype if they
  were computer generated.
• eg, use screen generators and report generators
  to generate the user interface.

27
Rapid Prototyping

• Client perception
• RP encourages client to request major changes
• Client wants to use RP as final product
• Client expects changes to final product to be as
  quick as changes to RP.

28
Rapid Prototyping

• Management Implications
• Immediate delivery
• Instant maintenance
• different than traditional Waterfall model
• Waterfall modelget it right first time
• Rapid prototypingmany changes, then discard
• Increased interaction with clients
• not true with other models they just use
  interviews

29
Case for Rapid Prototyping

• Not proven beyond all doubt
• Experiment of Boehm, Gray, and Seewaldt (1984)
• Seven different versions of product compared
• four specified, three prototyped
• Prototyping, specifying yielded equivalent
  performance
• Prototyped versions had 40 less code, 45 less
  effort
• Prototyped versions were lower on functionality
  and robustness (speced versions added features
  because they didnt know how difficult
  implementation would be)
• Prototyped versions were higher on ease of use
  and ease of learning
• Specifying made integration easier

30
Case for Rapid Prototyping (contd)

• Important facts (not often mentioned) about the
  experiment
• Experiment on seven teams of graduate students
• Three teams of size 2, and four teams of size 3
• Ten week duration
• No maintenance
• Treat results as indications, not facts

31
Experiences with Rapid Prototyping

• Analysis of 34 case studies Gordon and Bieman,
  1992
• 29 successes, 2 failures, 3 neutral
• (But few failures are published!)
• All agreed
• User participation was essential, user needs were
  met

32
Experiences with Rapid Prototyping

• Not all issues were addressed in all case studies
• (Only 16 mentioned ease of use, but all 16 were
  positive)
• Choice of prototyping language was not important
• 26 different languages used
• Most popular lisp (4), Smalltalk (3)

33
Controversy

• Discard or retain rapid prototype?
• Diametrically different processes used
• 18 recommended retention, 7 said discard
• 6 out of 6 large projects recommended retention

34
Testing during the Requirements Phase

• Aim establish clients real needs
• Users must interact thoroughly with rapid
  prototype
• Issues must reach client

35
CASE Tools for the Requirements Phase

• Language for Rapid Prototyping
• Interpreted languages environments (Lisp,
  Smalltalk)
• Hypertext (HTML) for user interfaces
• 4GL (Oracle, PowerBuilder, DB2)
• Fewer statements needed to achieve functionality
• Often interpreted
• Often powerful CASE tools are available in 4GL

36
CASE Tools for the Requirements Phase

• Danger of 4GL
• Part of larger environment tempting to use these
  tools to build-and-fix the prototype
• Cheap solution buying a separate RP tool is
  expensive

37
Metrics for the Requirements Phase

• Quality, reliability?
• Volatility, convergence how fast do the
  requirements change and converge.
• Changes during subsequent phases
• Number of times each feature is used
• the more often a feature is used, the more
  important it may be to the user
• less used features may be candidates for
  discarding.

38
Object-Oriented Requirements Phase

• On the one hand
• The aim is to find the clients needs
• Objects dont enter into it theyre design
  techniques
• On the other hand
• Using an object-oriented language for the rapid
  prototype may help to identify classes

39
Air Gourmet Case Study Requirements Phase

• See pages 308 through 311 of the Fifth Edition of
  Object-Oriented and Classical Software
  Engineering
• Read this before the next class!

40
Air Gourmet Case Study Rapid Prototype

• C and Java repid prototypes are available on the
  Web at www.mhhe.com/engcs/compsci/schach
• For speed in implementation
• Data are stored in fixed-size arrays
• 10 passenger records are stored in an array
• 20 flight records are stored in an array
• in final version, must allow unlimited numbers
  in arrays

41
Air Gourmet Case Study Rapid Prototype

• Only two reports are implemented (the other four
  are similar)
• report on low-sodium meals
• report on meals onboard the flight.
• other 4 reports are similar to the two that are
  implemented.
• other 4 reports are implemented as stubs. Just
  display a message when invoked.

42
Air Gourmet Case Study Rapid Prototype

• Interface is menu driven
• not as elegant as a graphical user interface
• but is fast to create
• GUI is often OS specific

43
Portion of Rapid Prototype

• C
• Java

44
Challenges of the Requirements Phase

• Employees of the client organization feel
  threatened by computerization
• Requirements team members must be able to
  negotiate with the client
• The clients needs may have to be scaled down
• Key employees of the client organization may not
  have the time for essential in-depth discussions
• Flexibility and objectivity are essential
• developer should not have any preconceived ideas