178
edits
Changes
no edit summary
This [[ Concept Phase |concept phase]] deals with coming up with the concept for the system. The design begins with understanding the need behind the design, understanding the set objectives and coming up with our expectations of the final product or prototype. The team would have to list down the requirements of the system and various subsystems. When doing so, an example of QA being followed in the requirement writing process would be to have all of the system’s requirements documented comprehensively. ID’s should be systematically assigned to these requirements so as to be able to trace the origin of a particular requirement, as well the entity on which it is being placed. The subsystems tasked with ensuring a given requirement is met also need to be explicitly defined in the requirement list in addition to having a precise definition of the requirement itself.
<br>
The possible methodologies to track and/or achieve the requirements should be also identified and documented. In case a [[ Concept Phase #Non-Conformance of Requirement |non-conformance]] meeting needs to occur, the reason why the requirement was not met needs to be documented exhaustively, as well as the final decisions and the outcome of the meet. In such a scenario, having systematic requirement IDs would help in tracking all of the inter-dependent requirements that are affected.
==Development Phase==
The [[ Development Phase |development phase]] deals with coming up with detailed concepts for realising the system.