Software for Managing Chaos

Posted on 2017 February 17 by modelpractice

The Cynefin framework enables us to talk about the complexity of knowledge and decision-making contexts in general. These are a few thoughts on applying Cynefin to software development, here in the so-called ‘Chaos’ context.

Managing ‘Chaos’

David Snowden and Mary Boone give the following example of managing chaos:

In January 1993, a gunman murdered seven people in a fast-food restaurant in Palatine, a suburb of Chicago. In his dual roles as an administrative executive and spokesperson for the police department, Deputy Chief Walter Gasior suddenly had to cope with several different situations at once. He had to deal with the grieving families and a frightened community, help direct the operations of an extremely busy police department, and take questions from the media, which inundated the town with reporters and fi lm crews. “There would literally be four people coming at me with logistics and media issues all at once,” he recalls. “And in the midst of all this, we still had a department that had to keep running on a routine basis.”

– D. J.Snowden, M. E. Boone, ‘A Leader’s Framework for Decision Making’, (Harvard Business Review, 2007) –

How could Deputy Chief Walter Gasior be supported? Perhaps, for example, by a press conference training? However, in general it is not very likely that a Deputy Chief of a Chicago suburb has to give important press conferences. So, a training beforehand would very likely never pay-off, and a just-in-time training would be unrealistic in this context.

Nevertheless, other things could prove useful in general as well as in particular. For example, a solid communication infrastructure, a spacious room for general purposes, that can be used for large press conferences in particular, etc.

Software for Managing ‘Chaos’

In terms of software this means that in situations like the above, general purpose software like e-mail, a decent word processor or spreadsheet are more appropriate than e.g., software that most efficiently supports a certain business process. But, how relevant are situations like the above to business software development? Isn’t it mainly about implementing well-structured business processes?

Example: BPM and ACM

For example, business process management (BPM) software consists primarily of elements to describe process activities, branch or join the flow, etc. This is very often sufficient for supporting 90% of the daily work of say, a back-office customer relationship process, where workers deal with customer requests, orders, static data, etc. Beyond these tasks, the remaining 10% of the daily work is more similar to Chief Gasior’s situation, where specific software support would be inefficient. This is where Adaptive Case Management (ACM) comes in. ACM is the complementary approach to BPM, i.e., it is NOT the more and more specific implementation of less and less often occurring processes. In contrast, it provides generic infrastructure for handling the remaining 10%, like communication and self management utilities.

Conclusion

In more general terms, when implementing information systems we go from functionality that is highly efficient to implement (large value, small effort), downwards till we reach a certain barrier of inefficiency. What we can do about the remaining functionality is to provide some general purpose functionality that supports generic user activities, like communication, or self-management. Notice, that this approach is significantly different from trying to implement the remaining specific functionality in a cheaper way.

So long
|=

PS
More on Cynefin here

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

A simple relational Model

Posted on 2016 October 1 by modelpractice

Let’s recapture some modelling basics:

Some Dia

What does a diagram like (Some Dia) say, in terms of logic?

Relations a b c dLets call the “->” relation R, obviously there are two elements where one is R-related to the other, we express this with two variables x and y, as shown in figure (a), by
(1) x R y

Next, we want to assume that the diagram shows all R-relationships of its contained elements, and thus we must exclude cases like (b) by
(2) ¬yRx ∧ ¬xRx ∧ ¬yRy

Moreover, we want to express that we have at least two elements by
(3) x ≠ y

Finally we assume the diagram to cover the whole model, i.e. there are no other elements, by
(4) ∀z x=z ∨ y=z

Thus, all together we get
(5) ∃x, y (1) ∧ (2) ∧ (3) ∧ (4)

(5) describes (some Dia) structurally, i.e. up to isomorphism. Additionally, we could give the elements a material meaning, say a certain Person (x) drives (R) a certain Car (y). (see Unambiguous Models)

So long
|=

PS
Describing single structures is usually not enough in modelling. What we want is to model sets of structures like every Person drives at least one car.

Posted in Foundations (rigour), Software_Engineering | Tagged , , , , , , , , , , , , , , | 1 Comment

Categories of semantic Models by Stachowiak

Posted on 2016 August 25 by modelpractice

In addition to former excerpts of Herbert Stachowiak’s 1973 book “Allgemeine Modelltheorie” (General Model Theory) here are some brief examples from the part on semiological (semological) classification of semantic models (chapter 2.3.2.3).

Semantic vs non-semantic Models

Prior to the subsequent ordering, Stachowiak distinguishes semantic from graphical/technical models. Semantic models are models of perception and thinking expressed by combinations of conventionalized signs. Examples of graphical/ technical models are viewable and graspable models like photographs, diagrams, function graphs; globes, crash test dummies, lab rats etc.

Moreover, following the linguistic separation of expressions of emotions (emotional semantic models) and thoughts (cognitive semantic models) by A. Noreen, Stachowiak deals only with the latter considering the former not to be part of the theory at all.

Kinds of semantic Models

These cognitive semantic models can now be separated into the following categories, here represented by examples:

  • allocative e.g. “Hello, you!”
  • optative e.g. “Have a nice trip!”, “Wouldn’t it be nice …”
  • imperative (order) e.g. “Move over!”
  • interrogative (question) e.g. “What’s you name?”
  • narrative (statement)
    • pre-scientific declarative e.g. “You can get it if you really want”
    • poetical e.g. “The nightingale, the organ of delight”, “Ready to drink wine, with a cherry blossom”
    • metaphysical as biomorphic (e.g. creation of the earth as egg of a prehistoric bird), technomorphic (e.g. canopy (sky), “pushing up the daisies”) or sociomorphic (e.g. willpower as police of the soul)
    • scientific
      • formal (formal science): e.g. expressions in language of first order logic and mathematical structures satisfying them. [see any textbook on mathematical logic]
      • empirical-theoretical (empirical science): structure of real world objects satisfying formal axioms [basically, extraction of formulas from (probably very very difficult) word problems]
      • operative and prospective: empirical models with objects changing (esp. over time) [see any imperative programming language]

Notice that Stachowiak has described these categories in much greater detail, and this is just a first brief overview. The examples are translated very liberally.

So long
|=

PS
The category of empirical-theoretical models, elementary to all kinds of engineering, is covered in more detail in Stachowiak on semantic Requirements Modelling

More on Stachowiak: Herbert Stachowiak postings

Posted in Epistemology, Herbert Stachowiak, Requirements | Tagged , , , , , , , , , , , , , , , , | Leave a comment

1 + x = 3 as a Query

Posted on 2016 April 4 by modelpractice

Just a brief recap of some software engineering fundamentals:

FOL Query

What is

(1) 1 + x = 3, with x ∈ N

from a software engineering perspective? Can it be considered a requirement? No, because it’s not a sentence and thus cannot be evaluated to true/ false.
Can it be considered a query? Yes, since it defines a result set on N, that is {(2)}.
This result set contains a single 1-ary tuple. Other cases are:
1 + x <= 3, {(1), (2)}
3 + x = 1, {}
1 + 2 = 3, {()}
3 + 2 = 1, {}

Here "()" is said to be a tuple with arity 0. For example, a 2-tuple (1, 2) can be defined by a set {{1}, {1, 2}}. Thus a 1-tuple (1) is {{1}}, and a 0-tuple () is {}. Thus, {()} and {} correspond to truth values true and false.

SQL Query

An SQL version would go like this: we define a table “+” (cols y, x, z) that contains all possible results (y+x=z) (what would make it actually infinite, but nerver mind), that we can query by

(2) select x from + where y = 1 and z = 3;

or alternatively for a table N of all naturals (col n) and a query language containing a + operator:

(3) select n from N where 1 + n = 3;

Boolean Query

Back to First Order Logic. Also the following equation can be considered a query of 0-ary tuples, a so called boolean query:

(4) ∃x 1 + x = 3

Notice, this could also be seen as a requirement, since it evaluates to true/ false. So could “1+2=3”. However, requirements are usually about sets not about single instances, i.e. Boy loves Girl, not Willy loves Kate. So, “1+2=3” would correspond more to a test case.

So long
|=

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

Unambiguous Requirements Models

Posted on 2016 March 28 by modelpractice

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).

Unambiguous is a core quality characteristic of software requirements specs (SRS). For example, IEEE 830 defines:

“An SRS is unambiguous if, and only if, every requirement stated therein has only one interpretation.”

Apart from linguistic confusions, like the escalator sign “Dogs must be carried” etc, even in a clearly stated requirement there can be numerous ways of interpretation.

Unambiguous in Higher Level Models

For example, in “Every Employee works for at least one Company” the unary predicate Employee(x) can be interpreted in various ways, and thus needs to be defined. Picturing this as part of an entity-level model (e.g. ER model) such a definition can be given by an informal (material) description in natural language, as for example: “A person that works part-time or full-time under a contract of employment.”. Since this kind of definition is the best one can do on the entity level, the model (pictured only on this level) can be practically considered unambiguous.

Unambiguous in Bottom Level Models

Subsequently, during the process of specification the predicate will usually be specified on a deeper level. In the above case attributes can be attached to the entity Employee, like “First name”, “Last name”, “Social security number” (SSN), etc, with a formally defined data type each, like char(7) for SSN, perhaps even with some further restrictions in a formal language like “^[A-Z]{3}[0-9]{4}$” (3 letters and 4 digits). Thus, by rigid typing on the bottom level the attribute be can structurally (up to isomorphism) defined.

Thus

Does that mean one can do away with all material descriptions of SSN like “A SSN is …”, the descriptive name “Social security number” itself (and replace it by “X”), and consequently with the entity-level description (“A person that …”) as well? In other words, would one consider a solely structural definition of SSN as unambiguous? Certainly not! Thus, unambiguity consists of a structural and material part. This connects it with, but also sets it apart from correctness, completeness, and consistency.

So long
|=

PS
The structural unambiguous specification on the bottom level is one important aspect that distinguishes software engineering from physical engineering disciplines.

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

Stachowiak on semantic Requirements Modelling

Posted on 2015 December 3 by modelpractice

In addition to former excerpts of Herbert Stachowiak’s 1973 book “Allgemeine Modelltheorie” (General Model Theory) here is a part on empirical-theoretical models wrt. empirical science (chapter 2.3.4.3 part 1 (formal semantic approach)).

Although I’m a software requirements analyst and not an empirical scientist, this describes pretty close the very basics of my kind of modelling.

First he recapitulates the formal (scientific) models (iow: basic maths) from an earlier chapter:

Starting point of the subsequently following considerations is the concept of the formal-scientific evaluation model in the closer sense, as introduced in the last chapter. It was said to be a (concrete or abstract) relational structure (M, a), that satisfies a given (sound) axiom system Σ. Latter consists of conditions in formal language, equipped with variables (argument places). The relational structure was a (n + 1)-tuple (M; Ru …, Rn), defined on a domain set M and n relations defined on M, satisfying the condition system Σ. With Σ also the theory induced by Σ (in addition of deduction rules) holds, since the satisfying Σ-evaluation entails a satisfying T(Σ) evaluation.

Such formal models can be applied to turn data (more or less well) into understanding of the world by abstraction:

These characterisations and in particular the differentiation between a theory and its possible satisfying evaluations are transferable to certain empirical scientific subject areas. Therefore, such a subject area has to be either available in a completely axiomatised way or its axiomatisation has to be progressed so far that linguistic description models and their associated allocation models can be sensibly distinguished. In other words, the conceptual apparatus of mathematical structural theory and the logical-semantic model theory can be applied to empirical scientific modelling in such cases. Here, the formal linguistic axiomatic constraint system Σ is abstracted from empirical data (with actually a broad subjective variety in the theory construction process) or it is at least constructed wrt. empirical data. This is due to the systematic summarising, explaining and prediction-enabling description of parts of the empirically accessible world it provides, especially the space-timewise-energetic entity and event world.

And here is how to do it, namely by interpreting the formal domain and relations by empirical entities and relationships:

The axiom system of an axiomatised empirical scientific theory is at best a system of logically fully formalised predicative statements, employing mathematical means of representation and descriptive, i.e. non-logical and non-mathematical, base terms. Let such an axiom system be interpreted by an empirical relational construct satisfying the axiom system of the associated empirical scientific theory T(Σ). Then this construct is said to be an evaluation model (in the closer sense) of Σ, or an (empirical) realisation of the axiom system Σ. The domain M of the construct consists of individuals of a part of the empirically accessible world of entities and events. Relations on M are empirically deducible respectively empirically verifiable properties of these entities as well as empirically deducible respectively empirically verifiable relationships amongst these entities.

For example, consider the axioms of classical particle mechanics:

(A1) P is a finite nonempty set.
(A2) T is an interval of real numbers.
(A3) Let p ∈ P and t ∈ T. Then s(p, t) is a twice t-differentiable vector-valued function.
…
Above, the set symbols P and T as well as the relation symbols s, m, and f are interpreted descriptive base terms, only implicitly defined by the formal axiomatic conditions. Their empirical interpretation takes place by the evaluation by terms of the used observation resp. measurement language. Let it be characterized on the level of the observation language as follows:
On (A1) P is a set of physical objects, e.g. the set of planet objects of the solar system, or more abstract, the set of centers of masses of the physical objects. The finiteness condition shell ensure the definability of the masses and the kinetic energy of the whole particle system.
On (A2) The elements of T represent periods of time. Concerning time measurement only, rational numbers had been sufficient. Reals are required to allow differentiation and integration wrt T.
On (A3) s = s (p, t) is a 2-ary location function, that describes the spacial changes of the physical objects (planets) p over time t. (A3) requires the existence of the 2nd derivative of s(p, t) wrt. t, s.t. (A7) can be satisfied.
…

In order to leap back to requirements modelling, as mentioned above, we take a look at the famous example by Jackson/ Zave 1995 of the requirements of a turnstile. They call an empirical realisation a designation set:

Each designation of the set gives a careful informal description by which certain phenomena may be recognised in the environment; it also gives a term by which the phenomena may be denoted in requirement and specification descriptions:
a) in event e a visitor pushes the barrier to its intermediate position ≈ Push(e)
b) in event e a visitor pushes the barrier fully home and so gains entry to the zoo ≈ Enter(e)
c) in event e a valid coin is inserted into the coin slot ≈ Coin(e)

In terms of Stachowiak: The unary relations Push(e), Enter(e), Coin(e) that are part of the formal requirements modelling language are defined by an empirical realisation in an informal observation language.

Thus, the theory of empirical-theoretical models by Stachowiak, provides a perfectly suitable foundation of semantic requirements modelling.

So long
|=

PS
1. Please excuse my rough and incomplete translation. Professional improvements welcome.
2. Ref: Michael Jackson, Pamela Zave (1995) Deriving specifications from Requirements: An Example
3. See also: Wilfrid Hodges (2009) Functional Modelling and mathematical Models: A semantic Analysis
4. More by Herbert Stachowiak: Fundamental Model Properties, Preterition and Abundance, …

Posted in Epistemology, Herbert Stachowiak, Requirements | Tagged , , , , , , , , , , , , , , , , | 1 Comment

Modeling for Understanding and/xor/etc Execution

Posted on 2015 July 30 by modelpractice

Inspired by the discussion on “Executable models are models or programs? (and does it matter?)” on Modeling Languages.

Say, we have a list of a few thousand requirements, each nicely and precisely formulated e.g. like this*:
(1) ∀p∈Person ∃c∈Car drives(p, c)

From a purely logical perspective, we would be fine, since such sentences can be processed by e.g. a model checker in order to check its logical qualities etc. However, from a human point of view, such a list of requirements is impossible to understand, e.g. to discuss with the requirements provider. Therefore, describing the requirements in a restricted, easy to visualize language, i.e. modeling, is very helpful. For example, think of the above sentence as part of an ER-diagram. Thus, modeling solely for the purpose of understanding can have a value.

An even larger value could be achieved if the same models were used for understanding and generating (other models or code) or even direct execution. This is the big promise of various tool vendors and language standards. Due to the nature of their interests (perhaps) they appear quite reluctant towards certain practical difficulties that come with such an approach.

ER Tree and Org ChartThe following example is inspired by a software project situation I recently encountered. Say, we develop a database application that holds the organization structures of companies. They are all assumed as hierarchical, i.e. tree-like. So, firstly, we model a general tree structure as an ER model, as in (er-tree). For example, every r must have leafs l in L or forks f in F. Every such f must have further forks or leafs, until all leafs are reached (the 1:… cardinality guarantees that it’s acyclic). Secondly, we enrich this solely structural model with some business specific properties, as in (er-org). For example, the team entity type inherits the structural (tree) properties from the board, but not its business properties, so we have to put the latter into a subclass of R, Board.

Now, say, you are the requirements provider from the business side, how would you think of an org chart? Certainly, not like this. In general, it is definitely no bad idea to establish a common language of discourse between analyst and requirements provider, even if it is new to the latter. This is always a trade-off between effort of getting used to it and benefit for communication and thinking. However, models like the above clearly push it too far.

Thus, we have two concerns in the application domain, precision of processing towards execution, as well as ease of understanding towards the requirements provider. In simple development approaches, we can perhaps use a simplified model for the customer, and maintain the actual model manually ‘behind the scenes’. However, a sophisticated approach – as executable modeling – should be able to handle a consistent mapping between the two, as it does between business and architectural concerns – at least if it wants to go the whole (ambitious) way, from biz to exe.

So long
|=

* If you don’t like the first order logic, you may think of it in natural language.

PS
Cloudifier

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

Splitting the Requirements Atom

Posted on 2015 July 11 by modelpractice

Requirements should exhibit, besides their logical properties (correct, complete, consistent, unambiguous), further important qualities. Atomicity is one of them.

When is a requirement said to be atomic? For example, can (1) a = 21 be an atomic requirement? Well, it could be split into (2) a ≥ 21 and a ≤ 21 or even worse into (3) a is odd, a is not a prime, a > 15 ∧ a < 25

Does that mean (1) not atomic? In requirements literature there are lots of statements like: “A requirement is not atomic, if it can be split into more than one requirement.”, but nothing rigorous (as it seems). Alternatively, can the atomicity concept from logic take us further? Logically, a requirement is a sentence, i.e. they evaluate to either true or false. In particular, an atomic sentence is a formula that doesn’t contain any logical symbols (and, or, not, quantifiers) and thus no variables. However, with requirements we want to express properties on the class level (Boy loves Girl), usually not for single instances (Abelard loves Heloise).

So, the atomicity concept from logic is not sufficient for requirements. Perhaps it can be expanded in a reasonable way? Worth to think about. Fortunately, the above example contains only a constant a, such that the atomicity concept of logic applies without modification.

This leaves us with 2 kinds of atomicity: 1. the logical one, s.t. a=21 can be called atomic. 2. the ‘atom splitting’ one that divides = into le, ge, s.t. a = 21 could not be called atomic.

How do these 2 interpretations relate to each other? Are they contradictory? Atomicity in 1 and 2 is compatible if = seen as an abstraction of ≥ and ≤. This means, they are statements on different abstraction levels, and since it makes lot of sense to picture requirements on different levels of abstraction separately it is perfectly reasonable to call a = 21 atomic. For example, Use Case Diagrams are a perfectly reasonable way to describe functional requirements, although they do not contain all details. Notice, that in addition, higher abstraction levels often use reduced language, that makes it impossible to express the details anyway, as in the = and Use Case Diagram example.

Thus, a = 21 can be called atomic, with respect to a certain abstraction level, and can also be split into details, like a ≥ 21 and a ≤ 21. Such details on rock bottom level are sometimes called atoms, too (e.g. by Robertson & Robertson).

So long
|=

PS Open Issue: can the logical atomicity be broadened to a useful concept in requirements?

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

What kind of Computer Science matters?

Posted on 2015 May 1 by modelpractice

Just came across Why Computer Science Matters? by Vugranam Sreedhar. He observes a decline in real computer scientists in favour of ‘commodity programmers’. Basically, I have to (sad but true) agree here, and would like to take a closer look at the roles involved, beyond well-trained computer scientists and commodity programmers only.

Let us recapitulate first*: In general, Information Systems (IS) perform 3 kinds of functions:

  • Memory function: maintain a representation of the state of the domain
  • Informative  function: provide information about the state of the domain
  • Active function: perform actions that change the state of the domain

Algorithms like a solution to the 8-queens problem provide complex kinds of active functionality.  Whereas a typical database application mainly provides memory and informative functionality.  Database applications (in all kinds and variations) are typical for business software. Developing them, can be broken down into structuring the overall problem, and implementing the resulting parts. Clearly, here the overall structuring is the much more ambitious task.  Thus, we get 3 kinds of people:

  • Software ‘Scientist’, solves complex algorithmic problems (focus on active functionality)
  • Software ‘Craftsman’, implements data access functionality and mid-complex business logic (focus on single memory and informative functionality)
  • Software ‘Engineer’, structures large data centric information systems (focus on overall memory and informative functionality)

Now, if we compare SwScientits and SwEngineers, although they are both jobs on an academic level, they are clearly of a different kind. Metaphorically speaking, SwScis solve a single small very complex word problem, whereas SwEngs take a very large text and break it down into many word problems of medium complexity.

So how did we get to focus so much on educating SwCraftsmen?** Was it perhaps that academia used to educate SwScientists only? Of course, if one asks industry, they say, they want ready to employ people, and they want them quick, and also a lot of them.*** And finally, did academia start to deliver SwCraftsmen, where actually SwEngineers would have been appropriate?

So long
|=

PS: Related stuff: Craftsman or Engineer?, Word Problems they don’t teach you in School.

* textbook: Antoni Olive (2007) Conceptual Modeling of Information Systems.
** or ‘commodity programmers’ (Vugranam Sreedhar)
*** best provided by vocational education?

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

Modeling & Abstraction at the very heart of Business Requirements Analysis

Posted on 2015 April 4 by modelpractice

In between Business Engineers and IT Architects, how does a Business Analyst (BA) for requirements fit in? From industrial practice we know a BA definitely makes a lot of sense. So, now we try to conceptualise this extra benefit. As we’ll see, it’s mainly based on abstraction (and thus modeling).

Business and Technology perspectives

Say, your company performs the business tasks described in figure (BizTasks):

Biz Tasks. CEO vs Janitor.

If you asked the CEO what her company is doing here, she would say sth like “We send greetings and invoices”, where ‘send’ means write and ship it, since a CEO doesn’t care if it is performed in 1, 2, or more steps, she solely has the business perspective.

If you asked the janitor, or whoever may be responsible for the tasks’ infrastructure, he would say sth like “We write ‘stuff’ and ship it”. The essential difference for him is, that he has to provide the writers with, say, a typewriter and a pen, and the mail office with, say, envelopes, stamps and a mail box nearby, in other words he has the technology perspective.

So, now that we have the biz and tech views, what is the requirements analyst’s view on this? And, moreover, is an analyst just a bit biz and a bit IT person, or does an analyst’s view makes sense on its own?

How Abstraction makes the Business Analyst

Although the janitor’s view is determined by technology, it doesn’t contain any technology itself, i.e. it consists of biz concepts (completely understandable to the CEO) only. Such a view is pretty exactly that of a BA in software requirements analysis: providing the implementors with relevant information about the business, in a technology free way.
Thus, does the BA have to be a technology specialist, in order to state relevant requirements?

Not if the BA can use an abstraction that hides the technology details. Notice, that abstraction is more than just reduction. It also has a ‘practical aspect’ (Stachowiak), in plain words, the abstraction has to make some ‘sense’ in it self. This is why a BA is not just a half-and-half biz and IT semi-specialist. The abstracting nature of the BA’s perspective makes software requirements analysis a self-contained discipline.

Information System as the Abstraction of Choice

As practice shows the concept of Information System (IS) is a ‘quite good’ abstraction for software requirements. For our purposes, by an IS we mean a system of information flows among participants. Moreover we assume an IS to be analytic, not designed, i.e. extracted from the world (by abstraction), not constructed into it. There are various definitions of IS* that are more or less all come down to data, functions, and interfaces.

In other words, analysis of software requirements means describing the world in terms of data, functions, and interfaces. No need of technology knowledge – in theory, of course. In practice some tech and biz knowledge is required as well, however the core competency – in which the BA differs – is the capability of abstracting (and thus modelling) the IS from the business. Also notice, that this is far more than just the ability to ‘think analytically’ often found in BA job ads.

So, remember: If you do not abstract, it is not analysis.

So long
|=

* textbook e.g.: Antoni Olive (2007) Conceptual Modeling of Information Systems.

PS
For now, of course the open issue left, is a closer look on how an IS fits the above purpose.

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