IT:PM:Docs/Specifications/IO
Summary
It's the nature of things that many BAs in the business of application delivery, double up as Technical Analysts.
Being that they have less technical experience than business experience, such BAs have trouble documenting User Interfaces and other IOs in a matter than removes ambiguity.
Here's a suggestion on how to make I/O specifications less error prone.
Notes
- Instead of using tables, use a set series of bullets. The reason is that each entry field of a UI has several attributes, and columns just don't fit well on an A4 page. The cramped reading makes for more errors.
An example:
- Form:
- Title: “Order Form”
- SubTitle: “Please enter your order below”
- Fields:
- Quantity:
- Label: Quanity
- Tip: How many pizzas do you want?
- Long/Popup Help: RESOURCE#138
- Type: integer
- Contraints:
- Required: yes. Error Code: 148
- Min: 1. Error Code: 149
- Max: 10. Error Code: 150
- Notes:
- Street:
- Label: Street
- Tip: Where do you live in Wellington?
- Long/Popup Help: RESOURCE#143
- Type:Text
- Constraints:
- Required: Yes. Error Code: 148
- Min(Length): 5: Error Code : 152
- Max(Length): 40: Error Code: 155
- Submit:
- Label: Order
- Tip: …
- Long/Popup Help: n/a
- Type:Primary Action Button
- Notes:
- Cancel:
- Label: Cancel
- Type: Secondary Action Button
etc.