Requirement Elicitation

Perancangan Sistem Informasi Logistik

Teknik Logistik UISI

2017
Finding the voice of the user
Want need
The features that users present as their wants dont
necessarily equate to the functionality they need to perform
their tasks with the new product
Customers as well as users need to have shared
understanding of the intended product
Who are the users?
Classifying users
Users can be grouped into different classes based on:
Their access privilege or security levels (such as ordinary user, guest
user, administrator)
The tasks they perform during their business operations
The features they use
The frequency with which they use the product
Their application domain experience and computer systems
expertise
The platforms they will be using (desktop PCs, laptop PCs, tablets,
smartphones, specialized devices)
Their native language
Whether they will interact with the system directly or indirectly
Identifying User Classes
From context diagram
From organizational chart, look for:
- Departments that participate in the business process.
- Departments that are affected by the business process.
- Departments or role names in which either direct or
indirect users might be found.
- User classes that span multiple departments.
- Departments that might have an interface to external
stakeholders outside the company
Documenting User Classes
User class
Characteristics
Responsibilities
Physical Location
...
Documenting User Classes
Connecting with user representatives
Each user class needs someone to speak for it
Examples of communication pathways
Requirement Elicitation
Requirement Elicitation Techniques
Interviews
Workshops
Focus Group
Observations
Questionnaires
System Interface Analysis
User Interface Analysis
Document Analysis
Interviews
The most obvious way:
- ASK
Some tips:
- Establish rapport: introduction, reviewing agenda and
objectives, ...
- Stay in scope
- Prepare question and materials ahead of time
- Suggest ideas
- Listen actively
Workshops
Facilitated session with multiple stakeholders: users, developers,
testers, ...
Used to elicit requirement from multiple stakeholders concurrently
More effective for resolving disagreements
Some tips:
- Establish and enforce ground rules
- Fill all of the team roles: note taking, time keeping, scope & rule
management
- Plan an agenda
- Stay in scope
- Use parking lots to capture items for later consideration
- Timebox discussions
- Keep the team small but include the right stakeholders
Observations
Directly observing how people do their jobs
Time consuming
Questionnaires
A way to survey large groups of users
Inexpensive
Some tips:
- Provide answer options that cover the full set of possible responses.
- Make answer choices both mutually exclusive
- Dont phrase a question in a way that implies a correct answer.
- Use scales consistently throughout the questionnaire.
- Use closed questions, not open ended, with two or more specific choices if
you want to use the questionnaire results for statistical analysis
- Consider consulting with an expert in questionnaire design and
administration to ensure that you ask the right questions of the right
people.
- Always test a questionnaire before distributing it
- Dont ask too many questions
System interface analysis
Examining the systems to which your system connects
Reveals functional requirements regarding the exchange of
data and services between systems
Can start from context diagram
User interface analysis
Study existing systems to discover user and functional
requirements
Can use screen shots when direct interaction not possible
Document analysis
Examining any existing documentation for potential software
requirements
Useful documentation:
- requirements specifications
- business processes
- lessons-learned collections
- user manuals
Elicitation Planning
Elicitation objectives
Elicitation strategy and planned techniques
Schedule and resource estimates
Documents and systems needed for independent elicitation
Expected products of elicitation efforts
Elicitation risks
Elicitation techniques by project characteristic
Conducting Elicitation
How do you know when youre done?
The users cant think of any more use cases or user stories
Users tend to identify user requirements in sequence of
decreasing importance
Users propose new scenarios, but they dont lead to any new
functional requirements
Users repeat issues they already covered in previous
discussions
Suggested new features, user requirements, or functional
requirements are all deemed to be out of scope
Proposed new requirements are all low priority
Some cautions about elicitation
Balance stakeholder representation
Define scope appropriately
Research within reason
Assumed and implied requirements
Assumed requirements
Those that people expect without having explicitly expressed
them
What you assume as being obvious might not be the same as
assumptions that various developers make.
Implied requirements
Necessary because of another requirement but arent
explicitly stated
Developers cant implement functionality they dont know
about.
What you should do for your end-of term project

Create a software requirement specification of a logistic

information system for a company (or business)
- You may pretend that the company currently doesnt have
any logistic information system
Create a GUI prototype (mockup) of the information system
Where to start
You need to find out and document the
- business process,
- documents, and
- users
involved in the logistic operation of the company
Use Data Flow Diagrams (DFD), Swimlane Diagrams, State
Transition Diagrams, and State Tables where necessary
Due: 29 November 2017