To Gather Requirements, from those who don't want to give time for interviewing?

Question

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 ?

Answer 1

It is 100% OK that your customer (in this case your Dad) doesn't want to bother with interviews to gather requirements as interviewing is but one method useful for requirements elicitation.

A few methods immediately come to my mind in this situation. If it were me, I'd probably pick and choose pieces of each of these to figure things out.

1. ARM - Accelerated Requirements Method.
2. Contextual Design, or Contextual Inquiry
3. Tracer Bullets
4. Straw Man SRS (Software Requirements Specification)

ARM

The Accelerated Requirements Method is a structured, fast, and relatively simple way to gather high level functional requirements. For this project you probably wouldn't need to apply the whole method, but instead focus on the "Brainstorm, Organize, and Name" phase. Basically you prompt a 7 minute brainstorming session with a question specific to some aspect of the project: "An important requirement of my day-to-day work is _." The point is to focus the brainstorming. Next you'd group and remove duplicates (shouldn't be too hard with one stakeholder...) and prioritize the gathered requirements by multi-voting. You might use some requirements to dive deeper in subsequent BON sessions. And you don't have enough stakeholders for multi-voting so you'll have to prioritize other ways.

See this case study from the SEI for an example using ARM to gather security requirements.

Contextual Design

It sounds like a big piece of what you're missing is domain knowledge in which case contextual design could really help. There's a book by Beyer and Holtzblatt which explains the entire process. You will be most interested in the contextual inquiry phase in which you essentially observe users as they do what they do. The idea is to be a as much a "fly on the wall" as possible and ask questions go gain insight about what a user is doing, why they are doing it, artifacts they are using, and so on. You can find out all kinds of interesting things just by watching a person in their typical day that they might not be able to otherwise describe, or might not even know themselves.

This could actually be pretty fun, and informative, and a great chance to spend time with your Dad and learn more about what he does (my Dad's job was always a mystery to me growing up).

Tracer Bullets

In this case, given that the relationship with the stakeholder (your Dad) is informal, the easiest thing to do might be to just start creating tracer bullets and see what you can hit. Tracer Bullets are a form of rapid prototyping where you acknowledge that, what you're doing is a prototype, an exploration but it will likely be included in a part of the system you're building too. You can start with paper prototypes and sketches, or it might be easier to create something more high fidelity using a tool like Balsamiq or HTML with JavaScript. The point is, give your stakeholder something to play with and he'll start telling you how to improve it to meet his needs.

Straw Man SRS

In the same vein as tracer bullets, put something in front of your Dad and he'll start telling you what's wrong (or right) with it. In this case, maybe you'd right a couple of user stories or use cases and take them to him for feedback. The trick when using any kind of straw man is to make sure that he actually reads/evaluates it and to avoid playing "wrong rock" (in which whatever rock you bring back is always the wrong one). Be sure to ask what he doesn't like about a proposed requirement in the straw man so you're not left guessing - otherwise you'll likely be wrong again!

Answer 2

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.

Answer 3

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.

Answer 4

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.