In my previous article, I wrote about the very basic concept of the importance of gathering requirements before any design work is done. My advice in that article was very general and broad. What I’d like to do in these next series of articles is to provide more detail about gathering requirements from an ASIC designers point of view. Hopefully I’ll be able to provide valuable advice and some insight into some of the day-to-day tasks I typically do as an ASIC engineer. As always, comments, helpful tips, and questions are welcome.
First, I’d like to emphasize a top-down approach when obtaining requirements. The idea being to start from a broad, 100,000 foot level and work your way to the ground-level details of the design.
This particular article will focus on Who to get requirements from. In this case, start with people who have broad-based knowledge of what your product requirements are, then, as you begin understanding high level needs, methodically obtain lower level requirements from people who have intimate knowledge in key areas. Start at the highest level (Level 10) and work down to the lowest level (Level 0).
Level 10. Marketing Folks
In many business books, its about getting to know your customer. Unfortunately, rarely do ASIC engineers interface with customers. So, the first line to customers will have to be the Marketing people. Gathering requirements from Marketing people can be seemingly tricky and fluid. It sometimes is difficult to nail down what is needed or wanted. In my view, marketing people tend to request building in many features. It seems as though, if possible, the product could have almost every feature dreamable, have high performance, low power, built right away, and cost very low. I believe its because of the notion that, if function x, y, and z is in the chip, it would make it more marketable and sellable. Ofcourse, its very difficult to have it all. Sometimes features are a list of items that are rarely used but added simply to be competitive against other products.
Marketing is trying to keep existing customers happy and trying to gain new customers. From a set of requirements, it usually is difficult to know which are meant to please existing customers, which are feature lists to compete against competitors, which are ideas from internal marketing, and which are dreamt up features from the Technology Office. I believe this is important and I’ll write more about this later on in follow-up articles.
In my experience, an ASIC engineer doesn’t have direct access to a Marketing person. Maybe some email or hallway conversations are possible between ASIC engineers and Marketers, but on the whole, ASIC engineers tend not to be invited to the discussion table. It is usually a Director of ASIC Engineering, VP of ASIC Engineering, or Project Manager that has access to discuss and negotiate the requirements. In some companies, only indirect access is available in the form of a document containing a list of high level requirements and their priorities . If not already available, try to obtain a formal requirements document from the Marketing department. That is, if your boss or project lead doesn’t have it already. At the very least, the requirements document should have a feature list and their priorities. At best, it should contain usage scenarios for your product and why a requirement is needed. In this way, you know the relative context of the product and it will help guide you through design decisions. Keep in mind that these requirements could change during the course of development so it is a good idea to periodically check for updates.
What is interesting sometimes is, if the end product is an evolutionary step from a previous product, try to get your hands on the previous product’s requirements document and compare the differences. Which items are different? What are the new requirements attempting to address?
Level 9. Your Boss
After you’ve reviewed the requirements document, the next person to go to is your boss. Try to get a feel for the important items on the list. For instance, some items listed could already be implemented but are in the document for completeness so it isn’t necessary to spend time on them. If raises, promotions, and bonuses are important to you, it is important to work on areas that are critical to the company’s success. By linking yourself to key areas, you will be recognized for a job well done. Raises are best backed up by aligning your goals to your boss’s goals.
You may have a module that you are currently responsible for. If so, your boss probably expects you to continue to maintain or enhance your piece of the chip. As an ASIC engineer, the key here is to see how your piece is involved to meet those requirements. How could your module be modified to efficiently, with minimum risk and schedule impact, address the requirement?
In some cases, you may be not have a module to work on or are ready to try your hand on something new. My advice would be to see which requirement feature you’d enjoy working on and volunteer to head up or be part of that project and mention it to your boss. Some bosses may not be ready to start handing out pieces of work, so at such an early stage, it would be a good idea to start meeting with other designers to see where help is most needed. Some engineers, who are already responsible for some modules, are the default designers for a particular feature. They may need some help or are ready to offload some design work.
(To be continued)
