-
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: Requirements
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
Separation of Analysis & Design wrt. Abstraction
Summing up separation of concerns of analysis and design wrt. abstraction, inspired by: Turner (2018) Computational Artifacts. Continue reading
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
The Killer Application of Software Modelling
From my experience as a business analyst (BA) I would say: checking or transforming models is interesting and important, but the real killer application of a model in software development is (simply) talking about it. Continue reading
Posted in Requirements, Software_Engineering
Tagged Business Analyst, customer collaboration, IIBA, IREB, managing complexity, model, Modelling, Requirements, Requirements Analysis, Requirements Engineering, Requirements Modeling, software development, software modelling, software requirements
1 Comment
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
Modeling for Understanding and/xor/etc Execution
Executable models have a great potential for achieving real separation of concerns. However, some practical modeling aspects on the business side deserve closer attention. Continue reading
Splitting the Requirements Atom
Atomicity is considered an important property of requirements. However, if we take a deeper look, we see the concept of atomicity lacks in rigour. Is e.g. the atomicity concept of Logic suitable here? Continue reading
Modeling & Abstraction at the very heart of Business Requirements Analysis
From industrial practice we know a BA definitely adds a lot of value to an IT project. So, now we try to conceptualise this in contrast to the Biz Engineer’s and IT Architect’s role. As we’ll see, a BA’s special benefit is mainly based on abstraction (and thus modeling). Continue reading
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
modelpractice 