The document provides guidance on how to effectively review software requirements as a stakeholder. It outlines an 8-step process for stakeholders to (1) identify their key objectives and problem areas, (2) prioritize problems, (3) link project goals to problems, (4) code objectives and problems, (5) annotate each requirement with relevant codes and ratings, (6) identify any important issues not addressed, and (7) provide feedback to the project team. Going through these steps helps stakeholders focus on requirements that matter most to their needs and provides a way to assess how well a project will meet objectives and address key problems.

1. How to review software requirements

2. Make the world a better place. Send this to project stakeholders who need to read requirements.

3. Part 1 Your role

4. You are a ‘stakeholder’ to a project

5. But what is a stakeholder?

6. It simply means you have a ‘stake’ in what the project is trying to deliver.

7. The project might make your life easier

8. or harder

9. or make little or no difference.

10. Either way

11. you are a

12. stakeholder

13. and you have to

14. read

15. and understand

16. and agree to

17. A set of ‘requirements’

18. because your signature

19. means you understand

20. what has been written down

21. and that your particular needs

22. and priorities

23. have been included

24. sufficiently.

25. Part 2 What are requirements and why do we have them?

26. Requirements are a sort of contract

27. between you

28. and the project team.

29. You negotiate for what you need to be included.

30. They write it down.

31. You sign it.

32. It’s a contract.

33. At the end of the project

34. you can call them

35. on what they failed to deliver.

36. And they can point out

37. that they delivered to specifications.

38. It can be a bit of a problem.

39. I hope this presentation helps

40. make the problem smaller

41. or even disappear.

42. Requirements come in two main flavours.

43. Agile Traditional

44. They look something like this;

46. Requirements are the way we (project people)

47. articulate what you (business people)

48. … want to see out of a new software product.

49. to see out of

50. Requirements are not

51. typically what we want

52. to see in a software package.

53. to see in

54. You run a business unit.

55. You are not a software developer.

56. Don’t tell the software developer

57. that you want a particular feature

58. because

59. they’ll give it to you.

60. Instead…

61. tell them what outcome you want to achieve

62. and why it is important.

63. That way you’ll get

64. what you need.

65. Part 3 Reading requirements

66. (By the way, the secret to this is all in the preparation.)

67. Remember these?

69. Step 1

70. Put the document down.

71. Step 2

72. Grab a trusted colleague

73. and piece of paper

74. or some sticky notes

75. or a whiteboard

76. And write down your current KPIs

77. Now add the things you do that are (a) important, and (b) not in your KPIs

78. KPIs that are reported on Important things not in your KPIs KPI # 1 KPI # 2 KPI # 3 KPI # 4 Not KPI # 1 Not KPI # 2

79. Step 3

80. Write down all the major problems you have with your business unit today

81. and attach them

82. to your list of KPIs and important things

83. KPI # 1 Staff retention KPI # 2 Quality KPI # 3 Financial KPI # 4 Accrued Leave Not KPI # 1 Happy Customers Not KPI # 2 Clean office Staying on Budget with unexpected events Staff attrition too high Customer satisfaction heading south Quality of service inconsistent John’s desk Jane and Lois’ leave is too high

84. Step 4

85. Drop your problems into an important / urgent prioritisation grid

86. Important + Not urgent Not important + Not urgent Important + Urgent Not important + Not urgent

87. Important + Not urgent Not important + Not urgent Important + Urgent Not important + Not urgent Staying on Budget with unexpected events Staff attrition too high Customer satisfaction heading south Quality of service inconsistent John’s desk Jane and Lois’ leave is too high

88. (Projects are expensive and complicated enough without loading up small-fry issues)

89. Only keep the important issues

90. Important + Not urgent Not important + Not urgent Important + Urgent Not important + Not urgent Staying on Budget with unexpected events Staff attrition too high Customer satisfaction heading south Quality of service inconsistent John’s desk Jane and Lois’ leave is too high

91. Step 5

92. Draw a circle

94. Write down a short description of the project’s goals in the circle

95. Solve world hunger

96. Now write your important problems and issues around the circle

97. Solve world hunger Staying on Budget with unexpected events Staff attrition too high Customer satisfaction heading south Quality of service inconsistent

98. Link up the project’s goals with your problem areas

99. With a description of how the project should be helping

100. Customers are fed Funding is adjusted to accommodate new costs Staying on Budget with unexpected events Staff attrition too high Customer satisfaction heading south Quality of service inconsistent Solve world hunger Staff want to help

101. Projects won’t connect with all your problems

102. Solve world hunger Staying on Budget Staff attrition Customer satisfaction Quality of service Staff want to help Customers are fed Funding is adjusted to accommodate new costs ?

103. (That’s a good thing)

104. (Overly large projects are too complex and usually fail)

105. Step 6

106. Take your KPIs and other important responsibilities

107. &

108. take the links

109. between the project’s goals and your problems

110. and

111. Make them headings

112. Staff want to help Customers are fed Funding is adjusted to accommodate new costs KPI # 1 KPI # 2 KPI # 3 KPI # 4 Not KPI # 1 Not KPI # 2

113. Give them a shorthand code

114. Staff want to help Customers are fed Funding is adjusted to accommodate new costs KPI # 1 KPI # 2 KPI # 3 KPI # 4 Not KPI # 1 Not KPI # 2 A B C D E F G H I

115. Now you are ready

116. to read those requirements

117. and assess

118. how the project will affect you

119. and your business unit.

120. Let’s revisit those steps:

121. Put aside the requirements Focus on your key objectives Identify your key problem areas Prioritize your problems Identify the links between the project goals and your problems Set up a code to track requirements against what’s important to you

122. Step 7

123. Read each requirement statement

124. At the end of each statement

125. Attach the code for each problem or goal you have

126. And then rate the requirement

127. on it’s ability to affect you

128. (good or bad)

129. When you complete the document you’ll have notes

130. On everything that is relevant to you

131. And you’ll also have

132. Lot’s of requirements statements

133. that have no relevance to you

134. Now you can focus

135. on what is important.

136. And you can see

137. how the project’s requirements

138. will affect you.

139. There is one last thing.

140. Step 8

141. Go back to your diagram

142. that links the project

143. to your goals and problems.

144. Solve world hunger Staff want to help Customers are fed Funding is adjusted to accommodate new costs Staying on Budget with unexpected events Staff attrition too high Customer satisfaction heading south Quality of service inconsistent

145. Which one of these issues

146. have been left out of the document?

147. Do they matter?

148. If they do, it’s time to write up a list…

149. and send it to the project team.

150. I hope this is helpful.

151. We’d love your feedback. (comments below)

152. www.betterprojects.net