Planning application deliverables is a critical phase in software system development that ensures all client and stakeholder expectations are clearly defined, agreed upon, and achievable. In Kenya’s diverse professional sectors such as healthcare, education, finance, and public administration, effective planning mitigates risks and streamlines project execution. This chapter focuses on the processes involved in reviewing system requirements, addressing legal considerations, resolving disputes, and managing contract termination to safeguard project success and stakeholder satisfaction.

3.1 System Requirement Review Process

The system requirement review process involves systematically examining the documented requirements for a software application to confirm that they are accurate, complete and feasible before design and coding begin. Defects found at this stage are far cheaper to correct than those found after release. For instance, a team building a hotel reservation system must confirm that the requirements for room availability, deposits and guest data handling are correct, consistent and lawful before development starts.

Steps in a requirements review:

1. Plan the review. The business analyst decides which part of the Software Requirements Specification (SRS) is to be reviewed, who will review it (client, developers, testers) and which criteria will be applied.
2. Circulate the documents. The SRS, a review checklist and any supporting models are sent to reviewers early enough for careful reading, for example three working days before the meeting.
3. Read individually. Each reviewer checks the requirements against the criteria and notes questions, ambiguities, conflicts and missing items.
4. Hold the review meeting. Reviewers and authors discuss the findings. The aim is to understand and record problems, not to redesign the system in the meeting.
5. Log the defects. Every issue is recorded with an identifier, the requirement affected, its severity and the person responsible for fixing it.
6. Revise the requirements. The author corrects the document and updates its version number and revision history.
7. Re-review and approve. Reviewers confirm that the corrections are adequate. The SRS is then approved as a baseline, which is the agreed starting point for design and later change control.

3.1.1 Review Criteria

The review criteria define the standards and benchmarks used to evaluate system requirements, ensuring they meet stakeholder expectations and technical feasibility. Clear criteria help a development team avoid costly rework by confirming that requirements are realistic, controlled and aligned with business goals. In this unit the main criteria are traceability, change management, version control, and testing and validation.

3.1.1.1 Traceability

Traceability is the ability to follow a requirement from its origin, through design and code, to the test that proves it works, and back again. It shows reviewers that every requirement has a purpose and that nothing has been forgotten or added without approval. For example, the requirement that a guest pays a deposit by mobile money can be traced to the hotel manager who requested it, to the payment module that implements it and to the test case that checks it.

Traceability is recorded in a requirements traceability matrix:

Types and uses of traceability:

• Forward traceability: follows each requirement forward to design, code and tests, so reviewers can confirm that every requirement is actually implemented and tested.
• Backward traceability: follows each design element or test back to a requirement, which exposes unrequested features, often called gold plating.
• Impact analysis: when a requirement changes, the matrix shows at once which design items, code modules and tests are affected.
• Coverage checking: a requirement with an empty test column signals that it has not been planned for verification.
• Stakeholder confidence: the client can see that each stated need has been captured and is being delivered.

3.1.1.2 Change Management

Change management is the controlled process of requesting, assessing, approving and recording changes to approved requirements. Without it, small unplanned additions accumulate until the schedule and budget are exceeded, a problem known as scope creep. For example, if a restaurant owner asks for a loyalty-points feature halfway through building an ordering app, the team must assess its effect on cost and time before agreeing to it.

Steps in a change control procedure:

1. Raise a change request. The stakeholder describes the change, the reason for it and its priority on a standard change request form.
2. Log the request. The analyst gives it a unique identifier and records it in the change register so that no request is lost.
3. Analyse the impact. The team estimates the effect on scope, cost, schedule, design, tests and other requirements, using the traceability matrix.
4. Evaluate the request. A change control board, usually the project manager, client representative and technical lead, reviews the impact and the business benefit.
5. Decide. The request is approved, rejected or deferred to a later release, and the decision and reason are recorded.
6. Update the documents. If approved, the SRS, traceability matrix, plans and test cases are revised and given a new version number.
7. Communicate the outcome. All affected stakeholders are told what was decided and how it changes their work.
8. Verify the implementation. After development, the change is tested and confirmed against the approved request before the request is closed.

3.1.1.3 Version Control

Version control is the practice of recording every change to a document or file so that earlier versions can be recovered, compared and identified. It prevents two reviewers from working on different copies of the SRS without knowing it. For example, if a developer builds a booking screen from version 1.2 of the SRS while the client approved version 1.4, the result will not match what was agreed.

Tools and mechanisms used for version control:

Good version control practices:

• Clear numbering: use a consistent scheme such as 0.1, 0.2 for drafts, 1.0 for the first approved baseline, 1.1 for minor corrections and 2.0 for major changes.
• Single source of truth: keep one master copy in a shared repository rather than several copies sent by email.
• Baselines: freeze approved versions so that later changes can only be made through change management.
• Attributable changes: record who made each change, when and why.
• Linked records: refer to the version of the SRS in test cases and design documents so that all items can be matched.

3.1.1.4 Testing and Validation

Verification asks whether the requirements are written correctly, while validation asks whether they describe what the users really need. A requirement that cannot be tested cannot be proved delivered, so reviewers check that each one is measurable. For example, "the system shall be fast" is not verifiable, whereas "the system shall display room availability within 3 seconds for 50 simultaneous users" can be checked.

Methods used to verify a requirement:

• Inspection: examining documents, code or the configuration to confirm that a requirement is met, such as checking that a screen shows the hotel's required fields.
• Demonstration: operating the system and observing the result, such as showing that a guest can cancel a booking.
• Analysis: using calculation or models to show a requirement is met, such as estimating that the database can hold three years of bookings.
• Test: running the system with prepared inputs and comparing actual with expected results, such as testing that a multi-factor login rejects a wrong one-time code.

Techniques used to validate requirements with users:

• Prototyping: a simple mock-up or working sample lets users react to the proposed screens before development.
• Walkthroughs: the analyst steps through scenarios with users to see whether the requirements support their real tasks.
• Acceptance test drafting: writing acceptance criteria with the client shows whether both sides understand each requirement in the same way.
• Stakeholder sign-off: representatives from each user group confirm in writing that their needs are correctly captured.
• Review checklists: reviewers apply a checklist covering completeness, consistency, clarity and feasibility.

Completeness check

Requirements must cover all necessary functions and constraints without omissions. For example, a retail shop's point-of-sale system should include inventory tracking, sales processing and reporting before it is considered complete.

Consistency check

Requirements should not conflict with one another or with organisational policies. A hotel's booking system cannot require both online-only reservations and in-person check-ins for the same booking if these contradict the hotel's operating rules.

Clarity and understandability check

Each requirement must be written in clear, unambiguous language so that every stakeholder, including non-technical users such as a front-desk clerk, can understand it. Vague words such as "user-friendly" or "quickly" should be replaced by measurable statements.

Feasibility check

Technical and resource constraints must be considered to ensure requirements can be achieved within the available budget and time. A small retail business's software should not demand hardware or connectivity that its staff do not have.

3.1.2 Legal Issues

Legal considerations in software requirements protect the client and the developer from liability and ensure compliance with national laws and international standards. A requirement that ignores the law may have to be removed or redesigned after delivery. For example, an online ordering platform that stores customers' phone numbers and addresses must be specified so that it handles this personal data lawfully.

3.1.2.1 Governing laws and international treaties

The governing law of a software contract is the legal system whose rules decide how the contract is interpreted and enforced. Contracts often name the governing law and the courts or arbitration seat that will handle disagreements. Where a system is built or used across borders, reviewers must also check which international agreements and foreign laws affect the requirements.

Kenyan laws that commonly affect software requirements:

• Data Protection Act, 2019: regulates the processing of personal data and places duties on data controllers and processors. Requirements for a system holding customer or patient records must include secure storage, access control, and respect for the rights of the people the data describes.
• Computer Misuse and Cybercrimes Act, 2018: deals with offences such as unauthorised access to computer systems. Security requirements such as authentication and audit logs support compliance.
• Copyright Act: protects software as a literary work and shapes questions of who owns code, documentation and designs.
• Law of contract: general rules on offer, acceptance, consideration and breach apply to development agreements.
• Sector regulations: certain sectors have specific rules that software must support. A tax-filing system, for example, must follow the latest tax laws and electronic filing standards.

International treaties and cross-border rules:

• Berne Convention: an international copyright treaty under which works created in one member country are protected in the others, which matters when code is developed or sold abroad.
• WIPO Copyright Treaty: extends copyright protection to computer programs and databases.
• TRIPS Agreement: sets minimum standards for intellectual property protection among members of the World Trade Organization.
• Cross-border data transfer: if a system sends personal data to servers or users in another country, the requirements must follow both Kenyan rules and any foreign data protection law that applies, such as the European Union's GDPR when data of people in the EU is handled.
• Choice of law clause: the contract states which country's law governs it, which is important when the developer and the client are in different countries.

3.1.2.2 End-User License Agreement

An End-User License Agreement (EULA) is a legal contract between the software owner and the person or organisation using the software. It does not transfer ownership of the software but grants a right to use it under stated conditions. For example, when a restaurant installs a purchased ordering application, the EULA states how many tills may use it and forbids copying or reselling it.

Typical clauses in a EULA:

• Grant of licence: states who may use the software, on how many devices or users, and for what purpose.
• Restrictions: prohibits copying, modifying, reverse engineering or sublicensing the software without permission.
• Ownership: confirms that intellectual property rights remain with the developer or licensor.
• Warranty disclaimer and limitation of liability: limits what the developer promises about faults and how much it can be asked to pay for losses.
• Data and privacy terms: explains what user data the software collects and how it is used.
• Termination: states when the licence ends, for example on breach, and what the user must do afterwards.
• Governing law: names the law and courts that apply to the agreement.

Ownership of software components:

Clarifying ownership prevents disputes. For example, a business commissioning custom software must specify whether the source code rights belong to the business or to the developer, or whether the business receives only a licence to use the finished product.

Licensing compliance for third-party components:

Third-party libraries and tools must be used within their licence terms to avoid infringement. A development team that uses open-source components in a commercial point-of-sale system must check that each licence permits commercial use and understand any conditions, such as acknowledging the author or releasing modified code.

Contractual obligations and requirement scope

Legal terms in a development contract influence the scope of the requirements and the deliverables. A client must make sure the contract clearly defines what is to be delivered, by when, to what standard, and what penalties apply for non-compliance. Requirements that are missing from the contract are difficult to demand later.

3.1.3 Dispute resolution

Disputes during requirements review and development can arise from misunderstandings, changing needs or contractual disagreements. Effective resolution mechanisms maintain project momentum and protect working relationships. For example, a hotel and its software vendor may disagree about whether a channel-manager feature was part of the agreed requirements.

Negotiation

Direct dialogue between the parties helps clarify issues and reach a mutually acceptable solution. For instance, a hotel and a software vendor may negotiate feature adjustments to fit the hotel's budget.

Mediation

A neutral third party facilitates communication and proposes compromises without imposing a decision. A client and a vendor who cannot agree on the acceptance criteria for a module may use a mediator to find a middle position and keep the project going.

Arbitration

A binding decision by an appointed arbitrator resolves the dispute outside the courts and is usually faster and more private. Parties often include an arbitration clause in the contract naming how the arbitrator will be chosen and which rules apply, so a small software firm and its client avoid lengthy litigation.

Litigation

As a last resort, disputes are resolved through the courts, which can be costly and time-consuming. A client might litigate if a serious breach of contract causes significant financial loss that cannot be settled by other means.

Documentation and communication

Maintaining thorough records of discussions, approved requirements, change requests and decisions reduces misunderstandings and supplies evidence if a dispute arises. Minutes of review meetings and signed baselines are especially useful.

3.1.4 Termination of Contracts

Contract termination is the formal ending of a software contract before or at completion, usually when objectives are no longer achievable or a party fails to meet its obligations. Clear termination provisions written into the agreement protect all stakeholders by stating when and how the contract may end.

Termination for convenience

Either party may end the contract without proving fault, usually after giving written notice. A retail business might terminate a software development contract because of a change in business strategy and pay only for the work done up to that date.

Termination for cause

Termination occurs because of a breach of contract. For example, a client may end the agreement if the developer repeatedly fails to deliver agreed functions, such as the payment module, after being given notice and a reasonable time to correct the failure.

Consequences of termination

Contracts typically specify obligations regarding payment for completed work, return of materials, deletion or return of data and continuing confidentiality, safeguarding the interests of both parties.

Transition assistance

Provisions for handover support ensure continuity. For example, when a business changes software provider, the outgoing developer may be required to transfer data, source code where agreed, and technical documentation to the new provider.

Legal and financial implications

Termination may trigger penalties, compensation or legal claims, so the contract must be carefully drafted and managed. Clauses on notice periods, payment for work in progress, and limits on liability should be reviewed before the agreement is signed.

Chapter Summary

This chapter focused on planning application deliverables by first detailing the system requirement review process, which involves assessing criteria such as traceability, change management, version control, and testing and validation. It also examined legal issues relevant to software projects, including governing laws, international treaties, end-user license agreements, dispute resolution mechanisms, and contract termination procedures. The creation of a comprehensive project work plan was emphasized, covering aspects like defining the project scope, identifying both internal and external key deliverables, setting milestones and timelines, and assigning duties and responsibilities. Additionally, the chapter addressed the need to establish quality criteria, recognize constraints and dependencies, manage resource sharing, and plan effective communication strategies. Finally, the importance of a project development agreement was highlighted, including its essential contents, the role it plays in project success, and the formal sign-off process that confirms mutual understanding and commitment. Together, these components provide a structured approach to managing software system requirements and ensuring successful application delivery.