Gathering User Requirements

Collecting and organizing users requirement- WHAT- User needs

Chapter 3
 Basic objectives of the chapter
 Define requirement and related concepts?
 Understand requirement collection techniques
– Interview , observation, questionaries….
 Understand requirement identification techniques
– Essential use case modeling
– CRC modeling
– Essential user interfaces modeling
 Being familiar with validating, organizing and documenting
requirements in the form of SRS
Basic Stages of Developing any Software Product
 Requirement gathering

 Analysis

 Design

 Implementation

 Testing

 Maintenance
 What are Requirement?
• A requirement is a statement or brief description of the
services and qualities a customer would like included in a
product.

 Requirements Gathering is the process of generating a

list of requirements (functional, system, technical, etc.)
from the various stakeholders (customers, users, vendors,
IT/IS staffs, etc.).

 It helps software developer to better understand the

problem.

 A collection of all this requirements is a requirements

document or Software Requirements Specifications.
 Why do we need Requirements?

 Project failure typically stems from missing requirements,

ambiguous requirements, or requirements that are
incomplete, conflicting, or duplicative.

 If the appropriate requirements are not communicated

effectively, the project is at risk to be developed in a manner
that leaves the stakeholders unsatisfied.

 Research shows that 68% of IS projects fail due to poor

definition of requirements at the start.
 Requirement Elicitation Techniques
 Interviews – face-to-face communication with one or a few
users, closed (fixed questions) or open.

 Observation – watching users performing their jobs and

using legacy systems.
 Survey/Questionnaires –collecting information from
many peoples
 Focus Group- gathering of people who are representative of
the users of a product
 Examination of problem reports – analysis of users’
feedback on existing systems.
 Functional and non-functional
requirements
Functional requirement
•Functional requirement is something the system must do.
•Some Examples of functional requirements include:
• Specifications of what the system must do
• Business rules that must be met
• Steps that the system must take in authentication
• Details of what must be tracked in the system
• The reporting requirements of the system
• Specifics relating to legal or regulatory compliance
• Outlines the levels of user and their authorization
• Details of how transactions must occur
 Cont…
• Non-Functional Requirements
– Nonfunctional requirements is a requirement that specifies criteria
that can be used to judge the operation of a system, rather than
specific behaviors.
– Some of the Non functional requirements :
• Speed – how fast the system performs certain activities.
• Availability – for how much of the time the system is available e.g. does it
operate overnight, or every day of the year, or not.
• Capacity – what the limits are of what the system is able to handle.
• Reliability – how dependable the system is.
• Usability – how easy the system is to use for the customer or end user.
• Security: How are the system and its data protected against attacks?
 How to conduct?
• Through techniques like
– Essential use case
– CRC model
• Identifying initial analysis objects and classes
– Essential user interface
• Using technology independent
• These all techniques will help us in making domain
analysis.
• How to develop those diagrams?
UML tools( useful in practice)
 Requirement Elicitation using use case
• Use cases are a standard technique for gathering
requirements in many modern software development
methodologies.
• Use case Modeling could be
– Essential
• Used at requirement elicitation stage
• Technology free
• Just to understand what users need to see on the
system from functions point of view
– System
• Is a continuation of essential use case
• Adding implementation related details
10
 Use case diagram

• use case diagram models the functionality of the

system using actors and use cases.
• Also, it shows relationship between actors and
use cases in a system
• A use case diagram consists of :
– The system boundary
– Actors
– Use cases
– Relationships (among use cases, among actors, and
between actors and use cases)

11
 Use Case Diagram for a Simple University

Input Marks

Grade Administrator
Enroll in
Semester

Distribute
Transcripts
Student

Registrar
 Identifying Actors
• Anything or anyone that interact with your system
• Including people, external systems, and other organizations
• Never part of the system
• Questions help to find actors
– Customer?
– Who obtains information?
– Who provides information?
– Who installs the system?
– Who operates the system?
– Who shuts down the system?
– What other system interacts with our system?
– Does anything happen automatically at preset time?
– Who will supply, use or remove information?
– Where does the system get information?

13
 Cont…
– Identify use cases
• First identify scenarios or examples of system usage
and compile or represent some similar scenarios
with one case.
• Question to be asked
– What are the tasks that the actor wants the
system to perform?
 Essential Use Case Description
• Sections
– Name – purpose of the use case
– Description – summary of a use case
– Actors (optional) – associated with the use case
– Status (optional) – work in progress etc…
– Precondition – conditions that must be met
– Post condition – effect of a use case action
– Extension Points (optional) – covered later
– Included Use Cases (optional) – covered later
– Basic Course of Action – logic followed
– Alternate Course of Action – Infrequently used path
– Change History (optional) – when, who, why
modified use cases
 Essential Use Case Description Example
Name: Enroll in Semester
Description: Enroll an existing student in a seminar for which she is eligible
Preconditions: The Student is registered at the university
Post conditions: The Student will be enrolled in the course she wants if she is eligible and room is available
Basic course of Action:
1. A Students wants to enroll in a seminar
2. The Student submits his name and student number to the registrar
3. The registrar verifies the student is eligible to enroll in semesters at the university according to some
rule
4. The student indicates, from the list of available seminars, the seminar in which he wants to enroll
5. The registrar validates the student is eligible to enroll in the semester according to the business rule
6. The registrar validates the semester fits into the existing schedule of the student
7. The registrar calculates the fees for the seminar,
8. The registrar informs the student of the fees
9. The registrar verifies the student still wants to enroll in the seminar
10. The student indicates he wants to enroll in the seminar
11. The registrar enrolls the student in the seminar
12. The registrar adds the appropriate fees to the students bill
13. The registrar provides the student with a confirmation that he is enrolled
14. The use case ends
 Alternate Course of Action
• Infrequently used path of logic in a use case
• Exception or error condition that must be handled
• Style issues
1. Includes the descriptions of actions that must be met to
invoke the alternate course
2. Identification and numbering scheme is used
3. Each step starts with the letter of the alternate course,
followed by the number of the step in the basic course of
the use case it replaces
4. The last step in each alternate course of should indicate
either that the use case ends or goes to the last step of the
Basic Course of Action
 Example of Courses of Actions
Alternate course A: The student is Not Eligible to Enroll in Seminars
A.3. The registrar determines that student is not Eligible to Enroll in Seminar
A.4 The registrar informs the student she is not eligible to enroll
A.5 The use case ends
Alternate Course B: The Student Does Not Have the Prerequisites
B.5 The registrar determines the student is not eligible to enroll in the seminar
she chose
B.6 The registrar informs the student she does not have the prerequisite
B7. The registrar informs the student of the prerequisites she needs
B8. The use case continues at Step 4 in basic course of action
Alternate Course C: The student decides not to enroll in an available seminar
C4. The student views the list of seminars and does not see one in which she
wants to enroll
C5. The use case ends
Requirement Elicitation using CRC

• Task of discovering the classes that represent the

things and concepts pertinent to your problem
space
• A CRC model is a collection of standard index cards
that have been divided into three sections
– CLASS – collection of similar objects
– RESPONSIBILITY – something that a class knows or
does
– COLLABORATOR - another class that a class interacts
with to fulfill its responsibilities
 Layout of a CRC card

CLASS NAME

Responsibilities Collaborators
 Finding a CLASS
• Recall definitions of a class and an object
• A Class represents a collection of similar objects.
• Person, Place, Thing, Event or Concept
• Eg. University System
– Students, professors, seminars
• Objects are things of interest in the system being
modelled.
• Class is a Singular noun or singular noun phrase
• Class names should also be simple
• The Class name appears across the top of the
CRC card.
 Finding Classes

 There are many ways to identify classes.

• One of the easiest to start with is noun
extraction.
• Noun extraction identifies all of the Nouns in a
problem statement and/or use-case scenario.
• The nouns extracted make excellent candidate
classes
• Other ways to identify classes are to look for
items that interact with the system, or things
that are part of the system.
• Ask if there is a customer of the system, and
identify what the customer interacts with.
 Responsibilities
• Anything a class knows or does
• Eg. – Students have names, addresses and phone
numbers. (KNOWS)
• Students also enroll in seminars, drop seminars
and request transcripts (DOES)
• Classes update their own attributes and nobody
else’s
• The Responsibilities of a class appear along the left
side of the CRC card.
 Finding Responsibilities
• How? Through verb extraction
– Verb extraction identifies all of the verbs in a problem
statement and/or use-case scenario.
– These are usually good indicators of actions that must
be performed by the classes of the system.
• Other techniques included asking what the class
knows, and what information must be stored about
the class to make it unique.
• Ask what the class does, and then flesh out how
the class might do it.
 Collaboration
• A class may not have enough information to do its
responsibilities, need information from other classes
• Takes one of two forms
– A request for information or
– A request to do something.
• EG. – The card “Student” requests an indication
from the card “Seminar”
– A request for information
– A request to do something
– The Collaborators of a class appear along the
right side of the CRC card.
 CRC Examples
User Menu
Responsibilities Collaborators
Display main menu
Ask user for PIN
Send PIN to Bank System for validation
BankSystem
Display validation errors
Ask Bank System for balance
BankSystem
Print Balance
Printer
Display Fast Cash menu
Debit Account
BankSystem
Dispense Money
MoneyDispenser
Print Receipt
Printer
Eject card
CardReader

Bank System
Responsibilities Collaborators
Validate PIN

Get Balance

Card Reader
Responsibilities Collaborators
Detect card inserted
Tell User Menu to ask for PIN User Menu
Eject card
 Essential User Interface Prototyping
• Place where user directly interacts with systems
• Low fidelity model, or prototype of the UI for your
system
• It represents the general ideas behind the UI, but
not the exact details
• Represents the initial stage of the UI
requirement in a technology independent
manner, just like essential use case model.
 Essential User Interface Prototyping
is an iterative development technique in which
users are actively involved in the mocking-up of
the UI for a system.
• It is represented by various rectangles enclosed in
a bigger one.
• Grouping of smaller rectangles can be done by
larger ones.
 Differentiating facts about essential UI
prototyping
• Focus on your users and their usage of the
system, not system features
• Simple tools including whiteboards, flip chart
paper and sticky notes
• Don’t focus on the design
o HTML, JAVA, Window Based
 Tools to be used
• For all essential modeling's the tool to be used is
simple:
– Paper, whiteboard, sticky papers….
• The purpose is to focus on the major issues (the
actual task) rather than technology or
implementation details.
 Example for essential UI
Student Information
Student Help
Enroll Students in Seminar
Number Requester

Student Name

Display Course Details

Requester Course Seminar Seminar
Number Location Availability

Course Enrollment
Course Searcher Name Requester
Course
Number Course
Description
Course
Name

Search Details Professor

Requester Requester
UI Prototype for a Student Transcript

Student Information
Student Number Student Phone Number Student Address Student Full Name

Student Email Period Student Status Payment Status

Amount Owed

Seminars the student he have taken during period of the transcript

Informational Message Footer Information

 Business Rules
• Any organization has its own internal policies and principles
on how to run its business
• E.g.: if a student wants to add a new course and if it is the case that
the student has reached the maximum semester load then the student
will be required to drop some courses he already registered for. Thus
the use case “Add Course” can extend to another use case called “Drop
Course” based on evaluation of a business rule that declares the
maximum credit hours the student is allowed to take in a semester.
– i.e.: If Current Load of student plus Credit hour of course to be
added is greater than the Maximum semester Load (say 21) then
include use case Drop Course
 Cont..
• Common ways of documenting business rule
– ID: BR001
– Name: Allowed Maximum Semester Load
– Description: A regular/day student is not allowed to
take more than 21 credit hours per semester. If the
student is an extension/evening student, he/she can
not take more than 12 credit hours per semester
 Organizing and documenting requirements
• Finally you are required to organize and document your
requirements collected through traditional methods, Essential use
case, CRC and UI prototype in one document which will serve as
an agreement document b/n the developers and users.
• Software Requirement Specifications(SRS)
– The SRS is a specification for a specific software product,
program, or set of applications that perform particular
functions in a specific environment.
– Software requirement specification is a kind of document
which is created by a software analyst after the
requirements collected from the various sources.
Next, Analysis
System use case modeling
Conceptual Class diagram
Sequence diagram
Activity Diagram
User interface prototype UI
Thank you!