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

2. 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)

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

4. 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.

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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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).

13. 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)?

14. 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?

15. 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

16. 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

17. Clerk uses system for ….

18. Electrician uses system to ….

19. Suppliers use the system to ….

20. 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:

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