How to formalize feature requests
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:
Require feature requests be written down with the appropriate requirements.
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?
No comments:
Post a Comment