### Modelling:

### Tweets

- #freestuff The Blackwell Guide to Philosophy of Computing and Information sites.sas.upenn.edu/sites/default/… 3 days ago
- @vardi Best brain train game: Lisp. It improved my Chess playing. Not kidding. 1 week ago

# Tag Archives: Requirements

## 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

## 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

## Henry Ford and Business Analysts

“If I had asked people what they wanted, they would have said faster horses.” – Henry Ford –

Isn’t this a nice litte example to show what Business Analysts are good for? Continue reading

## Complexity Awareness is Cost Awareness

If “engineering is producing an artifact to cost”, then how can modelling contribute to it? Continue reading

## Complexity Aware Modelling II

Complexity aware people are able to recognize complexity, and regard it over things like size. How do they recognise? Mainly by modelling! Continue reading

Posted in Mathematics, Model Thinking
Tagged abstraction, analysis, Complexity, computational, computational thinking, model, Modelling, Requirements, State Machine, thinking
3 Comments