Completeness, robustness, and safety in real-time software requirements specification
ICSE '89 Proceedings of the 11th international conference on Software engineering
Handling Obstacles in Goal-Oriented Requirements Engineering
IEEE Transactions on Software Engineering - special section on current trends in exception handling—part II
Requirements by collaboration: workshops for defining needs
Requirements by collaboration: workshops for defining needs
Inconsistency Handling in Multiperspective Specifications
IEEE Transactions on Software Engineering
The Process of Inconsistency Management: A Framework for Understanding
DEXA '99 Proceedings of the 10th International Workshop on Database & Expert Systems Applications
HICSS '03 Proceedings of the 36th Annual Hawaii International Conference on System Sciences (HICSS'03) - Track1 - Volume 1
Integrating Formal and Informal Specification Techniques. Why? How?
WIFT '98 Proceedings of the Second IEEE Workshop on Industrial Strength Formal Specification Techniques
Software Requirements
Why software fails [software failure]
IEEE Spectrum
| Hi-index | 0.00 |
As software specifications for complex systems are practically never 100% complete and consistent, the recipient of the specification needs domain knowledge in order to decide which parts of the system are specified clearly and which parts are specified ambiguously and thus need inquiry to achieve a more detailed specification. In this paper we classify 16 different situations (states) of requirements communication and analyze, based on a state diagram, how a mature inquiry culture can help to initiate transitions from undesirable states into more desirable states. In a case study the inquiry practices of a very large software development organization are shown. Knowledge networks within the organization play an important role in building up a mature inquiry culture.