Posts tagged non-functional

In a prior post, I suggested that the use of a thorough checklist of possible non-functional requirements categories is a good way to probe for the relevant requirements on a specific project under consideration.  As I think about it now, I realize it may also help to review non-functional requirements of other projects as another source of inspiration.

My point for writing today, however, is the idea that regardless of how one arrives at those requirements, one can still use the user-story format for recording them.  Particularly when the requirement is a business-level or business-driven requirement rather than a customer-driven one, this format allows the recording of the source of a requirement so that it is easier to explain and remember later:

Consider the example of the CTO constraining the team to use the existing orders database. (This was the real situation; the team was considering a second orders database that would be sychronized at night. The CTO overheard this and said “no!”) If we wrote this requirement as simply “Must use existing orders database” it would be entirely possible that a few months down the road we wouldn’t remember why we should be constrained in that way. We’d ask the product owner if she cared if we used a secondary database, and she’d say she had no objections. And we’d make a mistake of using one. Embedding the person who wants something can be very useful.

In my own experience with collecting and then analyzing requirements for several active projects (Each at a different phase of development) I have run into the problem of not remembering the source of requirements at a later date.   The author also suggests thinking of them as “constraints,” rather than “non-functional requirements” — which is a suggestion the linguist in me finds appealing, as it is a more naturally meaningful phrase.

While the CIO suggestion above does illustrate the way I find the user story format to help solve the requirement-source problem, I have a related problem that I have yet to solve: remembering the details of a negotiation.  Over time, different stakeholders may make differing or even competing requests.  Later in deelopment, when these stakeholders ask why their suggestion was not accepted and implemented, I have a hard time remembering the rationale for a particular decision.  Thoughts, anyone?