Affero Requirements Analysis + Changelog
Requirements analysis
Requirements specification for any solution
The following table lists all the requirements of the proposed system, as well as a reference code for use in the test plan. Citation of where these requirements came from is also listed in this table. Finally there is an assumed time constraint all the following requirements to have been met by no later than the 1st of May, 2011.
| Ref` | Requirements | Citation |
|---|---|---|
| #a | Must be capable of providing metrics on enquiry source location | |
| #b | Must be capable of providing metrics on enquiry times | |
| #c | Must be able to of coping with high traffic | |
| #d | Should be able to croudsource responses to the existing community of volunteers | |
| #e | Should allow new volunteers to help with responses | |
| #f | Must allow for information to be added to system | |
| #g | Must allow for information to removed from system | |
| #h | Must allow for information to be updated on system | |
| #i | Must be accessible for people all over the planet |
Data Flow Diagrams of proposed system
DFD Level 0
The DFD, or data flow diagram is a useful guide on showing the kind of data that the proposed system will come into contact with. It shows this at the highest possible level without loosing meaning in a Level 0 (the above). When moving on to more detailed DFD�s (Level 1 and 2) we can see how the complexities of the system can be modeled in an easy to understand way, piece by piece.
DFD Level 1
The above shows how the data in the proposed system will flow at a greater detail to that of the level 0 DFD. The large box in the middle which surrounds the processes represents the proposed system as a whole (the Community Contribution Wizard process from the level 0 DFD).
Entity Relationship Diagram for proposed system
Within the proposed system there are a lot of relationships between a number of entities however if we abstract all these complexities away we can see that overall, the system is designed to model and allow the flow of information between the following four entities
- areas of contribution
- visitors to the system front end
- modifications to the system from contributors
- and the reading and creating of metrics
Each of these four entities is related via a many-to-many relationship with all the others. This shows that all areas of the system are well connected allowing for easy use.
This was quite useful for me today. I rewrote this section just for you guys and it turns out that it helped my project documentation too! Thanks 😃
ChangeLog
Okay so today has been slow going, the day did not start in the most productive of manners, however some things have been cleared up so here we go:
- Decided on application structure
- Wrote the core script for Affero
- Fixed some testcases and code
- Created the basis for the user login system
- Fought gluephp till I realised I had made a typo and that was the root of my problems
- Wrote the core again as it failed to work the first time due to the script attempting to redeclare classes (I think I just lost the plot a bit)
In other big Affero news, I can now get even more feedback from you… if you have a few minutes to spare have a quick read through the code/documentation, if you find any bugs then submit them as issues over at github but please DO NOT submit patches. This will come in time, but I must hand the project documentation with code (c&p code not the ownership) to the exam board before I can open this up fully.
Finally don’t forget that I have a small survey for you on this two post a day rule. (See today’s other post).