Handling Obstacles in Goal-Oriented Requirements Engineering
IEEE Transactions on Software Engineering - special section on current trends in exception handling—part II
Toward Reference Models for Requirements Traceability
IEEE Transactions on Software Engineering
A Layered Architecture for Uniform Version Management
IEEE Transactions on Software Engineering
Recovering Traceability Links between Code and Documentation
IEEE Transactions on Software Engineering
An Operational Process for Goal-Driven Definition of Measures
IEEE Transactions on Software Engineering
Event-Based Traceability for Managing Evolutionary Change
IEEE Transactions on Software Engineering
Nonfunctional Requirements: From Elicitation to Conceptual Models
IEEE Transactions on Software Engineering
Scenario-Based Assessment of Nonfunctional Requirements
IEEE Transactions on Software Engineering
Requirement conflicts resolution: using requirement filtering and analysis
ICCSA'11 Proceedings of the 2011 international conference on Computational science and Its applications - Volume Part V
| Hi-index | 0.00 |
Software requirements express the requirements and constraints on a software product that contributes to the satisfaction of some 'need' in the real world. Ambiguity is a major problem in requirements specification. At its most basic, a requirement is a property that a system must exhibit in order for it to meet the system's motivating need. We ignore intentional ambiguity or the ambiguity that exists in early stages of requirements elicitation and focus on ambiguity that remains in a so-called final natural language requirements document. Ambiguity is a problem because the different readers of the requirements specification may understand different things. An essential property of all requirements is that they should be verifiable. In a typical project there will be a large number of requirements derived from different sources and expressed at different levels of detail. The existing Requirement Engineering Techniques and Methodologies are supporting to a specific set of activity like Elicitation or validation. Requirement Engineering develops a mutual understanding between customers and project teams about the product or system requirements. An agreed-upon and approved product requirement becomes the initial baseline for product design. Knowledge of ambiguous, inconsistent requirements to requirement engineer increases the capability to view the requirements from different perspectives. This paper discusses the requirement generation process and allied activities in it. It also focuses on methodologies, models and techniques for requirement engineering. As a part of applying complete requirement engineering, we claim that the crucial issues like architecture and design in system development can be effectively addressed.