Before beginning to write a program – let alone test it – you’ve got to have a clear idea of what the program is going to be about, which needs it will fulfill and just how it’s going to do so. That’s where requirements engineering comes in.
Requirement engineering encompasses obtaining the right stakeholders to tell you what the program will be doing and where the constraints concerning time, budget and the such lie. Furthermore helping these stakeholders to denote their knowledge – this may be done in natural language and/or using UML diagrams such as use cases, activity diagrams, class diagrams etc. This can be an arduous task at times, as the know-how these professional posses has often become so “natural” to them, they find it hard to externalize the same. Here the requirement engineer as a plethora of techniques to assist him in aiding the stakeholders. Once this body of knowledge has been denoted in a systematic fashion understandable to others – usually in a documentation of some sort, it needs to be expertly managed, as it tends to grow and change till … well basically till the program is no longer used.

Article Sponsored By