If it is hard to overstate the importance of requirements analysis, it is even harder to effectively conduct one. The complaint we keep hearing from other software developers is "How can I build a system without knowing what it is?" To certain extend, the complaint reveals the first part of the difficulty - we simply do not have enough requirements to analyze. Since software development is such an intellectual and specialized process, many customers cannot (at least at reasonable cost) describe down to the technical details what the final system would look like. Most likely they expect a system to expand the business capacity, cut cost, deliver superior services, or leap ahead of competitors. If software developers inherit the mindset of waiting for clearly formulated requirements from customers, they will be stuck in endless waiting or forced to build the software blindly.
At WISETEL, we build a different mindset. We get as much information as we can from you, the customer, but take the responsibility of formulating requirements for you. So it is perfectly OK for you to state only business goals and benefits, or provide further technical details and constraints. After analyzing the information thoroughly, we apply our domain expertise and software experience, and define clearly what the requirements are, what the cost would be, and how you can verify. In simple words, we define, you decide. You may be surprised by what you get, but you will agree what you get makes sense. We can do that because of our ownership-taking attitude. We never stop at knowing just about the system. We go one step further to understanding the industry background, the marketing trend, the company environment, the business competition, and the technological state-of-art. As experienced analysts, architects and software developers, we do whatever takes to formulate a system we believe to be the best you can get at the investment you are willing to make. So you may not get what you expect, but you will certainly get what you deserve. Through our experience, we learned that this is the way that shall be, and properly the only way that would work effectively. There are three good side-effects of this requirements formulation approach: (1) we would have the corresponding software vision and architecture in place to support the requirements. So there is no extra transfer of knowledge and potential lost or distortion of information after the requirements are formulated; (2) we would have the software testing strategy in place so that from the very beginning you know how to verify whether the final system meets those requirements; (3) you get educated along the way of working with us and reviewing our outcomes so that you understand not only the requirements are but also the reasons behind them.
Now you get a complete description of the system and you know clearly where it comes from and how to verify it. Things are pretty sunny, right? Unfortunately, life is never that easy, especially when we talk about describing a complicated software system that is going to be built by a group of intelligent people, through a certain period of time. The challenge comes from the second part of difficulty in requirements analysis, the changing dynamics of requirements. As we have embraced many years ago and now gradually become the consensus of software industry, requirements can never be accurately defined, and they are changing constantly. Yes, you read it right, even the requirements we formulate for you won't be accurate and for sure will change. The reason is very simple - software development process is also a cognition process, which is always iterative and open-ended. As long as we figure out or build something, you would move up to better understanding, and as the result, have some requirements that are new, deeper or different. Another force behind the changing requirements is the different paces of business and engineering activities. Software always takes time to build, but market and company situations can change much faster. Even before the software is completed, the situations have changed, and the changes would violate certain assumptions the initial requirements were formulated upon. Since software is much easier to be modified physically, there is always pressure to make requirements changes along the way of software development, add new features, add more details or change the existing specifications. So any efforts of defining 100% accurate requirements that can last through the whole life cycle not only doom to fail (at high cost), but also miss the point. Part of the values of software system is the ability to adapt to changes so that the business benefits can be maximized. Yes, embracing changes is never easy, but whoever can do it will stand out in competition. So the point is not how to make requirements more accurate and last longer. The point is how to build a system that is adaptive and agile. You certainly hear people say "How can you expect me to shoot a moving target?" Well, the nature of software development is similar to shooting the moving target, and any misunderstanding of that will certainly lead to project failures, resource wastes and even political battles. To be successful in building software systems that are adaptive to requirements changes, we must use the proper strategies to formulate the requirements in the first place. Learning from our own successes and failures, we have formed a so-call "three circle" strategy to effectively deal with the moving-target nature of requirements. Because the purpose of requirements formulation is to guide the development process and test the final system, the usefulness of the requirements is not judged by how accurate they are, but by how robust they are. Our goal is to formulate the requirements that can foresee the changes in the future and can be supported at reasonable costs.
