Software Requirements

Specification
Lecture 07
Lecture Outline

• Elicitation techniques
1. Workshops
2. Focus groups
3. System interface analysis
4. User interface analysis
5. Document analysis
1. Workshops
• A requirements workshop is a structured, facilitated event in which
a carefully selected group of stakeholders work together to discover:
• create,
• verify
• document predefined requirements,
• deliverables
• work products
1. Workshops

• a collaborative Requirements elicitation technique.

• Gathers all key stakeholders together for a short
• but intensely focused period.

• facilitator experienced in requirements

management can ensure the success of the workshop.
Workshop Participants

• Participants include:
• Scribe
• Content participants
• Facilitator
• Planning team technical member and facilitator
Preparation for workshop

• Selling the concept

• Ensuring the participation of stakeholders

• Attending the logistics

• Preparation of warmup materials

Warm up materials
• Project-specific information
• This might include drafts of requirements documents, bulleted lists of suggested features, copies of
interviews with prospective users,
• analyst's reports on trends in the industry,
• letters from customers,
• bug reports from the existing system,
• new management directives,
• new marketing data, and so on.
• Although it's important not to bury the prospective attendees in data,
• it's also important to make sure they have the right data.
Warm up materials contd..
Out-of-box thinking preparation

• Part of "getting their minds right" is encouraging attendees to think "

• out of the box." "Forget for a minute what you know and what can‘t be done due to politics.

• Forget that we tried to get management buy- in last time and failed.

• Forget that we haven't yet solidified our development process.

• Simply bring your insights on the features of this new project, and be prepared to think 'out
of the box.'"
What happens in Requirements Workshop

• Team members
• Create
• Review
• prioritize
• Complete
• Important deliverables
Tips for conducting effective workshop

• Establish and enforce ground rules

• Starting and ending time.
• Returning from breaks promptly.
• Silencing electronic devices.
• Holding one conversation at a time.
Tips for conducting effective workshop
contd..
• Expecting everyone to contribute
• Focusing comments and criticism on issues rather than
individual.
• Ensure participants follow them
Tips for conducting effective workshop
contd..
• Fill all of the team roles
• People must make sure the following tasks
• Note taking
• Time keeping
• Scope management
Tips for conducting effective workshop
contd..
• Ground rule management
• Scribe is recording every thing
• Flagging energy after lunch
• Light lunches, afternoon breaks, rearrange seat.
Tips for conducting effective workshop
contd..
• Plan an agenda
Tips for conducting effective workshop
contd..
• Stay in scope
• Role of facilitator to reel in the elicitation participants.
Tips for conducting effective workshop
contd..
• Use parking lots to capture items for later
consideration
• Quality attributes
Tips for conducting effective workshop
contd..
Time box discussion

fixed time for each discussion

Tips for conducting effective workshop
contd..
• Keep everyone engaged
• Facilitator must read the body language
• Understand why someone is not participating
• Try to engage the person
• Ask silent individuals
 Running the Workshop
 Allow for human behavior, and have fun with it.

 Do not “attack” other members.

 Do not get on a soap box.
 Do not come back late from a break.

 Workshop tickets

 Give every stakeholder 3 workshop tickets

 1 for being late

 1 for “cheap shot”
 1 for “soap box” [5 min position statement]
2. Focus group

• Group of users who focus in a facilitated session to

generate idea and input on project.
• Useful for exploring
• Users attitudes
• Impressions
• Preferences and needs
2. Focus Group contd..

• Used for developing commercial products and have no

access to end users.
• Large number of users
• Pool of users is selected to represent the full
spectrum.
2. Focus Group contd..

• Needs facilitator, scribe

• Less quantitative analysis

• Subjective feedback

• Participants have no decision making authority

3. System interface analysis

• Examining the systems to which your system connects

• Functional requirements regarding exchange of data

and services between systems.

• Context diagrams and ecosystem maps

3. System interface analysis contd..

• Requirements include
• What data to pass to other system
• What data is received
• Rules about data
• Validation criteria
3. System interface analysis contd..

• Existing functionality that do not need to implement.

• Example
• Validation rules for Shopping cart as order is passed to
order management system.
4. User interface analysis

• Study existing systems to discover user and fucntional

requirements.
• To interact with the existing system directly.
• Screen shots of existing system
• User manuals
• Draft use cases
4. User interface analysis contd..

• If system does not exist then

• Look at user interfaces of similar products.
Tips to avoid problems in user interface
analysis
• Do not assume
• If a functionality is found in existing system, then it must
be included in new system.
• Flow of the system will remain the same in the new
system.
5. Document analysis

• Examining existing documents for potential software.

• Requirements specifications
• Business processes
• Lessons learned collections
• User manuals
Why document analysis

• Can describe industry standards that must be followed

• Replace existing , past documentation can reveal
functionality that might be retained.
• For Packaged solutions, the vendor documentation
mentions functionality that users might need.
Why document analysis contd..

• To speed up on an existing system or a new domain.

• Document analysis serves as a research / guideline

and reduces the elicitation meeting time needed.
Why document analysis contd..

• Risks
• Available documents might not be updated.
• Requirements might have changed without specification being
updated.
• Documented functionality might not be included in a new
system.
Summary