-
Join 35 other subscribers
Modelling:
- Applications (relevance) (50)
- Abstract Thinking (11)
- Software_Engineering (40)
- Foundations (rigour) (42)
- Epistemology (20)
- Mathematics (19)
- Series (42)
- Herbert Stachowiak (6)
- Model Thinking (8)
- Reflections on Abstractions (14)
- Requirements (16)
- Uncategorized (3)
- Applications (relevance) (50)
Twitter
Tweets by modelpractice
Tag Archives: specification
Computational Artefacts and Software Requirements
What if the intention of a technical artefact is not at all physical, but solely logical? Continue reading
Posted in Epistemology, Requirements
Tagged analysis, computational artefact, computer science, design, Elements of Software RequirementsEngineering, engineering, epistemology, mind-body problem, Peter Kroes, Raymond Turner, Requirements, Requirements Engineering, software, software engineering, specification, Technical Artefact
5 Comments
Technical Artefacts and Software Requirements
The epistemic concept of “Technical Artefact” may prove useful for studying requirements engineering. It brings together the notions of the world as physical objects with the world of intentionally acting agents. Continue reading
Posted in Epistemology, Requirements, Software_Engineering
Tagged computer science, Elements of Software RequirementsEngineering, engineering, epistemology, Herbert Simon, mind-body problem, Nicola Angius, Peter Kroes, Raymond Turner, Requirements, Requirements Engineering, software, software engineering, specification, Technical Artefact, Teleology
4 Comments
Reflections on Abstractions: Correctness and Completeness
An earlier post on quality properties of models is compared to basic concepts of mathematical logic, in strive for rigour. What does a formal system of mathematical logic has in common with a modelling situation as in requirements analysis? It depends … Continue reading
Posted in Mathematics, Reflections on Abstractions
Tagged abstraction, axiom, Complete, completeness, consistency, Consistent, Correct, correctness, formal system, incomplete, incorrect, incosistent, logic, model, model quality, model theory, Modelling, Requirements, resolution, software requirements specification, specification, Unambiguous, venn diagram
Leave a 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 abstraction, Complete, completeness, consistency, Consistent, Correct, correctness, IEEE 830, incomplete, incorrect, incosistent, logic, model, model quality, model theory, Modelling, quality criteria, Requirements, software requirements specification, specification, Unambiguous, venn diagram
1 Comment
Reflections on Abstractions: Cases vs Models
We describe by simple means of basic Finite Model Theory a very important principle in software engineering: modelling properties is more expressive than just collecting cases. This, for example, is the reason why test cases can be derived from specifications but not vice versa. Continue reading
Posted in Mathematics, Reflections on Abstractions
Tagged abstraction, abstraction awareness, axiomatizable, Case, Finite Model Theory, finite models, formal methods, intentional programming, model, model theory, modeling, modeling theory, refinement, reflections on abstractions, ROA, specification, Test
Leave a comment
Models and Cases
What are the next letters in this sequence?
O O T T F F S S E
Continue reading
Posted in Mathematics
Tagged 0123456789, abstraction, Bertrand Meyer, Case, emergence, model based, modeling, Principle, sequence, specification, supervenience, Test, test driven, what are the next
1 Comment
modelpractice 