Requirements Analysis for the prototype

Bennett et al (2002) states that before designing the software the developer needs to capture specific requirements that will need to be developed in the system. Requirements analysis requires the involvement of the problem owner. Maciaszek (2005) describes this as a very important step as it is required to eliminate contradiction and overlapping of requirements. One of the leading requirements gathering

techniques is interviewing as it is a straightforward method of collecting facts and information from the problem owner.

4.3.1 The Interview

The author organized an informal interview session with the problem owner to discuss the prototype system. This session was organized for a number of reasons. Firstly, the author wanted to discuss with the problem owner about what is to be included in the prototype. The problem owner discussed the importance of the system to include Web application development concepts such as those present in the three tier architecture. After a lengthy discussion the author and the problem owner agreed that the prototype system must have some sort of functionalities that demonstrate how Django deals with a number of concepts. If the prototype system does demonstrate these concepts, the problem owner can use the prototype to show and teach her students about how Django handles these concepts.

These concepts include;

● Interaction with the Data tier – demonstrate how Django can create, retrieve, update and delete data from a database.

● Presentation of content – demonstrate how Django can present the data in an attractive manner. ● Maintaining state – demonstrate how Django handles the act of maintaining state.

● Interactivity between the 3 tiers – demonstrate how data moves between each tier in the application architecture.

Now that these 4 requirements have been established and agreed upon with the problem owner the author needs to think about designing functionality features that would demonstrate these 4 concepts listed above. The functionalities that are developed in the prototype system will be evaluated by the problem owner in the evaluation stage to see if they demonstrate the concepts mentioned above.

As mentioned in Section 2.4.2, the methodology to be used when developing the system is the Evolutionary prototyping approach. An advantage of using this approach is that the author can receive feedback about the system on a frequent basis from the problem owner. This will be important as the author has to design functionalities for the prototype system which will allow a teacher to produce and manage some learning material. The functionalities (the learning material) of the prototype system developed must demonstrate at least one of the concepts; Interaction with the Data tier, presentation of content, Maintaining state and interactivity between the 3 tiers.

For this to be done further research had to be carried out about Django to see what kind of functionalities (for the learning material) can be developed. This was carried out by the author and a list of functionalities that can be developed using Django was created.

These functionalities include;

● Allow a class list of students to be managed (add, delete, edit and display student details) – this functionality helps demonstrate the interaction with data tier and maintaining state. ● Allow example course questions to be set for students to practice – this functionality helps

demonstrate the interaction with data tier and maintaining state.

● Allow lecture notes to be published on the system for students – this functionality helps demonstrate the interaction with data tier and maintaining state.

● Allow messages to be managed (add, delete, edit and display for students) - this functionality helps demonstrate the interaction with data tier and maintaining state.

● Allow a poll feature that would receive feedback from students – this functionality helps demonstrate interactivity between the 3 tiers.

● Create a blog feature that allows students to post their comments about certain topics – this functionality helps demonstrate interactivity between the 3 tiers.

All of the above functionalities will be displayed on the User Interface and therefore this will help demonstrate the presentation of content concept.

4.3.2 Summary

This list of functionalities was taken to the problem owner to get feedback on their suitable to be part of the learning material and if these functionalities are can cover the 4 concepts described on the previous page. The feedback was positive and therefore now allows the author to move onto the design and implementation stage of developing the functionalities described in the list above.

5

The Case Study – Prototype Development Iteration 1

The requirements of the prototype system have been gathered from the problem owner. The iterative development stages consist of the design, implementing and testing stages. Bennett et al (2002), states that the design stage is about establishing how to deliver the functionality that was specified in the requirement analysis stage. The design stage is significant as the developer needs to make important decisions regarding the overall structure of the system. In the design stage of iteration 1, the structure of the prototype system will be developed. This includes the MySQL database and the AAI. Once the tables for the database and the pages of the AAI have been designed, they will need to be implemented. Once this is completed, the functionalities implemented need to be tested. For iteration 1, two main types of testing will be carried out. Firstly, there is unit testing and secondly, there is acceptance testing. The difference between these 2 types of testing will be discussed later on in the chapter when the testing needs to be carried out.

The system is composed of two parts and therefore it seems logical to carry out two iterations when designing, implementing and testing the system. The first iteration focuses with the design, implementation and testing of the first part of the system. This is an administrative interface (the AAI) that allows a teacher to manage (create, update and delete) learning material. The second iteration focuses with the design, implementation and testing of the second part of the system. This is a public user interface where anyone can view the learning material. The entire first iteration is discussed in this chapter, whilst the entire second iteration is discussed in the next chapter.