USER NEEDS REQUIREMENTS SPECIFICATIONS

1
USER NEEDS ? REQUIREMENTS ? SPECIFICATIONS

• By Walter Maner
• ?

Some content adapted from Behforooz and Hudson
Software Engineering Fundamentals Chapter 4 Glen
Ray and Craig Larman, Applying UML Patterns
2
NEEDS OF WHICH USER?

• The needs of the person who pays for your
  services (the client)?
• ... OR ...
• The needs of the person who will interact with
  the system on a regular basis (the operator)?

3
SHORT ANSWER

• for determining FUNCTIONAL requirements, the
  needs of the operator dominate
• for determining NONFUNCTIONAL requirements, the
  needs of the client dominate

4
FUNCTIONAL versus NONFUNCTIONAL

• FUNCTIONAL Requirements
• Describe an interaction between the system and
  its operator
• NONFUNCTIONAL Requirements
• Describe a property or characteristic that a
  software system must exhibit, or a constraint
  that it must respect, other than an observable
  system behavior
• Often describe a restriction on the system
  imposed by the client (e.g., must run under
  Win2K)
• This restriction limits the developer's choices
  for constructing a solution to the problem

5
THE NRS PROCESS CLASSICAL MODEL

• Client Needs Analysis (interviews) ?
• Operator Profiling (surveys) ?
• Use Case Construction ?
• System Requirements Specification ?
• Software Design Specification

6
THE NRS PROCESS AGILE MODEL

• Personas ?
• Proposal and acceptance of Use Cases ?
• Specification of SOME Use Case elements ?
• Construction and elaboration of Use Case
  scenarios ?
• Simulation of scenarios using roleplay or
  lo-fidelity prototype ?
• High-level test case construction

7
USE CASES

• A USE-CASE is a description of a NEED for
  particular types of communication with the
  software system
• input to the system
• output from the system
• This one- or two-way communication process
  generates a specific flow of events through the
  system

8
EXAMPLE USE-CASES FOR BGSU SIS

• A student needs to REGISTER FOR A COURSE.
• A professor needs to GET COURSE ENROLLMENT
  LISTS.
• A student needs to DROP A COURSE.
• A registrar needs to PRODUCE STUDENT TRANSCRIPTS.

9
USE-CASE CONTEXT DIAGRAMShowing 4 separate Use
Cases
Image Credit http//www.togethersoft.com/services
/practical_guides/umlonlinecourse
10
USE-CASE CONTEXT DIAGRAMThe entire world
stereotyped in politically incorrect Use Cases
Source http//www.umljokes.com/
11
USE CASES CAPTURE

• a typical interaction between a user (persona)
  and the system
• user-visible functionality only
• the moment when the user achieves their goal (or
  fails, if it is a negative Use Case)
• the external behaviour of the system from users
  points of view

12
USE CASES USED FOR

• implicit capture of user (persona) requirements
• what they need
• what interactions they expect to have with the
  system
• planning iterations of development
• constructing test cases

13
USE CASE SKELETON

• Use Case Name
• The use case begins when the actor does
• The system responds by
• The use case ends when

14
ACTOR IN USE CASE

• Primary Actor accomplishes goal via UC
• Typically a human user, also concepts like Time
• Secondary Actor provides a service to UC
• Typically, another system (non-human)
• Offstage Actor is interested in UC results
• Regulatory agency

15
USE CASE BASED ON SKELETON

• Check account balance
• The use case begins when the user (primary actor)
  enters a request for his account balance.
• The system responds by displaying the account
  balance.
• The use case ends when the user sees the balance.

16
USE-CASE SCENARIOS

• A USE-CASE SCENARIO is a specific instance of a
  Use Case
• If the Use Case is the theme, then the
  scenarios express variations on the theme
• For each Use Case, there may be many different
  scenarios
• usually many problem scenarios
• at least one normal scenario

17
USE-CASE SCENARIO Example for ATM Cash
Withdrawal Use Case
A cash withdrawal transaction is started when the
customer chooses cash withdrawal from the menu
of possible transaction types. Next, the customer
chooses a type of account to withdraw from (e.g.
checking) by selecting from a menu of possible
accounts, then a dollar amount from a menu of
possible amounts. The system verifies that it has
sufficient money on hand to satisfy the request,
then sends the customer's card number, PIN,
chosen account and amount to the bank, which
approves the transaction. The machine dispenses
the correct amount of cash and issues a receipt.
The bank is notified that the approved
transaction was completed in its entirety by the
machine, at which point the bank completes
debiting the customer's account for the amount.
Narrative format
18
ASSUMPTIONS FOR NORMAL SCENARIOS FOR SIS
USE-CASE 1

• A student wants to register for a course and
  these assumptions are true
• they have paid their bursar bill,
• they are taking less than the maximum number of
  courses,
• they have no course scheduled at that time,
• they meet all the prerequisites and
• there is room left

19
ASSUMPTIONS FOR ABNORMAL SCENARIOS FOR SIS
USE-CASE 1

• A student needs to register for a course and
  most of the normal-case assumptions are true ...
  but one of these is true
• they have not paid their bursar bill
• they have already registered for the maximum
  number of courses
• they already have a course scheduled at that time
• they are missing a prerequisite
• the course is full

20
USE-CASE ANALYSIS STEP BY STEP

• Identification of system boundaries
• Identification of actors among the objects
  outside the system boundary
• For each actor, identification of needs
  supporting a possible use-case
• Consolidation of related use-cases
• Construction of a use-case diagram
• Construction of use-case descriptions
• Construction of use-case narrative / scenario
• Identification of alternatives / exceptions

21
FORMALUSE CASE DESCRIPTION

• Formal use case description provides details of
  preconditions, postconditions, sequence of
  activities, and exception conditions in use case
• Describes actor interacting with computer system
  step-by-step to carry out business activity
• May have several scenarios for a use case, each a
  specific use case instance
• Many analysts prefer to write narrative
  descriptions of use cases instead of drawing
  activity diagrams

22
FORMAL UC DESCRIPTIONTop-level detail
From Systems Analysis and Design in a Changing
World, Fourth Edition
23
FORMAL UC DESCRIPTIONMid-level detail
This flow can be elaborated into a complete
step-by-step scenario or UML sequence diagram
From Systems Analysis and Design in a Changing
World, Fourth Edition
24
FORMAL UC DESCRIPTIONBottom-level detail
From Systems Analysis and Design in a Changing
World, Fourth Edition
25
FORMAL UC DESCRIPTIONAnother Example
26
Another Example
27
GENERIC USE CASE STRUCTURE

• UC Name in Verb Noun format
• Open Account, Enroll Student
• Description
• 1 paragraph high-level narrative description of
  the UC
• Actors
• List all Actors who can trigger use case
• Preconditions
• What must be true before use case can be
  triggered
• Perhaps another UC must precede this one
• Postconditions
• What must be true upon completion of the UC
• Step-by-step scenarios
• Base Scenario
• sequence of actions that must occur assuming
  nothing exceptional
• Alternative Scenarios
• a sequence branching off the base sequence
• occurs because of an exception

28
OUR USE CASE TEMPLATE
http//csweb.cs.bgsu.edu/maner/464/UseCaseTemplate
.doc
29
DIGRESSIONUse Cases in OOD Highlight the Nouns
30
DIGRESSIONUse Cases in OOD Partial Object List
31
EXTENDED EXAMPLE

• Element 1 of 4The USE CASE TITLE (task)
• Example Withdraw 50 from ATM
• Concise verb-object format
• Element 2 of 4The GOAL
• Example Have 50 cash to spend
• Usually a to have or to be verb

32
EXTENDED EXAMPLE

• Element 3 of 4The USER (or name of persona)
• Assumption A financially solvent customer of
  Huntington Bank, with a valid bank card, who
  needs 50 cash approaches the Huntington ATM in
  the BTSU
• Element 4 of 4The SYSTEM (or application)
• Assumption A normally functioning Huntington ATM
  located in the BTSU lobby

33
EXTENDED EXAMPLE Use Case Scenario

• Feedback
• ATM displays welcome message.
• ATM requests insertion of bank card.
• Action
• User inserts valid Huntington bank card,
  correctly oriented, as requested.
• Feedback
• ATM makes mechanical sound, ingests bank card.
• Action
• User sees bank card disappear.
• User waits 5 seconds for response.

34
EXTENDED EXAMPLE Use Case Scenario

• Feedback
• ATM displays Please enter your four-digit PIN
• Action
• User somehow enters correct four-digit PIN, 1
  digit at a time.
• Feedback
• ATM somehow acknowledges each digit as it is
  entered.
• Action
• User somehow signals that PIN entry is complete.
• Feedback
• ATM displays list of four options on screen
• Withdraw 50
• Withdraw other amounts
• Make a deposit
• Other transactions

35
EXTENDED EXAMPLE Use Case Scenario

• Action
• User somehow chooses Withdraw 50 option.
• User waits 15 seconds.
• Feedback
• ATM makes mechanical noise.
• ATM dispenses cash.
• ATM displays message Please remove your cash.
• Action
• User removes cash.
• Feedback
• ATM displays message Do you want to make
  another transaction Yes or No.

36
EXTENDED EXAMPLE Use Case Scenario

• Action
• User somehow chooses "NO".
• Feedback
• ATM makes mechanical noise as it prints receipt.
• ATM partially ejects bank card.
• ATM displays message Please remove your card
  and receipt.
• ATM makes repeated beeping sound.
• Action
• User removes receipt.
• User removes bank card.

37
EXTENDED EXAMPLE Use Case Scenario

• Feedback
• ATM stops making beeping noise.
• Action
• User watches screen for 15 seconds.
• Feedback
• ATM redisplays welcome message.

38
MAIN OBJECTIVEfor us, expressed in the form of
the main question a user wants answeredTOREPRESE
NTATIVE PERSONASTOUSE CASESTOUSER
NEEDSTOSYSTEM REQUIREMENTSfor us, expressed as
test cases
TYPICAL PROGRESSION
39
WRITING USE CASES

• Minimize verbosity
• Use terminology from business domain
• Avoid IT jargon / implementation concepts
• Never refer to mouse clicks, GUI widgets,
  screens, databases, etc.
• Each step begins with System or User
• Avoid using both System and User in same step
• Use present tense, active voice
• 1 or 2 discrete actions per step
• No if-else logic
• Adhere to triplet structure (N-V-O)

40
USE CASE MISTAKES ?

• Cashier enters item identifier
• System displays main menu
• User enters an item identifier
• System requests password from user
• Password is entered by user
• System generated error log
• User clicks on submit button
• System executes load_DB module
• System asks user for password
• Rating engine calculates the premium due
• System checks input for errors

41
UC Context Diagram
42
Extended ExampleSource Glenn L. Ray and Craig
Larman
Process Sale

• The following version of Process Sale is written
  in triplet style but it contains a major
  error
• Raise your hand when you find it

43
Extended Example UC Process Sale
Process Sale

• System provides make new sale option
• User selects make new sale
• System creates new sale
• System requests item identifier and quantity
• User enters item identifier and quantity
• System verifies item identifier and records sale
  of item
• System presents item description, price, and
  current total
• Steps 4-7 repeated until all items entered
• System requests is sale finished?
• User confirms sale is finished
• System requests payment information
• User enters payment information
• System handles payment
• System logs completed sale
• System generates receipt

44
Extended Example UC Process Sale
Process Sale

• System provides make new sale option
• User selects make new sale
• System creates new sale
• System requests item identifier and quantity
• User enters item identifier and quantity
• System verifies item identifier and records sale
  of item
• System presents item description, price, and
  current total
• Steps 4-7 repeated until all items entered
• System requests is sale finished?
• User confirms sale is finished
• System updates sale status to closed
• System requests payment information
• User enters payment information
• System handles payment
• System logs completed sale

45
USE CASE SUMMARY

• Goal oriented
• Capture the external interaction or dialogue
  between an actor and the system
• Simple UC diagram unpacks into an ordered
  sequence of steps
• When the sequence of steps is complete, it
  becomes a use case scenario
• One UC can contain multiple scenarios (more than
  one path thru a UC)
• Scenario can range from simple summary narrative
  to an elaborate template-driven document

46
USE CASE BENEFITS

• Emphasize user goals and objectives
• Decompose system functionality into a set of
  discrete tasks (divide and conquer)
• Easy for users to understand
• Can be reused for user documentation
• Basis for planning (estimating) work during each
  iteration
• Guide developers during implementation
• Test cases can be taken directly from UCs
• Independent of implementing technology

47
CLASSICAL (not agile) SOFTWARE REQUIREMENTS
SPECIFICATION (SRS)
48
WHAT IS A REQUIREMENT?

• DEFINITION
• A requirement typically describes what a system
  must BE or must DO in order to meet some specific
  need expressed by the client or by the operator
• RELATED TERMS
• features, operations, actions, constraints,
  results
• FOCUS
• INITIALLY, requirements are derived from what the
  client needs, or the problem the client wants
  solved
• LATER, additional requirements are derived from
  what the operator needs, or the problem the
  operator wants solved

49
SRS NEEDS DEFINITION

• A complete, enumerated listing
• Enumerations become fixed ID tags (Dewey
  Decimals)
• Once assigned, are not allowed to change
• Referenced later in requirements tracking
• List includes everything the client or operator
  need the proposed system
• to be
• to do
• Written in language both the client and the
  operator can understand

50
SRS EXAMPLES OF NEEDS

• NEED 1
• Water quality information must be accessible
  immediately.
• NEED 2
• The software must provide a means of representing
  and accessing external files created by other
  tools.

51
SRS REQUIREMENTS STATEMENTS

• For every defined need
• a complete precise statement of what is required
  to meet that need
• written in language developers can understand

52
SRS STATEMENT OF REQUIREMENTS FOR NEED 1
Water quality information must be accessible
immediately.
53
NEED 1 REQUIREMENTS

• Retrieval of water quality records must not
  require construction of a complex query
• Once requested, water quality records must be
  retrieved within five seconds of request
• The water quality record will include all of the
  following expressed in parts per million
  bacteria content, pesticide content, fertilizer
  content, fluoride content, and lime content
• The water quality record will be displayed in the
  form of a graph that can be readily assimilated

54
SRS STATEMENT OF REQUIREMENTS FOR NEED 2The
software must provide a means of representing and
accessing external files created by other tools.
55
NEED 2 REQUIREMENTS

• The user should be provided with facilities to
  define the type of external files
• Each external file type may have an associated
  too which may be applied to the file
• Each external file type may be represented as a
  specific icon on the user's display

56
NEED 2 REQUIREMENTS

• Facilities should be provided for the icon
  representing an external file to be defined by
  the user
• When a user selects an icon representing an
  external file, the effect of that selection is to
  apply the tool associated with the type of
  external file to the file represented by the
  selection icon

57
SIDEBAR

• IS IT A USER NEED or A SYSTEM REQUIREMENT?
• Sometimes hard to distinguish
• RULE OF THUMB
• I (client or operator) need X, therefore the
  system must do A, B and C.

58
SIDEBAR

• What becomes of requirements?
• Eventually, each one is converted or expanded
  into a set of design specifications

59
SRS ABBREVIATED TABLE OF CONTENTS

• INTRODUCTION
• Brief Narrative Description of the Proposed
  System
• Overall Goals for the Proposed System
• SYSTEM MODELS
• "Use Cases" for the Proposed System
• Top-level UML diagrams for the Proposed System
• FUNCTIONAL NEEDS AND REQUIREMENTS
• Definition of Each Need
• Specification of System Requirements for Each
  Definition
• NONFUNCTIONAL AND REQUIREMENTS
• Definition of Each Need
• Specification of System Requirements for Each
  Definition
• SIGNOFF SHEET

60
SRS REQUIREMENTS VALIDATION

• Are the requirements
• Correct ?
• Precise ?
• Unambiguous ?
• Complete ?
• Verifiable ?
• Mutually consistent ?
• Understandable ?
• Traceable ?
• Realistic ?