1. Requirements Elicitation Techniques
Collaborative Requirements gathering.
Quality Function Deployment.
User Scenarios
Elicitation Work Products

2. When does collaboration occur?
When people choose to collaborate.
A belief that there is more to be gained by collaborating than by competing.
People choose to collaborate when they see their personal and organization interests are acknowledged, valued and taken into account.

3. Why collaboration is so difficult?
Collaboration is about “not competing”.
We spend more time learning (and being rewarded) to compete, than collaborating.
“You must have missed school the day you were taught sharing in Kindergarten” - Diane Fisher, 2002

4. Collaborative Requirements Gathering
Meetings are conducted and attended by all interested stakeholders.
Rules for preparation and participation are established.
An agenda is suggested.
A “facilitator” controls the meeting.
A “definition mechanism” (work sheets, wall stickers) is used.

5. Quality Function Deployment (QFD)
QFD defines requirements in a way that maximizes customer satisfaction.
Function deployment is used to determine the value of each function that is required for the system.
Information deployment identifies data objects and events that the system must consume and produce.
Task deployment examines the behavior of the system.
Value analysis determines the priority of requirements.

6. Quality Function Deployment (QFD)
QFD identifies three types of requirements
Normal requirements
Expected requirements
Exciting requirements

7. Normal requirements
These requirements reflect objectives and goals stated for a product or system during meetings with the customer.
Examples of normal requirements might be requested types of graphical displays, specific system functions, and defined level of performance.

8. Expected Requirements
These requirements are implicit to the product or system and may be so fundamental that the customer does not explicitly state them. Their absence will be a cause for significant dissatisfaction.
Examples of expected requirements are ease of human/machine interaction, overall operational correctness and reliability, and ease of software installation.

9. Exciting Requirements
These requirements reflect features that go beyond the customer’s expectations and prove to be very satisfying when present.
For example, word processing software is requested with standard features. The delivered product contains a number of page layout capabilities that are quite pleasing and unexpected.

10. Use-Cases
A use-case scenario is a story about how someone or something external to the software (known as an actor) interacts with the system.
Use-Cases, identify the who, what, and how of system behavior.
Use Cases describe the interactions between a user and a system, focusing on what the system “does” for the user.
The Use Case model describes the totality of the systems functional behavior.

11. Use-Case Diagram

12. Elements of the Analysis Model
Scenario-based elements
Use-case: How external actors interact with the system (use-case diagrams)
Functional: How software functions are processed in the system (flow charts; activity diagrams)
Class-based elements
The various system objects (obtained from scenarios) including their attributes and functions (class diagram)
Behavioral elements
How the system behaves in response to different events (state diagram)
Flow-oriented elements
How information is transformed as it flows through the system (data flow diagram)

13. Class Diagram

14. State Diagram

15. Activity Diagram for RE