Quality Assurance Requirements
Software projects have the unenviable reputation as being the most likely to disappoint expectations due to failures resulting from errors. Experience has shown that the requirements phases are the source of both the most and the most expensive of these errors. For high quality software it is vital to ensure that requirements have been identified correctly and fully.
The requirements activity splits into three main stages: requirements definition, requirements specification (or functional specification) and software requirements specification. The requirements definition should be produced by the customer and is a description of what the system should do. The requirements specification is produced by the supplier and is a more technical and detailed interpretation of what the system will be able to do. The requirements specification should be based on what is feasible and while the responsibility lies with the supplier it must be developed in co-operation with the client. The software requirements specification is again the responsibility of the supplier and should be more detailed than the requirements specification. All these documents should be based on what the system is supposed to do, not how it should do it. Agreed requirements specifications form a natural commercial interface between the client and supplier, but this creates financial risks to both parties prior to finalising commercial arrangements.
The important principle of requirements is that all requirements should be testable. This is straightforward for the main functions of the system but care needs to be taken with 'goals' or the '_ilities' such as maintainability, usability, reliability, extensibility, and testability These goals must be converted to testable requirements. For example maintainability needs to be converted to specific requirements on documentation and coding. There are many tools and techniques such as SADTA box and arrow diagram based method. While SADT is a trademarked and copyrighted by Softech Inc. the term SADT is often used for any box and arrow method using complementary data flow and functional viewpoints. The structured element is often introduced by ensuring that individual diagrams have no more than six boxes so that a hierarchical structure is enforced. SADT diagrams are easily understood by non-specialists. SADT tends to lead to a functionally based design. and Use-CaseA requirements capture method that identifies the 'users' of the system and the actions (cases) that the system should support. The 'users' of the system are frequently human but may be external systems. Use Cases concentrates entirely on capturing high-level, user-centric requirements and leads naturally into object oriented design techniques., to help at the different levels of the requirements process. The bigger the project the more the use of these tools is justified.
As part of the suppliers quality assurance activities the software requirements specification should undergo a validation process. This validation should check the requirements for consistency, completeness and realism. In addition the validation should check that the requirements are verifiableThe process of ascertaining (by test and or analysis) that a development stage has been completed satisfactorily..
Optimal Solutions welcomes enquiries on Software Quality Assurance, and would be pleased to provide consultancy tailored to your requirements. You can get in touch by sending a message from our Contact Us page, or by calling us on the number below.