Establishing Requirements, Low-Fidelity Prototyping and Proposed Data Gathering - Case Study Example

ESTABLISHING REQUIREMENTS, LOW-FIDELITY PROTOTYPING AND PROPOSED DATA GATHERING  STUDENTS NAME: STUDENT NUMBER: PROGRAMME: PROFESSORS NAME: DATE: WORD COUNT: Introduction Human computer interaction is a critical component of information systems. Successful completion of any information systems projects requires comprehensive requirements analysis, design, implementation and eventual validation and testing. In human computer interaction sciences, human beings must have the capacity to interact effectively with computer based systems and the interaction must take into consideration the cognitive-affective aspects of information systems. Incorporation of human Computer Interaction (HCI) in Systems Development Life Cycle (SDLC) is critical in successful implementation of Information Systems (IS) (Sharp, Rogers and Preece 2007). Organizational needs must not be considered at the expense of human needs. While working towards satisfaction of organizational needs, enrichment of human users must also be considered with high requirements and early enough in the development cycle for effective implementation of human supported information systems. For a truly human centred development of information systems, there must be a careful and a timely integration of human computer interaction in software development life cycle. This research examines the process of establishing requirements and low fidelity prototyping in the proposed design of MaxiMarket (A shopping mall consisting of 87 outlets) Interactive directory. The proposed data gathering techniques that will be used to support the final design acceptance will also be given. Needs and Requirements The proposed MaxiMarket interactive directory should be designed and developed with the end user in mind. Needs and requirements must focus on both usability and user experience goals. Usability goals must be identified before commencing the projects and any evaluations to be conducted on the system based on the documented usability goals. It is critical that usability goals be identified at the requirements analysis stage to provide a basis for measuring technology against the usability goals on all consequent evaluations. The various alternative designs that will later be developed will be based on the usability goals identified at the beginning of the project. Belo are the various usability and user experience goals that must be achieved in MaxiMarket. Usability Goals Effectiveness Effectiveness measures the degree to which users can accurately and completely accomplish various tasks from the final system. When looking for information from MaxiMarket, users must be able to obtain correct as well as accurate information. Effectiveness must overcome the need for training users must be able to accomplish various tasks within a reasonable amount of time. Effectiveness has a direct relationship with the needs of the end users. The proposed MaxiMarket system must therefore be able to accomplish various tasks with the highest level of simplicity. Any output obtained from the system must be consistent with the input provided. Efficiency Efficiency measures how quickly users can complete various tasks. The proposed MaxiMarket system must therefore be able to achieve the requested directory tasks within a short period of time. A good design will make MaxiMarket directory users to thin that operations are taking less time than the actual time. Poor design will result if the end user thinks that the system is taking much time than it is supposed to be taking. Normal operations must be viewed by various users for the system to be considered efficient. Safety The proposed MaxiMarket system must be able to avoid dangerous situations during its operational lifetime. The key pads must for instance not injure the end users during operations. MaxiMarket will be required to provide users with techniques for recovering from errors in case they occur during operations. The system will also be required to have high privacy and data security. Safety must be observed both at the hardware as well as at the software levels. Utility MaxiMarket system will be expected to provide users with enough functionalities for accomplishing the required tasks. All the functionalities required for accessing the MaxiMarket directory and getting the various products at various stores must be available. Users must also be provided with functionalities to filter the products from the directory as required to suit their needs. Functionalities must not be too many as this will confuse the end users. Commonly used features must be available to all users while rarely used features such as admin login and database maintenance should be left for experts. Learnerability The final product must be easy to use and manage. The end users must be able to use the final product right away as training is usually very expensive and the business organization might not have a budget for training. This will be critical for the directory since MaxiMarket is working on a limited budget. Expert training should only be delegated for expert users. Memorability Once the end users have learned how to use the MaxiMarket directory, it must be easy to remember how to operate it. This will be especially critical for repeated and infrequent tasks such as retrieving the products list. User Experience Goals This will be the user satisfaction expected from the proposed MaxiMarket directory. This must be achieved for both products and services. For effective user experience to be achieved, the final product must be enjoyable, satisfying, fun, entertaining, helpful, motivating, aesthetically pleasing, supportive of creativity, rewarding and emotionally fulfilling. Development of Alternative Designs. Alternative designs will be implemented through evolutionary prototyping. Since all the requirements have been developed and validated in the requirements analysis stage, evolutionary prototypes will be used as the basis for continuous improvement of the final MaxiMarket system. The best prototype will be selected from the various models created based on their responsiveness to usability and user experience. The prototypes will also be used to provide common baseline for exposing the system to comments for further development. The prototypes given below captures the critical requirements for the final MaxiMarket directory system. The prototypes given are just evolutionary prototypes and more details can be added upon refinement. MaxiMarket database required a database to store products information and access to the products must be secure. Interaction with the database wll involves three layers which are the users, HCI interface and the data layer. The human layer will be comprised of customers and other users interacting with the database. Alternative designs will be used as the basis of evaluating the solution being modelled. Requirements might change as the design progresses and evolutionary approach will allow those changes to be accommodated. Other prototyping techniques such as throw away do not provide this flexibility. The prototypes given encompass the requirements which were captured for the first time, for the front office applications. This implies that both application and database prototyped must be used to evaluate the business logics and the functionalities expected in the final solution. A user selects a store and the system returns its location, description, and the floor where a given product is located. If no store is selected, the system defaults to main store and if no product group is selected, the system defaults to all categories. With the product group being all categories, the floor name at the bottom of the screen appears disabled and with a default value of FFF. The store description and location labels have been given as sample labels or names. 1st Prototype: Design 1 Below is an instance of the live operational interactive directory: 1st Prototype: Design 1 Users comprise of registered and unregistered users. The users are able to view the products from a central directory. Customized product view can also be seen. A user may for instance want to view both the products name and the product photo. The server side for the interactive directory is comprised of the database while the client side is comprised of the application software. Products information can be entered from the server side and a list of products maintained and managed by database administrators, metadata is used to provide data about data within the overall database. An example of meta data is product photos. Any data entry must be strictly controlled to maintain consistency in the final directory. From the front office side, customers can view the products from list views and other formats. Authorised staff such as administrators can also manipulate the database and set definitions such as authorizations by logging in with administrative credentials. Monitoring and visualizations can also be done. As new data is added from he back office or privileged front office, this data is automatically reflected in the application software on the client side. Product selectors can be used to create multi-views of the system ,such as zoomed information and product photos at various stores. Second prototype: Design 2 Below is an alternative prototype where users select a product and the interactive directory returns where it can be obtained i.e. store name, location and floor. Detailed product details are given at the bottom of the screen while the store details are given on the right hand side. The default product name is all categories which give a list of all products with their corresponding locations and other details on a list view at the bottom of the screen. Navigation from one product to another on the list view reflects the product location details on the right hand side. Belo is a live instance of the second prototype with a random product. Data Gathering to support the acceptance of design Business data will be used to test the acceptance of the proposed design. For end user acceptance testing to be done, sufficient test data will be collected from both internal and external sources. Internal data gathering will involve extraction of data from existing organizational databases. Online analytical processing (OLAP) databases will provide the required data for system testing. Data marts will be created to provide a scaled down version of the enterprise data from internal data warehouses. This data will be comprised of products information data and customer’s data. The data will be posted into the system and the output viewed to ascertain the system presentation accuracy. The main purpose of collecting data from internal data sources such as OLAP and datawarehouses is that the same data will be posted into the directory for customers to have the same products displayed on a central terminal. Product photos will also be captured from OLAP databases and data warehouses. Other primary data collection techniques will involve taking photos of various products within MaxiMarket. Photo shooting will be conducted as some new products photos might not have been captured in the production databases. Data mining techniques can also be used for data collection for system testing. In addition, data collection sheets such as questionnaires will be distributed to various organizational stakeholders and their views collected on the type and nature of data that they would like to have in the directory. The view of various users will be used to test the acceptance of the system. Data from the requirements specification documents analysed before the beginning of the project will be used as the key driver to acceptance testing. Designs must be tested against requirements such as user goals and user experience requirements. External data sources for design testing involve literature review of the standard design requirements. Requirements such as usability and performance requirements can be used to provide guidelines on which design is most reliable and acceptable for business automation. Data collected form external sources is critical for providing theoretical guidelines but the most critical data must be the one collected form organizational stakeholders. Data will also be collected through simple observations. Once the directory is deployed, various users will be invited to test the director and the designers will access the usability of designs based on how much time users take to use the system, the level of guidance required to use the system and other critical factors such as efficiency, effectiveness, recoverability and Memorability. Statistics collected during design testing with the various organizational stakeholders will be critical for evaluation of the design acceptance. End users Involvement Users’ suggestions and actions taken Below are some of the issues that were raised by some users during the development process and the actions taken. User Issue Action Taken User1 The interface is too complex Complexity of Interactive Directory Interface reduced User2 The colours are too shouting Cool and moderate colours used. Warm colours discarded User3 There is no help Help system integrated and users taught how to use it. The success of the proposed MaxiMarket directory will depend on how the end users will be involved in the design process. End users involved people like organizational managers, clerks, customers and administrators. Their involvement is critical in collecting the requirements of the system as well as testing and validating the requirements in the final solution. The end users will also be used to gain a deep insight into the domain being modelled. The designers might not be experts in the domain being modelled but organizational stakeholders are. To involve the users, the designer will use a technique called PEArL. It is an acronym for Participants, Engagement, Authority, Relationships and Learning. Their involvement will influence decision making is several ways. The table below gives the five elements of pearl and how they will influence decision making and final solution modelling for MaxiMarket directory. Acronym Meaning Properties P Participants Identify the people involved in the system Identify roles of different people Identify the reasons for involvement in the system Identify the distinction between participants and non participants Are there participants with multiple roles? Are there participants with shared roles? Are there dormant participants? Why do the roles of different participants differ? E Engagement Identify how participants will be involved in the system Identify the timelines for participants involvement Identify the mode of communication What factors in the operational environment can influence the participants involvement A Authority Identity the levels of authority in relation to the various roles Does the organizational policies dictate the flow of authority Is there any authority associated with the tools for engagement in the design process? R Relationships Identify any relationships in the participants and roles Identify possible changes in the relationships identifies What would be the possible effects of relationships change L Learning How is the problem being studied What design approaches will or have been used? Are there any new design ideas? Is there a distinction between theory and practice? The end users will be used as the key drivers of the overall project. Their requirements will be collected and documented for unit and system testing. Since the end users best understands the domain being modelled, their involvement at their various fields of expertise will help to develop a directory that is responsive to organizational needs. Involvement of very stakeholder will be critical in end user acceptance testing. End users gave a positive perception if an information system and they feel in ownership of the final product when their views and opinions are incorporated in system development. The only disadvantage of end users involvement users involvement using the client led design is that users only argue from the requirements point of view and have little understanding about the technical requirements of a system. Some requirements given by the end users might render the final solution vulnerable to security bleachers among other challenges. Designers must therefore be able to strike a balance between user requirements and system requirements. References Sharp, H. Rogers, Y. Preece, J. 2007, Interaction design: beyond human-computer interaction, 2nd edn, John Wiley & Sons Ltd Read More

 

Read More