Software systems are generally built to satisfy a set of requirements. Unfortunately, typical requirement documentation states the intended solution rather than present the key problem. But, to build good software, the developers need access to the problem statement, ideally a set of pain points for each category of user. Why bother?? Because the developers are able to make better decisions.
A well stated pain point should be::
1. Specific (Clear, context sensitive and well scoped)
2. Measurable (ideally objectively, but appropriate subjective measures can work)
3. Current (as opposed to may happen in the future)
---
A simple example to illustrate my point::
Solution: "I want to take Road-43 and taken exit-10 to arrive at the airport"
Pain point: "I need to catch an international flight at 4:45pm from Airport-X, I am currently in Location-Y"
Software documentation is often provided as a set of solution statements.
This hides the context as well as the real issue making it harder (than it already is) for the developers (or problem solvers) to find the most effective solution.
Why does this matter? Because, software development is all about making a series of decisions. Decisions made with the context of the real problem are very different from those we make if the input is a partial solution. Good decisions more of then than not lead to good software.
------
Note: I am capturing these thoughts to be refined into a set of notes on how to go about building software systems. Feedback/comments are very much appreciated. I may edit old posts to clarify and better state my ideas as well.
1 comment:
IT companies are gaining popularity with every passing day and tend to grow at a rapid speed. Software development procedures are getting purifies and verified with a brilliant merge of existing and new technologies everyday. Due to the massive demand of automation and perfection, many organizations are now opting outsourcing software development in order to meet their business needs
Post a Comment