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.