Review: Robertson & Robertson: Mastering the Requirements Process

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.