Introduction
A good requirement states something that is necessary, verifiable, and attainable. Even if it is verifiable and attainable, and eloquently written, if it is not necessary, it is not a good requirement. To be verifiable, the requirement must state something that can be verified by examination, analysis, test, or demonstration. Statements that are subjective, or that contain subjective words, such as easy, are not verifiable. If a requirement is not attainable, there is little point in writing it. A good requirement should be clearly stated.
In software development and ERP implementation projects, a requirement represents business needs and, usually, it is a document which describes the characteristics, attributes, and quality of a functionality that needs design and development. At XPLUS, it is referred to as Requirement Implementation Concept (RIC), which typically describes the capabilities, behaviors, and information a solution will require.
Since a requirement reflects the elements of a developed function, it is also crucial in the verification process, because all tests designed for a function should be mapped against its requirements and specifications. Requirement documentation ought to be maintained according to all changes made during the lifecycle of a project. This means each requirement change must be reflected in a system function or feature accordingly. The same goes for any related test cases. The source of any requirements towards the system are: business analysis, process analysis as per American Productivity & Quality Center (APQC) standard or business process charts, Conference Room Pilot (CRP) methodology and such like requirement analysis tools.
Business requirement analysis for a validation report
A consultant and a QA Engineer, possibly with the assistance of a technical architect, in the RP Modification phase need to check if the requirements are:
1. Unambiguous
There can be only one way to interpret the requirement. Sometimes ambiguity is introduced by undefined acronyms:
- REQ1 FO is working as desired with warehouses.
What does FO mean? To fix this, you can mention the full name and provide an acronym in parentheses:
- REQ1 The Finance and Operations (FO) module operates with the given functionality of advanced warehouse management (the list of functions is provided in Appendix 1).
2. Testable
Testers must be able to verify whether the requirement has been implemented correctly. The test ends with either a pass or fail. To be testable, the requirements must be clear, precise, and unambiguous. Some words can make a requirement untestable:
A. adjectives such as:
- robust
- safe
- accurate
- effective
- efficient
- expandable
- flexible
- maintainable
- reliable
- user-friendly
- adequate
B. adverbs and adverbial phrases such as:
- quickly
- safely
- in a timely manner
C. nonspecific words or acronyms: etc., and/or, TBD
A well-written requirement is along the lines of this:
- REQ2 Up to 100 positions per page should be displayed, then the page should break and the next 100 results should be displayed on it.
In this requirement, all search criteria should be explicitly listed. The designer and developer cannot guess what the user means by “etc.”
3. Clear
Requirements should not contain unnecessary verbiage or information, but rather be stated clearly and simply:
- REQ3 The user can upload the data using the drag-and-drop method or the data can be uploaded by choosing a file in File Explorer and clicking the upload button.
This sentence may be replaced by a simpler one:
- REQ3 Data should be uploaded into the system by clicking the Upload button.
4. Correct
If a requirement contains facts, these facts should be true:
- REQ4 Value Added Tax should be at 23% rate for all items that are in the system.
VAT depends on the type of product/service, so setting a 23% value for all items is incorrect.
5. Consistent
- REQ5 Time should be presented in this format HH:MM
- REQ6 Time should be presented in this format HH:MM am/pm
Sometimes it is possible to resolve the conflict by analyzing the circumstances under which the requirement is generated. For example, if REQ5 was submitted by a French user and REQ6 by an American user, the preceding requirements may be rewritten as follows:
- REQ5 For users from Europe the time format should be HH:MM
- REQ6 For users from the US and UK the time format should be HH:MM am/pm
6. Complete
A requirement should be specified for all the conditions that can occur:
- REQ7 In case of system failure because of lack of data, the system should display a modal with appropriate information and move back to the data upload step.
- REQ8 In case of system failure because of wrong type of data, the system should display a modal with appropriate information and move back to the data upload step.
A good requirement example:
REQ7 The customer wants to create an invoice from an existing and known purchase order. The invoice must include the following details: invoice number, customer data such as: name, address, tax number, creation date and sale date. The invoice should be sent to the customer that matches the data in the purchase order as an .xml file.
Requirements Validation Report
All the applicable requirements must be specified within the final report, which should contain information in tabular format with all the passed and failed requirements, where failed means that requirement does not meet the above criteria. A requirement should not be in conflict with any other requirements or assumptions. Checking these criteria requires analyzing the whole requirement set.
If you want to learn more download the complete e-book – Testing as a part of successful upgrade to MS Dynamics 365 FSCM and see our webinar – How to organize, optimize and energize your MS Dynamics 365 FSCM testing and maintenance with automation?
