I have some Paton’s Inca in a beige blend (the same colour that the One Piece Jacket was done in) but I can’t find exactly the sort of pattern that I want to knit, so it’s time to design my first jumper. I’m an information systems major rather than a textiles major, so I decided to apply software engineering principles to designing my jumper.

So, first of all, requirements elicitation. The business requirements of the jumper are;

• The jumper must accentuate my “assets” while downplaying any not-so-desirable attributes
• The jumper must fit, and should have plenty of stretch
• The jumper should be easy to maintain
• The jumper’s cost should be less than $150

Translating the business requirements into functional requirements;

• The jumper will have a v-neck that is 2o cms deeper than the top of my shoulder and shaping will begin 8 cms in from the shoulder. The v-neck accentuates the bust while drawing attention away from the hips and gives room for movement
• The jumper will be knitted in 1 x 1 rib to give shaping and stretch
• The jumper will have slight increase to allow for large bust and decreases for waist, possible increase for hips
• The jumper will have sleeves that finish 10 cm below the elbow (my preferred sleeve length)
• Paton’s Inca is $6 at Lincraft or $5.40 at K-mart (unless I can twist Damo‘s arm to get ACS to offer bulk packs cheaper). Therefore, the pattern must take less than 26 balls of yarn if I buy them at K-mart.

Next: knitting pattern design using functional decomposition

I recently had an article published by the IT Service Management Forum (itSMF) of Australia on what Kepner-Tregoe problem solving and decision making offers to ITIL Problem Management.

So far, one of the most useful concepts from KT is the use of a ‘deviation’ to determine whether you do in fact have a ‘problem’. A deviation is defined as the difference between an expected and actual condition – such as a server load twice that of normal, or a host being unresponsive when it should be up. If there is no ‘deviation’, then you must question whether you really have a ‘problem’. This is useful for distinguishing between development requests / enhancement requests and true ‘problems’.