| GISdevelopment.net ---> Technology---> Mobile Mapping |
Mobile GIS - A Study on Farmers's Requirements
Mohamad Ashari Alias
Faculty of computer Science & Information Systems
Universiti Teknologi Malaysia
81310 UTM
Johor Darul Takzim
Malaysia
Phone No: +607-5532458
Fax No: +607-5565044
E-mail: ashari@fsksm.utm.my
Abdul Rashid Mohamed Shariff
Department of Biological & Agricultural Engineering
Faculty of Engineering
Universiti Putra Malaysia
43400 Serdang
Selangor Darul Ehsan
Malaysia
Phone No: +603 - 86567126 / 89466414
Fax No: +603-89466425
E-mail: rashid@eng.upm.edu.my
Mohd Shafry Mohd Rahim
Faculty of computer Science & Information Systems
Universiti Teknologi Malaysia
81310 UTM
Johor Darul Takzim
Malaysia
Phone No: +607-5532458
Fax No: +607-5565044
E-mail: shafry@fsksm.utm.my
Abstract
Most existing GIS particularly precision farming has been developed based on stand-alone PC, which is not suitable for farmers who work on fields. Mobile GIS is proposed utilising the advantages of current mobile communication and computing. In this paper, we present result from our study on requirements of farmers. This study employs qualitative technique. Questionnaire has been distributed to respondents and collected by hand to reach widely dispersed respondents inexpensively. Reliability of the items in the questionnaire is tested using standard method. Sampling of population is done via random sampling method to farmers at Blok C, Sawah Sempadan and Sungai Sireh in Tanjung Karang, Selangor, Malaysia. Microsoft Excell is used to analyse data collected from the respondents. The result shows the current situation about farmers in Selangor in particular and Malaysia as a whole. A study on their expectation on the suitable device to be used on field is also presented. Results shows that they prefer to have mobile device to assist them while working on field. This result opens to research and development on mobile GIS.
Introduction
Developing products and services that meet the expectations of users and customers is critical to success. Requirement analysis is the foundation of a user-centered approach, creating products that appeal and meet user needs. User requirements analysis provides precise descriptions of the content, functionality and quality demanded by prospective users. For the identification of user needs the user perspective must be assumed and result in: Functional requirements and Non-functional requirements. The reliability of items in the questionnaire is tested by some experts in this field and using standard method. Mean and standard deviation for each item in the questionnaire is calculated to determine the acceptability of the result.
Methods for User Requirements Analysis
Informal methods such as observation, interview, document analysis, focus group analysis, checklists or questionnaires can be used for the elicitation of user requirements. Different requirements analysis methods can be applied in parallel to complement each other in order to yield more effective results. In our case, questionnaires and interview had been used to obtain user requirements. Both quantitative and qualitative method has been employed but in this paper, only quantitative result is presented.
Development of such systems follows the common software development life cycle (SDLC). SDLC is the overall process of developing information systems through a multistep process from investigation of initial requirements through analysis, design, implementation and maintenance. There are many different models and methodologies, but each generally consists of a series of defined steps or stages. To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. [10]. Phases in classic waterfall methodology are as below:
Determine User Requirements
According to [3], primary responsibilities for project manager are:
Purpose of User Requirements Definition
When user requirements are well understood from the start of a project, customer satisfaction with the resulting software will be higher.
Describe Users
Identify the characteristics of the intended users of the software:
Different job functions or levels of experience that differentiate the various sets of expected users. These groupings or types of expected users are known as the "user classes" for the software.
Describe:
Viewed broadly, a user is anyone who is affected by or who may affect the software product. User roles are the kinds of persons who will be affected by the system: those who use the software directly, those who use the results produced, and those who never see the system, but have information influencing its design (such as regulators and lawyers). Considering this broad list of user classes suggests features and functions that need to be included.
Information Technology departments at customer companies are another important group to consider. For example, including steps to participate in customer internal software development processes may be important to ensure acceptance of the completed software within their systems.
Gather Initial Requirements
Get the users involved very early in the concept discussions to understand what they need the software to do. These are the initial functional requirements.
Discuss the software requirements with end-users. Be sure to cover:
Review Requirements with Users
Review the initial requirements with end-users and funders to obtain their approval of:
User Requirements Specification - URS
The User Requirements Specification is a document produced by, or on behalf of your organization, which documents the purposes for which a system is required - its functional requirements - usually in order of priority/gradation.
Whilst the URS will not usually probe the technical specification, it will nevertheless outline the expectations and, where essential may provide further detail e.g. the User Interface, say Microsoft Windows®, and the expected hardware platform etc.
The URS is an essential document which outlines precisely what the User (or customer) is expecting from this system. The term User Requirement Specification can also incorporate the functional requirements of the system or may be in a separate document labeled the Functional Requirements Specification - the FRS.
Leading research indicates that poor requirements definition is a huge problem for many IT organizations. Unrealistic expectations that clients and users have regarding projects often arise because projects get started before the user requirements are determined. The biggest problems encountered on failed IT projects are:
Once identified, the user requirements effectively lay the foundation for developers, testers, and implementers to begin determining the functionality, responsiveness, and interoperability required of that system. Unfortunately, many people consider gathering user requirements as a waste of time. However, the strategy is crucial to a project's success for developers and project managers to obtain accurate user requirements as well as increase the level of client and user involvement on a project.
User requirements determine what succeeds and what fails. If only one product offers you the features you need, you'll use it no matter how ill designed or difficult to use it is (and no matter how onerous the commercial license). On the other hand, you'll walk right by the best-designed, award-winning software if it doesn't do what you want. [8]
Regardless of the method you choose to identify the appropriate tasks and requirements for your system, it is important that you conduct these activities before implementing any new design or major redesign of a system. This critical first step in the system design process will ensure that your final design is user-friendly, flexible and adaptable, and will eliminate expensive and unnecessarily frequent redesigns.
Results
Based on steps taken from [3], I present the result that we found accordingly: The purpose of this study is to develop mobile GIS. The users will be paddy farmers who normally work on field and mobile in nature. 200 questionnaires has been distributed to farmers at two different areas:Blok C Sawah Sempadan, Selangor and Sungai Sireh, Tanjung Karang, Selangor, but only 107 had been returned. Our study found that 83% farmers are male and 22% are female. In term of farming experience, 61% have more than 5 years experience, and 11% have 1 to 3 years experience and also 11% have 4 to 5 years experience. Only 7% have experience less than 1 year, and the rest are unknown. 25 out of 107 (23%) have computer at home and the rest have not. We found that those who do not have computer at home also do not know how to use computer.
Requirements from farmers that have computer and know how to use computer upon new system and device to be used
We would consider most on this group of farmers' requirements because they had experienced the benefit of using computer and have more understanding about computer and its system compared to the other group of farmers. Table 1 shows farmers' requirements towards the new system and Table 2 shows the farmers' requirements towards the device to be used.
The scale and its interpretation that has been used are given below:
Table 1 - Farmers Requirements Towards the New System
Table 2 - Farmers Requirements Towards the Device To Be Used
Nil scores are ignored, as they could not be taken into account to represent the farmers' requirement.
Final score of each mean score are interpreted (as a level of agreement) as below:
a. Mean 1 - 2 ą Low
b. Mean 3 ą Middle
c. Mean 4 - 5 ą High
Based on the mean values shown on Table 1 and Table 2, all items' mean are more than 3, which means middle and high agree. Standard deviations are also consistence along the questions with values less than 1 except item 5 (about the price of the device to be used), where there is varies level of agreement with the mean shows middle agree and standard deviation is1.32.
Conclusion
The result from our study gives us foundation to proceed to the next phase in the development of the new system. Regular review with users upon their requirements is still proceeding, as the time goes, users requirements may change or need refinement.
The next two steps are still undergoing research.
References
Mohamad Ashari Alias
Faculty of computer Science & Information Systems
Universiti Teknologi Malaysia
81310 UTM
Johor Darul Takzim
Malaysia
Phone No: +607-5532458
Fax No: +607-5565044
E-mail: ashari@fsksm.utm.my
Abdul Rashid Mohamed Shariff
Department of Biological & Agricultural Engineering
Faculty of Engineering
Universiti Putra Malaysia
43400 Serdang
Selangor Darul Ehsan
Malaysia
Phone No: +603 - 86567126 / 89466414
Fax No: +603-89466425
E-mail: rashid@eng.upm.edu.my
Mohd Shafry Mohd Rahim
Faculty of computer Science & Information Systems
Universiti Teknologi Malaysia
81310 UTM
Johor Darul Takzim
Malaysia
Phone No: +607-5532458
Fax No: +607-5565044
E-mail: shafry@fsksm.utm.my
Abstract
Most existing GIS particularly precision farming has been developed based on stand-alone PC, which is not suitable for farmers who work on fields. Mobile GIS is proposed utilising the advantages of current mobile communication and computing. In this paper, we present result from our study on requirements of farmers. This study employs qualitative technique. Questionnaire has been distributed to respondents and collected by hand to reach widely dispersed respondents inexpensively. Reliability of the items in the questionnaire is tested using standard method. Sampling of population is done via random sampling method to farmers at Blok C, Sawah Sempadan and Sungai Sireh in Tanjung Karang, Selangor, Malaysia. Microsoft Excell is used to analyse data collected from the respondents. The result shows the current situation about farmers in Selangor in particular and Malaysia as a whole. A study on their expectation on the suitable device to be used on field is also presented. Results shows that they prefer to have mobile device to assist them while working on field. This result opens to research and development on mobile GIS.
Introduction
Developing products and services that meet the expectations of users and customers is critical to success. Requirement analysis is the foundation of a user-centered approach, creating products that appeal and meet user needs. User requirements analysis provides precise descriptions of the content, functionality and quality demanded by prospective users. For the identification of user needs the user perspective must be assumed and result in: Functional requirements and Non-functional requirements. The reliability of items in the questionnaire is tested by some experts in this field and using standard method. Mean and standard deviation for each item in the questionnaire is calculated to determine the acceptability of the result.
Methods for User Requirements Analysis
Informal methods such as observation, interview, document analysis, focus group analysis, checklists or questionnaires can be used for the elicitation of user requirements. Different requirements analysis methods can be applied in parallel to complement each other in order to yield more effective results. In our case, questionnaires and interview had been used to obtain user requirements. Both quantitative and qualitative method has been employed but in this paper, only quantitative result is presented.
Development of such systems follows the common software development life cycle (SDLC). SDLC is the overall process of developing information systems through a multistep process from investigation of initial requirements through analysis, design, implementation and maintenance. There are many different models and methodologies, but each generally consists of a series of defined steps or stages. To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. [10]. Phases in classic waterfall methodology are as below:
- Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
- Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
- Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
- Implementation: The real code is written here.
- Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
- Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
- Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
Determine User Requirements
According to [3], primary responsibilities for project manager are:
- Purpose of User Requirements Definition
- Describe Users
- Gather Initial Requirements
- Review Requirements with Users
Purpose of User Requirements Definition
When user requirements are well understood from the start of a project, customer satisfaction with the resulting software will be higher.
Describe Users
Identify the characteristics of the intended users of the software:
- Names of industries, specific businesses and job functions
- Minimum computer skills and equipment that users will have
- Specialized technical knowledge or expertise that users will possess
- Specialized equipment that is owned or operated by the intended users
Different job functions or levels of experience that differentiate the various sets of expected users. These groupings or types of expected users are known as the "user classes" for the software.
Describe:
- Approximate numbers of the various types of users expected for the software
- How often users are expected to use the software
- The tasks that the users will accomplish with the software.
Viewed broadly, a user is anyone who is affected by or who may affect the software product. User roles are the kinds of persons who will be affected by the system: those who use the software directly, those who use the results produced, and those who never see the system, but have information influencing its design (such as regulators and lawyers). Considering this broad list of user classes suggests features and functions that need to be included.
Information Technology departments at customer companies are another important group to consider. For example, including steps to participate in customer internal software development processes may be important to ensure acceptance of the completed software within their systems.
Gather Initial Requirements
Get the users involved very early in the concept discussions to understand what they need the software to do. These are the initial functional requirements.
Discuss the software requirements with end-users. Be sure to cover:
- Key features and functions that the software must perform, including graphical interface, management reports, and human factors (usability)
- Benefits to the customer including savings that could be obtained
- Approximate cost for the development
- Any commercial software products that provide overlapping or competing capabilities.
Review Requirements with Users
Review the initial requirements with end-users and funders to obtain their approval of:
- What tasks the users want to use the software to do
- Key features and functions
- Reports and results the software should produce
- Other software that needs to interface to this software
- User interface description
- Other key requirements of users and funders.
User Requirements Specification - URS
The User Requirements Specification is a document produced by, or on behalf of your organization, which documents the purposes for which a system is required - its functional requirements - usually in order of priority/gradation.
Whilst the URS will not usually probe the technical specification, it will nevertheless outline the expectations and, where essential may provide further detail e.g. the User Interface, say Microsoft Windows®, and the expected hardware platform etc.
The URS is an essential document which outlines precisely what the User (or customer) is expecting from this system. The term User Requirement Specification can also incorporate the functional requirements of the system or may be in a separate document labeled the Functional Requirements Specification - the FRS.
Leading research indicates that poor requirements definition is a huge problem for many IT organizations. Unrealistic expectations that clients and users have regarding projects often arise because projects get started before the user requirements are determined. The biggest problems encountered on failed IT projects are:
- Misunderstood requirements and scope creep, which often cause an over-allocation in resources, additional cost or overdue deliverables.
- Incomplete requirements (data, reports), which result in incomplete information about the system.
- Unstable requirements or new requirements being added during the development phase.
- Ambiguity regarding the functionality and objectives of certain requirements.
- Conflicting goals by different teams (e.g., the users may want one thing and the business requires another approach).
- Too many "nice-to-have's" that wouldn't actually be used.
Once identified, the user requirements effectively lay the foundation for developers, testers, and implementers to begin determining the functionality, responsiveness, and interoperability required of that system. Unfortunately, many people consider gathering user requirements as a waste of time. However, the strategy is crucial to a project's success for developers and project managers to obtain accurate user requirements as well as increase the level of client and user involvement on a project.
User requirements determine what succeeds and what fails. If only one product offers you the features you need, you'll use it no matter how ill designed or difficult to use it is (and no matter how onerous the commercial license). On the other hand, you'll walk right by the best-designed, award-winning software if it doesn't do what you want. [8]
Regardless of the method you choose to identify the appropriate tasks and requirements for your system, it is important that you conduct these activities before implementing any new design or major redesign of a system. This critical first step in the system design process will ensure that your final design is user-friendly, flexible and adaptable, and will eliminate expensive and unnecessarily frequent redesigns.
Results
Based on steps taken from [3], I present the result that we found accordingly: The purpose of this study is to develop mobile GIS. The users will be paddy farmers who normally work on field and mobile in nature. 200 questionnaires has been distributed to farmers at two different areas:Blok C Sawah Sempadan, Selangor and Sungai Sireh, Tanjung Karang, Selangor, but only 107 had been returned. Our study found that 83% farmers are male and 22% are female. In term of farming experience, 61% have more than 5 years experience, and 11% have 1 to 3 years experience and also 11% have 4 to 5 years experience. Only 7% have experience less than 1 year, and the rest are unknown. 25 out of 107 (23%) have computer at home and the rest have not. We found that those who do not have computer at home also do not know how to use computer.
Requirements from farmers that have computer and know how to use computer upon new system and device to be used
We would consider most on this group of farmers' requirements because they had experienced the benefit of using computer and have more understanding about computer and its system compared to the other group of farmers. Table 1 shows farmers' requirements towards the new system and Table 2 shows the farmers' requirements towards the device to be used.
The scale and its interpretation that has been used are given below:
- Strong Disagree
- Disagree
- Middle Agree
- Agree
- Strong Agree
Nil scores are ignored, as they could not be taken into account to represent the farmers' requirement.
Final score of each mean score are interpreted (as a level of agreement) as below:
a. Mean 1 - 2 ą Low
b. Mean 3 ą Middle
c. Mean 4 - 5 ą High
Based on the mean values shown on Table 1 and Table 2, all items' mean are more than 3, which means middle and high agree. Standard deviations are also consistence along the questions with values less than 1 except item 5 (about the price of the device to be used), where there is varies level of agreement with the mean shows middle agree and standard deviation is1.32.
Conclusion
The result from our study gives us foundation to proceed to the next phase in the development of the new system. Regular review with users upon their requirements is still proceeding, as the time goes, users requirements may change or need refinement.
The next two steps are still undergoing research.
- Gather Initial Requirements
- Review Requirements with Users
References
- Mohamad Ashari H.A., Abdul Rashid M.S and Mohd. Shafry M.R., 2005. "Integrated Precision Farming Systems Architecture by Integrating GPS and Hotspot Technology". NARGIS '05, 4th - 8th July, 2005, Darwin, Australia.
- Sim D'Hertefelt, 2000. "13 common objections against user requirements analysis, and why you should not believe them" http://www.interactionarchitect.com/articles/article20000609b.htm
- "Determine User Requirements" http://www.epri.com/eprisoftware/processguide/userreq.html
- Jeanette F., Jack P., Jack F. "Web Site User Centered Design: Techniques for Gathering Requirements and Tasks". IBM Corporation http://www.internettg.org/newsletter/june98/user_requirements.html
- Jason P. C., 2003. "Determine user requirements now to avoid problems later" http://builder.com.com/5100-6315_14-5054103.html
- "User requirement anlysis" http://www.vnet5.org/pub/approach/ura.html
- "User Requirements" http://www.edocmagazine.com/quick_article.asp?ID=28502
- Andy Oram. "Meeting User Requirements--How Free Software Achieves Quality" http://www.oreillynet.com/pub/wlg/6223
- "IBM Ease of Use - User Requirements" http://www-306.ibm.com/ibm/easy/eou_ext.nsf/publish/2514
- Russel K. "QuickStudy: System Development Life Cycle". http://www.computerworld.com/developmenttopics/development/story/0,10801,71151,00.html