Something about Requirement Engineering

What is Requirement Engineering?

The primary issue that is scaled as the success of a software system is whether it is capable enough to meet all the requirements of its users, that is the satisfaction level of its users reflects its degree of success.

Requirement Engineering includes some processes regarding this fact. A requirement engineering process is a set of structured activities to derive, validate and maintain systems requirements document [1, 2]. As an engineering task generally defined as the creation of cost effective solutions to real-life problems by applying scientific knowledge, requirement engineering can also be described as the task to discovering development activities to a real-world problem, so that the appropriateness and cost effectiveness of the solution can be analyzed [2, 3, 4]. Generally, RE techniques are needed which support: Articulation of product concept, problem analysis, feasibility studies, modeling, documentation, automated support for the RE process and provides: standardized ways of describing, maintaining and assessing the quality of work products [1, 2].

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].

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, whereas 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 then becomes 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 detect 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; otherwise he’ll formalize the descriptions and show those to customers in the 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 that reside 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 possess: 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. Purpose of the requirement document
2. Scope of the product
3. Definitions, acronyms and abbreviations
4. References
5. Overview of the remainder of the document
2. General description
1. Product perspective
2. Product functions
3. User characteristics
4. General constraints
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

References

[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.

History

• 18^th March, 2006: Initial post