User requirements
The initial activity of the process model is to analyze the user requirements. It is obvious that in any software project, the first and foremost activity is to have an understanding of what the users require.
There are various tools and techniques to analyze user requirements. However, it is important to note that, while it is important to understand the user requirement in full, the idea here is not to write loads of documents, especially when it comes to PHP projects. What is more important is to make sure that we model what the users require and, based on the models, get the users to provide feedback, and then improve the model based on the user feedback. Some simple techniques that can be used to capture requirements include:
- Studying the existing system
- Observation of the users in action in a real environment
- Interviews with potential users and stakeholders of the system
Some tools that can be used to capture requirements include:
- Data flow diagrams showing how data flows and processing happens in the system
- Use case diagrams that portray how potential users of the system would be using the system. When using use case diagrams, it is critical to capture all of the major use cases of the system at a high level. It does not need to be too detailed, but we need to ensure that we have not missed any key use case scenario in the implementation. We can always seek the help of the users to help us validate the use cases and fill in the gaps, in case we have missed any key user requirements.
When documenting user requirements, we need to be comprehensive, concise, and clear. This is because the team members need to be able to refer to those, whenever they want. If the requirement specifications are too bulky and take time to read, it might not help the team. Therefore, it is always a good idea to use diagrams and tables to summarize information, whenever possible, to make sure that the captured information can be grasped by the team members at a glance.
We need to make sure that the team members really refer to the requirements to during the project life cycle. Therefore, anything that encourages them to use those requirement specifications is welcome and would make the project’s success more probable.
Modeling what the users want
The purpose of the requirements gathering activity is to help us understand what the users want. The next step is to come up with a model that bridges the gap between the real world and the software world. For example, we need to be able to map the user requirements to the data model, and the business logic model, that we can implement with the software technology that we know.
Data modeling
Data modeling activities are supposed to produce the data model that represents the data involved with the system under consideration. Entity relationship diagrams are the most well known tool to help model data in a system.
Note that modeling data is the first activity following the user requirement gathering. This depicts the importance of the data modeling activity with respect to the design and implementation of the rest of the system. Most of the systems are all about effective data storage processing and presenting.
The outcome of the data modeling activity is a set of diagrams that represent the entities within the system and their relationship to each other:
It is important to note that a data model is not the same as a database design. The model is the reference that can be used as the input to the database design activity, and the data model is also the input for the business modeling activity of the process. Data design will be explained later in this article.
Business modeling
Once we understand the data involved with the system, the next step is to understand the business activities carried out with those data. Business logic modeling can be done with tools such as data flow diagrams or use case diagrams. The objective is to understand what sort of business activities the users carry out with the software system being developed. The inputs and outputs of the business logic processing and the various data stores, where the data is pulled from, are modeled in this phase of the process. Like in the case of data modeling, we can validate the business model with the user and incorporate user feedback back into the model. It is also noteworthy that the business modeling activity is different from the business logic design activity. Business logic design is based on the business model that we develop in this phase of the process.
The output of the business modeling activity is the business model. Simply speaking, it is a set of diagrams that represent the use cases or the data flow. Like in the case of data model, the business model should also be simple to refer back, if team members require to do so.
Once we have both the data model and the business model, we can move on to the user activity analysis.
User activity analysis
While executing business functions with the software application, users engage in various activities using the system. Analyzing those activities becomes the next important activity in the process, and it also opens up the doors to understanding and designing the user interface.
Based on the business model and the data model, we can analyze the various activities that the users would want to carry out with the system. We can make use of the data processing functions of data flow diagrams, or use case diagrams, and come up with a list of user activities for each business use case of the system.
The list of user activities becomes the input for the storyboard design activity.
Before looking into the details of the presentation layer design, let us step back for a moment and look into data layer design.
Designs and implementing the data layer
The process model proposed in this article is intended to be used for PHP projects, and therefore, is based on the MVC pattern. The data layer represents the model in MVC. In the design of the PHP application, we need to first attend the data layer.
Using the data model as the input, we can perform data design. The data design can be independent from a specific database management system. However, the information, such as data types, needs to be taken into account. The number of tables, their relationships, the volume of data involved, and related performance implications need to be taken into account.
The next activity is the implementation, keeping open the option of switching the database management systems or supporting multiple database management systems open. In this activity, we might either use the database management systems directly or use SQL and try to be database agnostic. In addition to creating the database, the team members involved with the data layer implementation also devise plans for testing and also for carrying out unit testing.
In addition to SQL based unit testing, they need to implement the database access logic, which is also a part of the database layer, using PHP. The team members can then implement unit tests with PHP to verify the implementation. Executing the unit tests can be automated using PHP frameworks, upon each source code change.
Once the implementation is complete, it can be tested and verified completely using system testing by a quality assurance team.
Database implementation is a prerequisite for business logic implementation. However, business logic design need not wait until the database implementation is complete. As soon as data model is available, business modeling can be done and followed by business logic design. It is the business logic implementation that requires database implementation. The business layer sub-team can start its design work in parallel with the data layer sub-team and work side by side on their designs.
