Requirements Very High level specification of what system should do Eliciting and Prioritizing these requirements

Mostly done during Inception and Elaboration By System Manager and System Analyst Conflict resolution Identify stakeholders/actors Identify use cases Identify constraints Functional Requirements Non-functional Requirements Prioritize requirements What the system should do (not how)

SRS – System Requirements Specification Well formed requirement – ‘shall’ Requirements elicitation – “map is not the territory” Primary method is by use-case modeling

Vision E_build will be a system/software package that manages and facilitates resources – such as material, personnel, equipment, and vendors – and is portable and accessible for field use. It will provide a user friendly interface for office as well as field personnel.

banner.htm The prototype UI will be extended appropriately for difference services

Find system boundary – what is external to the system (drawn as a box) Find actors (outside of the box) – interact directly with the system May have multiple roles Actor (external) is different from ActorDetail (internal representation) Find use-case (inside the box) Users, installers, maintainers, other interacting systems Create Scenarios

Actors Customer Vendor Maintenance Marketing Department Workers Manager Inventory Database Others?

Req. ID Description Severity 1. The system shall allow customers to view project progress Must 2. The system shall track inventory and trigger orders when supplies fall short Desired 3. The system shall maintain customer database 4. The system shall provide online communication for construction crew

Use case started by actor Written from the actors perspective What functions does the actor want from the system Which of the store/retrieve functions are triggered by the actor Are actors to be notified of system state change? External events that are notified to the system Glossary

Detail the use cases Actors involved Pre-Condition for trigger When triggered Sequence/set of events completed Post-condition, verification and documentation Branching during use-case (if) Repetitive actions

Cross-reference requirements against use cases Alternate paths in a use-case are called scenarios Primary scenario does “what expected” Unintended or exceptions that cause other scenarios – are secondary scenarios Specify the scenarios that help understand the system’s desired behavior Non-functional requirements not captured by use-cases

Basic Steps in Use case development Step 1: Confirm actors and goals. Have all actors and their goals been identified? Which actors can be generalized (combined)? Which goals are potential use cases? Step 2: Develop an outline of the use case(s). For the goals identified as potential use cases, what are the key pieces? For each outline level, what are key data? Outline all use cases. Prioritize the use-case flows. Decide on a final use-case list (for initial pass).

Step 3: Write a brief description of the use case(s) Step 3: Write a brief description of the use case(s). What two or three sentences describe all actors and the basic flow? Generate content first, and worry about word-smithing later. Step 4: Detail the basic flow. What event starts the use case? How does the use case end? How does the use case repeat some behavior? What is the "happy" (best case) path? Are there is one and only one basic flow? Step 5: Detail the alternate flows. Are there optional situations for the use case? What might go wrong? What might not happen? Which resources might be blocked? Which alternate flows are special — perhaps nonfunctional — requirements (i.e., they apply to this use case only)?

Step 6: Review the use case(s). Are there more use cases Step 6: Review the use case(s). Are there more use cases? Should some use cases be redefined? Which ones can be combined? Step 7: Record pre- and post-conditions. What was the previous state before this use case comes into play? What happens once the use case is complete? Step 8: Develop generalizations for all use cases. Determine shared content and process for the use cases. What items have been noted for the glossary or as global business rules? Who has the most recent and accurate source document? Where is it located?

Use Case Customer uses the system to order copies of blue-prints Vendor uses the system to provide their current sales event information Manager uses the system to schedule construction workers Sys. Admin uses the system to upgrade software Clerk and Accountants uses the system to create invoice and audit accounts

Manager uses the system to schedule upcoming meetings Manager uses the system to schedule/hire employees Manager uses the system to record data Manager uses system to place special bid rates Manager uses system to trigger audit trail Manager uses system to place orders

Clerk uses system for ….

Electrician uses system to ….

Suppliers use the system to ….

Use Case: UpdateWorkStatus Actor: Supervisor, Manager Precondition: WorkOrderIssued Flow of events: Select UpdateWorkStatus button from Maids frame Select WorkOrderNumber (from list of rooms to be cleaned) Select appropriate choice of status update (scheduled, started, in progress, pending, completed, …) Submit Type in time and actor id in the next screen Close Postcondition: UpdatedWorkOrder Alternative Flow:

Uc/req Uc1 Uc2 Uc3 Uc4 .. Req1 X Req2 Req3 Req4 Req5 …