requirements modelling

Overview

There is a variety of techniques for creating a model, depending on the situation you're in: interviewing a prospective user, modeling a business, re-engineering an existing system. There is a battery of techniques for progressing from the blank paper towards something meaningful: scenarios and storyboards, rich pictures, grammatical analysis.... Different analysts have their own favorites, and the various techniques have strengths in different areas of work. A strength of object oriented analysis is that we lay equal emphasis on dynamic and static views and their inter-relationship (as opposed to purely functional or entity-relational analysis).
All methods have it in common that you are making a gradual approach from a fuzzy to a clear picture. (One of the requirements of a modeling language is therefore that it should be good at representing whatever you know at any stage along this approach --- unlike a programming language, which only has to represent the end product of your labours.)
One of the benefits of modeling in a formal language is that you can know when you've got a consistent picture. How does this work? We use a technique that forms part of Catalysis.

Consistency

Static relationships are modeled with attributes and associations. By 'static relationships', we mean any that could be formulated as read-only queries: What is this Customer's account number? Who does this Employee report to? Who owns this bed?
Dynamic relationships are modeled with use-cases. By 'dynamic relationships', we mean those that entail a change in static relationships: opening a new account; transferring an Employee to a different division; selling a bed to a Customer.
 

Use-cases and associations

An important property of a use-case is what it achieves. For use-cases with a definite start and end, we can describe this with a goal or postcondition. (In Catalysis, the idea of use-case is extended to cover all procedures, tasks, events and operations, inside or outside the software, and whether they actually use the software or not: anything that happens is called an 'action.')

For example, selling something always achieves a tranfer of ownership from the vendor to the purchaser, together with a transfer of money in the opposite direction. This achievement is what makes it a sale rather than anything else; how it is achieved --- by what sequence of steps or with what intermediate agencies --- is less general: credit-card sales, mail-order sales, over-the-counter sales are all subtypes of the basic idea of sale.
We can draw instance diagrams ('snapshots') to illustrate the change of static relationships achieved by a use-case. The nature of the changes tells us what attributes or associations we need. The query, 'Who owns this thing?' is one that is altered by a sale; so we invent an 'owner' association and use it in an instance diagram --- in fact, a pair of diagrams, drawn one on top of the other, that show a sale happening.

If we want to include the effect of a sale on the customer's pocket -- well, let's have an attribute called 'pocket' that represents a quantity of money; and the vendor will have a till. Every sale entails a complementary change of their contents, and we can show those on the snapshots too.
Once we've drawn the snapshots, we can adjust our class diagram to make sure it includes the associations and attributes we've been using.

Notice how the description of the action tells us what objects and associations we need. In some modeling techniques, there is no particular relationship between the static and dynamic parts of the model: in this technique, the need for associations is dictated by the need to describe the actions. (It's analogous to the need for variables and types in a program: they're there to provide the information manipulated by the procedures.)

State-charts, associations and use-cases

We've seen how thinking about a use-case's achievements can tell us what objects and associations we need; but we can go the other way too, by asking "what can change this association or attribute?" A particularly effective technique is to draw statecharts. (In Catalysis, we use them descriptively, with no implication of any particular  implementation.) For example, we might ask our retailing clients about the lifecycle of things they sell. The answer might be that a Thing is ordered, eventually is received and goes into stock, will be displayed on the shelf, and can either be sold or lost. Each of the transitions in the statechart is interpreted as an action (use-case): we can document it in a diagram with an ellipse,  write its postcondition, and illustrate the effect with a before/after snapshot; and hence perhaps derive some more associations. 

The modeling cycle

This diagram sums up the analysis cycle we've described. When modeling, you may find objects and use-cases through a variety of techniques. There is no constraint on the order in which you find them; but whenever you find use-cases, you describe their effects and thereby find objects with their attributes and associations; and whenever you find objects, you ask what can happen to them (perhaps with the help of statecharts), and thereby find use-cases. Eventually, you come to a steady state in which you're discovering no new elements in the model; and at that point, you know your model is self-consistent. Along the way, you've had to ask a lot of questions about the domain (which might not have been asked in any method that demands less connection between the different views of the model)

.

Traceability

In object-oriented design philosophy, the aim is to build software as a simulation of the world in which it works. If the structure of the software mirrors the structure of the domain, then it's easy to trace changes in requirements (which are expressed in terms of the clients' domain) through to the necessary changes in the software.  Again, software requirements management should make explicit the refinements of any SRS (software requirement specification).

One thing you can do with your model, then, is to press the 'generate code' button on your modeling tool, and create a working prototype of the software.  But it isn't always possible to stick to this ideal in practice. The demands of performance, distribution, and separation of concerns make it necessary to apply a variety of patterns that entail rearrangements and extra classes. For that reason, it's worth keeping a domain model separate from your software. What we can do is to keep the overall structure equivalent to the domain model at a certain level, with independent local transformations where necessary. Documenting the model and the transformations, however curtly, helps maintainers understand the software and make changes that cohere with the original spirit of the design, and so helps prolong its maintainable life.

complete solutions for requirements engineering
(consultancy, courses, workshops, mentoring, seminars, development)