5.2 Inter-System Interaction Requirement Pattern


5.2 Inter-System Interaction Requirement Pattern

Basic Details

Related patterns:

Inter-system interface

Anticipated frequency:

Between zero and five requirements per inter-system interface

Pattern classifications:

None

Applicability

Use the inter-system interaction requirement pattern to specify a particular type of interaction across an inter-system interface.

Discussion

A typical interface involves a range of different types of interactions. A credit card payment service might exist primarily to enable retailers to debit a cardholder, but its interface will do various other things, such as reverse a transaction and check a card's credit limit. These are business-related functions, but the interface might also possess a number of more technical and supporting interactions: initiating a connection (and shutting it down); requesting resend of a previous message; notifying status; and so on. An interaction type, for the purposes of this requirement pattern, means the exchange of a particular type of information-which could involve messages in both directions. For example, a request and corresponding response count as an interaction.

Whether we want our requirements to address specific types of interactions depends very much on who owns the interface. There are four distinct situations in which we might find ourselves, and they have a direct bearing on our reasons for wanting to specify individual types of interactions, which in turn affect how much we should say:

  • Situation 1: We own the interface. It's our responsibility to make the interface complete, so use the requirements to prevent something from being forgotten. You don't have to scratch your head trying to think of all the secondary interactions the interface needs; certain capabilities can be stated in very general terms.

  • Situation 2: We don't own the interface but can influence its design. Use the requirements to identify and describe features we'd like to see in the interface. Treat the interface owners as the primary audience for these requirements, so aim to make a strong case for the inclusion of each one.

    Beware that each of these requirements is outside our control, so until the interface owner accepts it, we don't know that the interface will satisfy it.

  • Situation 3: We don't own the interface and cannot influence its design, but know what it looks like. Rather than force all readers of the requirements specification to refer to the interface specification to understand what it involves, it can be useful to sum up the individual interactions in requirements. Our requirements can capture the essence of the interface-to make effort estimation easier, for example. The earlier we get a feel for the difficulty of implementing this interface, the better.

    Alternatively, you can write an informal summary of the interface rather than formal requirements. (You still must include it within the requirements specification, though.) This gives you the opportunity to include subjective judgments (such as on the quality of its documentation, its overall complexity, and so on). You could ask a developer to study the interface and write a summary.

  • Situation 4: We don't own the interface, cannot influence its design, and don't know what it looks like. This is a risky situation to be in, but it happens. We're obliged to commit to building an interface without knowing what it involves-how extensive or tricky it will be. Flag this as an area of concern, and do all you can to obtain the necessary information as quickly as possible. We won't be able to write interaction type requirements until we know what the interface looks like.

Content

An inter-system interaction requirement needs to contain the following:

  1. Interaction type name This allows us to refer to it.

  2. Interface name and ID The interface over which the interaction occurs must be clear; the requirement's context (for example, following the interface's main requirement) is not enough. When referring to an interface, mention its interface ID to prevent misunderstanding.

  3. Interaction purpose Describe what this interaction is for. Make clear who initiates it.

  4. The information to pass This needn't be comprehensive. (Indeed, sometimes there's no need to say anything at all.) Concentrate on the important information. If the interaction involves flows of information in both directions, you can spell out what each one contains-but if the requirement grows too large (perhaps over half a page), split each flow into a separate requirement.

Template(s)

Open table as spreadsheet

Summary

Definition

«Interaction summary»

The «Interface name» interface («Interface ID») shall «Interaction purpose description» [that passes at least the following information: «Information to pass»].

Example(s)

Here are a couple of example inter-system interaction type requirements for interfaces we own:

Open table as spreadsheet

Summary

Definition

Raise alarm with alarm monitor

The alarm monitor interface (i6) shall allow the system to raise an alarm (that is, to pass an alarm message and cause all appropriate people to be notified). A raise alarm request shall include at least the following information:

  • Message ID

  • Message text

  • Time of occurrence

  • Alarm raised by (person or process name)

The alarm monitor shall respond with an acknowledgment (or an error response indicating that it has been unable to raise the alarm).

Warehouse interface status

The interface between the system and the warehouse (i2) shall provide the ability to verify the operational status of both the interface and the warehouse system itself.

Extra Requirements

None

Considerations for Development

Refer to the inter-system interface requirement pattern earlier in this chapter.

Considerations for Testing

Refer to the inter-system interface requirement pattern for the big picture of testing an interface as a whole.

An inter-system interaction requirement specifies only what the interaction must achieve, its goal. The implementation might turn out to be more complex. For example, a requirement might imply there will be one request and one response, whereas in practice, it takes two of each. Therefore, testing an interaction requirement must be concerned with only whether the goal is achieved, not the intricacies of the implementation. Additional testing should be done to verify that the physical interactions work properly. Data flow diagrams can be useful in devising tests for the physical interactions but will be less so for the logical interactions.

Formulate both valid cases and invalid (erroneous) cases. In the first case, identify valid but unexpected cases. Does the interface deal properly with valid interactions that won't happen every day but can come along at any time? It's never possible to test every eventuality, but try to cover as representative a spread of situations as possible.




Microsoft Press - Software Requirement Patterns
Software Requirement Patterns (Best Practices)
ISBN: 0735623988
EAN: 2147483647
Year: 2007
Pages: 110

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net