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

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.

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

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.

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.

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

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.

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.

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.

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.

Use-Case Diagram

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)

Class Diagram

State Diagram

Activity Diagram for RE