Introduction to prototyping
1.1 Definition and objectives
A prototype is a functional model that works similar to the component of the product. In most cases, the client only has the general perspective of what is expected from the product of software. In such a situation where there is no detailed information concerning the system input, processing requirements and the output requirements, the prototyping model can be used. Prototyping has a number of objectives. First, it is employed in order to overcome the possible client misinterpretation and also to test technical feasibility of the proposed design and its purpose. Next is that it is meant to answer the questions concerning the feasibility of the product design or its suitability through the production of limited version of the product. Third is that they are used for the purpose of providing a better impression of experience for the user as compare to what simple descriptions can do. It also provides away of selecting the best product option out of the available alternatives. They are thus a way of ensuring that users are given the opportunity to evaluate the software product. Prototyping are used as a requirements technique and as a means of getting product specification. Other objectives include the need to increase flexibility of the development process by permitting the client to interact and experiment with a functional representation of the product (Sommerville, 2006, Wiley, 2002).
There are therefore two types of prototypes namely version1 and version 2 which are used as requirements techniques and as specifications respectively. The version1 prototype makes use of prototype as a way of fast determination of the client needs. It is then discarded as long as the specifications are agreed upon. The importance of version1 prototype is to represent the features of the software that will be visible to the client or user. The visible features are like inputs approaches and formats of outputs. It does not really matter in this case whether the prototype is working or not. In the case whereby the first version of prototype fails to meet the needs of the client, then it is rapidly converted in to the second version where the prototype is used as the specifications for the design stage. The version2 of prototyping has an advantage in that it is fast and accurate since no time is used in drawing up the specifications although it has some difficulties such as incompleteness, ambiguities and contradictions (Sommerville, 2006).
1.2 Merits of using low fidelity prototypes
Low fidelity prototypes helps the developers get the most appropriate requirements from the clients or users. It speeds up the research of visual control algorithms thus helps in the design and implementation of software design for quick prototyping. Low fidelity prototype also provides an outline of the software product. It is designed to offer the user with the idea of what the real software may appear or look like. It is thus advantageous in that it gives a software idea at the early stages of the design. In addition, low fidelity prototypes can be used to form the foundation of high fidelity prototype by the software design team. Consequently, this kind of prototyping helps the designers to produce or generate software that better fits the needs of the user (de Sá, et al. 2011, de Souz, Ferreira & Maurer, 2013).
Description of Methods
Arriving at the prototype
2.1.1 Use of interview method
The interview method was used to collect requirements data from the garden designer users who use the system and the client who in this case is the garden owner who interacts with the system for which a garden can be designed. This was done with an aim of finding out what the user wanted in terms when using the system. One thing that went wrong during the interview process is that much emphasis was placed on the garden requirements rather than system requirements. It turned out that I did not have the most suitable set of questions for the garden designer and the garden owner. The questions focused on the garden design instead of how the garden designer would use the system. In other words, the requirements to be collected through questions such as those could not help in coming up with user centered design (Sommerville Ian, 2012).
2.1.2 Use of Volere Shell Card Method
The second method used was the Volere shell cards which were very helpful in understanding the requirements in comprehensive details. The Volere shell cards generate a summary of requirements by giving the description and Fit criteria. The Volere shell is a kind of guide on how the requirements should be written and it consists of printed cards each with requirements attributes that can be employed for the initial requirements gathering. Every attribute helps in understanding and testing of the requirement (Robertson & James, 2013).
The shell card used consists of the attributes namely the description, the rationale and the Fit criterion. The description part of it is used to describe or rather explain what it does while the rationale explains the reasons as to why we want requirement. The Fit criterion part of the shell card explains why it works or the test condition. The main aim still is to collect the right and all inclusive data given that incorrect requirements will result to a software product intended for the green dream which is also wrong. As a result it is very significant to get the right understanding of what is essential for the period of the prototyping phase. The Volere shell cards used in this case were divided into three categories: Volere shell card user tasks, Volere shell card characteristics of users and Volere shell card environment.
The description attribute in the Volere shell card user task emphasized that the orders have to be entered precisely for the purpose of sending the entered orders into the database. The second part of the description explained that the system should store the date and time when the garden design project is set to be commence. The rationale attribute maintained that the designer have to enter client information correctly using the correct format. The client information to be entered includes name, email, phone number and payment details or card number. It is only after the input of this client information that the reference order can be produced. The rationale also explained the schedule for landscaper employment within a given time frame. The Fit criterion part of the shell card indicated that the garden design orders will be sent to the database with all data precisely entered. In addition, the Fit criterion also explained that the stored design orders have to be logged within three hours of completion (Rogers, Sharp, & Preece, 2011).
The description attributes in the category of Volere shell card characteristics of the users describes how the system menu should appear. In this case, the menu should have icons which are easy to use as per the description with the second part of this attribute stating a requirement that the system software will function only by means of interactive graphical user interface using handheld device (Rogers, Sharp, & Preece, 2011). The rationale part of user characteristic shell card explains that all users prefer to use image icons and that the software is for the garden designer and not the client. The Fit criterion requirement description is that menu displayed will have image icons which are easy to view. In addition, the Fit criterion states that the software product should be tested for it to be compatible with hand held device.
The third group of requirement gathering was grouped under Volere shell card environment. The description attribute part of this category stated that the garden owner would like specialized furniture. The description requirement also stated that the garden owner would like a small garden (Robertson, Suzanne, and James Robertson, 2013). The requirement under rationale was that that the software product should be marketed for the garden leisure usage and that the client has made it clear that that they do not want any expansion on their garden. On the other hand, the Fit criterion part of this requirement category maintained that the product should be medium sized hot tub designed for garden usage. Furthermore, the Fit criterion stated that the size of the garden should not change or vary (International Oil Spill Conference Proceedings, 2011).
2.1.3 Use of persona
The use of persona was used for the purpose of getting a better understanding of who is using the system which in this case includes the garden owner or client and the garden designer. The user of the system is thus more acquainted with what he/she wants in the system but which is lacking in the current system. In addition to that, the information received during requirement collection is dependent on the various personas each with different interest (Laforest, Duffe, Demers, & Gauvreau, 2011).
2.1.4 Future use case scenarios
Use case scenarios are useful in this case they were used to show the functionality of business process. This is done by breaking it into a series of simply identifiable steps. The steps can be written in English or any other language used in the working place for access by all stakeholders However; we used English in our use case scenario. It was therefore important to use case scenarios to help in the description of business processes in addition to understanding of the functionalities required. As long as the scenarios are decided upon they become the framework of requirements (Robertson & James, 2013).
2.1.5 Use cases and essential use cases
Use cases are used to smoothen the progress of functional requirements of the system. It is used as a technique of communication in order to describe requirements of a system. They also build the foundation for precise requirement document. The small numbers of use cases are implemented as early as possible for the purpose of getting stakeholder’s reaction. The use cases are very important because they also help in the generation of dynamic object oriented specifications (Robertson & James, 2013). It is from the reaction of stakeholder that more and valid requirements can be discovered.
2.1.6 Drawing out prototypes
This was used to show the individuals who played the roles of garden designer and garden owner. As a result the respective roles are used to update the prototype drawings in addition to improving the system design (de Souza Alcantara, Ferreira, & Maurer, 2013). The prototyping is crucial in overcoming the partial misunderstandings of the client and to test the technical feasibility of the suggested design. The drawing of prototypes is also based on user centered design principles. Therefore, all the above discussed methods play a great role in gathering user requirements for user centered information systems (Sommerville Ian, 2012).
The prototypes consist of a home page that is displayed on three displays. The display on the other hand consists of shared display, employee display as well as the client display. The home page varies on every display and the shared display shows a home page where the employee can input data or stuff in order to generate an order. A welcome page has also been made available for the client (de Sá, Antin, Shamma, & Churchill, 2011). Once the staff has logged into the system, then the start of the order is created in which the shared display shows a list of garden products. These products can be selected by the employee screen so that an order to be created. The client in this case will be able to see the particular product that is selected. The client does not need to do anything apart from speaking to the garden designer in order to create their garden. The ultimate page displays a list of everything that has been ordered and then generates the design quote for the garden. In the case where all things are ok or satisfactory with the page of the quote, the client will be able to input the details of payment which all have to conform or agree with the terms and condition of the order (International Oil Spill Conference Proceedings, 2011).
How the prototype satisfies the requirements and any changes to be made as a result of user feedback
3.1 How it satisfies the requirements
Apart from the additional screen making it simpler, but it will also make the process of getting the bespoke garden simpler for the garden owner. Since the user feedback was to simplify each page and make it simpler, the system designer will be capable of generating a garden design without too much effort (Laforest, Duffe, Demers, & Gauvreau, 2011). I also simplified the design in order to put every task on the screen such as deciding on the garden, hot tubs, garden turf, furniture and garden sheds of which all have no individual (de Souza Alcantara, Ferreira, & Maurer, 2013).
3.2 Changes to be made as a result of user feedback
However, there was a problem during the demonstration of my finding with one of the shell cards since it did not work, having introduced handheld device yet it should be a design for an eSpace system. Having learned from this, I have therefore adapted my requirements so that they center on the three displays which was not shown correctly since the user could as well have a device that can display what they need to see on the specific screen and not on a handheld device. Therefore, I have had to change the Volere shell card so that I can implement changes that take place in the prototype. The effect of replacing handheld device with eSpace means that the system software will function through interactive graphical user interface using eSpace which a new interactive workspace that supports sales transactions (Laforest et al. 2011).
The changes on the prototype include how to make the design pages extra simplified given that they had too much navigation across the screen features. The changes have therefore been made including the inclusion of added pages for the plans of the garden so that when the garden designer deigns the system for the garden owner, they can have an overview of the exact thing that is required. The navigation page is the major page that requires changes (Dutch Holland, phD & Harriet Pritchett 2013). The changes needed include splitting the page in to extra pages for the purpose of simplifying the system in addition to making it simpler as well as making it more organized. Lastly is the splitting up of the final quote page in two more quote pages, followed by splitting of payment page.
4.0 A reflection of your experiences in the application of the theory to the practice.
The entire data gathering using the various methods was very beneficial in drawing out the prototype. This helped me understand the system better. The additional interview on how to improve the system was also very useful like the making of a number of extra feature that is extra clear and easy to appreciate. In fact, this was a perfect way of developing low fidelity prototype and offered a great approach of designing the system (Laforest et al., 2011).
5.0 A summary of the findings and recommendations.
In conclusion, I found that people are generally resistant to change and for this reason, the system designer needed a simpler but extra efficient system in order to create garden design. Prototyping is thus a better approach to take in gathering precise user requirements for user centered design as it eliminates misunderstanding of the client concerning system requirements and its functionality. This is because accurate requirements translate to accurate and, efficient and reliable system (Dutch Holland, & Harriet Pritchett, 2013). Last but not least, the implementation of garden design is thus a digital engineering approach which involves implementing digital technology for business value. This kind of implementation is one of the hardest activities that any company may take on. Nonetheless, the principles for this kind of complicated implementation are at last down in writing as shown by the prototyping process. The incorporation of design work in IT and technology in general is an evident that the future belongs to digital engineers (Dutch & Harriet, 2013).
References
de Souza Alcantara, T, Ferreira, J, & Maurer, F 2013, June, Interactive prototyping of tabletop and surface applications. In Proceedings of the 5th ACM SIGCHI symposium on Engineering interactive computing systems (pp. 229-238). ACM.
Dutch Holland, phD & Harriet Pritchett, MED, 2013, The Future belongs to Digital Engineers: Transforming the industry. Retrieved on 10th /04/2015, from https://books.google.co.uk/books?id=ugCz_LRDTyUC&pg=PT24&lpg=PT24&dq=new+for+some+but+still+absolute+requirements+for+a+company+that+is+%22going+for+it%22!&source=bl&ots=1-B3-1SLOd&sig=idJPzg20odxws9ryXgwezgvs4M&hl=en&sa=X&ei=uRkgVbH6JoXTaKW5gpAE&ved=0CCEQ6AEwAA#v=onepage&q=new%20for%20some%20but%20still%20absolute%20requirements%20for%20a%20company%20that%20is%20%22going%20for%20it%22!&f=false
In Proceedings of the 5th ACM SIGCHI symposium on Engineering interactive computing systems (pp. 229-238). ACM.bad grammar: A prototype is a functional model that operationally similar to the component of the product. In most cases, the client only has the general perspective of what is expected from the product of software.
International Oil Spill Conference Proceedings (IOSC) (Vol. 2011, No. 1, p. abs82), American Petroleum Institute.
Laforest, S, Duffe, J, Demers, A, M, & Gauvreau, M 2011, March, eSPACE: emergency Spatial Pre-SCAT for Arctic Coastal Ecosystems project. In International Oil Spill Conference Proceedings (IOSC) (Vol. 2011, No. 1, p. abs82), American Petroleum Institute.
Robertson, Suzanne, and James Robertson, 2013, Mastering The Requirements Process. Upper Saddle River, NJ: Addison-Wesley, Print. ISBN-10: 0321815742
Rogers, Y, Sharp, H, & Preece, 2011, Interaction design: beyond human-computer interaction, John Wiley & Sons.
Sommerville Ian, 2012, Software Engineering,7th edition, Addison Wesley.
