Business Analysis Ch 4

1. Chapter 4: Requirements
Elicitation and Collaboration
Learning Outcomes
• Overview and Definitions
• Elicitation Steps
• Elicitation Techniques

2. Relationships Between Knowledge Areas
BAs elicit information from and collaborate with stakeholders to work
towards a common goal of clearly defining the business requirements
for your project.

3. Understanding Requirements
• ​A requirement is a specification of a need that can include
functions, behaviors and qualities of a product, service or a
system.
• A requirement is either a condition or a capability that is
required from you by a stakeholder for a specific project
– Conditions - might mean contractual terms obligations, compliance
requirements, time frames or budgets or policies to comply with
– Capabilities - these could be features that your stakeholders – The laptop shall
be blue color or it must have 14” display or internet speed should be min
1mbps, these are capabilities that your solution needs to have
• Set of requirements are used to capture the information
needed to design, build and test a process, service, product or
system.

4. Examples of Requirements
• Business Requirements
– Declining ticket sales require a strategy to increase the number of customers at our
theaters.
– Customers have overwhelmingly cited the inconvenience of standing in line as the
primary reason they no longer visit our theater. We will remove this impediment by
enabling customers to buy and print their theater tickets at home with just a few clicks.
– Design our web site and commerce so that all FCC, SEC and other relevant governmental
regulations are properly adhered to.
• Stakeholder Requirements
– As an Administrator, if I click on the Preferences tab on the App, I should be able to select
appropriate filters as my preferences
– As a Customer, I would like to have basic controls as buttons on the TV, whenever I may
lose my remote
– As an Order Manager, I would like to see all active orders in a single screen, as I need to
quickly access that feature several times during the day

5. Examples of Requirements
• Solution Requirements (Functional Requirements):
– The system shall capture customer orders using the various channels such as Retail POS,
Online e-commerce website, etc.
– The business rules related to the processes outlined must be configurable by the system
and not hard-coded into the application system developed
– Customers should be able to submit all the details in the online application form within
10 minutes in a secured way
– Customer could either order using online or offline channels
• Solution (Non Functional Requirements)
– Performance: The website's load time should not be more than one second for users.
– Reliability: Applicants can access their resume 98% of the time without failure.
– Availability: Employers can post jobs on the website throughout the week at any time
during the day.
• Transition Requirements
– The floors in the house must be covered with sheets to protect the floors when the
moving company moves the furniture into the house.
– Additional support staff must be available during the first month after the system has
been implemented to assist with additional support queries that may be received.
– Data from the Existing system must be migrated to the New System prior to the rollout

7. Requirement Attributes
• Each individual requirement
is typically structured to be
– distinct/unique,
– relevant,
– testable,
– Traceable
– unitary or atomic (meaning that
it addresses one thing and only one
thing).
• Collectively, sets of
requirements shall be
consistent and cohesive and
aligned / mapped to the
business goals

8. Elicitation and Collaboration KA - Overview
• The Elicitation and Collaboration knowledge area describes the tasks that
business analysts perform to obtain information from stakeholders,
confirm the results and communicate with stakeholders soon after the
BA information is assembled.
– Elicitation is the drawing forth or receiving of information from stakeholders
or other sources. Collaboration is the act of two or more people working
together towards a common goal.
– It is not a “phase” but an ongoing activity as long as analysis work is
occurring; Should not be considered an “isolated” activity
– May trigger additional elicitation activities to obtain details and to fill the
gaps and increase understanding
– Elicitation and collaboration can be planned, unplanned, or both and is
ongoing.
• Planned activities include workshops, experiments, and/or surveys whereas
unplanned activities can be last-minute or 'just in time' collaboration or
conversations.

9. Requirements Gathering Vs Elicitation
• Requirements Gathering is about collecting/gathering requirements from
within available information in the enterprise information assets.
– Requirements gathering is often what we do before elicitation. Few
information that may be ready to be collected include for example,
• information that is stored in documents (such as process models or regulations or
technical and whitepapers),
• systems (such as business rules or as-is functionality), and
• knowledgeable requirements-oriented stakeholders who have already drawn out
their own needs and are ready to tell us exactly what they need and want (they are
relatively rare, but they exist).
• Requirements Elicitation – Draw Out or Eliciting Requirements from the
Stakeholders
– More often, requirements usually must be drawn out (Elicitation) by a variety
of techniques that get to the root of the problem to be solved, understanding
stakeholder needs, and/or requirements.
– Requirements usually don’t just sit around waiting to be picked up and
collected together from some documents.

10. Input-Output Map
• This Elicitation and
Collaboration tasks
include:
– Prepare for Elicitation
activities
– Conduct elicitation activities
– Confirm the outcomes of
elicitation activities
– Communicate Business
Analysis Information so
elicited
– Manage Stakeholder
Collaboration

11. 7 Steps to Gather Requirements
(From the Video Clip)
1. Understand the needs by meeting the sponsors
– what is their need what is the outcome that they're looking for
– Elicit specific numbers against that outcome
– specifics as to how many people will be impacted by this
– why they want this or what sorts of performance
2. Understand the project limitations or constraints
– Time, money, resources, rules and policies and regulations
3. Do I know what I need to know?
– Understand what do I need to know to implement the solution or what specific
features/functionalities or capabilities (people, locations, process, volumes of
transactions, technology, etc.) they are looking for
4. Who or what document / databases can provide the information I need
5. How will I collect the information – Selection of requirements elicitation /
gathering techniques
– Interviews, focus groups, workshops, brainstorming sessions, document analysis, prototyping, etc.
6. When will I collect these information – BA Project Plan Schedules
7. What will I need to collect these information – which people and tools

12. Task: Prepare for Elicitation
Purpose: To understand the scope of the elicitation activity, select
appropriate techniques, and plan for (or procure) appropriate supporting
materials and resources.
Description Business analysts prepare for elicitation by defining the
desired outcomes of the activity, considering the stakeholders involved and
the goals of the initiative. The task includes:
– Determining which work products will be produced using the elicitation
results
– Deciding which techniques are best suited to produce those results
– Establishing the elicitation logistics and support materials
• Important for BA’s to understand the Priority, Criticality of the
requirements being elicited.
• BA’s role is to identify knowledgeable stakeholders, help them
participate and help them reach consensus.

13. Five Key Questions for Requirements Elicitations
• Question #1: How does this business requirement add value to your team and the entire
organization?
– The answer to this question is useful in determining what the ultimate priority of the requirement will be. Ultimately,
you want to focus on the requirements that provide the most business value to the entire organization.
• Question #2: What will happen to the business if we choose to not implement this
requirement?
– The answers to this question will seek out what the current state looks like and what risks will be involved if the
requirement is not implemented in any future state changes. Collaborating with your stakeholders will help you
determine the criticality of this requirement and if it should be prioritized to be implemented sooner than later.
• Question #3: What business data should be captured and stored for future use?
– Eliciting the key business data requirements will be useful when creating a data model, data dictionary, database, or
business report that will contain this key information.
– After eliciting the business data requirements, you should collaborate with your stakeholders to validate you are
capturing all data that will provide the most business value .
• Question #4: How will this requirement help the business become more efficient?
– This question will get your stakeholders to think about their current process and help determine the business value
and priority of the new requirement.
• Question #5: Who are the key business resources involved with this business process?
– It is extremely important to make sure you can identify all key business stakeholders with whom to elicit and
collaborate on requirements.

14. Elements
• Scope of Elicitation: BA’s consider the following aspects:
– Business domain
– Overall corporate culture and environment
– Stakeholders who are involved and their group dynamics
– Stakeholder locations
– Skills of the business analysis practitioner
– Strategy or solution approach
• Select Elicitation Techniques
– The techniques used depend on cost and time constraints, the types of
business analysis information sources and their access, the culture of
the organization, and the desired outcomes;
– When selecting elicitation techniques, business analysts consider:
• techniques commonly used in similar initiatives,
• techniques specifically suited to the situation, and
• the tasks needed to prepare, execute, and complete each technique.

15. Other Elements
• Setup Logistics: Logistics are planned prior to an elicitation activity. The
logistics for each elicitation activity include identifying:
– the activity's goals,
– participants and their roles,
– scheduled resources, including people, rooms, and tools,
– locations, communication channels,
– Techniques, and languages used by stakeholders (oral and written).
• Secure Supporting Material: Business analysts identify sources of
information that are needed to conduct the elicitation activity.
– There might be a great deal of information needed to conduct elicitation
including people, systems, historical data, materials and documents. Business
analysts procure or develop the materials and tools needed.
• Prepare Stakeholders: Business analysts may need to educate
stakeholders on how an elicitation technique works or what information is
needed.
– Stakeholders may be unresponsive or challenging during an elicitation activity.
In preparing for elicitation, the business analyst should ensure that there is
buy-in from all necessary stakeholders.

16. Task: Conduct Elicitation
• Purpose: draw out, explore, and identify information relevant
to the change.
• Description: There are three common types of elicitation:
– Collaborative: involves direct interaction with stakeholders, and relies on
their experiences, expertise, and judgment.
– Research: involves systematically discovering and studying information from
materials or sources that are not directly known by stakeholders involved in
the change. Research can include data analysis of historical data to identify
trends or past results.
– Experiments: involves identifying information that could not be known
without some sort of controlled test. Experiments can help discover
previously unknown information.
• Experiments include observational studies, proofs of concept, and prototypes.
• Stakeholders may collaborate in elicitation by:
– participating and interacting during the elicitation activity, and
– researching, studying, and providing feedback on documents, systems,
models, and interfaces

17. Elements of Conduct Elicitation
• Guide Elicitation Activity: BA’s consider the following:
– the elicitation activity goals and agenda,
– scope of the change,
– what forms of output the activity will generate and how does the output integrate into
what is already known,
– who provides the information, who will use the information, and how the information
will be used.
• Capture Elicitation Outcomes:
– If the elicitation activity is unplanned, outcomes are captured and integrated into the
appropriate planned outcomes.
– Capturing the elicitation outcomes helps to ensure that the information produced during
elicitation activities is recorded for later reference and use.
• Key Considerations
– Guard against Scope Creep by Tracing requirements to business goals/objectives
– Document requirement attributes (source, value, priority)
– Create Glossary of key domain terms and use this while eliciting requirements
– When there is more than one system, ensure requirements of the new system are
backward compatible with existing systems (“legacy system”)

18. Task: Confirm Elicitation Results
• Purpose: check the information gathered during an elicitation
session for accuracy and consistency with other information
elicited.
• Description: Elicited information is confirmed to identify any problems
and resolve them This review may discover errors, omissions, conflicts,
and ambiguity in requirements.
• Elements:
– Compare elicitation results against source information: sources from which
elicitation results may be derived, including documents and stakeholder
knowledge. The business analyst may lead follow-up meetings where
stakeholders correct the elicitation results and ensure accuracy.
– Compare elicitation results against other elicitation results: Business analysts
compare results collected through multiple elicitation activities, identify
variations in results and resolve them, to confirm that the information is
consistent and accurately represented.

19. Challenges in Requirements Elicitation
Few of the challenges that BA’s face during requirements
elicitation are:
• Conflicting requirements from different stakeholders
• Unspoken or assumed requirements
• Difficulty gaining access to the right stakeholders or their time for this
purpose
• The stakeholders' unwillingness to change or help design a new product.
• Not enough time available or allocated to meet with all the important
stakeholders.
The key to overcoming these challenges as you elicit requirements is to
continually motivate your users, developers and customers to communicate
and cooperate with each other. You can do this by selecting the right
elicitation techniques.

20. Requirements Elicitation – Issues and Rationale

21. Task - Communicate Business Analysis Information
• Purpose: Ensure stakeholders have a shared understanding
of business analysis information.
• Description: Business analysts must communicate appropriate
information to stakeholders at the right time and in formats that meet
their needs considering the language, tone, and style that is appropriate
to the audience.
• Communication of business analysis information is bi-directional and
iterative. It involves determining the recipients, content, purpose, context,
and expected outcomes.
• Business analysts engage stakeholders to ensure they understand the
information and gain agreement. The business analyst acts on any
disagreements.

22. Element: Communicate Business Analysis Information
Package
• The main purpose of this element is to provide stakeholders
with the appropriate level of detail about the change so they
can understand the information it contains.
• BA information packages may be prepared for a number of reasons
including:
– communication of requirements and designs to specific stakeholders,
– evaluation of possible alternatives,
– formal reviews and approvals,
– inputs to solution design,
– conformance to contractual / regulatory obligations, and for reuse
• Stakeholders are given the opportunity to review the
information package, ask questions about the information,
and raise any concerns they may have.

23. Elements: Confirm Elicitation Results
Format of Communication: Possible forms for Information packages may include:
• Formal Documentation: usually based on a template used by the organization and
may include text, matrices, or diagrams. It provides a stable, easy to use, long-
term record of the information.
• Informal Documentation: may include text, diagrams, or matrices that are used
during a change but are not part of a formal organizational process.
• Presentations: deliver a high-level overview appropriate for understanding goals
of a change, functions of a solution, or information to support decision making.
Common communication platforms include:
• Group collaboration: Communicate the package to a group of relevant
stakeholders at the same time.
• Individual collaboration: communicate the package to a single stakeholder at a
time to gain individual understanding of the information.
• E-mail or other non-verbal methods: communicate the package when there is a
high maturity level of information that will need little or no verbal explanation to
support it.

24. Task: Manage Stakeholder Collaboration
• Purpose: Encourage stakeholders to work towards a common
goal.
• Description: Stakeholders hold varying degrees of influence and
authority over the approval of work products, and are also an important
source of needs, constraints, and assumptions.
– Managing stakeholder collaboration is an ongoing activity. New stakeholders
may be identified at any point during an initiative.
– The more significant the impact of the change or its visibility within the
organization, the more attention is directed to managing stakeholder
collaboration.
– Business analysts manage stakeholder collaboration to capitalize on positive
reactions, and mitigate or avoid negative reactions.
• Business analysts actively manage relationships with stakeholders who:
– provide services to the business analyst, including inputs to business analysis
tasks and other support activities,
– depend on services provided by the business analyst, including outputs of
business analysis tasks, and
– participate in the execution of business analysis tasks.

25. 25
Skills that BA must have in order to perform the task of
eliciting requirements?
• Interviewing
• Facilitating collaborative sessions
• Observation
• Resolving conflicts; eliminating root cause conflicts;
reaching consensus
• Thinking abstractly; Finding and leveraging patterns
• Writing business documentation
• Creating models or pictorial description while eliciting
• Inquisitiveness – asking more and more relevant
questions
• Listening and oral communication skills

26. Elicitation Techniques
• Interview
• Surveys
• Document analysis
• Interface analysis
• Prototyping
• Reverse engineering
• Observation
• Brainstorming
• Focus group
• Requirements workshop

27. Map of
Elicitation
Techniques

28. Elicitation Techniques – Comparison Matrix

29. Requirements Workshop
• Purpose: To capture requirements quickly in a structured
way.
• Workshops may be used to:
– Scope
– Discover
– Define
– Prioritize
– Reach Consensus and Review
• Description:
– Facilitated
– Short, intensive (1, 2 days)
– Not a meeting!
– Scribe documents requirements and issues
– Attended by carefully selected Stakeholders and SME’s

30. 30
Requirements Workshop Process
1. Preparations for a Requirements Workshop
– Clarify Stakeholder needs and workshop purpose
– Identify critical stakeholder participants
– Define agenda
– Determine documentation method
– Schedule the session (arrange room/equipment logistics)
– Prepare & send materials in advance
– Conduct pre-workshop interviews with attendees**
2. Conduct/run Workshop
– Elicit, analyze and document requirements
– Obtain consensus
– Maintain focus
3. Post workshop wrap-up (done by facilitator)
– Follow-up on open actions
– Complete workshop documentation and distribute to attendees and sponsor

31. 31
Requirements Workshop - Strengths & Weakness
Strengths
• Detailed requirements can be elicited quickly
• Stakeholders collaborate and gain mutual understanding of
requirements
• Less expensive than performing multiple interviews
• Feedback is immediate
Weaknesses
• Difficult to schedule
• Success depends upon facilitator expertise / participant knowledge
• Too many participants will slow down process
• Too few or not right mix of participants will jeopardize quality

32. 32
Focus Group
• Focus Groups – the 11th Technique listed in the
Business Analysis Body of Knowledge employs a
skilled facilitator(s) and a small group of
prospective or current customers to seek out and
understand what the customer or user wants
and/or how they use a product or service.
• Typically a focus group walks the users through a
set of open-ended questions about a product or
service. The participants give their feedback,
criticisms and opinions for the questions asked
and the moderator may record them.
• Focus Group is a means to elicit ideas and attitude
(frustration, dislikes, likes, challenges...etc) about
specific product, service or opportunity in an
interactive group environment.

33. 33
Focus Group
• Focus groups are often combined with several other business analysis
techniques such as brainstorming, user scenarios, nominal-group
technique and usability testing.
• Things to Know:
– Qualitative Research, not quantitative
– Typically group is in same room, can be done online
– Guided by a moderator
– Appropriate at any point in life-cycle
– Group can be homogenous or hetrogenous
– Intended Audience: Stakeholders, BA’s, Marketing
• Pros: Save time and money compared to interview; learn people’s
attitude, experience and desires; participants can consider their
personal view in relation to other perspectives
• Cons: Issues of trust; unwillingness to discuss sensitive topics; what
people say may not be consistent with how they actually behave;
homogenous group may not represent the complete set of
requirements; needs a skill moderator; schedule difficulties; not
effective in eliciting ideas for new or changing product.

34. The Interviewing Technique - What is it?
• Purpose: To elicit information from a person or group in an
informal or formal setting by talking to the person.
• The 2 basic types of interviews:
– Structured = pre-defined list of questions
– Unstructured = open-ended discussion about what the business expects
from the target system.
BA
Potential User
SME
Stakeholder
list of
questions
Formal Informal

35. Preparing for the Interview
1. Define the focus or goal of the
interview
2. Identify the interviewees:
– Find out which stakeholder has the
most authentic and current information
– Determine what stake a person has
– Determine how important the
information is that is held by a specific
person
3. Design the interview
– May need to custom design for specific
interviewee’s
– Determine the format (structured vs.
unstructured; Open or Closed)
– Organize questions into a logical
sequence
– Determine the location, Date and Time
– Determine the scribe, if one is needed
4. Contact the Interviewee
1. Explain the objective and why their
input is needed
Pros:
 Engages the Stakeholders
 Can be used in different situations
 Allows for full discussions and
explanations
 You can observe non-verbal behavior
 Allows follow-up questions
 Can set clear objectives and maintain
focus
Cons:
 Not ideal for reaching consensus
 Requires considerable commitment
from the participants
 Requires training of the BA for
performing good interviews
 Follow-up questions are dependent on
BA’s business knowledge
 Transcription can be complex and
expensive
 Is subject to interviewee’s
interpretation
35

36. Conduct & Follow Up on the Interview
1. Opening the interview:
 Give introduction; State purpose
2. During the interview:
– Stay focused on the interview goals
– Address all concerns (during
interview or as follow-up)
– Practice active listening
3. Close the interview:
– Ask if there were any areas
overlooked
– Summarize the session
– Thank the interviewee
4. Follow-up and Review
– Post Interview follow-up:
– Organize the information and send
notes to interviewee
– Interviewee reviews for
completeness
Factors for successful interviewing
include:
• BA’s level of understanding of the
business domain
• BA’s experience at conducting
interviews
• BA’s documentation skills
(documenting discussions)
• Readiness of the interviewee to
provide relevant information
• How well the interviewee
understands the business wants
and needs
• Rapport between the BA and the
interviewee
36
You may have few iterations of an interview with a stakeholder before the
elicitation of a requirement becomes complete

37. Surveys
Purpose: A survey is a questionnaire-based elicitation technique that allows you to
gather information from many people (anonymously) about customers, products,
work practices and a range of issues, attitudes, and stakeholders in a short period
of time.
Survey categories:
Closed : Respondent selects from predetermined choices (easier to analyze,
limited responses)
Open : Respondent is free to answer as they wish (wider range of responses,
difficult to quantify)
Pre-work:
– Definition of Purpose and Target
– Determination of Survey Type
– Determination of Target Sampling
– Determination of Survey Specification
– Designing and Testing the Survey

38. Survey/Questionnaire - Process
1. Survey preparation
– Define purpose and target group
– Choose survey type
– Select Sample group
– Select distribution and collection
methods
– Project desired level of response
– Determine if interviews needed
– Write survey questions
• Communicate purpose
• Short, comprehensive, Fast to
complete
• Clear and Concise (avoid
negatives, branching)
– Test the survey
• Target Sample
• Peer Review
2. Distribute / administer / collect
survey
– Determine functionality that
needs to be reverse-engineered
– Evaluate cost benefit (look at
potential benefits)
3. Evaluation and communication
of survey results
– Collate responses
– Analyze and summarize the
results
– Report findings to the sponsor
– Review, discuss, reach
consensus on what has been
uncovered.
(may utilize various techniques to
administer including,
workshop, focus group,
website, email, individually)
38

39. 39
Survey / Questionnaire – Strengths & Weakness
Strengths
• Closed surveys provide quantitative data for statistical analysis
• Open surveys offer insights and opinions not easily obtainable
• Not time consuming for responders
• Effective and efficient for dispersed Stakeholders
• May get a large number of responses
• Quick and relatively inexpensive to administer
• Can offer responders anonymity
Weaknesses
• Open questions require more analysis by the BA
• Statistical sampling methods are required
• Some questions may be unanswered or answered incorrectly
• May require further iterations
• Not suited to get information on actual behaviors
• May be difficult to get participation
• Requires a lot of prep and knowledge ahead of time

40. Prototyping
• Prototyping is a simplified representation of a process, system, or system
component that clarifies and visualizes interface requirements before an
application is designed or developed
• Classification of Prototypes
– Purpose
• Evolutionary
• Throwaway
– Scope
• Horizontal
• Vertical
• Phases of prototyping
– Preparation Phase
– Designing Phase
– Evaluation Phase
Can I change the colors?
Can I change the selections?
Can we highlight the ones I want?
Can I get another variation?

41. Prototyping..Contd
• Multiple iterations of requirements gathering and analysis, design
and prototype development.
• After each iteration, the result is analyzed by the customer.
• Their response creates the next level of requirements and defines
the next iteration.
Strengths
• Customers can see steady progress.
• Customer is reluctant to commit on requirements
Weaknesses
• No check on Time.
• No check on Iteration steps.

42. 42
Document Analysis
• Document Analysis is a means to elicit requirements of an existing
system by studying available documentation and identifying relevant
information
• Used:
– 1) if Objective is to gather detail of AS-IS or
– 2) if SME’s for existing systems not available
• Pros: have a starting point; leverage existing materials to discover and/or
confirm requirements; a means to cross-check requirements from other
elicitation techniques
• Cons: limited to the “as-is” perspective; existing documents may not be
up to date; can be time consuming and tedious

43. 43
Document Analysis – The Process
• Prepare
• Evaluate which system and business documentation are relevant and
appropriate
• Analyze
• Study the Materials
• Identify relevant business details
• Document details as well as questions
• Wrap-Up
• Review and confirm details with SME’s
• Obtain answers to follow-up questions

44. 44
Interface Analysis - What is it?
• Purpose: To reach agreement with the Stakeholders on what
interfaces are needed (BABOK says initiated by “PM’s and Analysts”).
– What is an interface? A connection between 2 components.
• Examples of the 3 types of interfaces (below):
Target
System
Hardware Device
HR
System
USER
INTERFACE
EXTERNAL
SYSTEMS
EXTERNAL
DEVICES
Benefits Support
Desk
Types of Interfaces
•User Interfaces
•Software Interfaces
•Hardware Interfaces

45. 45
Interface Analysis - Description
• To identify interfaces between solutions and/or solution
components and define requirements that describe how they
will interact
– It distinguishes which system or solution component provides specific
functionality along with the input and output data needs.
• It forms a basis for interoperability between the components:
– By separating the requirements for each system or solution
component, and
– Jointly defining the shared interface requirements
– Building a Glossary and Data Dictionary is critical
• Intended Audience:
– BA’s and Interface Designers:
• For working on detailed system or component interfaces
– Designers and Data Modelers:
• For designing system-to-system requirements

46. Interface Analysis..Contd
Process:
• Preparation Pre-work
– Identify and classify within a
domain
– Use Tool like context Diagram
– Understand the Business
Glossary
– Identify any Shared
Requirements if available
• Conduct Interface Analysis
– Determine the interface type
– Elicit the specific details,
depending on the type
Advantages
• Early identification of interfaces
provides an early, high-level view of
interoperability for planning:
• Impact on delivery date.
• Collaboration with other systems or
projects.
• Specification of the interfaces should
prevent difficulties in integrating
multiple components.
Disadvantages
• Does not provide insight into other
aspects of the solution since the
analysis does not assess the internal
components.
• Only focuses on inputs, outputs, and
key data elements
• It requires good technical expertise

47. Observation Technique
• Types of observation
– Passive observation
– Active observation
• Preparation for observation
– User sampling
– Establishing trust
– Preparing questions
• Points to be considered
– Reassure workers that their work is not in question
– Explaining the purpose and process of the observation
– Use of video and other recording equipment
– Physical setting
– Organizational setting
– Workflow setting
• Finally, Get answers, Have feedback summary reviewed and
Debriefed

48. 48
Brainstorming
• Brainstorming is a way of eliciting many creative ideas for an area of
interest (BABOK)
• Brainstorming is a creativity technique of generating ideas to solve a
problem. The main result of a brainstorming session may be a complete
solution to the problem, a list of ideas for an approach to a subsequent
solution, or a list of ideas resulting in a plan to find a solution (wikipedia)
– Brainstorming is defined as: Using one’s brain to storm a problem.
• When is Brainstorming used?
– Focus on a topic or problem
– Best applied in a group
– When diversion thinking is needed
• Pros: elicit many ideas in short time and non-judgmental environment
that enables thinking outside the box
• Cons: Dependent on participants’ creativity

49. 49
Brainstorming – The Process
• Prepare
• Define Topic
• Determine Time Limit
• Decide Participants (ideally 6-8) – range of background
• Establish Criteria
• Conduct Session
• Share ideas – no criticism, discussion, evaluation
• Visibly record ideas
• Encourage Creativity, Building on other’s ideas
• Don’t limit number of ideas
• Wrap-Up Session:
• Evaluate at the end
• Create list of ideas – eliminate duplicates
• Rate ideas (prioritize by multivoting)
• Distribute the final list

50. Reverse Engineering
• Purpose: To extract implemented
requirements from software code.
Used where the existing system has
little or outdated documentation.
• Definition: A Process of analyzing a
subject system/product to identify
underlying business processes, data
and rules.
• General Categories:
– Black Box: Study system/product
without examining internal
structure
– White Box: Inner workings of the
system/product are studied
• Results: Understanding and DETAILS!
Strengths
– Protects investment in existing
system/product
– Provides detailed, updated
information; allows update to
documentation
Weaknesses
– Expensive and time-consuming
– May be restricted by copyright laws
(should research)
– Requires specialized skill and tools
50