Gathering user requirements is a critical phase in software system development that determines the success or failure of a project. It involves identifying and understanding the needs of all stakeholders who will interact with or be affected by the system. In Kenya’s diverse professional landscape, this process must incorporate input from various sectors such as healthcare, education, finance, and public administration to ensure the system is relevant, usable, and sustainable. Engaging stakeholders effectively lays the foundation for a system that delivers value and meets organizational goals.

1.1 Key project stakeholders

The requirements of key project stakeholders vary according to their roles, responsibilities and interests in the software system. Each group brings a different perspective that influences the system's functionality, usability and strategic alignment. In Kenyan organisations, recognising and balancing these diverse requirements promotes buy-in and reduces the risk of costly rework. In this unit, the key stakeholders are grouped into the project team, the system users and the organization management.

1.1.1 Project team

The project team is directly responsible for analysing, designing, developing, testing, implementing and maintaining the software system. Their requirements focus on clarity, feasibility and resource availability, so that each member can carry out assigned tasks effectively. When the requirements given to the team are vague, the same ambiguity is passed on into the code, the tests and the final product.

1.1.1.1 Team members & their roles

A typical project team includes people with different skills, and each role determines the kind of requirements that person needs and prioritises. For example, a developer needs detailed technical specifications, while a business analyst needs comprehensive user stories to translate business needs into functional designs. Clear role definitions prevent overlaps and gaps: in a team building a loan tracking application for a lending firm, one member owns the database design, another owns the user interface and a third owns testing, so accountability is never in doubt.

Common roles and what each one needs:

• Software developer: writes and integrates code, so needs precise functional specifications, data models and interface definitions.
• Business or systems analyst: gathers and documents requirements, so needs access to users, managers and existing process documents.
• Quality assurance tester: verifies the system against requirements, so needs requirements that are clear, measurable and testable.
• User interface designer: designs screens and navigation, so needs information about user tasks, skill levels and devices used.
• Database administrator: designs and maintains data storage, so needs data volumes, data relationships and retention rules.

Technical requirements from the team: the team requires precise technical specifications, including system architecture, programming languages, data models and integration protocols. These ensure the system is scalable, secure and maintainable. For instance, a team building an asset tracking system for a logistics company may specify mobile compatibility and integration with the existing database so that updates and reports are available in real time.

1.1.1.2 Project managers

The project manager plans, coordinates and controls the project so that it is delivered on time, within budget and to the agreed scope. Unlike other team members, the project manager needs information about the whole project: available budget, human resources, tools, deadlines and risks. Requirements gathered from stakeholders feed directly into the project plan, so poorly defined requirements lead to poor estimates.

Main responsibilities of the project manager:

• Planning and scheduling: breaks the work into tasks, sets milestones and assigns people to tasks.
• Budget control: tracks spending against the approved budget and reports variances to management.
• Risk management: identifies risks such as changing requirements or staff shortages and plans responses.
• Scope control: manages change requests so that new requirements do not silently enlarge the project.
• Stakeholder communication: keeps the team, users and management informed of progress and decisions.

Resource and time constraints: the project manager must know the real resources and realistic timelines before committing to a delivery date. A software team that allocates too little time for testing, for example, will often release a system with bugs, which shows why scheduling requirements must be well defined.

Communication and collaboration needs: effective communication channels and collaboration tools are essential so that activities are coordinated and issues are solved promptly. A project management platform for task tracking, shared documents and feedback, for example, improves transparency and reduces delays during the rollout of a stock control system.

1.1.2 System users

System users are the people who operate, maintain, build on or depend on the software once it exists. Their requirements emphasise ease of use, functionality and support, so that the system improves productivity and meets daily operational needs. Different users interact with the system in different ways, so each user group must be identified and consulted separately during requirements gathering.

1.1.2.1 Developers

Developers are users of the system's technical side: its source code, application programming interfaces (APIs), database structures and documentation. They extend, fix and integrate the system long after the first release, so their requirements concern maintainability and clarity rather than screens and reports. A developer asked to add a mobile payment feature to an existing sales system, for example, depends on documented interfaces and a working test environment.

Typical developer requirements:

• Clear specifications: a software requirements specification that states exactly what each feature must do.
• Coding standards: agreed naming, structure and commenting rules so that code written by different people is consistent.
• Version control: a repository that records changes and lets the team return to earlier versions.
• Test environment: a separate copy of the system where changes can be tried without affecting live data.
• Technical documentation: diagrams, data dictionaries and API descriptions that explain how components fit together.

1.1.2.2 System Analysts

System analysts act as the link between business users and the technical team. They study current processes, gather and document requirements, model the proposed system and check that the finished product meets the need. In a hotel reservation project, for instance, the analyst interviews reception staff, draws the booking process and converts it into requirements the developers can build.

Typical system analyst requirements:

• Access to stakeholders: time with users and managers to ask questions and confirm understanding.
• Existing documentation: current forms, reports, procedures and data samples that show how work is done today.
• Modelling tools: tools for drawing data flow diagrams, use case diagrams and entity relationship diagrams.
• Requirements traceability: a way to link each requirement to its design, code and test so nothing is lost or added unnoticed.
• Prototypes and feedback: early sample screens that users can review so misunderstandings are found before coding.

1.1.2.3 End-users

End-users are the people who use the system daily to perform their work, such as shop attendants, receptionists, clerks and customers using a self-service portal. They know the real business process, so their requirements shape the features and screens more than any other group. If their needs are ignored, the system may be technically correct yet unused.

Typical end-user requirements:

• Functional needs: features that support their tasks, such as data entry forms, reporting and workflow automation. A hotel receptionist, for example, needs quick room search, booking and billing in one flow.
• Usability: an intuitive interface that minimises training and suits different skill levels, with simple navigation and clear messages.
• Accessibility: support for inclusive use, such as readable text, a suitable layout for small phone screens and, where needed, more than one language.
• Support and training: training sessions, user manuals and a helpdesk so that users can adapt to the new system with little disruption.
• Security and privacy: protection of personal and business data through role-based access control and encrypted transactions, so users trust the system.

1.1.2.4 System Administrators

System administrators keep the system running after it goes live. They install and configure the software, create user accounts, assign access rights, monitor performance, apply updates and restore data when something fails. A system administrator at a distribution company, for example, must be able to add a new warehouse user and remove a former employee's access on the same day.

Typical system administrator requirements:

• Administration console: a screen or tool for managing users, roles and system settings without editing code.
• Backup and recovery: tested procedures and tools to back up data and restore it after failure.
• Logging and monitoring: audit logs and alerts that show errors, failed log-ins and unusual activity.
• Deployment and configuration guides: step-by-step documents for installing, upgrading and configuring the system.
• Security maintenance: a way to apply patches and updates with minimum downtime and to enforce password and access policies.

1.1.3 Organization management

Management's requirements focus on strategic alignment, compliance and return on investment. Management sponsors the project, approves the budget and decides whether the delivered system is accepted. Their input ensures the system supports organisational goals and regulatory frameworks, and the way the organisation is structured determines who gives that input and who has authority to approve it.

Strategic alignment and business objectives

Management requires the software to support key business goals such as efficiency, cost reduction and service improvement. A document management system that speeds up approval of purchase requests and reduces paperwork, for example, supports an organisation's digital transformation plan. Requirements that cannot be linked to a business objective should be questioned, since they add cost without adding value.

Compliance with policies and regulations

The system must comply with relevant laws and internal policies, including data protection and financial rules. For example, a customer records portal handling personal information must include features that respect the requirements of the Data Protection Act, 2019, such as controlled access and care in how personal data is stored and shared. Compliance requirements are usually non-negotiable and must be recorded early.

Budgetary and financial requirements

Management requires clear cost-benefit analyses, adherence to budget and transparent reporting on expenditure. For example, the management of a retail chain may require the inventory system to produce periodic financial reports so that stock levels can be monitored and losses reduced. Such requirements affect the choice of technology, the number of features and the delivery phases.

Performance monitoring and reporting

The system should give management dashboards and analytics to monitor performance and inform decisions. A loan portfolio system, for example, can generate real-time reports on disbursements and repayments, allowing managers to act before problems grow. These reporting requirements must be captured early because they determine which data the system must collect and store.

1.1.3.1 Organization structure

Organization structure is the way an organisation arranges its people, departments and reporting lines. For a requirements analyst it is a map of who makes decisions, who uses the system and who must approve changes. In a distribution company with sales, warehouse and finance departments, for example, each department head may state different, and sometimes conflicting, requirements for the same stock system.

Management is usually seen at three levels:

• Top management: sets strategy and approves the project, so needs summary information and measurable benefits.
• Middle management: supervises departments and turns strategy into plans, so needs reports that compare performance with targets.
• Operational level: carries out daily tasks, so needs tools for transactions and routine work.

Common structures compared:

Understanding the structure helps the analyst to identify all stakeholders, direct questions to the right person, find the person with authority to sign off requirements and plan how information will flow during the project.

Chapter Summary

This chapter explored the process of gathering user requirements for software systems by first identifying key project stakeholders and their distinct roles, including project team members, managers, developers, system analysts, end-users, system administrators, and the organization's management structure. Understanding these stakeholders is crucial for capturing comprehensive requirements. The chapter then examined various data collection tools essential for eliciting user needs, such as questionnaires, observations, experimentation, interviews, surveys, and case studies. Attention was given to the preparation of these tools, emphasizing the design of effective questionnaires, observation checklists, and interview questions to ensure accurate data collection. Finally, the chapter detailed the practical application of these methods in collecting user requirements data, highlighting how each technique contributes uniquely to understanding user expectations and system functionality. This holistic approach ensures that software development aligns with stakeholder needs and organizational objectives.