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`RequirementsCitation
#aMust be capable of providing metrics on enquiry source location
#bMust be capable of providing metrics on enquiry times
#cMust be able to of coping with high traffic
#dShould be able to croudsource responses to the existing community of volunteers
#eShould allow new volunteers to help with responses
#fMust allow for information to be added to system
#gMust allow for information to removed from system
#hMust allow for information to be updated on system
#iMust 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).