16

Possible Duplicate:
How do you deal with changing requirements?

This question must have been asked a thousand times but there seems to be little progress in this area:

  • I have asked the customer what he would like the system to do, to little avail!

  • I have asked the customer about the system that the software is supposed to replace, but the system is either too complex or he does not know about the system or there is no system to replace.

  • I have been through telling the customer what he wants, only to find the requirements change at a later date, etc.

  • I have tried using a common language, only to realise later that the customer does not know the difference between a textbox and a label.

The list goes on and too much is taken for granted in methodologies such as DDD. I hint at this here: Which layers should reflect the domain language (if a domain language can strictly exist)?

Let's get this nailed into some kind of algorithm!

EDIT

This is the classical bad customer and is not a one that I would want.

A prevailing attitude about whether a developer should visit a customer would be considered costly. A developer is supposed write software; a day out of the office, away from development work plus expenses can often outweigh the profit on the work to be done.

You can provide mockups and wireframes but if this is not the person who is going to use the system them their input is not going to be of much use.

Community
  • 1
Phil C
  • 1,956
  • 1
  • 18
  • 34
  • 9
    Are you sure you want this customer? –  Apr 10 '11 at 09:26
  • It wouldn't be a decision for me to make but this one could give us lots of work in the future where requirements would be less ad hoc and ambiguous. – Phil C Apr 10 '11 at 09:33
  • When the customer hired you he must have spelled out the objective,goal,motto of the project. I think it will be good start for the requirement gathering. You might not want to guess requirements. if the customer does not know what he wants, he would not have initiated the project. Customer should point you to the right person. your mockups and wireframes will come after you have initial specs document – ViSu Jun 07 '12 at 08:01

7 Answers7

11

Your problem seems to step from the fact that the "customer" is probably a person who will not use the system. Some things I remember from SE class:

  • Try visiting the people who will actually use the system and observe them in actual working conditions. This can be important because of domain differences between users and developers, difference assumptions can be made by the two groups. If this is not possible, at least include one of the end-users directly in the requirements process.
  • Use some kind of UI designing software to show them screenshots of the UI you may design based on your current requirements. This avoids the problem of technical terms and graphical representation often highlights problems that might otherwise be overlooked.
apoorv020
  • 666
  • 5
  • 11
  • 2
    I like your answer and it deserves an upvote but: 1) visiting customers is costly. I'm supposed to write software and a day out of the office away from development work plus expenses can often outweight the profit on the work to be done; 2) Yep, I provide mockups and wireframes but if this is not the person who is going to use the system them their input is not going to be of much use. – Phil C Apr 10 '11 at 08:49
  • 1
    What about asking them to put you in contact with an end-user directly? – apoorv020 Apr 10 '11 at 08:55
  • I've tried that but these chaps are much too busy in their workaday lives to sharpen their own saw. So it leads to second guessing but I would include the suggestion in an algorthim of this kind. So take an upvote. – Phil C Apr 10 '11 at 09:01
  • 2
    Visiting customers can be costly, but losing customers because you can't give them what you want is probably worse! I would figure out the end user and go spend 2-3 days with them watching them work, and mapping out user stories with them. (really it can do so much for a relationship to sit down with people) – Zachary K Apr 10 '11 at 09:01
  • @Zachary: That role should be performed in every organisation but it is not a developer's role to do that. It could be part of a business analyst role. – Phil C Apr 10 '11 at 09:51
  • 3
    To my mind it matters more that is done then who does it. I am in a funny spot, for the last few years I have been working on an in house product so everyone who uses my software is in the office and I can go talk to them (its kind of nice mostly) – Zachary K Apr 10 '11 at 10:17
  • I love where I work but I wish I had that luxury too, even though it is not my role to talk to customers – Phil C Apr 10 '11 at 14:01
  • You get the client to pay for the cost of the time to provide the analysis. If they are serious about the software they will pay for this service. If they refuse to see the value then they probably aren't worth working with, anyway. – Dan Diplo Feb 04 '12 at 11:38
6

I know this is an ugly phrase in the development world, but this is really where business consulting comes into play. If the client doesn't actually know what their problems are and what kinds of solutions they might want, you really can't design software to help them.

Agile is great and functional design takes well to revision during the development process. Business analysis -- at least the bulk of it -- is best handled in a more waterfall fashion (ooh, an even uglier word today), with the actual business requirements resolved before any functional software design begins.

Mind you, this work doesn't have to be done by a business consultant (though for many projects it'll save a whole lot of time and pain), but the same kinds of effort are required if you do it. From your comments it doesn't sound like this work is budgeted, but it really is important to take a step back with your client and figure out how his business works, at least the parts the software will directly touch. Neglecting to do so will almost guarantee a failed project.

Matthew Frederick
  • 1,719
  • 10
  • 15
  • 1
    Well put. If this project has a customer (that doesn't know what they want) and a developer (that doesn't know what the customer wants) without any business analysis skills in between the two, then I suspect failure beckons. – Carson63000 Apr 11 '11 at 01:35
  • Yes, incomplete understanding on both sides (business and developers) is a guaranteed path to failure. – abhi Feb 13 '13 at 21:11
2

  1. Identify your stakeholders. Usually there are few of them, not just one customer.

  2. Ask each of them what they want from the project. Any project should deliver new "Quality". "Replacing existing software" does not make sense without explanation Why? 5-whys method could be applicable in this situation to understand what the client really needs.

  3. using dictionary like "label", "textbox" when you talk to Stakeholders on early phase of requirements gathering is rather bad idea. You should keep your mind and minds of stakeholders clean from Design Ideas until you do not understand requirements.

m5ba
  • 475
  • 2
  • 9
2

Customers do not have requirements. They have problems.

Selection of problems to solve and their conversion to requirements is a separate role which requires knowledge in customer domain and knowledge of what can be done by technology and what cannot.

Sometimes this role may be taken by customer if it has knowledge of technology - but it's unlikely the case here.

So either you should study customer domain or find a right person which will be in the middle.

maxim1000
  • 745
  • 4
  • 8
  • 1
    They still have business requirements, irrespective of whether these are resolved through technology – Phil C Apr 10 '11 at 12:45
2

I like to think about requirements as decisions about the future. The future is in flux, and so are decisions about it. When new information comes to light, we should revise our decisions accordingly.

The best way to gather information is to release your software as often as possible so the customer can test it. From that feedback, change your decisions.

In other words: experiment, observe and adapt.

Martin Wickman
  • 13,305
  • 3
  • 31
  • 66
1

Mapping people as a group to an algorithm ( social studies / stats ) can lead to much learning.. trying to map individual people to an algorithm ( alchemy ) can only lead to insanity.

Assuming you have tried the above, then the only option I see for you ( given that the project still needs to go ahead, and you are still employed ) is to set up the project as an agile one - and cost it per delivered feature.

Deliver only the most obvious and essential features, and let it then grow organically.

It might very well be that the entire system is just too complex for your customer to keep in his head. So when you make suggestion A it sounds reasonable and he say "Yes", but when you come back with a question the answer will contradict decision A - simply because the relationship of these two is not clear to him.

Side Note: If you are asking him about textboxes and labels you are asking him the wrong questions. It is likely he is only interested in it just working.. not how it works. That is for you do decide ( with user input ).

Stephen Bailey
  • 2,236
  • 14
  • 14
  • I agree that in these circumstance that "Deliver only the most obvious and essential features" should be delivered first opposed to wholly relying on a MoSCoW scale... Take an upvote for making me laugh too. – Phil C Apr 10 '11 at 09:03
1

As Stephan Bailey says the only way this can work is if you take an agile approach.

I would start prototyping UI and showing those to the customer, that should at least focus them a little, even if they hate your first attempt hopefully this will at least bring them around to telling you what the do want.

There is one major risk with showing a UI prototype, and that is that the customer will see "screens" and assume that the work is complete because they can see it. It takes a lot of work to pursuade them that a few buttons are not an application. For this reason do not make the prototype too polished, keep it rough and do not try and mock up too much functionality.

Community
  • 1
Steve
  • 5,264
  • 1
  • 21
  • 27
  • Yeah, I happily tell them that "it's just a drawing; the software does not exist" – Phil C Apr 10 '11 at 09:35
  • Over the years (decades, yikes!) I've found that super-simple line drawn wireframes are best (even hand drawn, for the right customers). When it hints at software but doesn't actually look like software, you not only ensure that the client doesn't feel like a bunch of the application has been built, but you also keep away from needless (at this stage) design discussions. There's nothing like trying to work out whether certain fields on a form make sense with the client repeatedly bringing up whether a certain shade of red is desirable. – Matthew Frederick Apr 10 '11 at 10:48