2

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?

  • 1
    You "thought of" requiring feature requests to be written down? Are you saying that currently your product planning is conducted orally? That is a surefire way to disaster. Anyone who can't be bothered to set down at least the beginnings of the desired behaviour in an email doesn't deserve to get it. – Kilian Foth Aug 8 '13 at 19:23
  • Feature requests boil down to What, When, Who, and Where can we send the bill. It's our job to do the How and actually do it. – Rob van der Veer Aug 8 '13 at 19:29
  • @Kilian, Yes and I agree. As I said, I'm new to software development and I'm trying to figure out industry-standards. I would like to require feature requests be written down, but I want to make sure I'm not neglecting my responsibility as a developer before I start to do so. – fbynite Aug 8 '13 at 19:43
  • @RobvanderVeer - you can't do the 'how' if you have not clarified 'what' and that takes a conversation which both parties have some responsibility. – JeffO Aug 8 '13 at 21:25
  • @JeffO i never said to skip the talks! In my experience the feature request is taken too far into a complete work item. Stay focussed on getting down to the request, not the solution. – Rob van der Veer Aug 8 '13 at 21:28
6

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.

5

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.

  • 1
    This is exactly right. I'll just add that experience should teach you the right questions to ask. Go through the process enough times and you'll continually get better at gathering requirements. – Matt S Aug 8 '13 at 19:33
  • Do not confuse a feature request with a Plan of Approach or an Elaboration Fase. – Rob van der Veer Aug 8 '13 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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