4

What are the ways of managing the evolving requirements without turning them into a mess?

We do not have a dedicated analyst in our team so this role is shared by all the members.

Our reoccurring workflow is the following:

  • Users send us the initial version of requirements for new functionality which is then followed by a discussion with many questions and clarifications.
  • After functionality is implemented and new version of application is deployed users can play with it, and decide what they like, and what they don't. Very likely they ask for some changes or additions. And the cycle repeats.
  • Nobody summarizes the requirements in a document approved by the users. We just store msg files in the archive.
  • After N iterations it's quite painful to restore the whole discussion and understand why system behaves now as it does and what its evolution was. Especially it is difficult to explicitly emphasize client's decisions.

Ideally I'd prefer to have some system which allows to store and compare versions of documents, and attach discussions both to the whole document and the particular change. Yet, I am unaware of such a software.

Could you provide some advice or methodology for managing requirements?

paparazzo
  • 1,937
  • 1
  • 14
  • 23
Pavel Voronin
  • 1,640
  • 1
  • 18
  • 25

2 Answers2

4

If your team is small or you can't dramatically change your process.....

Could you provide some advice or methodology for managing requirements?

Some sort of document management system. Preferably with version history and dates.

As horrible as SharePoint is for many things, it is a good tool for this. Depending on your implementation you can also add signoffs/approvals.

With something like this, you can just look through the revision history.

Or use SVN. It has a good office functionality too to compare different office versions.

Nobody summarizes the requirements in a document approved by the users. We just store msg files in the archive.

Have a main requirements document. Setup a process to add/remove to this. Perhaps have it associated with user testing.

Worst case is you save new copies of UserRequirements.docx as 2015_11_18_UserRequirements.docx and have an archive of them. Or something equally as bad.

But regardless you need a way to have a "master" user requirements process with history. You will need to setup a process with your business team, so they understand they must update this document (not send you an email) if they want formal changes.

enderland
  • 12,091
  • 4
  • 51
  • 63
2

The first thing that you are going to want to do is to define a requirements management process. You're going to want to consider multiple facets: receiving customer/user requirements at the start of a project, elicitation from all stakeholders (including business and regulatory requirements), deriving requirements, capturing requirements, validating requirements, tracing requirements to their point of origin and to artifacts (design, code, tests) as appropriate, and managing incoming change requests (including source and rationale).

The next thing to do is to appoint a person to be the requirements manager. I'm not sure how your organization and projects are structured, but I prefer a product-centric approach where that's possible, where every product is managed as an item. Therefore, every product would have a primary (and hopefully a backup) person to manage the requirements for that product.

Once you have a process and a person (or people) to lead the execution of that process, you're going to want to look at the tools you need to support that process. There are tools designed to support requirements engineering - I'm familiar with IBM Rational DOORS, but there are lots of tools, and I'm sure that there are some that are even free and open source. There are also application lifecycle management (ALM) tools that include requirements management, but go beyond to other facets of software development.

Your approach of using documents is, in my experience, going to lead to problems in the long term, especially if you maintain multiple products or a software product line. You're going to want to maintain your requirements in a tool that supports requirements engineering best practices, and then be able to export to spreadsheets and documents when necessary.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283