Analyzing user requirements is a critical phase in software system development that ensures the final product aligns with the actual needs of its users. In Kenya’s diverse professional landscape, organizations ranging from county referral hospitals to retail businesses rely on clear and comprehensive requirements to avoid costly project failures and ensure user satisfaction. This chapter explores the different types of user requirements, providing a framework for capturing and understanding what stakeholders expect from software systems.
User requirements describe what a software system must do and the constraints under which it must operate. They form the foundation for system design, development, and validation. In Kenyan workplaces, capturing accurate requirements demands engaging multiple stakeholders such as end users, IT staff, and management across sectors like education, banking, and agriculture. These requirements fall into various categories including functional, non-functional, technical, budget and timeline, and legal and regulatory requisites. Understanding each type helps ensure the software system delivers value, complies with regulations, and fits within organizational constraints.
Functional requirements specify the essential actions and behaviors the software must perform to meet the user’s needs. They define what the system must do in terms of inputs, processes, and outputs, serving as the blueprint for developers and testers. For instance, at a county government office, a payroll system’s functional requirements would include calculating salaries, generating pay slips, and managing tax deductions accurately.
Functional requirements describe specific functions or features the software must provide to satisfy user tasks and objectives. They often include user interactions, data processing, and system responses. These requirements are usually expressed as “The system shall…” statements to clearly articulate expected behavior.
Functional requirements ensure the software addresses core business needs and user tasks. Without them, developers risk building irrelevant or incomplete features, leading to user dissatisfaction and wasted resources. For example, in a SACCO’s loan management system, missing a functional requirement for loan approval workflow could cause operational delays.
Common types of functional requirements include data input validation, report generation, user authentication, transaction processing, and notifications. A retail business’s inventory system might require real-time stock level updates and automatic reorder alerts as key functional needs.
Functional requirements are typically gathered through interviews, questionnaires, observation, and workshops involving users and stakeholders. In a university setting, engaging lecturers, administrators, and students helps clarify functional needs for a learning management system.
Non-functional requirements define the quality attributes and constraints that the system must satisfy, shaping how the system performs its functions. These include aspects such as usability, reliability, performance, and security. For example, a hospital’s patient record system must ensure data confidentiality and system availability to comply with healthcare standards.
Non-functional requirements specify system properties that do not directly relate to specific functions but impact user experience and system operation. They often govern system behavior under certain conditions, such as response time limits or fault tolerance.
Key categories include performance (speed, throughput), security (access control, encryption), usability (ease of use, accessibility), reliability (uptime, error rates), and maintainability (ease of updates). Each category influences design decisions and testing criteria.
In Kenya’s public sector, non-functional requirements like security and reliability are critical to protect sensitive data at institutions such as the Kenya Revenue Authority. Similarly, banks require high availability to support continuous transactions.
Non-functional needs are often captured through stakeholder interviews, benchmarking, and standards compliance. For instance, a hotel booking system may adhere to international usability standards to enhance customer satisfaction.
Technical requirements outline the technological environment and constraints within which the software must operate. They include hardware platforms, operating systems, network configurations, and integration with existing systems. For example, a cooperative society’s accounting software may be required to run on affordable local servers and integrate with mobile money platforms.
These requirements define system compatibility, scalability, and technology stacks. They ensure the software fits into the organization's current infrastructure and future IT plans.
Technical requirements specify minimum hardware specifications such as processor speed, memory, and storage. Software dependencies like database management systems or programming languages are also identified.
Systems often need to interface with other applications or databases. For example, a county hospital’s patient management system must integrate with the national health insurance database to verify coverage.
Technical requirements may include adherence to industry standards or organizational policies, such as using secure protocols or approved software licenses to comply with NEMA’s digital record-keeping policies.
Budget and timeline constraints define the financial resources and schedule within which the software project must be completed. These constraints impact scope, technology choices, and resource allocation. For example, a retail business launching an e-commerce platform must balance features against available capital and market deadlines.
Budget requirements involve estimating costs for development, licenses, hardware, and maintenance. Proper budgeting prevents project overruns and ensures sustainable operations, as seen in county government IT projects funded by devolved funds.
Timeline requirements specify project start and end dates, key deliverables, and review points. A university implementing a new student information system may schedule phased rollouts aligned with academic calendars.
Budget and timeline often require prioritizing features, leading to minimum viable product approaches or phased enhancements. For example, a SACCO may first develop core savings and loan modules before adding advanced analytics.
Identifying risks such as funding delays or resource unavailability helps in planning contingencies. A hotel chain deploying a new reservation system must consider seasonal peak periods when setting timelines.
Legal and regulatory requirements ensure the software complies with applicable laws, policies, and standards. In Kenya, these may include data protection laws, tax regulations, and sector-specific guidelines. For instance, a bank’s customer data system must comply with the Data Protection Act and Central Bank regulations.
Developers and analysts must identify relevant legislation such as the Kenya Data Protection Act, the Finance Act, or health sector regulations. This ensures software functionality aligns with legal obligations.
Systems handling personal data must implement controls for consent, data access, and breach notifications. For example, a county referral hospital’s patient management system must safeguard patient confidentiality in compliance with national health laws.
Different sectors have unique regulatory requirements. Agricultural cooperatives may need traceability features to comply with export standards, while educational institutions must adhere to KNEC data policies.
Legal requirements often mandate maintaining records of transactions and system changes. A SACCO’s loan system must generate audit logs for regulatory inspections by the Sacco Societies Regulatory Authority.
Create a free account to open more of this chapter.
Free: practical guides, quick cards, workplace scenarios and more.
Create a free accountThis chapter explored the various types of user requirements essential for effective software system development, including functional, non-functional, technical, budget and timeline, as well as legal and regulatory requirements. It emphasized the importance of accurately identifying the system application requirements by clarifying the purpose and goals of the system. The analysis phase was detailed through feasibility studies, prioritization of requirements, and thorough examination of functional, non-functional, design, and risk factors to ensure a comprehensive understanding of what the system must achieve. The process of documenting system application requirements specifications was also covered, highlighting the need for clear articulation of functional, non-functional, design, and technical requirements alongside assumptions, constraints, a glossary, and appendices. Finally, the chapter underscored the critical role of reviewing and revising these specifications to maintain accuracy and relevance throughout the software development lifecycle. This structured approach ensures that user needs are thoroughly captured and translated into actionable system requirements.