How to record client requirements?

Question

How a typical Software development company keep records of client requirements? For example:

A) One day client asked us to add a tracking code to his website.

B) Another day same client asked us to add a different code but same vendor code in a separate page. This code will not work without above tracking code A).

After few months same client asked us to update the tracking code of point A). In this situation if developers take action to update point A) then point B) will cause the issue and nobody aware about it, until it causes some issue.

Given this example, can you tell me how a large organization handling this kind of situations? Are they waiting for errors to show-up in the page?

Answer 1

Agile provides 3 opportunities to catch this error prior to production

1. The dependency should have been captured in the acceptance criteria: When story B is written, it should have been linked back to story A. And an acceptance criteria should have been written to capture that.

2. Unit test should break: While not all Agile teams may be writing unit tests, Agile tries to improve engineering practices. Test Driven Development (TDD) is a key practice of Extreme Programming.

3. Agile dev teams are actively engaged in understanding why a story is needed: I am not sure whether this is typical. However, some of the Waterfall dev teams that I have seen are more focused on executing what the client asks for. The approach seems to be that if the client wants it and willing to pay for it, they can have it. On the other hand, Agile dev teams work hand-in-hand with the Product Owner in writing user stories and acceptance criteria to reach commonly agreed business goals. So, they tend to challenge what a Product Owner wants if it doesn't make sense.

In general, Agile has frequent retrospectives. Even if some of these types of errors crept into production, they should be surfaced in a retrospective and opportunities are available to come up with practical process improvements.

Answer 2

What you need is formal change control.

You start by capturing the requirement on a Change Request. This should detail everything the client wants to change. If the change is significant it may also require the use of a separate Requirements Specification, but that would still be referenced in the Change Request.

Once it has been submitted to the vendor, the vendor needs to assess the cost and impact of making the change. Typically the Change Request would do the rounds into several connected departments/teams, such as Development, Testing, Hardware/Infrastructure, MI etc. Each team is able to assess the impact on their area of making the change- Developers need to code the change, testers need to write test scripts and execute system and integration testing, MI needs to figure out if the change affects a data warehouse feed and subsequent reports and estimate the time to change the feeds and reports and so on.

When every team has assessed the impact (the developers would pick up the regression issues) and the costs in terms of effort to deploy, the costs and impact would be discussed with the client in a Change Board. If the client accepts the costs and impacts then the change is allowed to be scheduled into a release.

If you operate an Agile development process then I am not certain this applies, but it is certainly how we do things in a controlled waterfall environment.

Answer 3

One way to capture requirements is to put it in a document (word/pdf) with as much details as you can. Mention the stated requirements, if necessary provide wireframe diagram and also state your assumptions in the requirements. And take a written sign off from the user/customer.

Usually such requirement documents should be shared on a common portal(sharepoint, jira) where your IT team and the users would have access.

This sharing and signoff mechanism will ensure that the customer has agreed to the requirement and you can charge extra money for any change to the requirements

Answer 4

Best case is you have documented all of the business capabilities the client wants in the contract. This has several advantages for both parties:

• Vendor (you) has clear idea of what customer wants and can allocate appropriate resources to deliver it.
• Customer has some level of predictability around costs and delivery time-frame.
• Both parties have a shared understanding of what end-points, milestones, etc are.

From the business capabilities documented in the contract you can then work through development of requirements documents per ViSu, but you need to have the contract in place first to help protect against scope creep.

Answer 5

We use a form named modification request form to track Customer's change request. Each request is assigned a unique number, area of change etc..

Customer fills change request in the modification request form. We evaluate change request, prepare an understanding document, and pass back to user for confirmation. On user confirmation we initiate the change process.

We store these modification request and understanding document in an in house developed system and add unique modification request number to the code for easy future reference by the team.

Answer 6

Change control won't help if you don't have solid documentation to start with.

I would suggest looking up business requirements documents (BRD) and systems requirements specifications (SRS) for reference.

Yes, client requirements should be documented and tracked. Any change request or update should translate into changing the original documents to match the new requirements and make sure all the impacts have been analysed.