A Requirements Engineer is variously referred as a: Software Engineer; Researcher; Requirements Analyst; Systems Analyst; System Engineer; Systems Engineer for Business; Requirements Modeler. S/he contains skills as: Interviewing skill, group work skills, facilitation skills, negotiation skills, analytical skills, presentation skills and modeling skills [1, 3].
Figure: Requirement Engineering and Software Engineering
From the perspective of a software system development, two activities can be distinguished as requirement engineering and software engineering. Software Engineering can be defined as the activity involved in the whole life cycle of a software development process, where as Requirement Engineering is one central activity in that life cycle (See Figure 1). Requirement Engineering can be separated from the Software Engineering, as some questions and problems raised form the RE that can’t be tackled as Software Engineering [6, 7, 8]. Requirement Engineering starts with ‘goals’ expressed form the customers and through some processes it produces the “Requirements Specification” [4, 6]. This specification is then become the starting point of the Software Engineering process to build the future system.
Tasks Involved in Requirement Engineering
Generally Requirement Engineering involves the following tasks:
Requirements Elicitation:
Requirements Elicitation is regarded as the first step in RE process. It invokes the task to find out the requirements. Several elicitation techniques are used by the Requirement Engineers, which are implemented depending on the time and resources available to him. Techniques that are involved in this step may be traditional (survey, interview, analysis of existing document etc), group elicitation, prototyping, model-driven or cognitive techniques [3, 4].
The goals to elicit requirements are to identify system boundaries, stakeholders (including paying customers, users and developers), high-level goals (such as business goals) to lower-level goals (such as technical goals) etc. [3]. As a matter of fact, eliciting goals is concentrated on the problem domain and stakeholder needs.
Modeling:
After the task of requirements elicitation, the analyst will build the model that represents the problem domain. Modeling the requirements makes easy to analyze them. Analysis techniques, generally used here, are requirement animation, automated reasoning (e.g., analogical and case based reasoning, knowledge based critiquing), consistency checking (e.g., model checking) etc. [3, 4].
Basically, the analyst studies the models he has built to detecting problems (i.e. inconsistency) or the problem to integrate new models with the rest of the requirements. [6].
Validation:
Now, if the analyst finds any problem, he has to communicate with the customer again considering this issue; other wise he’ll formalize the descriptions and show those to customers in proper way [1, 6].
IEEE/ANSI 830-1993 Standard for Requirement Documents
In case of Requirement Engineering, the Requirements Documents is one of the most important facts, to be concentrated. This contains a specification about what a computer system need to do, rather how it will be implemented [1]. Specifications those resides in a good requirement document, are unambiguous, complete, consistent, modifiable, verifiable, traceable and usable. Models which are to be used as a basis for the specification should posses: A high level abstraction, human readability, precision, completeness and mappability to later phases [1, 2, 4].
IEEE/ANSI 830-1993 standard (IEEE, 1993) suggests the structure for requirements documents, which is given below [2, 5].
1. Introduction
1.1 Purpose of the requirement document
1.2 Scope of the product
1.3 Definitions, acronyms and abbreviations
1.4 References
1.5 Overview of the remainder of the document.
2. General description
2.1 product perspective
2.2 product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies.
3. Specific requirement
Covering functional, non-functional and interface requirements. These should document external interfaces, functionality, performance requirements, logical database requirements, design constraints, system attributes and quality characteristics.
4. Appendices.
5. Index.
Reference
[1.] Linda A. Macaulay, Requirements Engineering, Spinger-Verlag, 1996.
[2.] R. H. Thayer, M. Dorfman, Software Requirement Engineering, 2nd edition, IEEE Computer Society Press, 1997.
[3.] Nuseibeh, B., Easterbrook, S., Requirements engineering: a roadmap, Proc. Conf. On The Future of Software Engineering, Limerick, Ireland, 2000, pp. 35-41.
[4.] P. Loucopoulos, V. Karakostas, System Requirement Engineering, McGraw-Hill, 1995.
[5.] IEEE Std 830-1993, Recommended Practice for Software Requirements Specifications, Software Engineering Standards Committee of the IEEE Computer Society, New York, 1993.
[6.] Yih-Chang Chen, Empirical Modeling for Participative Business Process Reengineering, the E-University of Warwick, 2001.
[7.] Jacobson, Ivar, et al., Object-oriented Software Engineering—A Use Case Driven Approach, Addison-Wesley, 1992.
[8.] Armour, F.J., Kaisler, S.H., Enterprise Architecture: Agile Transition and Implementation, IT Pro, November/December 2001.