Download Courage Chibiya BSc Computer Science (Industry)

Transcript
ƒ Input and calculate single patient results
ƒ Import and calculate batch/multiple patient results
ƒ View and save results, preview and print reports and results
ƒ Access and view help
In addition, user controls must be implemented for any reusable graphical component to enable
efficient date entry and page navigation. The user interface must be adaptive to user locales and
display dates and numbers in correct formats for the user’s locale.
Software Interfaces - The application will interface with an existing software component that
encapsulates the rules for calculating marker results. The system is required to communicate with the
external software components by passing data in the correct format and data type.
4.6 Requirements Evaluation
The International Standards Organisation (ISO 9126, 1991) specifies 6 quality evaluation criteria for
software requirements. In theory, good requirements are feasible, clear, verifiable, complete,
consistent and testable. Essentially, requirements must be testable, this is important for validation
purposes. However some requirements are not testable by nature and for those requirements, other
evaluation criteria were used to evaluate those requirement is the Testing chapter.
A test plan was drawn up based on the functional requirements, the tests cases in the test plan will be
used to check the functionality of the final solution. Additionally, the test plan will serve to prove the
testability and verifiability of the system requirements. The test plan can be found in Appendix ETesting. If a requirement cannot be tested or is infeasible it will either be eliminated or scaled down to
a more attainable, specific and testable requirement. The requirements specification in Appendix F
assigns unique identifiers to every requirement to allow the design, code and test cases to be traced
back to the requirement (IEEE, 1998).
The use of the VORD technique to divide the application into separate view points was done with a
view of ensuring that the elicited requirements were consistent and compatible (not conflicting with
each other). In the case where independent viewpoints had identical or conflicting requirements, such
issues were discovered and rectified using a simple comparison of each viewpoint’s requirements to
those of other viewpoints. It is assumed that by following the guidelines explained here and
evaluating the system requirements as specified, the risk of implementing a system that does not
satisfy requirements will be mitigated.
22