Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Customer Requirements: dealing with customers who dictate functional specification?

 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marco,

Do you have any tips for dealing with customers who prefer to dictate functional specification rather than explore business needs?

I'm in an environment where we are doing development for internal consumption, rather than for outside (paying) customers, not that this would necessarily impact the strategy.

Thanks!
 
Author
Posts: 110
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi A Flatoff,
dictate as in: You will build exactly *this* by the end of next week, no questions allowed? Can you elaborate a tiny bit more?

Cheers
Marco
 
A Flatoff
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My users frequently like to provide functional specification without any kind of background on why the require features.

For example (for a document management implementation):

- provide ability for graphical annotations on documents (e.g. sticky notes)
- allow for redaction on documents
- provide employee status information (active / terminated) along with employee documents
- allow viewing employee documents by employee VP or location
- color code documents by category

They basically provide their vision for design and functionality for the application but don't provide information on why they are requesting functionality. If the programming teams were to implement the functionality exactly as specified, the customer might be happy (or maybe not due to inaccurate communication or interpretation of functional requirement. The bigger problem is that there may be easier / better way to solve the user's business problem, but because the business problem is unknown, the better solution may not be realized.
 
Ranch Hand
Posts: 135
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

A Flatoff wrote:The bigger problem is that there may be easier / better way to solve the user's business problem, but because the business problem is unknown, the better solution may not be realized.



I have experienced this as well. Sometimes the solution built is what the customer asked for and not what they needed because the developer was merely "an order taker" as opposed to someone engaged in learning a little about the business and about the problem being solved.
 
Marco Behler
Author
Posts: 110
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ah I see.

The answer is, unsurprisingly, rather simple:

What you basically have to do is get together with your internal people for a day or two and see what and how they do it.

As you seem to be working in a bigger environment, that means convincing your boss to literally just watch your internal colleagues while they are working and ask them a ton of questions/listen regarding their workflows. Hint: Do not try to shortcut here with presentations that the other department might give to you and a bunch of your programmer colleagues. There is nothing to be learned in those 30 minutes.

No, literally you have to sit with them. It is *amazing* what will happen to your development activities and software quality *after* you have done exactly that.
 
A Flatoff
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds like good advice. We usually try to solve that problem by asking probing questions in meetings. It does seem like shadowing for a while and observing the as-is directly would be the most accurate way to understand their processes.
 
Bras cause cancer. And tiny ads:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!