Requirements Defined
What are requirements? In the web and custom application business – as in most technology-related businesses – requirements are a document (or set of documents) that describe what needs to be developed and how it should work.
Is it a tool to automate certain business processes? Is it an application that tracks large amounts of data and produces detailed reports? Is it a platform for online training? Or is it a combination of many different things?
In order to get what you want out of your project, you need to define it accurately, and the requirements analysis process helps to do just that. The final requirements document should have enough detail to clearly articulate the business or functional challenges that the website or application must solve. It should be understandable for you (the customer or user), but have enough detail to enable a software developer to build what’s expected.
Poor requirements analysis, or the complete lack of requirements definition, is one of the leading causes of project failure according to the Project Management Institute. (1)
The requirements process starts with the client articulating a high level vision of their business or functional needs, then continues by working backwards (usually with the help of a project manager and business analyst) to compile a detailed list of all the functional areas, user interfaces, data inputs and outputs, and business logic.
Wikipedia states: “The requirements should be documented, actionable, measurable, testable, traceable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.”
It makes perfect sense: if you don’t know what you’re building or what it’s supposed to do, how can you measure success? Furthermore, how do you know when you’re done? Any project that starts without a well documented and shared vision of the end product is pretty much doomed to fail.
The Requirements Process
Generally, the process to document requirements starts with communication between the project team and the customer. What is the business need? What is the purpose of the project? These conversations will determine what level of requirements will be needed.
Sometimes, your project team may ask to have an initial review of requirements done before they will quote on a project. Why? This step – whether it comes before an estimate, after, or both – helps build a common understanding of scope among all parties. For very large projects, an initial look at the requirements is absolutely required to determine how much time and effort will be needed to complete the project. If requirements can be looked at before any work starts, you will get a much more accurate estimate based on a known scope.
For straightforward projects, the proposal containing a high-level list of features may be adequate. However, for large or complicated projects, a requirements analysis phase will most likely be needed and will be factored into the project budget.
Once the high-level business needs identified in the initial conversations between the project team and the customer are defined, the process moves on to the finer details: what are the types of users that are needed and how they will access the system; what information is collected and produced; what reports should be generated; how are payments are processed. Although this may seem laborious, the process of asking questions about what the site or application needs to do helps you and your project team clearly articulate an ideal version of the end product and allows everyone to determine if expectations are met. The critical process allows all team members to contribute their perspectives about how to achieve the goals of the project.
The answers to all of these questions are put in a detailed requirements document that is reviewed by the necessary people on both the customer and project teams. All stakeholders make changes and suggestions before a final draft of the requirements document is reached. Only after the requirements are clearly documented and agreed upon will development begin. The more detailed, clear and unambiguous the requirements are, the better the final product!
Save Time & Money!
It may seem counter-intuitive, but taking the time to perform a thorough requirements analysis with a detailed requirements document as the final result can actually save you money and time in the long run. While documenting requirements can be a time-consuming process – especially in a large project – having a clearly articulated requirements document helps to avoid having the software developer build functionality that is not required and also can help to avoid unnecessary changes later in development. As the graph below shows, changes take more time to make (and cost more!) the farther a project gets in the development process.
Detailed requirements can also help you break your project up into phases, allowing your project team to see which pieces of a project are dependent on each other or which ones can be tackled independently. This can help accommodate budget constraints or time concerns, as you can decide up front which parts are most critical to tackle right away and determine the ones that can wait until a later date.
Avoid Misunderstandings!
Clearly defining the requirements of your project can really help in avoiding misunderstandings between you and your project team. As with all software development projects, it is inevitable that changes will come up as the development progresses, but the requirements document provides you and your team with a concrete reference, allowing everyone to assess whether the needed changes were part of the project scope in the first place, or whether a change/addition will be required.