优秀课件笔记english-writing专业英语写作5

 Elements of a Business Plan
• 1. Cover sheet
• 2. Statement of purpose
• 3. Table of contents
• I. The Business
• A. Description of business
• B. Marketing
• C. Competition
• D. Operating procedures
• E. Personnel
• F. Business insurance
• Financial Data
• A. Loan applications
• B. Capital equipment and supply list
• C. Balance sheet
• D. Breakeven analysis
• E. Pro-forma income projections (profit & loss
statements)
Three-year summary
Detail by month, first year
Detail by quarters, second and third years
Assumptions upon which projections were
based
• F. Pro-forma cash flow
恩格
• 1876 电话
• 1906 真空管
• 1940 第一双尼龙袜面市
• 1944
• 相对论,
人员构成
公司现有人员学历构成表
大学（本科及专
科）
66%
硕士以上
3%
其它
2%
中专以上（中专、
高中、职高及中
技）
29%
硕士以上
大学（本科及专科）
中专以上（中专、高中、职高及中
技）
其它
组织结构图
总经理产品经理1
产品经理2
产品经理3
资源主管
4.18
总务部
人力资
源部
招聘解聘 绩效考核
行政管理
人
力资源
物力资
源
培训
接受
投诉
执法处
罚
营销主管
4.3 4.5 4.18 4.19
销售部
市场部
各
办事处
客户中心 文档中心
市场管理
销
售运营
网站配合
广
告策划
物流与采购主管
4.6 4.7 4.9 4.15
采购工程部
物流系统 采购
外协
发货
、运输
技术主管
4.4 4.5 4.8 4.9 4.19
技术部
立项开发 项目进程管理
生产转化
技
术咨询
现场服务
财务主管
财务部
专家组
••数数据据成成批批更更新新
全全面面的的物物料料主主文文件件维维护护
••多多级级权权限限设设置置
••定定价价在在线线分分析析
••维维护护记记录录日日志志
••多多种种定定价价公公式式
灵灵活活的的定定价价方方式式
••日日期期敏敏感感性性
••多多优优惠惠条条件件组组合合
••营营业业税税分分摊摊
••运运费费核核算算
特特定定客客户户定定价价
••价价格格底底线线预预警警
••客客户户信信息息追追踪踪
••特特定定商商品品报报价价单单
•规格n
•规格1
客户群1
客户群n
•客户n
•客户1
客
户
总
体
经商品大类1
营
范
围商品大类n
•商品n
•商品1
行分类列分类
定价矩阵
定定价价管管理理
内部决策
••销销售售额额与与利利税税额额
••客客户户满满意意度度统统计计
••销销售售量量与与结结存存量量
••无无形形资资产产价价值值分分析析
经经营营状状况况统统计计分分析析
效效益益评评价价
经经营营环环境境
企企业业产产出出
企企业业投投入入••流流动动资资金金投投入入
••设设备备能能力力投投入入
••固固定定资资金金投投入入
••能能源源消消耗耗投投入入
••设设备备利利用用效效率率
••资资金金利利用用效效率率
••劳劳动动生生产产效效率率
••投投资资成成果果评评价价
••社社会会贡贡献献评评价价
••客客户户市市场场需需求求统统计计
••销销售售渠渠道道统统计计
••促促销销策策略略分分析析
••劳劳动动力力投投入入
••品品类类批批量量决决策策分分析析
••供供应应商商信信誉誉统统计计
••资资金金融融措措市市场场分分析析
内部决策
成本控制
内部决策
• 第一部分
概要
• 一、公司简介
• 二、产品及竞争
• 三、管理层及骨干
• 四、既有业绩与未来
• 五、资金需求及用途
• 六、融资方案及投资回报预测
• 第二部分
公司背景
• 一、公司业务发展历史
• 二、发展目标
• 三、公司性质及股本结构
• 四、现有资产状况和财务状况分析
• 五、公司支持体系（资金、市场、技术）
• 六、其他信息（已签合同、协议等）
• 第三部分
所有者/
管理者背景
• 一、股东背景及其股份比例
• 二、管理者简介
• 三、主要技术人员简介
• 第四部分
行业及市场分析
• 一、概要
• 二、生产方式介绍
• 三、目标市场
• 四、客户定位及描述
• 五、主要竞争对手及合作伙伴
• 第五部分
产品/
服务介绍
• 一、概述
• 二、详细描述
• 三、竞争对比
• 四、产品/服务的独到性
• 五、研究与发展
• 六、知识产权及保护
• 第六部分
市场计划
• 一、价格策略
• 二、促销战略
• 三、营销体系组建
• 四、市场增长计划及措施
• 第七部分
财务计划及分析
• 一、融资需求及可出让股份的比例
• 二、资金用途
• 三、投资回报预测
• 四、投资退出方式
• 第八部分
风险分析及对策
• 一、市场风险分析
• 二、技术风险分析
• 三、管理风险分析
BUSINESS PLAN
–
AMERICAN
MANAGEMENT TECHNOLOGY
• 1. Executive Summary
• 1.0 Executive Summary
• By focusing on its strengths, its key customers, and the
underlying values they need, American Management
Technology will increase sales to more than $9 million
in three years, while improving the gross margin on sales
and cash management and working capital.
• This business plan leads the way. In order to implement
these changes and improve profitability, we plan to
borrow another $100,000 long-term this year.
• AMT is built on the assumption that the
management of information technology for business
is like legal advice, accounting, graphic arts, and
other bodies of knowledge, in that it is not
inherently a do-it-yourself prospect. Smart business
people who aren't computer hobbyists need to find
quality vendors of reliable hardware, software,
service, and support. They need to use these quality
vendors as they use their other professional service
suppliers, as trusted allies. AMT seeks to fulfill
these needs and become the leader in business
information technology for its region.
• AMT provides both computer products and
services to make them useful to small
businesses. We are especially focused on
providing network systems and services to
small and medium business. The systems
include both PC-based LAN systems and
minicomputer server-based systems. Our
services include design and installation of
network systems, training, and support.
• AMT is a privately-held C corporation owned in
majority by its founder and president, Ralph
Jones. There are six part owners, including four
investors and two past employees. The firm
includes 21 employees, under the president
and four managers. Our main management
divisions are sales, marketing, service, and
administration. The service department handles
service requests, support, training, and
development. At present, we are weakest in the
area of technical capabilities to manage the
database marketing programs and upgraded
service and support, particularly with crossplatform
networks. We also need to find a
training manager.
• 例如：甲公司生产A、B、C、D四种产品，A、B、C、D
产品市场增长率分别为本11%、12%、6%、3%。而甲公
司这四种产品的年销售额分别为10、20、15、5，乙公司
这四种产品的年销售额分别为5、30、5、10（百万元）。
依上述资料，根据BCG方法我们得到甲公司A、B、C、
D四种产品的业务组合如下：
市场增长率
市场占有率
明星
A
问题
B
金牛
C
瘦狗
D
10%
1
高
高
低
低
市场增长率 市场占有率
11%>10% 高 10/5=2>1 高
12%>10% 高 20/30=0.67<1 低
6%<10% 低 15/5=3>1 高
3%<10% 低 5/10=0.5<1 低
• There are several different kinds of computer retailers
within the industry including:
• Computer dealers: often focused on a few main brands of
hardware, usually offering only a minimum of software, and
variable amounts of service and support. Their service and
support is not usually very good and their prices are usually
higher than the larger stores.
• Chain stores and computer superstores: usually offer decent
walk-in service, with very aggressive pricing, and little
support.
• Mail order: offer aggressive pricing of boxed product. For
the purely price-driven buyer, who buys boxes and expects
no service, these are very good options.
• We currently depend on newspaper advertising
as our main way to reach new buyers. As we
change strategies, however, we need to change
the way we promote ourselves. We will be
refocusing on our core message of service
through radio, cable TV, sales brochures, direct
mailers and newspapers. We need to sell the
company, not the product. We sell AMT, not
Apple, IBM, Hewlett-Packard, or Compaq, or
any of our software brand names.
• The Yearly Total Sales chart summarizes our
ambitious sales forecast. We expect sales to
increase from $5.3 million last year to more
than $6 million next year and to more than $9
million in the last year of this plan.

• Keys to Success
• Differentiate from box-pushing, price-oriented
businesses by offering and delivering service
and support -- and charging for it.
• Increase gross margin to more than 30%.
• Increase our non-hardware sales to 20% of the
total sales by the third year.
• 2. Company Summary
2 . C o m p a n y S u m a r y
• Company Ownership
• Company History
• Sales
• Gross Margin
• Gross Margin %
• Operating Expenses
• Collection Period (days)
• Inventory Turnover
• Balance Sheet
• Current Assets
• Cash
• Accounts Receivable
• Inventory
• Accumulated Depreciation
• 3.
Products and Services
P r o d u c t s a n d S e r v i c e s
• Product and Service Description
• Competitive Comparison
• Sales Literature
• Fulfillment :
• With the hardware lines, our margins are declining
steadily. We generally buy at ... Our margins are
thus being squeezed from the 25% of five years
ago to more like 13-15% at present. In the mainline
peripherals a similar trend shows, with prices
for printers and monitors declining steadily. We are
also starting to see that same trend with software ....
商业供应链系统 详细模式
定定价价管管理理
成成本本控控制制
经经营营状状况况统统计计分分析析
总总帐帐
应应收收帐帐
应应付付帐帐
现现金金管管理理
定定单单录录入入//开开票票
库库存存管管理理
采采购购管管理理
零零售售管管理理
分分销销管管理理
客客户户信信息息管管理理
供供应应商商信信息息管管理理
人人力力资资源源管管理理
流程管理
“链”管理
财务管理
内部决策
• Technology
• Service and Support
• Our strategy hinges on providing excellent service and support.
This is critical. We need to differentiate on service and support,
and to therefore deliver as well.
• Training: details would be essential in a real business plan, but not
in this sample plan.
• Upgrade offers: details would be essential in a real business plan,
but not in this sample plan.
• Our own internal training: details would be essential in a real
business plan, but not in this sample plan.
• Installation services: details would be essential in a real business
plan, but not in this sample plan.
• Custom software services: details would be essential in a real
business plan, but not in this sample plan.
• Network configuration services: details would be essential in a
real business plan, but not in this sample plan.
• Future Products and Services
• 4.Market Analysis Summary
4 . M a r k e t A n a l y s i s S u m a r y
• Market Segmentation
• Target Market Segment Strategy
• Market Needs
• Chain stores and computer superstores:
• Mail order
• Market Needs
• Market Trends
• The most obvious and important trend in the market is
declining prices. This has been true for years, but the trend
seems to be accelerating. We see the major brand-name
manufacturers putting systems together with amazing specs-
-more power, more speed, more memory, more disk
storage--at amazing prices. The major chain shops are
selling brand-name powerful computers for less than $1,000.
• This may be related to a second trend, which is the
computer as throw-away appliance.
• A third trend is ever greater connectivity.
• Market Growth
• Service Business Analysis
• Business Participants
• Distributing a Service
• Competition and Buying Patterns
• Main Competitors
• 5. Strategy and Implementation Summary
5 . S t r a t e g y a n d I m p l e m e n t a t i o n S u m a r y
• 6. Management Summary
6 . M a n a g e m e n t S u m a r y
• Organizational Structure
• Management Team
• Ralph Jones
, President: 46 years old, founded
AMT in 1984 to focus on reselling high-powered
personal computers to small business. Degree
in computer science, 15 years with Large
Computer Company, Inc. in positions ending
with project manager. Ralph has been attending
courses at the local Small Business
Development Center for more than six years
now, steadily adding business skills and
business training to his technical background.
7. Financial Plan
7 . F i n a n c i a l P l a n
• 7.1 Important Assumptions
Presentation Writing
• understand your task and audience
• structure your presentation
• frame your presentation
• select visuals, and
• practice for your speech
TECHINICAL WRITING IN
GENERAL
• Mistakes Technical Writers Make
• Not Understanding the Product or
Application
• Parroting the Subject-Matter Expert
(SME)
A common mistake among both SMEs and
writers is to assume that the user
understands the vocabulary.
• 一般认为，黑客起源于20世纪50年代麻省理工学院的实验室
中，他们精力充沛，热衷于解决难题。
• 60年代，黑客代指独立思考、奉公守法的计算器迷，他们利
用分时技术允许多个用户同时执行多道程序，扩大了计算器
及网络的使用范围。
• 7O年代，黑客倡导了一场个人计算器革命，他们发明并生产
了个人计算器，打破了以往计算器技术只掌握在少数人手里
的局面，并提出了计算器为人民所用的观点，这一代黑客是
计算机史上的英雄。其领头人是苹果公司的创建人史蒂夫﹒
乔布斯。在这一时期，黑客们也发明了一些侵入计算器系统
的基本技巧，如破解口令（Passwordcracking）、开天窗
（TraPdoor），等等。
• 80年代，黑客的代表是软件设计师，包括比尔·盖茨在内的这
一代黑客为个人计算机设计出了各种应用软件。
• 而就在这时，随着计算器重要性的提高，大型数据库也越来
越多，信息又越来越集中在少数人手里。黑客开始为信息共
享而奋斗，这时黑客开始频繁入侵各大计算器系统。如今的
黑客队伍人员杂乱，既有善意的以发现计算器系统漏洞为乐
趣的「计算机黑客」（Hacker），又有玩世不恭好恶作剧的
「计算机黑客」（Cyberbunk），还有纯粹以私利为目的，任
意篡改数据，非法获取信息的「计算机黑客」（ Cracker）。 　　

Working Without a Plan
Your plan should include:
• a list of the documents or chapters that will be
written
• the file-naming conventions that will be used
• the location in the network where the
documents will be stored
• the method by which the documentation will be
delivered to the customer
• he method by which the customer will access
the documentation
No File-Naming Convention
• Imagine that you are documenting a network
application called QDO. This network has four
nodes (named BBB, QETO, IB, and PBN), each
of which requires a product description,
installation guide, configuration guide, and user
guide. IB and QETO also require a command
reference guide, and since PBN includes a GUI,
it requires online help for 25 features, each of
which comprise the functions of Add, Modify,
and Delete. Confused? Unless you have a filenaming
convention, everyone else at work will
be too.
No Document-Numbering Plan
• Now let's say that, for every node your company
produces, you will create one or more of the following
documents:
• product description
• site preparation guide
• acceptance testing procedures
• installation guide
• configuration guide
• user guide
• command reference guide
• alarms and notifications guide
• troubleshooting guide
• maintenance procedures
• Not Using a Template
• Using a One-Size-Fits-All Template
tzaesFTgnpSAUOme
• Using a Bells-and-Whistles Template
all sorts of fancy features like:
grid marks,
crop marks,
tables to be used in this kind of document,
tables to be used in that,
headings for this and headings for that, all kinds
of automatic document-management features
• Multiple Tab Stops
• No Glossary
• Putting Information in the Wrong Order
Example
Incorrect: Select Style from the Format menu.
Correct: In the Format menu, select Style.
Poor Spelling
Future Tense
No Revision-Numbering Plan
• The revision number indicates which version of the
document the customer is using, and which version
you are writing.
• Version 1.0 is the original version of the document
for the first version of the product or application
• Version 1.1 is the first revision
• Version 1.8 is the eighth revision
• Version 2.0 is a completely new release of the
document for the second version of the product or
application
• Supporters of technology say that it solves
problems and makes life better.
Opponents argue that technology creates
new problems that may threaten or
damage the quality of life. Using one or
two examples, discuss these two positions.
Which view of technology do you support?
Why?
• Technology is improved especially in developed
countries. Our lives is connected to technology.
Technology is used in everyday life. People use it in
different ways. It can make our lives better, but it
can be cruel if it’s used for bad purposes.
First, technology makes our lives better because it
serves us well and helps us save time. As we can
see one of well-known inventions is internet. For
example, in the developed countries, Internet are
used in everyday life. It’ s used in schools and
businesses because it provides a lot of information
about anything all over the world.
• On the other hand, technology can be very
dangerous for us. Because of its ability of finding
information, our personal information can no
longer be sec ret. For instance, computers is
used to keep most of the information. In other
cases, hackers can search to our secret file and
steal the information via computer. Another
example is that some companies can search and
find information about us just by our credit card
receipts or checks. That could make our lives
worse than before.
• In short, technology gives us many advantages.
Abstract Writing
• An abstract is a stand-alone statement
that briefly conveys the essential
information of a paper, article, document
or book; presents the objective, methods,
results, and conclusions of a research
project; has a brief, non-repetitive style.
• What goes in an abstract?
• What is the style of an abstract?
Abstract
• Introduction
• Experimental Procedure
• Discussion
• Conclusion
• References
• Appendices
How do you write an abstract?
• Highlight the objective and the conclusions that
are in the paper's introduction and the discussion.
• Bracket information in the methods section of the
paper that contains keyword information.
• Highlight the results from the discussion or results
section of the paper.
• Compile the above highlighted and bracketed
information into a single paragraph.
• Condense the bracketed information into the key
words and phrases that identify but do not explain
the methods used.
• Delete extra words and phrases.
• Delete any background information.
• Rephrase the first sentence so that it starts off
with the new information contained in the
paper, rather than with the general topic. One
way of doing this is to begin the first sentence
with the phrase "this paper" or "this study."
• Revise the paragraph so that the abstract
conveys the essential information.
• Abstract: ATM networks have received a lot of
attention in the past few years, both in academia and
in the commercial press. Although a lot of the
promises are based on hype and not (yet) backed up
by working systems, ATM does have some features
that make it interesting as a network technology, both
in the sense that it creates new opportunities for
network users and creates new challenges for network
builders. I will first give a brief overview of ATM,
focussing on the traffic management issues. I will then
use simple examples to illustrate the two main traffic
management approaches that are currently being
pursued by the ATM community. Finally, I will give an
overview of the Credit Net project and discuss how it
addresses some of the open ATM research problems.
Thesis Writing
• Thesis Writing Manual
• Thesis Preparation Regulations
Graduate School Regulations Concerning
Thesis Preparation
Writing and Presenting Your
Thesis or Dissertation
• Introduction
• Summary of Key Ideas in this Guide
• The Thinking About It Stage
1.Be inclusive with your thinking.
2. Write down your ideas.
3. Don't be overly influenced by others-it's your research.
4. Try and set a realistic goal.
5. Set appropriate time lines.
6. Take a leave of absence when it will do the most good.
7. Try a preliminary study to help clarify your research.
Preparing The Proposal
• 8. Read other proposals.
• 9. Prepare a comprehensive review of the literature.
• 10. Photocopy relevant articles.
• 11. Proposal should be first 3 chapters of
dissertation.
• 12. Focus your research.
• 13. Include a title on your proposal.
• 14. Organize around a set of questions.
• 15. Some considerations for designing your
research:
• 16. Use your advisory committee well.
Writing The Thesis Or
Dissertation
• 17. Begin writing with sections you know the best.
• 18. Rewrite your proposal into dissertation sections.
• 19. Use real names/places in early drafts of
dissertation.
• 20. Print each draft on a different color paper.
• 21. Use hand drawings of graphics/tables for early
drafts.
• 22. Make your writing clear and unambiguous.
• 23. Review other dissertations before you begin to
write.
• 24. Introduce tables in the text, present the table
and then describe it.
• 25. Use similar or parallel wording whenever
possible.
• 26. Let your Table of Contents help you improve
your manuscript.
• 27. Write real conclusions and implications -
don't restate your findings.
• 28. Make your Suggestions for Further Research
meaningful.
• 29. Chapter One should be written last.
The Thesis/Dissertation Defense
• 30. Attend some defenses before it's your turn.
• 31. Discuss your research with others.
• 32. Don't circulate chapters to committee.
• 33. The defense should be team effort - you and
adviser.
• 34. Don't be defensive at your defense.
• 35. Organize your defense as an educational
presentation.
• 36. Consider tape recording your defense.
• 37. Prepare an article on the outcomes of your
research.
Agenda for Thesis Defense of
candidates for Master’s Degree
• The list of names of the chairman, members and
secretary of the thesis defense commission is
announced.
• The chairman of the thesis defense commission
announces the start of the thesis defense.
• The supervisor makes a briefing on the morality
and studies of the candidate.
• The candidate presents the main points of his
thesis (within the limit of an hour).
• Members of the commission ask questions.
• A recess of the 20-30 minutes ( in which the
candidate prepares to answer questions) is taken.
• The candidate answers questions.
• Members of the commission ask more questions.
The candidate answers each of them offhand.
• The thesis defense commission holds a secret
meeting to appraise the quality of the candidate’s
thesis and his answers to the questions asked. A
ballot is taken.
• The results of the appraised and the ballot are
announced.
• The meeting adjourns.
Writing Research Papers
• General form of a research paper
• Title page
• Abstract
• Introduction
• Materials and Methods
• Results
• Discussion
• Conclusion
• Acknowledgement
• Literature Cited (Reference)
General style
• To make a paper readable
• Mistakes to avoid
• In all sections of your paper
Lab Report/Test Report Writing
• Title Page
• Title
• Project Vendor
• Solution Provider
• Contact
• Date
THE IBM 360 ARCHITECTURE
T H E I B M 3 6 0 A R C H I T E C T U R E
• In mid-April 1964 IBM introduced the 360 family
of
computers.
• The beginning of modern computer architecture can
be dated from then.
• The profound intellectual innovation was the strict
separation of architecture from implementation
• The IBM, at that time, had about 6 or 7 separate and
incompatible product lines (this is in contrast to IBM's
line of punched card equipment which was one
consistent sequence of equipment):
• Some of the determining characteristics of these
"lines" were small vs. large computers, business vs.
scientific applications, history/technology,
organizational; e.g., Endicott vs. Poughkeepsie Labs
vs. San Jose Labs vs. World Trand (England); all
were independently designing computers.
• Lost economies of scale, particularly in
peripherals, research and development, ....
• Decided they would have one product line that
was upward and downward
compatible
(Upward compatible was common, you have a
program for one computer, then the next one up
would be designed to include all the instructions
and other capabilities of the original plus
"some"; you just wouldn't use the "plus some."
But going the other way was more difficult. How
could you run an application that was
programmed on a powerful computer with a rich
instruction set on a small computer with a small
set? It was not clear that this could be
accomplished.
• An idea of MV Wilke's (through IBM World
Trade) from the fifties provided the answer.
The solution was microprogramming
m i c r o p r o g r a m i n g
. The
idea was to build the architecture around
micro instructions. Then arbitrarily complicated
instructions (at the programmer level) could be
emulated by microprograms that were stored
non-volatilely in read only memories (ROM).
Firmware
F i r m w a r e
. Then for the small computers, the
instructions not available in hardware could be
emulated in firmware.
• April 7, 1964 IBM announced the IBM 360 family:
Models 30, 40, 50, 60, 62, 70 spanning a performance
range of about 25 to 1.
• The new family was incompatible with all the previous
lines (although emulators were implemented for most
of them, again based on microprogramming)
• Ultimately, the family evolved into the IBM 370
(announced in 1970), IBM 303x (beginning in 1977),
IBM 43XX (beginning in 1979), and IBM 308X (starting
in 1981) all with 360 architecture and resulting in a
performance range of thousands to one. 309X, (3090-
400 over 2000 times faster than the System 360
Model 30.
• Important firsts, integrated scientific and business,
upward and downward
compatibility, clear
demarcation between architecture and implementation,
multiprogramming, microcoded emulation.
Processor Products -- Final Report of
SPREAD Task Group, December 28, 1961
• This report recommends a new family of
compatible processors for the IBM product
line. A summary of the major points follows.
• 1. IBM customers' needs for general-
generalpurpose
processors can be most profitably
met by a single compatible [Top of Page 7]
family extending from the smallest storedfamily
storedprogram
core-memory machine to the
machine for customers growing beyond the
7094 and 7030.
• There are processor needs above and below
this range; it is not yet evident that these
can be compatible with the new processor
family.
• 2. Justification for the compatible family has
been established with respect to marketing.
It is clearly advantageous to development
and manufacturing.
Introduction
A. Mission and Objectives
• 1. The SPREAD activity was initiated to
establish an overall IBM plan for data
processor products. The plan is to encompass
all stored- program processor developments in
IBM, is to extend to 1970, and must consider
the following factors.
• a. Solid logic technology (SLT), which
promises improved cost/performance and
reliability.
• b. New market demands for systems capable
of multiterminal, on-line, real-time,
multiprogramming operation.
• c. The explosive growth in applied programming
demanded by a larger number of dissimilar
systems.
• d. The 15- 20 engineering groups generating
processor products and the need for the
establishment of consistency -- i.e., an IBM
"image" in the processor field.
• e. The need to resolve the interactions
between present and new processor products
across divisional and World Trade lines.
• 2. Faced with these present problems, the SPREAD
task force set as its objectives:
• a. The definition of a new line of processor products.
• b. The establishment of logical design, engineering,
and applied programming ground rules, within which a
processor product line consistent across divisions and
World Trade must be defined.
• c. The creation of a plan for the introduction of these
new products that will optimize the conflicting
demands of: (1) Market need. (2) Impact on present
installed processors.
• d. The initiation of an appropriate management
measurement and control mechanism to assure the
implementation of the SPREAD product concepts.
Software Requirements
Specifications
• An SRS is basically an organization's
understanding (in writing) of a customer
or potential client's system requirements
and dependencies
at a particular point in
time (usually) prior to any actual design or
development work.
• It's a two-way
insurance policy that assures
that both the client and the organization
understand the other's requirements
from that perspective at a given point in time.
• Reasons for Systems Projects
Information
Technology
Department
Existing
Systems
The
Economy
Government
Competitors
Customers
Suppliers
Technology
Strategic
Plan
Top
Managers
User
Requests
The SRS document itself states (in precise and
explicit language):
• functions and capabilities a software system
• any constraints
by which the system must
abide.
• An SRS contains functional
and
nonfunctional requirements
only;
it doesn't offer design suggestions, possible solutions to
technology or business issues, or any other information other
than what the development team understands the customer's
system requirements to be.
A well-designed, well-written SRS accomplishes
four major goals:
1.
It provides feedback to the customer:
2.
It decomposes the problem into
component parts
:
3.
It serves as an input to the design
specification:
4.
It serves as a product validation check:
Information-gathering stage can
include
• onsite visits,
• questionnaires,
• surveys,
• interviews,
• and perhaps a return-on-investment (ROI)
analysis or needs analysis of the customer or
client's current business environment.
What Kind of Information Should
an SRS include?
• 1. Interfaces
• 2. Functional Capabilities
• 3. Performance Levels
• 4. Data Structures/Elements
• 5. Safety
• 6. Reliability
• 7. Security/Privacy
• 8. Quality
• 9. Constraints and Limitations
• 1. Introduction
• 1.1 Purpose
• 1.2 Document conventions
• 1.3 Intended audience
• 1.4 Additional information
• 1.5 Contact information/SRS team members
• 1.6 References
• 2. Overall Description
• 2.1 Product perspective
• 2.2 Product functions
• 2.3 User classes and characteristics
• 2.4 Operating environment
• 2.5 User environment
• 2.6 Design/implementation constraints
• 2.7 Assumptions and dependencies
• 3. External Interface Requirements
• 3.1 User interfaces
• 3.2 Hardware interfaces
• 3.3 Software interfaces
• 3.4 Communication protocols and interfaces
• 4. System Features
• 4.1 System feature A
• 4.1.1 Description and priority
• 4.1.2 Action/result
• 4.1.3 Functional requirements
• 4.2 System feature B
• 5. Other Nonfunctional Requirements
• 5.1 Performance requirements
• 5.2 Safety requirements
• 5.3 Security requirements
• 5.4 Software quality attributes
• 5.5 Project documentation
• 5.6 User documentation
• 6. Other Requirements
• Appendix A: Terminology/Glossary/Definitions
list
• Appendix B: To be determined
the fundamental characteristics
of a quality SRS.
• Complete
C o m p l e t e
• Consistent
C o n s i s t e n t
• Accurate
A c u r a t e
• Modifiable
M o d i f i a b l e
• Ranked
R a n k e d
• Testable
T e s t a b l e
• Traceable
T r a c e a b l e
• Unambiguous
U n a m b i g u o u s
• Valid
V a l i d
• Verifiable
V e r i f i a b l e
summarizes the classes,
categories, and components of
SRS quality indicators.
• Shall
, Must or must not
, Is required to
, Are
applicable
, Responsible for
, Will
, Should
• Adequate, be able to, easy, provide for, as a
minimum, be capable of, effective, timely, as
applicable, but not limited to, if possible, as
appropriate, capability of, if practical
at a
minimum, capability to, normal
Sample SRS
• 1. INTRODUCTION
• 1.1 Purpose
• 1.2 Scope
• 1.3 Definitions, Acronyms, and Abbreviations
• 1.4 References
• 2. THE GENERAL DESCRIPTION
• 2.1 Product Perspective
• 2.2 Product Functions
• 2.3 User Characteristics
• 2.4 Assumptions and Dependencies
• 3. THE SPECIFIC REQUIREMENTS
• 3.1 Functional Requirements
• 3.1.1 Introduction
• 3.1.2 DFD
• 3.1.3 Inputs
• 3.1.4 Outputs
• 3.1.5 Processing
3.1.5.1 Validations
• 3.1.5.2 Tolerance limits
• 3.1.5.3 Exception conditions
• 3.1.5.4 Security Considerations
• 3.1.5.5 Error Recovery :
• 3.1.5.6 External Interface
• 3.1.5.7 Response Time Consideration
• 3.1.5.8 Sequence of output (in case of reports)
• 3.1.5.9 Estimated volume of transactions
• 3.1.5.10 Any assumptions made
• 3.1.5.11 Retention Period
• 3.1.6 Special Note
• 3.2 Performance Requirements
• 3.3 Design Constraints
• 3.3.1 Standards Compliance
• 3.3.2 Hardware Limitations
• 3.4 Attributes
• 3.5 External Interface Requirements
• 3.5.1 User Interfaces
• 3.5.2 Hardware Interfaces
• 3.5.3 Software Interfaces
• 3.5.4 Communications Interfaces
• 3.6 Other requirements
• 3.6.1 Other Requirement 1
• 3.6.2 Other Requirement 2
• 4. APPENDIX A - title
• 5. APPENDIX B - title
Writing Computer Instructions
• Organizing a procedure
Restrict yourself to information that is necessary for
the user to carry out the action.
Use a descriptive heading to forecast what is coming.
Use numbered entries to describe individual steps,
but use a bullet for a single-step procedure.
• EXAMPLE
E X A M P L E
– From the Tools
menu, click "Options
", and then click the
"Edit
" tab.
– …
– -or-
– From the Tools
menu, click "Options
".
– Click the Edit
tab.
– Make sure it is clear what a user should type
when user input is required. Try to format the
text in such a way that the user input appears
on a new line.
• Keep all steps of the procedure together.
Try to keep all steps on one page in
printed documentation, and keep a
procedure to one screen if used online.
Conventions for writing about
menus and commands
• Capitalize menu names, command and command
button names, dialog box titles and tab names as
you see them in the application interface.
• Do not capitalize interface elements used
generically, such as toolbar, menu, scroll bar, and
icon. Capitalize the names of functional elements
that do not have a label in the interface, such as
toolbars (the Database toolbar) and toolbar buttons
(the Insert Table button).
• Make menu names bold when you use them in a
procedure step.
• Put the options you choose from the menu in bold
and in quotation marks.
• How to ask for user input
• Key names, combinations and
sequences
• Short cut keys
• Sample Instruction 1 - WS_FTP Pro for
Windows 95/98/NT
• Sample Instruction 2 - Simple
Registration
Servlet
Documentation & Report Writing
• Report Overview
• Part 1 - short!
• Introduction
• ... what you're going to describe
• Part 2 - the majority!
• The description itself
• Part 3 - short!
• Summary
• ... of what you've described
• Introductory Material
• Chapter 1 Problem Definition
• Chapter 2 Related Work
• Chapter 3 Outline Solution
• Chapter 4 Detailed Design
• Chapter 5 Testing & Validation
• Chapter 6 Future Development
• Chapter 7 Conclusion - Solution Summary
• Appendix I References
• Appendix II Test Material
• Appendix III User Manual
• Appendix IV Relevant Code
Planning User Documentation
• PLANNING USER DECOMENTATION
• – A GUIDE FOR SOFTWARE PROJECT
MANAGER
Roles and Responsibilities
• Who should write the documentation?
• The programmers themselves
• A contracted technical author
• Outsourcing
• Who should review my documentation?
• Who should manage my documentation?
• Spreading the authoring work more evenly
• Look and feel of the Help system
• Structuring the Help system
• Conceptual topics
• Summary
IT Project Proposal Preparation
Primer
• what needs to be done and why,
• when it needs to be done and how,
• who is going to do the work,
• how much will it cost,
• the alternatives and risks.
• Helpful Tips To Get You Started
• Helpful Tips for Proposal Development
• Helpful Tips About Proposal Contents
• Helpful Tips for Submitting Your Proposal
• Elements of a Good Project Proposal

The Story of the Trojan Room
Coffee Pot
• Late 1991 A group of thirsty researchers including
Paul Jardetzky and Quentin Stafford-Fraser point a
camera at a coffee pot and write custom software to
allow the image to be displayed on all their screens.
• Feb 1992 Bob Metcalfe writes about XCoffee in
CommWeek
• Feb 1993 Marc Andreessen proposes that a new IMG
tag be added to HTML to allow images to be
embedded in web pages.
• Mar 1993Beta release of NCSA Mosaic 0.10 contains
support for embedded images.
• November 1993Dan Gordon modifies original system
to allow it to respond to web requests. With Maryyn
Johnson, he connects it to the web, and XCoffee is
transformed into the first webcam.
• ?/td> A huge amount of media coverage over the next
few years. We start to keep a list but then lose track.
• May 1995 Enough people ask about the story that we
publish the Trojan Room Coffee Pot Biography.
• 1996?Hits on the Coffee Pot image pass one million.
Journalist Steve Farrar points out that it has had more
'visitors' than King's College Chapel and is therefore
the number one tourist attraction in East Anglia. More
media coverage.
• May? 1998 Hits on the Coffee Pot image pass 2
million?/td> Media start to describe pot as
'historical item' instead of 'novelty'.
• April 2001 News spreads that the impending
move of the Computer Lab means that camera
will be switched off. Much media coverage
including front page of both London Times and
Washington Post.
• July 2001 Article subtitled "When Convenience
was the Mother of Invention" appears in the
Communications of the ACM.
• Aug 2001 Longest-serving pot is auctioned on
eBay to raise money for coffee facilities in the
new lab. Sold to Spiegel Online for £3350.
• Several people have asked about the origins of the
Trojan Room coffee pot. It started back in the dark
days of 1991, when the World Wide Web was little
more than a glint in CERN's eye. I was working on
ATM networks in a part of the Computer Lab known as
the Trojan Room, (a name which, perhaps, causes
some amusement to American readers). There were
about fifteen of us involved in related research and,
being poor, impoverished academics, we only had one
coffee filter machine between us, which lived in the
corridor just outside the Trojan Room. However, being
highly dedicated and hard-working academics, we got
through a lot of coffee, and when a fresh pot was
brewed, it often didn't last long.
• potOperStatus
• SYNTAX Integer {
• off(1),
brewing(2),
• holding(3),
• other(4),
• waiting(5)
• }
• Some members of the 'coffee club' lived in
other parts of the building and had to
navigate several flights of stairs to get to
the coffee pot; a trip which often proved
fruitless if the all-night hackers of the Trojan
Room had got there first. This disruption to
the progress of Computer Science research
obviously caused us some distress, and so
XCoffee was born.
• In the Trojan Room there were several racks of simple
computers used in the testing of our networks. One of
these had a video frame-grabber attached and was
not being used at the time. We fixed a camera to a
retort stand, pointed it at the coffee machine in the
corridor, and ran the wires under the floor to the
frame-grabber in the Trojan Room.
• Paul Jardetzky (now working in California) then wrote
a 'server' program, which ran on that machine and
captured images of the pot every few seconds at
various resolutions, and I wrote a 'client' program
which everybody could run, which connected to the
server and displayed an icon-sized image of the pot in
the corner of the screen. The image was only updated
about three times a minute, but that was fine because
the pot filled rather slowly, and it was only grey-scale,
which was also fine, because so was the coffee.
• This system only took us a day or so to construct but was rather
more useful than anything else I wrote while working on
networks. It also made a better topic of conversation at dinner
parties than ATM protocols.
• The first published record of XCoffee came when Bob Metcalfe
wrote about it in Comm Week on 27th January 1992 after
visiting the lab, and inspired by this success, there was talk of
other monitoring applications using low-frame-rate video.
Systems such as XSandwichVan and XPrinterOutputTray were
mooted, but the elderly frame grabber eventually gave up the
ghost, Paul and I moved on to other things, and the Trojan
Room coffee pot would have sunk into obscurity had not Daniel
Gordon and Martyn Johnson resurrected the system, treated it
to a new frame grabber, and made the images available on the
World Wide Web. Since then, hundreds of thousands of people
have looked at the coffee pot, making it undoubtedly the most
famous in the world.
• I don't think the coffee's any better, though.
The Back of the Envelope
• A Story
• It was in the middle of a fascinating conversation on software
engineering that Bob Martin asked me, ``How much water flows
out of the Mississippi River in a day?'' Because I had found his
comments up to that point deeply insightful, I politely stifled my
true response and said, ``Pardon me?'' When he asked again I
realized that I had no choice but to humor the poor fellow, who
had obviously cracked under the pressures of running a large
software shop.
• My response went something like this. I figured that near its
mouth the river was about a mile wide and maybe twenty feet
deep (or about one two-hundred-and-fiftieth of a mile). I
guessed that the rate of flow was five miles an hour, or a
hundred and twenty miles per day. Multiplying
1 mile x 1/250 mile x 120 miles/day ~ 1/2 mile3/day
showed that the river discharged about half a cubic mile of
water per day, to within an order of magnitude. But so what?
• At that point Martin picked up from his desk a proposal for the
communication system that his organization was building for
the Summer Olympic games, and went through a similar
sequence of calculations. He estimated one key parameter as
we spoke by measuring the time required to send himself a
one-character piece of mail. The rest of his numbers were
straight from the proposal and therefore quite precise. His
calculations were just as simple as those about the Mississippi
River and much more revealing. They showed that, under
generous assumptions, the proposed system could work only if
there were at least a hundred and twenty seconds in each
minute. He had sent the design back to the drawing board the
previous day. (The conversation took place about a year before
the event, and the final system was used during the Olympics
without a hitch.)
• That was Bob Martin's wonderful (if eccentric) way of
introducing the engineering technique of ``back-of-theenvelope''
calculations. The idea is standard fare in engineering
schools and is bread and butter for most practicing engineers.
Unfortunately, it is too often neglected in computing.
• Rules of Thumb. I first learned the ``Rule of 72'' in a
course on accounting. Assume that you invest a sum
of money for y years at an interest rate of r percent
per year. The financial version of the rule says that if
r times y = 72, then your money will roughly double.
The approximation is quite accurate: investing $1000
at 6 percent interest for 12 years gives $2,012, and
$1000 at 8 percent for 9 years gives $1,999.
• The Rule of 72 is handy for estimating the growth of
any exponential process. If a bacterial colony in a
dish grows at the rate of three percent per hour, then
it doubles in size every day. And doubling brings
programmers back to familiar rules of thumb:
because 210=1024, ten doublings is about a
thousand, twenty doublings is about a million, and
thirty doublings is about a billion.
• Suppose that an exponential program takes ten
seconds to solve a problem of size n=40, and
that increasing n by one increases the run time
by 12 percent (we probably learned this by
plotting its growth on a logarithmic scale).
• The Rule of 72 tells us that the run time doubles
when n increases by 6, or goes up by a factor
of about 1000 when n increases by 60.
• When n=100, the program should therefore
take about 10,000 seconds, or a few hours. But
what happens when n increases to 160, and the
time rises to 107 seconds? How much time is
that?
• Suppose that an exponential program takes ten
seconds to solve a problem of size n=40, and
that increasing n by one increases the run time
by 12 percent (we probably learned this by
plotting its growth on a logarithmic scale).
• The Rule of 72 tells us that the run time doubles
when n increases by 6, or goes up by a factor
of about 1000 when n increases by 60.
• When n=100, the program should therefore
take about 10,000 seconds, or a few hours. But
what happens when n increases to 160, and the
time rises to 107 seconds? How much time is
that?
• You might find it hard to memorize that there
are 3.155x107 seconds in a year. On the other
hand, it is hard to forget Tom Duff's handy rule
of thumb that, to within half a percent,
Pi seconds is a nanocentury.
Because the exponential program takes 107
seconds, we should be prepared to wait about
four months.
• Little's Law states that `The average number of things
in the system is the product of the average rate at
which things leave the system and the average time
each one spends in the system.' (And if there is a
gross `flow balance' of things entering and leaving, the
exit rate is also the entry rate.)
• if you're in line waiting to get into a popular nightspot,
you might figure out how long you'll have to wait by
standing there for a while and trying to estimate the
rate at which people are entering. With Little's Law,
though, you could reason, `This place holds about 60
people, and the average Joe will be in there about 3
hours, so we're entering at the rate of about 20 people
an hour. The line has 20 people in it, so that means
we'll wait about an hour. Let's go home and read
Programmer instead.' You get the picture.''
• Peter Denning succinctly phrases this rule
as ``The average number of objects in a
queue is the product of the entry rate and
the average holding time.'' He applies it to
his wine cellar: ``I have 150 cases of wine
in my basement and I consume (and
purchase) 25 cases per year. How long do
I hold each case? Little's Law tells me to
divide 150 cases by 25 cases/year, which
gives 6 years per case.''
Rabbit
• The rabbits have powerful reproduction ability.
One pair of adult rabbits can give birth to one
pair of kid rabbits every month. And after m
months, the kid rabbits can become adult
rabbits.
• As we all know, when m=2, the sequence of the
number of pairs if rabbits in each month is
called Fibonacci sequence. But when m<>2,
the problem seems not so simple. You job is to
calculate after d months, how many pairs of the
rabbits are there if there is exactly one pair of
adult rabbits initially. You may assume that
none of the rabbits dies in this period.
• Input : the input may have multiple test cases.
In each test case, there is one line having two
integers m(1the number of months after which kid rabbits
can become adult rabbits, and d is the number
of months after which you should calculate the
number of pairs of rabbits. The input will be
terminated by m=d=0.
• Output:
• you must print the number of pairs of rabbits
after d months, one integer per line.