- What's Covered in This Chapter
- Design Approach and Artifact Choices
- Free-Form Architecture Diagram
- From User Stories to Design
- Exploring Classes Using CRC Cards
- Application Flow Map (Homegrown Artifact)
- UML Class Diagram
- UML Package Diagram
- Directory Structure
- Sample File Names
- End-to-End Development Steps
- Acceptance Tests
- Other Considerations
- Summary
- Recommended Resources
Acceptance Tests
Acceptance tests can serve as our detailed requirements as they do in many Agile style projects. One example is a list of valid operations a user can perform on a given screen. The idea of using acceptance tests as requirements is feasible because these tests are something our customer expects our application to conform to. For our purposes, we will use them only for our unit tests; however, it is becoming more and more common in the real world to use acceptance tests as detailed requirements.
The following sections are our list of acceptance tests and something we will implement for the user stories we will develop. In the real world, these types of acceptance tests would be provided by the customer.
Sign In
- The employee id can be up to 6 characters. The password must be between 8 and 10 characters.
- Only valid users can sign in.
Timesheet List
- Only a user's personal timesheets can be accessed.
Enter Hours
- Hours must contain numeric data.
- Daily hours cannot exceed 16 hours. Weekly hours cannot exceed 96 hours.
- Hours must be billed to a department.
- Hours can be entered as two decimal places.
- Employees can view and edit only their own timesheets.