EXPERT RESPONSE
My first question is whether consideration has been given to deploying a commercial payroll application or contracting with a hosted payroll application provider? Payroll can be pretty complicated when you consider workers in different states and counties, varying tax rates, and of course ever-changing state and federal laws.
Assuming the decision has been made that it is better to build from scratch than purchase a commercial application, I would start by understanding the scale the system will need to support. Is this for 20 employees or 2000 employees? Are there requirements such as the application being available on the company intranet, meaning it must be Web-based? Security must also be considered when dealing with payroll information. We have all read news articles about companies losing employee information, phone numbers, addresses and even social security numbers. You don't want to be that company on the daily news. Privacy is important with payroll topics, typically only specific individuals are allowed to see the information. You will need to gather these nonfunctional requirements so that you start with an architecture that will be secure and meet your deployment needs.
To gather the functional requirements you are going to need to identify the individuals who will be using the system. Most likely there are individuals in the Human Resources organization that will need to enter payroll information, submit new employees, and so forth. You may also want to extend the system to employees to view vacation balances or to submit vacation requests. First determine who will be using the system and then start asking some questions and capturing the requirements you hear. A tool such as Caliber DefineIT would help you quickly capture the desired scenarios and then validate those scenarios with your users. (Disclaimer: I work for Borland Software, but strongly believe that a tool such as DefineIT is a great way to get started gathering these types of requirements.)
Rather than focusing on having a software requirements document as the final output, I would focus on gathering and validating the functional requirements with the end users. Don't expect that you will figure out every bit of detail right away, but you should be able to gather a good picture of what the users want, then refine the model, filling in the details and probably raising some questions. The beauty of using a diagram or storyboard to validate the requirements with the user is that it provides an interactive way to walk through the requirements, instead of just sending a document and asking for feedback.
|
|
 |
Once you have refined the scenarios to a sufficient level of detail, you may still wish to produce a software requirements specification (SRS) by combining the diagrams with the other nonfunctional requirements you have discovered along the way, or you may discover that a Word document and a few scenario diagrams is all that is needed to get started on the project, and that you will refine the requirements and discover new ones with each sprint.
|
