Unit 3

 (Net Time: 115 min)

Section 1 Gather Information

5 activities:

Gather detailed information

Define requirements

Prioritize requirements

Develop user-interface dialogs

Evaluate requirements with users

6 techniques

                Interviewing users and other stakeholders

Distributing and collecting questionnaires

Reviewing inputs, outputs, and documentation

Observing and documenting business procedures

Researching vendor solutions

Collecting active user comments and suggestions

stakeholders: internal/external, operational/executive, technical/support, client

Checklist for interview (p51, F2-9)

vendor research: new ideas, already state of art, cheaper/less risky to buy

open-items list: could not answer, not considered yet

                Functional requirements: must perform

model types: textual, graphical, mathematical

Activity diagram: describes user (or system) activities, the person who does each activity, and the sequential flow of these activities (P58, F2-14)

Section 2 Define Requirements

Use case: an activity that the system performs, usually in response to a request by a user

User goal technique: a technique to identify use cases by determining what specific goals or objectives must be completed by a user. (output)

                identify users->classify users by function and organizational->interview for goals of verb-noun->

create use cases->reconcile use cases->identify common use cases->review

                The overarching objective is to identify how a system can improve the user’s perfor- mance and productivity.

Event decomposition technique: a technique to identify use cases by determining the external business events to which the system must respond. (all inputs so comprehensive, one event for one use case so right level)

                external events: link to use cases

                temporal/state events: link to use cases + trigger

                exclude system controls  “perfect technology assumption”

elementary business processes (EBPs):  the most fundamental tasks in a business process, which leaves the system and data in a quiescent state; usually performed by one person in response to a business event

event    something that occurs at a specific time and place, can be precisely identified, and must be remembered by the system

system control: checks or safety procedures to protect the integrity of the system and the data (login, backup, change password)

CRUD(read/report): cross check, summarize and show connection

brief use case description: an often one-sentence description that provides a quick overview of a use case

UML use case diagrams: graphically show the use cases and their relationship to users

                actor/user (stick figure) - many to many- use cases

                user’s view point = one use case diagram per user, per sub system

                <<include>>: a relationship between use cases in which one use case is stereotypically included within the other use case