0

I am a lead developer working for the IT department of an organization. Recently I have been assigned a new project. Initially, the business analyst responsible for the project sent me developer requirements. After I reviewed those documents, I noticed that there were lot of gaps and that clarity was missing, which I brought back to the business analyst. Similarly, other team members also come up with clarification questions related their part of development work. It took a month and a half to clear up this confusion on the requirements. However the problem isn't all these requirement clarifications, but instead it's in the fact that not all of these changes are documented in any central location and aren't updated in the original project specializations. As a result, the gap between the initially specified requirements in the requirement document and the finalized requirements is so high.

Thus, not everyone involved in the project is on the same page, and every time I need to explain the history of how the initial requirements changed to current one. I feel it is not productive and is tedious.

Here My primary problem is all the latest changes are not updated in requirement docs. Due to this I am facing issues like other colleagues asking too many questions about requirements. Hence the root cause is not updating all the updates about requirements in the original document, I am asking question about that only. Hence my question would become

How to deal with too many requirement changes and not updated/documented in single place?

  • This question appears to be off-topic because it is a question about programming not navigating the workplace. – IDrinkandIKnowThings Apr 10 '14 at 4:08
  • @Chad - I disagree, it's a question on project management, not programming. It just happens to involve a programming project. – panoptical Apr 10 '14 at 4:10
  • OK then it belongs on PM.SE It is not about navigating the workplace – IDrinkandIKnowThings Apr 10 '14 at 4:10
  • That I do agree with (didn't know there was a Project Management SE). – panoptical Apr 10 '14 at 4:21
  • Mmm...fragmentation. – aroth Apr 10 '14 at 5:06
2

It's really not terribly complicated. You, or your boss, or someone on up the chain needs to assign a project manager to the project. That manager would be responsible for organizing all the requirements, constructing a timeline (and making sure each team is sticking to that timeline), and managing the budget for the project. This manager would be the point man (or woman) for the entire project, and would allow for a central point of organization for the requirements.

In larger firms, project managers are actually job titles, and those people are usually dedicated to doing the above for 1 or a handful of projects. In smaller firms, it may be one person wearing multiple hats as part of the project, one of which reads project manager.

2

However the problem is all these requirement clarifications, discussions summary is in Emails not documented single place and not updated in original requirement documents.

That is a problem. So why not document the changes somewhere centralized and easily accessible? Does your company run a wiki (or if not, then why not?)?

That's where your requirements documentation should live, and any discussions that happen in relation to the requirements should be attached there. The requirements themselves should be updated in the main document as changes are agreed upon, and each change should be scoped as it is applied to the main requirements document. Your wiki will maintain a log of all changes as they are made, making it easy to view how the requirements have evolved over time. And it can also be configured to notify all members of the development team whenever a change is made, ensuring that everyone is kept informed of changes as they are made.

If your company is not running a wiki, then your immediate task is: Convince your manager(s) that they really, really need to be running a wiki or some comparable solution.

And also due to many changes in the requirements the gap between initially specified requirements in the requirement document and the finalized requirements is so high.

Software requirements are never finalized. If the requirements have changed then you really need to update your "finalized" requirements document to reflect the changes. Otherwise you run into exactly the issues you are describing.

If you find it too disruptive to work off of a "living" requirements document (which it certainly can be), you can take a snapshot of the requirements (or some subset of requirements) and call that your Minimum Viable Product. Then your MVP requirements can stay fixed, and that's what you build your initial release towards. Any changes to the requirements are recorded against the main document (or within the product backlog, if you are using agile/Scrum), and you deal with them after completing your MVP implementation.

The problem is not every one who are working for the project on the same page. And every time I need explain the history how initial requirements changed to current one. I feel it is not productive and tedious.

How can I deal with it?

You should:

  1. Establish a canonical "source of truth" that everyone can use to see the current requirements. A wiki works wonders for this.
  2. Ensure that information related to the how and why of your changing requirements is documented and accessible from your "source of truth". If a requirement changes because of an e-mail exchange, attach the e-mail exchange to your requirements document and cross-reference as appropriate.
  3. Ensure that the main requirements document always shows the most recent version (and keep it as up to date as possible), and that previous revisions are only shown if/when explicitly requested.
  • 1
    And you don't work on changes to the requirements until they official documents are updated. – HLGEM Apr 10 '14 at 20:19

Not the answer you're looking for? Browse other questions tagged or ask your own question.