Another question deserves equal attention: “Were the requirements properly understood, defined and agreed upon?”
Software quality depends on requirements engineering, effective testing and informed risk decisions. These disciplines connect what people need with evidence of what a system delivers.
1.0 REQUIREMENTS ENGINEERING
Requirements engineering involves discovering, analysing, documenting, validating and managing requirements. It helps stakeholders agree on the problem, the intended outcome and the conditions a solution must satisfy.
Interviews, workshops, observation, existing documents and prototypes help uncover needs and resolve conflicting expectations. Appropriate documentation may combine written requirements, examples and models.
For example, a customer might request another approval screen. Investigation could reveal that the actual need is to prevent unauthorised transactions. Understanding the purpose helps the team evaluate suitable solutions.
Requirements must also be clear enough to assess. Consider:
"The application must be fast"
An illustrative alternative is:
“Under a workload of 1,000 concurrent users, at least 95% of account-balance requests shall display a result within three seconds.”
These figures are examples requiring agreement based on actual needs and technical conditions.
Requirements should address functionality, quality expectations, interfaces, constraints and failure conditions. For a payment application, this includes what happens when a connection drops after confirmation and how a customer establishes whether payment succeeded.
2.0 MANAGING PRIORITIES AND CHANGES
Requirements evolve as stakeholders learn and business conditions change. Effective management includes prioritisation, version control, change assessment and traceability across the project lifecycle. These practices apply to traditional and Agile approaches.
Increasing a payment limit, for instance, could affect approval rules, fraud controls, customer messages and existing tests. Treating it as a simple number change may overlook those consequences.
Traceability connects the original need to its requirements, implementation and tests, making affected work easier to identify.
3.0 TESTING AND EVIDENCE EXAMINING
Software testing evaluates software and related work products to identify defects, assess quality and support decisions. It includes reviews performed without executing software and tests that examine running software. Testing supports checking specified requirements and evaluating whether users’ needs are met.
A payment application may calculate charges correctly yet leave customers uncertain about interrupted transactions. Both technical correctness and practical suitability require attention.
Testing also differs from debugging: testing can expose a failure; debugging investigates its cause and implements a correction.
3.1 Test Selection
Useful techniques include examining input groups, boundaries, combinations of conditions and changes between system states. Exploratory testing uses learning and observation to guide investigation.
For a hypothetical RM5,000 transaction limit, examples include amounts below, at and above the limit, invalid entries, repeated submissions and interrupted connections.
Different testing activities answer different questions:
A refund calculation may work correctly by itself but fail when communicating with a payment provider. One successful demonstration cannot establish the quality of the entire system.
4.0 SETBACKS, LIMITATIONS AND DISADVANTAGES
Requirements engineering and testing require time, competent people, stakeholder participation and suitable resources. Excessive documentation can slow decisions, while inadequate documentation can leave critical assumptions unresolved.
Testing also has practical limits. Exhaustive testing is generally impossible, repeated checks can become less effective at finding new defects, and the absence of detected defects does not establish that users’ needs have been met.
The following are illustrative implementation problems and responses:
A distinction matters here: correcting a defect fixes the immediate problem; corrective action addresses its cause to reduce recurrence.
For example, repairing one incorrect calculation is a correction. Investigating an ambiguous calculation rule, improving its specification and checking related calculations addresses the wider cause.
5.0 RISK ASSESSMENT
Risk assessment is an explicit part of risk-based testing. Risks are identified and analysed, and the results guide testing priorities, scope and effort. Testing considers both product risks and project risks.
Product risks concern the delivered software for example, incorrect payments, exposed records or unacceptable response times. Project risks concern delivery conditions, such as unavailable skills, delayed environments or insufficient resources.
A practical assessment should establish what could go wrong, its likelihood and consequences, existing controls, further treatment and responsibility. It should also identify the evidence needed to evaluate the treatment and the remaining risk requiring a decision.
For an illustrative payment service:
These examples do not imply that every organisation needs the same controls. Assessment should reflect its systems, information and operating context.
6.0 INFORMATION SECURITY MANAGEMENT SYSTEM (ISMS) ISO/IEC 27001
Some parties asked me about how ISMS can help. An Information Security Management System (ISMS) provides an organisational framework for managing information security. ISO/IEC 27001:2022 establishes requirements for that system, including information security risk assessment and treatment. Its purpose includes preserving the confidentiality, integrity and availability of information.
An ISMS complements requirements engineering and testing. Security risks can inform requirements, those requirements can guide implementation and testing, and the results can support decisions about control effectiveness and remaining risk.
Its scope extends beyond software defects to the way information is handled through people, processes and technology.
For example, where assessment identifies a risk of unauthorised disclosure, the organisation might establish access requirements, implement appropriate controls and evaluate their operation. Responsibility must also cover how access is granted, reviewed and removed.
An ISMS does not replace broader software risk assessment or functional testing. Equally, passing functional tests does not establish that information security risks are adequately managed.
An organisation’s ISO/IEC 27001 certification and an individual’s professional qualification also serve different purposes. Neither guarantees that a particular application is secure or defect-free.
7.0 EVIDENCE, AUTOMATION AND RELEASE DECISIONS
Clear defect reports should identify the relevant version and environment, describe the steps taken, and distinguish expected from observed results.
Automation can accelerate suitable repeatable checks, but requires careful selection and maintenance. Its benefits depend on the quality of the checks performed.
For instance, confirming automatically that a payment page opens provides little evidence about payment accuracy or duplicate handling.
Test planning should establish scope, responsibilities, resources and completion criteria. Release decisions should consider the evidence available, unresolved defects, untested areas and remaining risks.
8.0 IREB, ISTQB AND MSTB
- IREB : the International Requirements Engineering Board - provides the Certified Professional for Requirements Engineering (CPRE) certification scheme, supporting structured knowledge in understanding, documenting, validating and managing requirements,
- ISTQB - the International Software Testing Qualifications Board - provides the Certified Tester qualification scheme, including the Certified Tester Foundation Level (CTFL), supporting knowledge of testing principles, techniques, management and tools.
In Malaysia, the Malaysian Software Testing Board (MSTB) supports professional development and conducts examinations under the ISTQB Certified Tester scheme as Malaysia’s ISTQB member board.
The value of professional qualifications depends on applying the knowledge with experience, communication and sound judgement.
9.0 APPLYING THE KNOWLEDGE
Organisations should involve relevant stakeholders early, define measurable expectations, assess risks, maintain traceability and evaluate changes before implementation.
When failures occur, they should correct the immediate problem, investigate its causes, implement proportionate corrective action and verify effectiveness. Findings should feed back into requirements, controls and future tests.
Reliable software depends on clear requirements, meaningful testing and accountable risk decisions throughout its operational life.
