Requirements can fall into two different categories: business and functional. A business requirement asks, "What business need does this project fulfill?" Dor example, a project to develop a corporate tax system—one that allows accountants to prepare corporate tax returns in-house instead of outsourcing the work—would fulfill a business need and hence be a business requirement. On the other hand, a functional requirement asks, "How will this system behave when it is fulfilling the end user' s request for activity?" In other words, when the user clicks the Report button, what happens in the background?
A requirements document will contain both business and functional requirements. Keep in mind that we ' re looking for ways to apply some metric to any requirement that we write, so that you can validate at project completion time that the project is indeed finished and how successful it was. Subjective requirements formulation results in vague or abstract decisions about the closure or success of the project.
Business requirements usually involve processes and procedures ("end user will click Reports y Tax Report to generate an end-of-year tax report"). Functional requirements address things like security issues, ease of use, speed requirements, availability (24/7?), and security ("end user must enter a username and password to access the Tax portion of the new system").
You will take the requirements that you' ve synthesized from interaction with the customer and break them further down into one of these two types. Future changes to the requirements must go through the established change- management process.
Was this article helpful?