Review: Robertson & Robertson: Mastering the Requirements Process

By: | Post date: October 30, 2006 | Comments: No Comments
Posted in categories: Information Technology
Tags:

In re: http://www.amazon.com/Mastering-Requirements-Process-Suzanne-Robertson/dp/0201360462

A nicely methodical textbook, with overview, step-by-step breakdowns, and some needed contextualisation. The authors are sympathetic to agile development, and tailor their advice to analysts going down that path; but they recognise the tension between agile development and explicit requirements, and insist that requirements come from the whiteboard, not the keyboard, even if you needn’t produce a form document of requirements at the end. (So agile projects do pen scenarios, because they need to understand the reqs; they just don’t turn those scenarios into formal functional requirements, because understanding needn’t mean writing up.) More generally, repeated emphasis on abstracting the requirements spec from particulars of implementation, and modelling enough of the business to discern how the product will fit into the ecology (although that’s closer to O’Connell et al.’s worldview).

The requirements specification has a very useful way of identifying application scope from your business analysis:

* A business event is a single external stimulus (from an adjacent system, be it actor or automated), which triggers a response: a finite sequence of activities within the work (the business). This response is a business use case; as much as possible, it is autonomous from the other business use cases in the system.

* A system carries out several use cases, just as a Service Usage Model has several columns.

* The analyst gets to choose the scope of the business use case: narrowly within a computer system, or preferably closer out to the actor. The more stuff going on is encapsulated by the business use case, and the blacker the box as far as the actor is concerned, the more flexibility in design is afforded.

* The *product* use case scenario is the stuff going on in the business use case that you choose to automate.

So a business use case is a single activity diagram, with a single trigger as input. Its implementation will involve products with interfaces: these products would be service expressions in e-Framework terms, or sequences thereof, as Rehak points out. They also involve wetware and piping binding the service expressions into a column of the Service Usage Model; that can and will be outside e-Framework scope. So a service expression specifies a module of working code; and working code (either a single module, or a concatenation thereof) is an implementation of a product, which carries out a subset of the activities specified as a use case within the business process — but do not necessarily exhaust it: the system still involves actors, after all.

The size of the product — how much of the business use case, the process, it incorporates — is a design decision, and would not be deterministic. The discovery of the entire business system, including the adjacent systems to interact with it, enables a well-informed decision on product scope. But the scope of the service expression is a judgement call:

“To make decisions about the product boundary for this business use case, we need to define the constraints. [These are physical and policy constraints which are going to be specific to the business.] We also need input from the stakeholders who understand the technical and business implications and the possibilities for the product boundary along with the business goals for the project.” (p. 151)

Note (and I was surprised to realise this, but shouldn’t have been) that the activities in the use case to be incorporated into the product need not be sequential. The example given is of an airport passenger check in. Use case (done as scenario):

1. Locate reservation in the system.
2. Identify passenger.
3. Check passport.
4. Attach frequent flyer points.

The product goes from 1 to 4; it does not do 2 and 3, which are the business of a different system, talking to different databases with different authorisation. So the choreography of services into a product is a matter of timing (1 > 2 > 3 > 4) and interface (2 -> output -> 3); but the identification of distinct services is only a matter of interfaces: when in the use case the product is going to get hold of the data doesn’t matter to what services go into the product. I know how to do 1 and 4; 2 and 3 are an external, adjacent system I will put myself on hold for.

So no neat mapping from business process map to services map. Well, that’s no surprise, but makes life more interesting.

The tale of φαῖο

By: | Post date: October 26, 2006 | Comments: 2 Comments
Posted in categories: Language
Tags:

In my capacity of working on the lemmatisation of Greek for the Thesaurus Linguae Graecae project, verbs are much more of a hassle than nouns, because Greek verbs just have more latitude to do idiosyncratic stuff than nouns. The running joke with Greek verbs, in fact, is that there is no such thing as a regular verb; even λύω, so favoured in textbooks as an exemplar (because its root ends in upsilon, one of the few consonants or vowels not to cause grief when it is juxtaposed to the tense suffixes), has variable length on that upsilon depending on the tense. However, the truly, insanely, every person is its own story verbs — i.e. the athematic irregulars: εἰμί, εἶμι, ἠμί, φημί — had already been covered by the lemmatiser I’ve been elaborating; and since they require a lot more deep Greek than I’m comfortable with, I’ve usually managed to steer clear of them. It doesn’t help that these verbs are so irregular, that the lemmatiser deals with them in a completely different way from other verbs: they’re basically treated not as stems + a class of suffixes, but each as their own set of suffixes, from scratch.

And so it was that a perfect storm of irregularities had me scratching my head for a full hour with a single verb in Moschus. Not a long verb, actually a rather short verb; which in Greek hurts you rather than helps you, because you can’t, like, buy a vowel to work out what’s going on. In fact, my problem was there were too many vowels. The verb was φαῖο, and it shows up in the following passage

αὐτὰρ ὃ μειλίχιον μυκήσατο· φαῖό κεν αὐλοῦ
Μυγδονίου γλυκὺν ἦχον ἀνηπύοντος ἀκούειν
(Moschus, Europa 97-98)

I have no idea what phaîo means. Neither does my lemmatiser. The thing doesn’t look like a verb; but it looks like an Ancient Greek noun even less. I look for dictionary entries sarting with φα- that might help me make sense of this; no such luck. I leaf through my Smyth and (paper) Kühner-Blass grammars — respectively the basic English and ludicrously detailed German grammar of Greek; no go. Now, in the cis-webic age, Google knows all, so I pop into the Project Gutenberg translation of Moschus to see if it would help; Moschus is writing bucolic Greek — meaning Doric or Aeolic mooshed with Epic, and damn me if I have any idea what the mooing is about. The Gutenberg edition of the bucolic poets is old and out of copyright enough to be unhelpful at times — Theocritus 30 is completely missing (and in the other Gutenberg Theocritus, the translator pretends it’s addressed to a girl); but the Moschus passage has made it, moo and all:

Then he lowed so gently, ye would think ye heard the Mygdonian flute uttering a dulcet sound.

Nice to know bestiality wasn’t as big a deal to the translator. OK, so φαῖο means “you think”. Nope, still not getting it. I spend half an hour, uninformed Modern Greek speaker that I am, trying to yoke it to φαίνομαι “seem”; but there’s no alchemy that’s going to make that nu completely disappear absent a sigma to knock it over. (Keep that sigma in mind, it ends up with a candlestick in the conservatory.)

In desperation, I ask TLG central for a clue; and TLG central sends me the variant readings of the verb in their edition. The variants in the manuscripts are φαῖε, φαίε, and φαίης. Now, I don’t know what φαίης means either, but the lemmatiser does: it’s the optative active 2nd sg of φημί, “say”; so “you would say”. “You would say” means pretty much “you would think”; the same happens in Modern Greek (λες και). Bell goes off in my head, I look at the verb table for φημί in my grammar, and I attain enlightenment.

Here’s the perfect storm:

  • First up, the optative is reasonably rare in Greek to begin with, and died early; so with my slapdash knowledge of Ancient Greek, it would be easy for me to have not clicked to it.
  • Second, we have in φαῖο a middle/passive optative, not an active like φαίης. The middle/passive ending for the 2nd sg should have been –iso; but proto-Greek did away with its sigmas between vowels, so all that was left was –io. Which doesn’t look like a verb ending I’d be familiar with, and for good reason: Middle Greek ended up putting such 2nd sg passive sigmas back in. (Ancient Greek has lou-omai “I am washed”, *lou-esai > *lou-eai > lou-eːi “you are washed”; Modern Greek has restored the forms to lun-ome, lun-ese.)
  • Normally Greek verbs are thematic: they have a vowel, an -e- or -o- depending on the person, between the verb stem and the personal inflection. This means that the optative passive ending is normally –oîo; and –oîo I had seen before enough to recognise. But φημί is one of those irregular athematic vowels — meaning it’s archaic enough not to have a thematic vowel. The –io goes straight onto the verb stem pʰa-. pʰa + io = φαῖο. Because I had not grokked the optative by being force-fed it at school, I wasn’t familiar enough with the ending to make the conection.
  • The killer was the change in Moschus. I had actually gone past the description of φημί in Kühner-Blass, who had a generous three or four pages about it, listing all its attested tenses. It turns out that standard, Attic Greek only used the verb for “say” in the active; having it in the middle voice is an other dialect thing, and since we have a lot more Attic than other dialects, we don’t have all that many middle voice φημί in our literary texts to begin with. Nonetheless, Kühner and Blass (dunno which one, though Kühner’s earlier solo edition is in Google Books) saw fit to include all known middle instances of φημί. They list the indicatives, the list the subjunctives, they list the infinitives, they list the imperatives.

    No optatives listed.

  • Which can only mean one thing. In the 19th century, the editors of Moschus had gone with the common, normal Attic form φαίης. Kühner-Blass is 19th century, and so is Liddell-Scott. When A.S.F. Gow did his new edition of Moschus in 1952, he looked at φαίης and φαῖο, and did what a philologist should: he went with lectio difficilior. (OK, I’ve got a normal boring Attic optative, and a weird unknown Doric optative. Maybe the scribe who wrote that manuscript thought he’d out-Doric Moschus, so he made φαῖο up. That might have happened, and Kühner-Blass is adamant that that kind of thing has happened with Herodotus. But it is rather likelier that the scribe took one look at Moschus’ φαῖο, had the same reaction I did, and plugged in the form of the verb he was much more familiar with.) In doing so, Gow brought back into the corpus a likely authentic Doric optative. But noone is bothering to revise the 19th century grammars, so the grammars won’t tell me that.
  • Moreover, the way irregular athematic verbs are handled in the lemmatiser, actives and middles are handled separately, as distinct classes of endings — whereas normal verbs lump all the possible classes of endings together that would attach to a given tense stem. So it didn’t guess at the middle version of the verb, whereas normally it would.

So that’s the story of φαῖο. The lemmatiser now knows what the verb means; alas, it’s the only instance of a middle optative of φημί in the corpus, but every verb counts (especially when it’s in my performance index testbed). Not that I was happy to have been running around for an hour trying to work out a verb I should have grokked immediately. But that’s how pioneers work, I guess.

Review: O’Connell, Pyke & Whitehead. Mastering your Organization’s Processes.

By: | Post date: October 26, 2006 | Comments: No Comments
Posted in categories: Information Technology
Tags:

In re: http://www.cambridge.org/0521839750

This book was looking at Business Process Management (with Capital Letters, since it’s a distinct methodology), from a managerial rather than an IT perspective. Though it very occasionally got bogged down in detail of tactical approaches, overall it was a delight to read: judiciously cynical of everyone (especially IT, but also management fads and office politics), with dollops of Very British Wit, a dash of donnish humour, and quite practical about the constraints under which you could end up deploying Business Process Mgt.

It turns out I was mistaken about what this was about: the Management of Business Processes presupposes their analysis, but there wasn’t much about the analysis in there — appropriately so: 1, analysis is what IT does, not management, and 2, with BPM software, you end up doing a lot of the orchestrating of workflow and process components from your desktop yourself. One of the sidepoints for me of the book was making me realise the power of integration — having absolutely eveything supporting your business processes talking to each other, and being able to reconfigure your processes in a hurry. This was really more big picture stuff than immediately useful, but it gives handy context — including some quite useful lists of what to look for in management solutions, and it can inform the questions of how you interrogate an organisation’s culture.

Did I mention how delightfully cynical it was? Actually, it reminded me of why I hated the 2nd edition of the Camel Book, and liked the 3rd. The 2nd was Larry Wall being wacky and petulant (“Perl is the way is it coz I said so, and aren’t I cute”), and I couldn’t stand reading it. The 3rd edition brought in a coauthor who actually ended up apologising for Perl’s idiosyncracies through the book — “this looks bizarre, but there is a reason why you might choose to do things that way”. That was the edition I was able to read, and it was for a similar reason that I liked this one: I wasn’t preached at or evangelised to, but addressed with some respect as a reader mature enough to make my own decisions. And the authors did the right thing by repeating themselves every few chapters and recapping: they are writing for people with short attention spans (they apologise at the start of the book for inadvertently insulting people’s intelligence), and that honestly makes for a much more readable book in all. OK, ok, that’s my humanities bias again.

  • September 2024
    M T W T F S S
     1
    2345678
    9101112131415
    16171819202122
    23242526272829
    30  
  • Subscribe to Blog via Email

    Join 296 other subscribers