产品研发流程程序文件
体外诊断试剂盒研发流程
研发控制程序 1：设计策划 1：产品工艺以及 2：设计输入 原材料采购研发流程
体系研究资料 3：设计输出 2：形成产品标准 4：设计评审
3：稳定性研究资
5：设计验证1：采购控制程序 料 6：设计确认 2：原料技术指标及
1：产品工艺初步调试 4：性能评估资料 7：设计更改
质量要求
2：标准品的定标测试 5：临床资料
:3：供方评估方案
3：产品工艺的改善 6：形成产品说明 4：合格供方名录及资质
4：性能测试（准确度、 书
精密度、灵敏度、线性、 对应的记录文件
与对照试剂盒相关性等）
1：设计策划
5：产品稳定性研究
2：设计输入1：采购文件 6：参考值范围确定
3：设计输出2：原料验证记录7：临床试验
4：设计评审3：质控血清记录8：形成研发记录 5：设计验证 6：设计确认 7：设计更改
资料调研
方法学确立
研发有关的质 量体系文件
研发过程
报告编写
1：化学发光免疫法
2：化学发光酶免法
3：酶联免疫等 4：检测仪器
原料的购买及其检验标准品的确定对照试剂盒的选择
产品工艺初步确定标准品实验 产品工艺进改进
性能测试
临床实验参考值确定稳定性研究。
新产品开发流程及ECR流程图
新产品开发流程图产品科(包括图样设计,成品编码,原材料开发)研发部工程部生产部IE业务部采购价格科重新打样小批量试产样与客户确认价格根据客户所提供的信息要求进行产品外观设计Yes木架结构设计核算最终成本工作中心建立Yes1.成品临时编码2.原材料临时编码(针对客户的开发)No缝套设计YesYes成品样品试作采购对原物料进行大货采购Yes根据产品科提供的产品外观设计进行产品内部结构设计No采购下单购买样品所需材料No 收到产品科所提供的产品设计图接到产品科提供的需求相关信息建入系统中(研发用)制作产品图样(外观图)木架样品制作缝套样品制作缝套样品评审No客户确认价格Yes 移交工程资料给工程部工程试产样品制作拿到供应商所提供的样品客户下单开发新的供应商或已有供应商按要求进行打样(主要为皮，面料)与客户确认图样确认采购样品是否合乎要求签订标样留存木架样品评审成品样品评审No工程试产样评审提交总经理核准Yes 更新BOM 系统及PLM系统材料报废率测定皮/布/板材……取得样品材料总经理核准Yes样板设计木架部件设计工程资料重新整理1. 面套排版图优化2. CNC 排版优化3. 海棉/丝棉排版优化4. 相关资料处理总经理核准Yes 各工段预估标准工时成品/原材料开发编码转换成ERP 正式代码PLM 转成正式代码YesNo计划部门安排大货生产No工程资料归档(上传到PLM)整理工程资料木架3D 图/面套样板图/材料明细表/各种操作流程SOP/海棉丝棉纸板图从客户接到产品信息(有样品照片)从客户收到产品信息/要求(无样品照片)建立初步BOM资料建立初步标准工时在系统中建立最终BOM更新工时系统样品成本预估价格谈判总经理核准NoNo生产问题检查没问题有问题1. 成品开发临时编码2. 原材料临时编码(针对公司自己开发)公司内部全新产品开发(效果图)收到产品科新品图样Yes确认是否接单开发YesYes通知客户，不接该单设计NoNoYes有定单，成品及原材料的编码转换成公司正式编码样品投放市场建立最终标准工时进入系统维护限价Yes进入ERP 财务限价Yes ERP 生成销售订单启动MRP 运算相关信息建入系统中(研发用)新产品开发流程图解释说明产品科(包括图样设计,成品编码,原材料开发)研发部工程部生产部IE业务部价格科采购1.对于接到客户的需求，需要详细记录，以提供更多的信息给厂内相关人员2. 如果与产品科人员讨论后不接单，需要向客户说明原因3. 当产品科依需求设计好图样，需要与客户确认是否满足其需求，如果OK，需要签定图样，以免事后客户做变更。
ISO9001新产品研发控制程序
ISO9001新产品研发控制程序1.目的为了建立一套新产品研发控制程序，包括从最初一个全新的产品立案和产品研发的全过程直到产品放行到生产部。
相关负责人及产品进程安排和设计文件的发放等。
2.适用范围：2.1本程序适用于公司所有的产品有关技术性的可行性研究及评估及有关研发项目，包含公司内部项目和公司外部项目；2.2本程序适用于公司研发所有产品研发项目；2.3本程序包括新产品导入、有关技术性的可行性研究及评估、设计、设计评审（含可靠性测试）、设计更改等新产品研发全过程。
3.定义：市场部需发起新产品定义方案；研发部需对新产品作出技术性可行性研究及评估4.职责：4.1业务部：市场或客户需求信息的提供及反馈研发部；4.2研发部：主导新产品的设计和开发的全过程，以及供应商送样和客户送样的检验；4.3采购部：样品、小批量试产所需物料的采购；4.4生产部：协助样品制作及试产过程；4.5品质部：负责产品的检验与确认；4.6相关部门：产品开发各阶段的参与及评审；4.7总经理：新产品开发意向书的最终核准。
5. 内容：5.1新产品开发流程中的相关节点管理规定责任单位作业流重点说明相关文件/表单营销中心1、营销中心收到客户信息，有新产品研发需求，经董事会评审同意后，向产品研发中心发出《新产品开发通知书》（附件一）。
提供样品（如有），详细描述新产品的相关信息。
【新产品开发通知书】研发中心2、研发中心收到《新产品开发通知书》后，由研发中心副总组织相关人员召开新产品开发起动会议。
客户新产品开发授权样品/图纸/概念/邮件研发中心3、研发部文员在会后1个工作日内形成【新产品开发起动会议纪要】（附件二）；在会后3个工作日内形成【新产品开发计划及进度跟踪甘特图】（附件三）。
研发中心/相关部门4、对于重要客户的重要新产品或开发难度大的新产品，研发副总认为有必要时，可以成立专项的新产品开发项目管理小组。
小组长可以是也可以不是由研发副总兼任，必要时也可以请董事会成员挂帅。
产品研发流程程序文件
3.15假设质检未通过，产品经理修改相关成果和文档；假设质检通过，质量操作部将相关成果和文档放入资源治理部门归档；
3.16同时产品研发组制作软件，技术支持部和市场部制作宣传材料，之后，技术支持部对销售人员进行内部培训，市场部申请并取得著作权；
4相关文件
4.1《产品规划说明书》
4.2《立项汇报》
4.3《综合评审记录》
4.4《质量操作立项汇报和可行性分析汇报说明书》
4.5《工程方案书》
4.6《质量操作工程方案评审记录》
4.7《资源调度单》
4.8《需求分析说明书》
4.9《质量操作需求分析说明书评审汇报》
4.10《资源中心验收单》
4.11《评审规程》
这些假定和约束条件可能包含：治理方针；运行环境，包含硬件设备和支持软件的限制；与其他应用间的接口；并行操作；实时功能；审查功能；操作功能；所需的高级言语；通信协议；应用的临界点；平安保密方面的考虑等。
【提示注意】
本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或操作的改变时对产品需求将造成影响。
3.8产品经理获得研发工程资源后，进行需求分析，并将相关成果交技术委员会进行内容评审；
3.9假设内容评审未通过，产品经理修改需求分析；假设内容评审通过，质量操作部对《需求分析说明》进行质量检验；
3.10假设质检未通过，产品经理修改《需求分析说明》，假设质检通过，相关成果和文档放入资源治理部归档，同时产品经理带着研发相关人员进行总体设计；
4.12《总体设计说明书》
4.13《概要设计说明书》
产品技术中心-工作流程说明
产品技术中心-工作流程说明为优化技术中心工作流程，提升产品和项目质量管理，实现既定的产品开发规划及任务目标，经研究制定如下工作流程说明：1.产品研发流程1.1.流程示意图1.2.角色分工1.3.流程说明1.4.基本准则1）每项任务的每个阶段，都需要确定负责人和基本时间计划；2）每项关键工作完成后，都需要进行效果评估和情况通报；3）不能按计划完成，需要提前通知上级负责人，并给出原因和预备方案；4）大会前充分沟通，而不是大会推卸责任或无效讨论；5）所有的产品修改需求都提交给产品部门，经过产品确认再提交设计或技术部门，BUG除外。
2.发布升级流程2.1流程示意图2.2角色分工2.3流程说明3.代码审查流程3.1流程示意图3.2角色分工3.3审查要点1）检查开发人员是否遵守开发规范准则中的规定；2）检查代码是否存在逻辑错误、性能低下或安全隐患问题，包括循环、递归、线程、事务；3）检查代码是否存在过多冗余，有无可复用率，模块之间的耦合关系设计；4）检查系统用户的提示是否简洁明了，有无歧义或不妥；5）检查第三方框架或组件的使用是否合理；6）检查代码是否存在未注释或注释不明或难阅读、理解。
3.4审查好处1）提高代码质量；2）及早发现缺陷，降低修补成本；3）促进团队内部知识共享，提高团队的整体技术水平；4）审查过程也是一种思路重构的过程，帮助更深入理解系统和维护代码。
4.新签需求流程4.1流程示意图说明：1）定制类需求原则上只接收有营业执照的企业性质的客户，不接收无营业执照的个人定制，个别无风险项目例外。
2）目前公司以自有产品开发为主，在基于基础产品或一定业务领域上承接定制类项目，故新需求统一对接产品部，后续视业务量再定夺是否成立专职项目部。
7 / 114.2流程说明5.问题受理流程5.1流程示意图5.2细分业务技术服务说明：本细分业务技术人员清单，主要为内部业务口提供BUG问题的对应技术服务人员。
5.3问题分类任何产品使用过程中出现的问题，均可通过“问题受理流程”通知技术人员，项目负责人将对问题进行确认安排人员处理。
新产品开发流程程序文件
新产品开发流程程序文件
摘要：
随着市场竞争的日益激烈，企业不断努力寻求创新和发展。
新产品开发作为企业创新的重要流程，需要一个系统化的程序文件来指导和管理。
本文介绍了新产品开发流程程序文件的重要性，以及其核心内容和实施步骤。
一、引言
新产品开发对于企业的发展至关重要。
一个成功的新产品可以为企业带来新的市场机会，增加销售额和利润。
然而，新产品开发不是一项简单的任务，它需要一个规范的流程和程序来指导，并且需要跨部门协作和沟通。
新产品开发流程程序文件的编制可以帮助企业组织和管理新产品开发的各个环节，提高效率和质量。
二、新产品开发流程程序文件的重要性
1. 指导和规范
新产品开发流程程序文件可以为企业提供指导和规范。
它明确了各个阶段和步骤，包括市场调研、产品设计、原型开发、测试、
批量生产等等。
每个步骤都有明确的任务和要求，有助于团队成员理解和遵守，从而提高工作效率。
2. 协同和沟通
新产品开发通常需要跨部门协作和沟通。
编制新产品开发流程程序文件可以帮助不同部门之间建立沟通桥梁，明确任务分工和协作方式。
这可以减少沟通误解，提高协同效率，从而加快产品开发进度。
3. 问题识别和解决
新产品开发中经常会遇到各种问题，例如技术难题、市场需求变化等等。
新产品开发流程程序文件可以帮助企业及时识别问题，并提供相应的解决方法和措施。
这有助于减少风险和延误，提高项目成功率。
三、新产品开发流程程序文件的核心内容
1. 市场调研。
研发程序文件
5.4.1研討通過、修改完成後，總經理簽發各有關文件。
5.4.2總經理根據市場、客戶需求、提出新產品設想，具體的合同評審過程詳見《合約審查程序》。
5.4.3文件發放和管理詳細說明於《文件與資料管制程序》。
5.4.4評審通過轉入第三階段工作。
5.5第三階段（後期）
5.5.1正式量產：
5.5.2生產單位依製程規範、測試規範及包裝規範、設計報表、檢驗記錄及相關控制表單進行量產。
5.5.3產品專案負責人需確認首批產品的品質水準，以確保品質的一致性。
5.5.4量產前之設計變更：
5.5.5顧客要求之設計變更，研發部門登錄後直接變更並通知各相關單位。
5.6.3涉及安全、電磁兼容的設計、電氣結構及關鍵元器件發生變更時，須及時向認證機構提出申請，批准後方可實行變更。
5.6.4當產品安全性的關鍵元器件及影響EMC的關鍵元器件發生變更時，依據“產品變更控制流程圖”（附件二）執行。
6.參考文件
6.1新產品導入程序（QP-E005A）
6.2合約審查程序（QP-B001A）
5.3.5品保部從試產批中按規定的要求進行全檢或抽樣檢查。
5.3.6研發部對自檢合格的試產品根據不同的要求分別送出一定數量的（產品鑑定或定型‥ ‥ ‥）樣品送公證機構鑑定，鑑定證書由公司備案。
5.3.7研發部經理召集第三階段設計審查會議，根據研發部的試產報告、設備、儀器、輔具、物料配套供應等各類齊全的技術文件資料，最終確定產品進入批量生產。
5.2.6研發部工程師根據簽字認可的資料進行樣品製作。
5.2.7樣品做好后，對樣品做相關可靠性測試或者破壞性試驗！可靠性測試有：高低恒溫測試、跌落測試、老化測試、震動測試等！
新产品开发及承认流程程序文件
新产品开发及承认流程程序文件一、说明本文件描述了新产品开发及承认流程，旨在促进新产品快速开发、高效承认，确保新产品的质量和准时上市。
二、定义1.新产品：指公司内部或外部创新团队所提出的，具有市场开发潜力的产品。
2.开发团队：指由市场部、研发部、运营部等相关职能部门组成的团队。
3.承认团队：指由高级管理人员、质量控制人员等相关部门组成的团队。
三、流程1.新产品提案(1)通过市场调研和竞争分析，市场部综合评估市场需求，确认新产品提案。
(2)新产品提案包括市场需求、竞争分析、预计市场份额、预计销售利润等信息。
2.研发与设计(1)开发团队根据新产品提案，制定详细的开发计划和产品设计方案。
(2)开发团队进行产品原型制作，并进行内部评估。
(3)开发团队进行产品设计的迭代优化，确保其符合市场需求和技术可行性。
3.测试与验证(1)开发团队进行产品功能测试和性能测试，包括产品寿命测试、环境测试等。
(2)开发团队对产品进行可靠性和安全性验证。
(3)开发团队承认产品的技术性能，并对测试结果进行总结和评估。
4.承认流程(1)开发团队编写新产品承认报告，并提交到承认团队。
(2)承认团队对新产品进行评审，并提出意见和建议。
(3)开发团队根据承认团队的意见和建议，进行产品进一步优化。
(4)承认团队根据新产品承认报告和优化进展，对新产品进行承认决策。
(5)承认决策结果通知开发团队，包括承认或不承认的理由和决策依据。
5.产品准备与上市(1)开发团队在承认决策通过后，开始进行产品准备工作，包括产品规格、包装设计、市场推广方案等。
(2)开发团队与供应链部门合作，确保产品制造和供应的准备。
(3)开发团队与运营部门合作，进行市场上市计划和推广。
(4)上市后，开发团队与运营部门、市场部门进行产品迭代优化，持续改进产品。
四、文件管理1.新产品提案、开发计划、产品设计方案等文件由开发团队负责管理。
2.新产品承认报告和相关评审意见由承认团队负责管理。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1目的及适用范围1.1为规范产品研发过程，提高产品研发的效率、质量，降低研发成本，特制定本程序；1.2本程序文件适用于侏罗纪公司产品研发；1.3本程序文件由侏罗纪公司制定，其解释权及修改权属于；1.4本程序文件从2003年月日起执行；2职责2.1产品部负责产品研发；2.2质量控制部负责对产品开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成果放入资源中心存档；2.3技术支持部和市场部负责宣传材料和用户手册的制作，以及和产品销售流程的衔接环节和动作；3产品研发流程3.1技术副总从公司战略规划决案中形成产品规划，下发给技术研发部；3.2技术研发部经理进行产品研发立项；3.3公司组织人员对产品立项进行评审，若评审未通过，相关文档放入行政综合部备案；3.4若立项评审通过，质量保证部对立项进行质量检验，若质检未通过，修改立项报告；3.5若质检通过，开始制订项目计划，同时质量保证部将立项相关文档放入行政综合部归档；3.6技术部经理将项目计划提交给技术副总评审，若未通过，技术部经理修改项目计划；3.7若评审通过，质量控制部对项目计划进行评审，若质检评审未通过，产品经理修改项目计划，若质检评审通过，产品总监安排研发项目资源；3.8产品经理获得研发项目资源后，进行需求分析，并将相关成果交技术委员会进行内容评审；3.9若内容评审未通过，产品经理修改需求分析；若内容评审通过，质量控制部对《需求分析说明》进行质量检验；3.10若质检未通过，产品经理修改《需求分析说明》，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理带领研发相关人员进行总体设计；3.11产品经理和研发人员完成总体设计后将相关成果交技术委员会进行内容评审；3.12若内容评审未通过，产品经理修改《总体设计说明》；若内容评审通过，质量控制部对《总体设计说明》进行质量检验；3.13若质检未通过，产品经理修改《总体设计说明》，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理和研发人员进行程序设计/测试；3.14完成程序设计/测试后，产品经理将相关成果交质量控制部进行功能测试，若测试未通过，产品经理修改相关成果，若测试通过，质量控制部对相关成果和文档进行质量检验；3.15若质检未通过，产品经理修改相关成果和文档；若质检通过，质量控制部将相关成果和文档放入资源管理部门归档；3.16同时产品研发组制作软件，技术支持部和市场部制作宣传材料，之后，技术支持部对销售人员进行内部培训，市场部申请并取得着作权；3.17市场部在取得着作权后制作用户/技术手册；3.18产品研发组完成软件制作后，质量控制部对制作的软件进行质量检验，若未通过质检，产品研发组重新制作软件；若通过质检，相关成果和文档放入资源管理部归档，同时产品经理进行产品研发总结；3.19质量控制部将产品研发总结等相关成果和文档放入资源管理部，同时市场部进行软件产品包装，销售部进行产品销售；4相关文件4.1《产品规划说明书》4.2《立项报告》4.3《综合评审记录》4.4《质量控制立项报告和可行性分析报告说明书》4.5《项目计划书》4.6《质量控制项目计划评审记录》4.7《资源调度单》4.8《需求分析说明书》4.9《质量控制需求分析说明书评审报告》4.10《资源中心验收单》4.11《评审规程》4.12《总体设计说明书》4.13《概要设计说明书》4.14《详细设计说明书》4.15《质量控制系统设计报告评审记录》4.16着作权相关文档（略）4.17《软件质量保证单》4.18《软件缺陷报告》4.19《项目总结》产品规划说明书时间合评审记录（公司）时间立项报告评审记录记录编号： - 时间：年月日1．本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页风险评估与控制（立项建议报告评审附页）1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。
并将各项填写完整。
2.风险描述：描述当前过程中可能发生的风险。
风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。
风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级 为最高级。
风险现值：风险发生可能性与风险级别的乘积。
风险控制措施：预防风险发生的措施。
第 页/共 页可行性分析报告评审记录记录编号： - 时间：年月日1．本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页风险评估与控制（可行性分析报告评审附页）1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。
并将各项填写完整。
2.风险描述：描述当前过程中可能发生的风险。
风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。
风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级 为最高级。
风险现值：风险发生可能性与风险级别的乘积。
风险控制措施：预防风险发生的措施。
第 页/共 页项目计划书备注：抄送财务部、人力资源部时间项目启动计划评审记录记录编号：时间：年月日1.项目启动计划评审由项目管理部门组织评审。
2.评审完成后由开发体系决策层SMG批准。
3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页开发计划评审记录记录编号：时间：年月日2.评审完成后由开发体系决策层SMG批准。
3.本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页开发计划检查表（开发计划评审附页）项目名称：项目编号：检查人/日期：批准人/日期：风险评估与控制（开发计划评审附页）1.评估中风险不限于表中已列出的，应依据评审的具体情况增加风险项。
并将各项填写完整。
2.风险描述：描述当前过程中可能发生的风险。
风险发生可能性：风险发生的概率，以百分数表示，为0到1，增量为0.05。
风险级别：风险发生造成损失的严重程度，以0~10级表示，其中10级 为最高级。
风险现值：风险发生可能性与风险级别的乘积。
风险控制措施：预防风险发生的措施。
第 页/共 页软件问题报告记录编号： - 时间：年月日1. 问题描述栏中可以填写问题现象及其产生原因，如果有用户的书面说明，则可以直接引用。
2. 修改描述一栏描述问题的确切原因、修改办法以及修改后的效果。
3. 本页不足记述时，可以有附页，格式自定。
总页数包括本页与所有附页。
项目资源调度单（借鉴产品中心任务书）备注：抄送财务、人力资源部时间软件需求分析说明书1.引言1.1目的说明编写软件需求说明书的目的，指出预期的读者。
1.2背景（1）待开发的软件系统的名称；（2）本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；（3）该软件系统同其他系统或其他机构的基本的相互来往关系。
1.3参考资料列出所用的参考资料，如：（1）本项目的经核准的计划任务书或合同、上级机关的批文；（2）属于本项目的其他已发表的文件；（3）本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
（4）列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
1.4术语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
2.项目概述本部分描述影响产品和其需求的一般因素。
此处并不说明具体的需求，其描述的内容仅仅是为了更容易理解、深化需求规格，其用意是为从多方面、多角度考虑需求以提供思维参考点。
2.1一般描述本节描述软件开发项目的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料，解释待开发产品和其相关的其他产品或项目的关系。
如果本产品是独立的，而且自含全部内容，应在此说明。
如果所定义的产品是一个较大系统或项目中的一个组成部分，那么在此需要描述如下内容：要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口；指出本产品主要的外部接口（不需要详细描述，详细描述放在其他章节中）；描述所使用的计算机硬件、外围设备。
这里仅仅是一个综述性描述。
【技巧】在本节的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。
【提醒注意】本节所描述的既不是设计方案，也不是在方案设计时的约束条件，它仅仅为方案设计时的约束条件提供了一个可以解释的理由。
2.2功能简述对待的软件产品功能提供一个摘要。
【技巧】编制功能的一种方法是制作功能表，以便客户或第一次读这个文件的人很容易理解；用方框图来表达不同的功能和它们的关系有益于理解。
【提醒注意】方框图不是产品的设计，而只是一种有效的解释方式。
本节不是具体需求的陈述，只是对具体需求部分中为什么要对一些需求做出描述的铺垫。
2.3用户特点本节描述产品最终用户（包括操作员、维护员和系统工作人员等）具有的受教育水平、工作经验及技术专长等一般特点。
如果系统的大多数用户是一些临时的用户，那么就要求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。
2.4假定和约束给出影响软件需求说明书中陈述的需求的每一个因素。
这些因素不是软件的设计约束，但是它们的改变可能影响到需求说明书中的需求。
这些假定和约束条件可能包括：管理方针；运行环境，包括硬件设备和支持软件的限制；与其他应用间的接口；并行操作；实时功能；审查功能；控制功能；所需的高级语言；通信协议；应用的临界点；安全保密方面的考虑等。
【提醒注意】本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或控制的改变时对产品需求将造成影响。
本节的内容不能用来陈述具体需求或强加若干特殊的设计约束，而应对具体需求部分中的某些具体需求或设计约束的描述提供理由。
3.具体需求本章应包括软件开发者在建立设计时需要的全部细节。
本章的编写应该遵循如下基本原则：遵循可验证性、无歧义性等的准则，对每一个需求细节作具体描述；在软件需求说明书前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景；按符合逻辑的和可读的方式组织；详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。
【提醒注意】每一项需求的描述都应包括至少5个方面的内容：功能需求；性能需求；属性需求；外部接口需求；设计约束。
3.1功能需求用文字、图表或数学公式详细描述被开发软件的输入、处理、输出以及在上述过程中发生的基本操作。
对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成：3.1.1引言（1）描述该功能要达到的目标、所采用的方法和技术；（2）清楚说明功能意图的由来和背景。
3.1.2输入（1）详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）。