tag:blogger.com,1999:blog-8455540866725604198.post4572359048462288222..comments2017-06-07T06:11:35.524-04:00Comments on elephantangelchild: How do I track requirements?kcunninghttp://www.blogger.com/profile/04641419717110221695noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8455540866725604198.post-9057783664415710152009-06-17T22:13:04.941-04:002009-06-17T22:13:04.941-04:00Great post. :-)
Sometimes, having a fully feature...Great post. :-)<br /><br />Sometimes, having a fully featured platform can make requirements management difficult, for three reasons:<br /><br /> 1) Delivering a requirement requires some customisation, but this is either ignored or mis-estimated.<br /><br /> 2) The platform does more than your requirements state. There may be work to <i>turn off</i> of things, working out what exactly and how much effort is required is difficult. These types of requirements tend to come in later, when people start testing the system, so they're difficult to estimate for.<br /><br /> 3) Even if you want the out-of-the-box functionality (which may happen because the requirement is "I want this feature of Plone", explicitly), you still need to track it and test it. Plone could have a bug in the version you're using, or something you did elsewhere could've had a negative impact on this feature. So, even things that are provided out of the box require an effort estimate and planning and acceptance testing.<br /><br />On your other point, about comments, you are absolutely right. As a rule of thumb, a developer is only going to read the full "thread" for a requirement once. In all day-to-day activities, he or she will look at the title only, and this needs to be enough. That's why I'm a big fan of user stories:<br /><br /> "As an [actor], I can [feature], so that [business value]"<br /><br />These types of requirements have a number of advantages:<br /><br /> - They're short enough to talk about and remember<br /> - They're descriptive<br /> - They identify the who, the what and the why in a concise statement<br /> - They are deliverables, not tasks, so you can measure when they've been completed<br /> - They can be estimated with story points, which is a great way to get decent estimates quickly<br /><br />MartinMartin Aspelihttps://www.blogger.com/profile/11251335463579376973noreply@blogger.comtag:blogger.com,1999:blog-8455540866725604198.post-76444340580737192042009-06-17T18:12:15.997-04:002009-06-17T18:12:15.997-04:00I think interactions are fundamental: most of the ...I think interactions are fundamental: most of the "normal people" do not differentiate between "user experience" and "functionality", so if you provide outstanding functionality with a frustrating user experience, the customer is going to complain that "the functionality isn't there".<br /><br />Probably, formalizing a "language" in which to model an UI and interactions which is understandable by anyone and unambiguous can help dramatically in avoiding circling.Anonymousnoreply@blogger.com