Professional PHP Design Patterns

20.2. Initial Requirements Analysis

The boss at ACME Company presents me with the preceding requirements document. While it's a good starting point, I still have plenty of questions. The next step is to consider my approach.

There are two ways to approach a requirements document that you have questions about:

• Create a list of questions and send them back to the stakeholders. Then one of three things will happen. You may receive answers back, you may just receive an updated requirements document, or you may receive answers back with direction to update the requirements document yourself.

• Gather the questions together and send them off to the stakeholders with a stipulation: you plan to update the requirements document for their review based upon the answers to these questions. This second way is usually the way that I try to approach the analysis. This way, everyone is clearly informed of what the next steps in the process are.

I should really interject a reminder here: this book is about Design Patterns and not business practice. However, some of these steps are required steps to make good decisions when choosing the Design Patterns for the PHP application. Without getting the clarification that is needed, the architecture may suffer. It may take longer to make the right decisions. Or, even worse, it's possible to make too many assumptions and create a wholly inaccurate architecture. I want to make sure to get clear requirements in the first step of the case study in order to ...