How to formalize feature requests

Question

I'm new to developing software and have been handling feature requests for an internal web-app I built.

Sometimes the feature requests are straight-forward and require minimal business logic for me to implement, so I talk to the person for a bit, write their requirements down, and get to work.

However, I'm starting to work on feature X where X has dark-corners of business-logic and special-case scenarios keep on popping-up because I didn't ask the right questions and/or the person I'm speaking with didn't think about mentioning it.

So I'm curious, how do professionals handle this process? Some things that I thought of are:

1. Require feature requests be written down with the appropriate requirements.

2. Understand their job well-enough so I can do mine.

An example to illustrate a similar problem is, implementing government regulations in code. I researched the regulations, created a flowchart and went from there. I could have saved a couple days had someone well-versed in said regulations, written the requirements down and handed them to me.

I'm doing the same thing for feature X, except, nothing is written down so I'm unable to deduce their business logic without going through a step-by-step process through their job. Even that fails sometimes, because some special-case wasn't present that day.

Using the above example, is it the responsibility of the developer to research this or something that should be provided?

Any suggestions for making this process go a bit smoother?

Answer 1

The problem you depict has no general solution. You have internal clients (I guess from your question), which are professionals in their field, but of course not specialists in formalizing requirements.

In short: it's your task as a programmer to understand the domain well enough to build software. Try to build up a glossary of terms/grasp the language your client speak. Do not expect their logic to be perfect.

Also, do not try to make requirements extraction process itself too formal. Iterative development process may help the clients to see missing pieces. Prototypes are also useful. Some clients may be stressed that you do not understand things, which are obvious (to them). Just observing their business process may give you lot of insights.

Read those regulations yourself when possible. Try to find someone, if you don't understand specific moments.

Unless your clients are technically inclined, it's futile to impose formalities (or even your "process") on them. Even worse to speak software-domain language instead of problem-domain language.

However, every situation is unique. The best thing is to gather more experience in the problem domain. Just be open-minded to understand problem-domain to the extent needed to build software. Friendly atmosphere also helps a lot. People may get tired of dull req gathering sessions.

There are some books on the topic. For example, some parts of http://www.amazon.com/Just-Enough-Requirements-Management-Development/dp/0932633641 ("Just Enough Requirements Management: Where Software Development Meets Marketing" by Alan Mark Davis) can help to understand how reqs gathering is done on larger scale. Of course, famous "Code Complete" by Steve McConnell can also give some good insights.

Even if your organization has someone, whose job is writing requirements, it may help to participate in the process to at least give earlier feedback on technical feasibility. If there is no person for that, all that is developer's responsibility.

Answer 2

It seems the question you're asking is about up-front requirements. Users can provide everything in writing and still not be clear enough for you to write any code. You can require all the contracts you want, but they'll still come back and indicate it's not what they want (Time-cost decisions are another question.).

There are some technical details that you need to do. Going back and forth on clarifying requirements isn't uncommon. In some places, there are business analysts and architects who may do a lot of this, but then the communication still needs to happen. Usually, they're more equiped to understand what you need.

The responsibility is on both parties and there is no perfect spot in the middle of the road where you two will always meet.