Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Actually, I'm A Fresh CS graduate,who want to build a System for his Dad's Road Transport business. However,the issue is whenever I go to ask to him about : what are people involved in his business? whats their routine work? or how their business actually works? then he avoids my questions, and says, just give me system by utilizing your knowledge, to ease my transporting business,and rest all you think.

So, I had brainstormed about it, but I still feel the need of viewpoint of my dad,as he is actually in that business.

Hence, how can I get business requirements form him ?


migration rejected from Dec 25 '15 at 7:37

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by MichaelT, Scant Roger, GlenH7, Ixrec, gnat Dec 25 '15 at 7:37

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

Possible duplicate of Dealing with bad/incomplete/unclear specifications? – gnat Dec 25 '15 at 7:37

If you can't interview, there are a number of other requirements elicitation techniques that you could try:

  • Questionnaires. The people who would use their system don't have to give up their time. Get them a questionnaire and let them complete it when they are available. You could do several iterations of questionnairs, but that could consume a lot of time. You need to spend a lot of time determining what you need to know and getting it on the questionnaire, while eliminating information you don't need so you save everyone's time.
  • Storyboards and UI mockups. Users think in terms of what they have to do. Create some kind of flowchart, storyboard, or UI mockup and present it to them. Have them walk through the steps and see if it flows for them. You can derive new feature requirements from comments and suggestions made during a walkthrough, as well. I think this would work best in an incremental and iterative development methodology, where you can repeat this on a somewhat regular basis and get continued feedback on your current implementation as well as new features.
  • Role playing. Learn the business domain yourself and try to put yourself in the role of your user. Think the way they think and work the way they work. Then use your application or walk through your own models/mockups, find problems, and fix them. This can be hard if you don't have an understanding of who the users are and what they do.
  • Shadowing. Follow different people from your user classes and observe them at work. Take notes on things they say. Don't interrupt their workflows, though. Instead, note areas for improvement as well as common metaphores and business terminology so you can apply it in your application.
  • Rapid prototyping. If you have some existing knowledge about the business and the domain, start building a prototype. Be sure to decide if you are going to evolve it or throw it away, as that will change your development approach. Release early, release often, and gather feedback.

Could you work with one of your dad's employees for a day or so? That way you (hopefully) see what they do and find important in their work, instead of what others tell you.


I come from a family who own a trading business, and in our family we have a saying about doing business with friends and/or family members (at least those family members who aren't part or closely related to those taking part in the business) (FnF):

FnF make bad business relations. Expectations are often not realistic and thus disappointment is usually a big risk, and if bad things happen one which will continue to haunt you even after business is done.
Also, they usually try to play on your emotions to get (too much of) a bargain, usually way past what can be considered rationally acceptable

If you still can, you should set out a framework for doing business which puts the assignment outside your personal relation with your dad. This will enable you to approach your work with a better understanding of what each party (i.e. you and your dad/his company) can expect of each other, and makes it easier to place and evaluate demands each party has.

In any case, you should make clear that you cannot proceed without more contextual information and tell him his behaviour is somewhat unreasonable. You have to explain to him that his non-cooperation is acting as a blocking factor to your work. I'd also phase your work planning, with several go/no-go decision moments if you still can. You might try using ARM, tracers of some other pitching methods mentioned to get a foot in the door. When he rejects the possibilities you pitch, reiterate that without proper information you cannot create a good/better product, and make clear that your product has a much higher chance of not meeting expectations because of that.

The knowledge (knowhow/knowwhy) you have cannot be applied without knowing what to do (where/what within context). To make it tangible, you could use an analogy of a truck driver who needs a map to get where he needs to go. If he fails to comply, I'd dump the assignment if possible. It's probably very hard to fulfill the expectations if you don't know what to aim for.


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