Good Requirements - Part VII - Feasibility
To summarize the previous 6 posts:
- Present requirements as simple, eloquent and atomic statements. By doing this, one increases the clarity and ease of testing them.
- Define a structure for your requirements. This will allow one to determine the completeness of a body of work as well as make it easier to attain consistency.
- Another benefit of a defined requirement structure is that it can make one's body of work more traceable. End-to-end traceability increases confidence.
This post will talk about requirement feasibility. For requirements, feasibility means that a requirement can be accomplished within cost and schedule. Personally, I find determining whether a requirement is feasible or not to be a difficult thing.
There are no easy guidelines for determining what is feasible. People, groups and companies have different competencies; thus what is feasible for one group may not be feasible for another group.
During the initial requirements gathering stages, I suggest focusing on making requirements succinct and complete. I feel that the requirement gathering process should answer the question, "What do you need?"
To determine if something is feasible or not, is an attempt to answer, "How do we do it?" By adhering to my previously mentioned guidelines, one will allow solution architects and system designers to understand and attempt to answer this question.
2 comments:
Hi nice article.. could tell me how to answer the following interview question?
"How do you handle a requirement that is not feasible?"
Awaiting your response.
Hello Sruni,
First of all, this is a very interesting interview question; one I would expect to catch a lot of people off guard.
Allow me to set the context for my response to ensure I'm answering you correctly. You've gathered the business requirements from the client. The development team is now examining them and comes to the conclusion a specific requirement is not feasible.
Here are my thoughts:
How important is the requirement? How much value does it deliver?
If it doesn't deliver much, then a case can be made to state the requirement will not move into development. I'm a big fan of having high-level objectives defined before doing business requirements - you can use this to show how valuable the requirement is. Have a frank discussion with the client, "From a cost-benefit perspective this requirement might not be worth it."
If it is definitely required, why is it considered infeasible by the design team?
(1) Because it's beyond their expertise? They can investigate external consultants for help.
(2) Because it is impossible (look up the traveling salesperson problem.) Are there mechanisms to come up with an optimal answer (not the perfect one?) Explain why the client can only get an optimal solution and the limitations of the solution they are getting.
I hope that helps and I hope I've answered your question.
Post a Comment