I mentioned earlier that our fictional customer requires a simple online time entry and approval system. Let's go into a bit more detail here. It is always a good idea to define what business problem is being solved, whom it is being solved for, and why our solution is important to the customer. In addition, it is important to understand what the customer's expectations are: for example, when is the solution needed, and what is the project scope. Let's assume that a fictional organization wants to build a timesheet system to manage its hourly staff. To get things started, we can define the problem statement as follows. Problem Statement Our employees currently submit their weekly hours worked using a paper-based timesheet system that is manually intensive and error-prone. We require an automated solution for submitting employee hours worked, in the form of an electronic timesheet, approving them, and paying for the time worked. In addition, we would like to have automatic notifications of timesheet status changes and a weekly reminder to submit and approve employee timesheets. Given our general problem statement, we can break this down into the following feature set or business requirements; this process could be considered a part of use case analysis, in the Unified Modeling Language (UML) world:
Now that we have some basic business requirements, we can proceed with our software development process. |