Assessing desktop application requirements is a critical step for ICT Technicians in Kenya, as it directly influences the success of software solutions deployed within diverse organizations. Whether supporting a county government office or a retail business, understanding the precise needs of users ensures that desktop applications enhance productivity and align with operational goals. This chapter explores key concepts, documentation practices, and validation techniques essential for gathering and confirming application requirements accurately.

1.1 Desktop application requirements identification

In the ICT workplace, correctly identifying the requirements of a desktop application is fundamental to delivering a solution that meets user expectations. Desktop applications serve a broad range of functions, from patient record management in a clinic to loan processing in a SACCO. Effective assessment begins with grasping the core concepts and terminologies, then learning why desktop applications matter, how user requirements are collected and how they are analysed.

1.1.1 Key concepts and terminologies

Understanding the terminology used in desktop application requirements is essential for clear communication between ICT technicians, users and stakeholders. This foundation enables a technician to interpret user needs accurately and translate them into technical statements that a developer or installer can act on.

Desktop application

A desktop application is software installed and operated on a personal computer or workstation, designed to perform specific tasks without requiring continuous internet connectivity. Example: a patient record management system running on the reception and consulting room computers of a clinic.

Requirements

Requirements define what the application must do or the conditions it must satisfy. They include functional aspects such as processing payroll in a county government office, and non-functional aspects such as security and performance.

Functional requirements

These specify the core operations the application must perform, such as generating reports or managing inventory. Example: a retail shop application must track stock levels and record each sales transaction.

Non-functional requirements

These relate to quality attributes such as usability, reliability, performance and security. Example: a cooperative society may require that its desktop application encrypts member data and opens a member account in under three seconds, to maintain member trust.

Stakeholders

Stakeholders are individuals or groups affected by the application, including end-users, management and ICT support staff. Example: in a secondary school, stakeholders of a fee management application include the bursar, the principal, class teachers, the accounts clerk and the school ICT technician.

1.1.1.1 Importance of desktop application

A desktop application runs directly on the computer's operating system and uses the computer's own processor, memory and storage. This makes it fast, dependable and suitable for work that must continue even when the network or internet is down. Understanding this value helps a technician decide whether a desktop solution is the right answer to a user's need before requirements are collected.

The main reasons desktop applications remain important are:

• Offline operation: The application works without a continuous internet connection. Example: a hotel front desk can still check in guests and print receipts during a network outage.
• Speed and performance: Processing happens on the local machine, so heavy tasks such as sorting thousands of records, rendering reports or editing large files run quickly.
• Access to hardware: Desktop applications communicate easily with local devices such as receipt printers, barcode scanners, fingerprint readers and external storage. Example: a supermarket point-of-sale application reads barcodes and opens the cash drawer.
• Data control and security: Sensitive data can be stored on the organisation's own computers and protected with local access controls, backups and encryption, which reduces dependence on outside servers.
• Rich user interface: Windows, menus, keyboard shortcuts and drag-and-drop features give users powerful tools for long daily work such as accounting, drawing or word processing.
• Customisation to the business process: An application can be configured around the exact way an organisation works, for example a school's own fee structure and report card format.
• Predictable running costs: Once installed and licensed, the application does not depend on monthly data bundles to operate, which suits small offices with limited connectivity.

1.1.1.2 User requirements collection techniques

User requirements collection is the process of finding out, from the people who will use or be affected by the application, what they need it to do. A technician who skips this stage risks installing or building software that users reject. Different techniques suit different situations, and a good assessment usually combines two or more of them.

The common techniques are:

• Interviews: One-to-one or small-group conversations with users and managers, using prepared questions. They give detailed answers and let the technician ask follow-up questions. Example: interviewing a SACCO loans officer about how loan applications are approved.
• Questionnaires and surveys: Written sets of questions given to many users at once, on paper or electronically. They are efficient when users are many or scattered, for example all lecturers in a college.
• Observation: The technician watches users perform their tasks in the actual workplace. It reveals steps and workarounds that users forget to mention, such as copying data by hand from one sheet to another.
• Document analysis: Studying existing forms, registers, reports, receipts and manuals to see what data is captured and what outputs are produced. Example: studying a pharmacy's stock card and sales book before specifying a stock application.
• Focus groups and workshops: A facilitated meeting where users from different departments discuss needs together. It helps to expose disagreements early and builds shared ownership.
• Prototyping: Showing users simple screen sketches or a basic working model so they can react to something visible. It is useful when users find it hard to describe what they want.
• Review of the existing system: Using the current system, manual or computerised, to list what works and what causes complaints.

Conducting an interview follows these steps:

1. Identify the users and stakeholders to be interviewed, for example the cashier, the manager and the ICT support person.
2. Prepare open questions linked to the tasks the application will support, such as "How do you record a new customer today?"
3. Book a time and place that do not interrupt the user's busy periods, and explain the purpose of the interview.
4. Begin with easy background questions, then move to tasks, problems and expectations for the new application.
5. Record answers accurately through written notes or, with permission, an audio recording.
6. Ask follow-up questions to clarify vague statements such as "the system must be fast", by asking what time is acceptable.
7. Summarise the main points back to the user to confirm that they were understood correctly.
8. Compile the notes soon after the interview, while details are fresh, so they can be analysed with those from other users.

1.1.1.3 User requirements analysis

User requirements analysis is the examination of the raw information collected, so that it becomes clear, consistent and ready to guide the application. Raw notes from interviews and questionnaires are often repetitive, vague or contradictory. Analysis turns them into organised requirements that a developer or installer can understand. Example: a clinic receptionist says "I need to find patients quickly" while the doctor asks for "complete patient history on one screen"; analysis converts these into a search function and a consolidated record view.

The analysis proceeds through these steps:

1. Collate all the information from interviews, questionnaires, observations and documents into one place.
2. Break the information into individual requirement statements, each stating one need only.
3. Classify each statement as functional (what the application does) or non-functional (how well it does it, including security, performance and usability).
4. Remove duplicates and resolve conflicts between users, by returning to the stakeholders concerned where necessary.
5. Clarify ambiguous statements and replace words such as "fast" or "user-friendly" with measurable conditions, for example "a report must display within five seconds".
6. Prioritise the requirements into those that are essential, important and desirable, so that limited time and budget are spent on the most valuable ones.
7. Check feasibility against the available computers, operating system, budget, skills and time.
8. Model the requirements where helpful, using simple use case descriptions or flow diagrams showing who does what with the application.

Example: classification of requirements for a school fee management application.

The analysed requirements then pass to the documentation and review stages covered later in this chapter.

Common problems in requirements identification

Even careful technicians meet difficulties when identifying requirements. Knowing them in advance helps to avoid them.

• Unclear or vague statements: Users describe needs in general terms, so the technician must ask for specific, measurable details.
• Conflicting needs: The finance office and the stores department may want different things from the same screen, and the conflict must be settled with the stakeholders.
• Unstated assumptions: Users often forget to mention tasks they do automatically, which is why observation and document analysis support interviews.
• Changing requirements: Users add new wishes as the work progresses, so changes must be agreed and controlled to avoid the project growing beyond its time and budget.
• Missing stakeholders: Leaving out a group, such as the ICT support staff who must maintain the application, leads to gaps discovered late.
• Limited user availability: Busy users may postpone meetings, so sessions should be scheduled early and kept short and focused.

Chapter Summary

This chapter explored the essential steps involved in assessing desktop application requirements, beginning with the identification of desktop applications and understanding their significance in various user contexts. It emphasized the importance of gathering user requirements through effective techniques and the subsequent analysis needed to translate these needs into actionable specifications. The documentation of desktop application requirements specifications was detailed, highlighting the necessity of thorough review processes to ensure accuracy and completeness. The chapter also examined various validation techniques to confirm that the documented user requirements align with actual user expectations and system capabilities. Finally, it outlined the preparation of a comprehensive system requirements specification report, which serves as a critical reference for developers and stakeholders throughout the application development lifecycle. This systematic approach ensures that desktop applications are designed to meet user needs effectively while minimizing errors and misunderstandings. Through these processes, the foundation for successful desktop application development is firmly established.