Complete thesis - Murdoch University

equirements analysis – the process of analysing requirements to resolve conflicts, determinethe bounds of the system and elaborate software requirements from systemrequirementssoftware requirements specification – the structure, quality and verification of the requirementsdocument(s) as a precondition to successful requirements handling. Documentquality assessment is seen as an important aspectrequirements validation – through the use of reviews, prototyping, model validation andacceptance testingrequirements management – through change management, requirements attributes andrequirements tracing.This breakdown is seen to coverthe areas discussed in most requirements engineering texts and standards, eitheridentically, or derived from these and other sources to reflect a consensus compatiblewith industry, the literature and standards, and mirrors the mature andstable concepts in Requirements Engineering.(Sawyer and Kotonya, 2000, p 21)The value of this document is two-fold:• an acknowledgement that the Knowledge Area of Requirements Engineering is notconstrained to software issues solely. A need to understand the context of the problem,in terms of technical, social/organisational and environmental issues is emphasised• the interdisciplinary nature of the activities undertaken throughout the RequirementsEngineering process is also acknowledged. Requirements Engineering is seen to be anactive, human activity, relying on inter-personal skills as well as technical competence.The SWEBOK is a comprehensive description of the knowledge needed for the practice of softwareengineering, but intentionally does not cover non-software engineering knowledge thata software engineer must know. Although one of the objectives was to provide a foundationfor curriculum development, the SWEBOK is intended to cover knowledge after four yearsof practice (Carrington, 2000). Additionally, while the document assigns Bloom levels to allsubtopics up to Analysis level, the milestone at which these competencies are to be attainedis beyond the scope of this study. Further, no rationale for the competency levels assignedis provided in the document (so, for example, while ‘Elicitation techniques’ are required at‘Application’ level (presumably after four years of experience), ‘Requirements tracing’ needonly be ‘Comprehended’, but ‘Requirements negotiation’ developed to ‘Analysis’ stage).70