Tag Archives: IEEE 830

Unambiguous Requirements Models

We’ll see that the concept of ambiguity of (requirements in software engineering) models comprises structural as well as material aspects, on all model levels (top to bottom). Continue reading

Posted in Requirements, Software_Engineering | Tagged , , , , , , , , , , | 1 Comment

Models: Correct, Complete, Consistent, Unambiguous

How do you judge how ‘good’ or ‘bad’ a model is? I mean models like we use them in software requirements specification or business analysis. On this, one can find criteria in literature like BABOK, Wikipedia, IEEE, research papers, or textbooks. However, for some reason these criteria sets are quite different in each case. I’ve tried to get the things a little straighter, starting with the ‘big four’ quality characteristics of software requirements specifications … Continue reading

Posted in Mathematics, Requirements | Tagged , , , , , , , , , , , , , , , , , , , , , | 1 Comment

Making use of IEEE 830 for Requirements Engineering

IEEE 830 provides eight quite abstract characteristics for good requirements, like correctness, completeness, traceablity etc. Continue reading

Posted in Software_Engineering | Tagged , , , , , , , , , , , , , , | Leave a comment

Are your Requirements complete?

Completeness is one big issue in requirements engineering. Here’s how this can be approached by systematic analysis. To me this is already a basic application of modeling and its benefits. Continue reading

Posted in Epistemology, Software_Engineering | Tagged , , , , , , , , , , , | 3 Comments