Crawling out of the chaos

Real Life has a way of sneaking up and consuming all of your time, in very amusing ways.

The job has been busy lately, but not in very productive ways.  In light of that, here's a little rant on requirements for software.  Unfortunately, there's often little the Ninja can do to improve this situation, because Requirements Gathering is often enshrined in the Marketing or Architecture Departments, well away from the developers who have to implement them (And as often well awat from the people who will use the system)

The things that the Ninja must do when Requirements are handed down from On High are:

1. Make sure there are as few conflicting requirements as possible.
2. Make sure that each requirement is clear.  Performance measured in transactions/second, for example
3. Make sure that any external systems have a well-defined API to talk into the system

You will not always be able to eliminate all the conflicting requirements, but those that remain should be loudly noted to The Powers That Be.

Anything that is vague, get a clarification in writing - ideally in the documentation, but in an email with several of the developers and requirements authors cc'd.

Also, make sure that the requirements document is versioned, and that you have noted in email which version you are developing to.  I have had more than one occasion where the document writer "improved" the requirements and "neglected" to inform development of these changes, which were well-publicized to the customer.

---

Technorati Tags --
Software, SoftwareDevelopment, Computers, Programming
HTTP