Level of Requirements 业务需求 项目视图与范围文档 用户需求 质量属性 其他 非功能需求 用例文档 系统需求 功能需求 软件需求规格说明 其他 非功能需求 约束条件

The Example of STD

The Example of DFD Data Flow Diagrams

Use Case Example View Report Card Student Register for Courses Registrar Professor Billing System Course Catalog Register for Courses Select Courses to Teach Submit Grades Maintain Professor Information Maintain Student Information Close Registration Login

Requirements Specification Template（1） 一 引言 1 目的 2 文档约定 3 预期的读者和阅读建议 4 产品范围 5 参考文献 二 综合描述 1 产品的前景 2 产品的功能 3 用户类和特征 4 运行环境 5 设计和实现上的限制 6 假设和依赖

Requirements Specification Template（2） 三 外部接口需求 1 用户界面 2 硬件接口 3 软件接口 4 通信接口 四 系统特性 1 说明和优先级 2 激励/响应序列 3 功能需求

Requirements Specification Template（3） 五 其他非功能需求 1 性能需求 2 安全设施需求 3 安全性需求 4 软件质量属性 5 业务规则 6 用户文档 六 其他需求 附录A 词汇表 附录B 分析模型 附录C 待确定问题的列表

例： §3.概念模型和规范化 …… Instructor Student Enrolled in Teach Class I D # Name Sex Title Instructor ID Class ID Grade Student ID Credit Subject

Example 开发一个学生成绩管理系统 步骤 学生可以随时查询自己的成绩单 教务人员可以通过该系统维护学生信息、课程信息和成绩信息 系统必须提供必要的安全措施以防非法存取 步骤 创建实体关系图 创建数据流模型 编写数据字典 创建行为模型 编写加工规格说明

Structured Analysis Process (1) 数据建模 实体：学生、课程、成绩 属性： 学生：学号、姓名、性别、出生日期、入学年月 课程：课程编号、课程名称、课程学分、课程描述 成绩：学号、课程编号、分数、考核日期 ERD

Structured Analysis Process (2) 功能建模 第0层DFD 教务人员维护学生信息和课程信息，并登录 学生的选课成绩； 学生查询自己的成绩单。

Structured Analysis Process (3) 第1层DFD 对第0层DFD图中的一个加工“学生成绩管理”进行展开。

Structured Analysis Process (4) 第2层DFD 对第1层DFD图中的一个加工“查询学生成绩”进行展开。

Structured Analysis Process (5) 根据以上实例和经验，绘制数据流图应当遵循以下原则： 分层时，子图的输入、输出数据流必须和父图中相应加工的输入、输出数据流一致； 加工的编号应该唯一且具有层次性； 加工不应该只有输入或只有输出，通常既有输入又有输出； 数据流图不应反映处理的顺序； 加工之间应通过数据存储进行通信，避免从一个加工直接流到另一个加工； 数据应通过加工进行流动，避免从一个数据存储直接流到另一个数据存储； 数据流图中所有元素的命名应当对客户有意义，且与业务相关； 不要在一个图中绘制7个以上的加工，否则难于绘制和理解。

Structured Analysis Process (6) 编写数据字典 学生

Structured Analysis Process (7) 学号

Structured Analysis Process (8) 学生成绩查询

Structured Analysis Process (9) 行为建模 学生成绩信息需要采取安全措施，可以采取登录方法避免非法使用系统。这样，该系统存在“登录”、“正常”和“出错”等状态的转换。

DATA CONTEXT DIAGRAM object returned coins 0* selection Vend customer product object returned coins selection slug Context diagram describes the system function and defines the system scope Only one process bubble At least one input and one output flow At least one terminator All terminators are connected to at least one input or output flow No data exchanged between terminators

DFD 0: VEND PRODUCT object coins returned slug due price table 5* Dispense change 1* Get customer payment 3p Validate 2p product price 4p valid selection 6p price table products slug coins returned due Data Flow Diagrams are used for process decomposition Every process is decomposed in other processes (within a DFD) or in one PSPEC (outside a DFD) Rule of 5 +/- 2 is used: Balance between lack of information (3 or less) and too much (more than 7) Up to 4 levels of decomposition Each Data Flow Diagram specifies the decomposition of its parent bubble REMARK: There is no limit given by the technique itself. These limits are given by quality criteria (simplicity, …)

DFD 1: GET CUSTOMER PAYMENT Deposit coins 1.4p Accumulate 1.2p Clear payment 1.3p object 1.1p Validate slug coins_parameters coin held_coins coin_value current_payment Processes are the active elements in the model Process performs a transformation: if and only if ALL input information is available production of all information is IMMEDIATE, I.e. all processing is done in zero delay The output from the process should be a function of the input to it Data flows allow transit of data within the system Store is a place where information is preserved

DFD 5: DISPENSE CHANGE change due change coins coins 5.1 Get change 5.2 payment coins change coins

PSPEC DFD 0: VEND PRODUCT (PARTLY) object 5* Dispense change 1* Get customer payment 3p Validate 2p product price price table slug coins returned due valid selection PSPEC 3 PSPEC 2 PSPEC’s are the lowest abstraction level Make a PSPEC approximately 1/2 page long Shows the relation between process input and output flows Any form of specification may be used: Drawings Math equations Structured English PSPEC 3: Validate payment Inputs: payment : data in price : data in Outputs: change due : data out sufficient payment: control out Body: if payment >= price change due = payment - price sufficient payment = yes otherwise sufficient payment = no

SUMMARY 0* 1* 3* 2* Context Diagram DFD 0 DFD 1 DFD 2 DFD 3 1.1* 1.2p 3.1* 3.2p 3.3* DFD 1.1 DFD 3.1 DFD 3.3 PSPEC PSPEC PSPEC PSPEC PSPEC PSPEC PSPEC PSPEC PSPEC PSPEC PSPEC

CONTROL CONTEXT DIAGRAM - CCD customer 0* Vend product coin return request available Data flow Control flow Carries information needed Carries information that by a process to perform is to be interpreted for transformations changing system behavior and/or activating processes Control Context Diagram describes the system function and defines the system scope (same as for data) Control Context Diagram defines the external control interface of the system

DATA/CONTROL CONTEXT DIAGRAM customer 0* Vend product object returned coins selection slug coin return request available

CFD 0: VEND PRODUCT coin return request coin detected coins sufficient 5* Dispense change 1* Get customer payment 3p Validate 2p product price 4p valid selection 6p price table products coins coin detected dispensed sufficient available coin return request Control Flow Diagram (CFD) is coupled to the equivalent level DFD and shares the same processes Control Flow Diagram shows control flows instead of data flows The control processing is described in the Control Specification (CSPEC) The CSPEC is represented by a bar At most one CSPEC for each DFD/CFD

DFD/CFD 0: VEND PRODUCT coin return request coin detected object coins 5* Dispense change 1* Get customer payment 3p Validate 2p product price 4p valid selection 6p price table products slug coins returned due coin detected dispensed sufficient available coin return request

CFD 1: GET CUSTOMER PAYMENT Deposit coins 1.4p Accumulate 1.2p Clear payment 1.3p 1.1p Validate coins_parameters sufficient coin detected

DFD/CFD 1: GET CUSTOMER PAYMENT Deposit coins 1.4p Accumulate 1.2p Clear payment 1.3p object 1.1p Validate slug coins_parameters coin held_coins coin_value sufficient detected current_payment

CFD 5: DISPENSE CHANGE return request product available 5.1p Get coin 5.2p payment return request product available

DFD/CFD 5: DISPENSE CHANGE Get change coin 5.2p payment return request product available change due coins change coins

CSPEC - 3 LOGICAL BLOCKS ICF1 Out1 ICF2 ICF: Input Control Flow Sequential logic Event Logic Action Logic ICF3 ICF2 ICF1 Action1 Action2 Action3 Event1 Event2 Out1 Out2 Out3 ICF4 ICF5 Event3 ICF: Input Control Flow Out: CSPEC Control output ICF3 ICF2 ICF1 Out1 Out2 Out3 ICF4 ICF5

EVENT LOGIC Is specified in an event logic table: Only pertinent events combinations are showed One combination defines only one event Several distinct combinations may define the same event

SEQUENTIAL LOGIC It means to manage the historical aspect of events, It keeps memory of past events for the current abstraction level It describes the system OPERATING MODES It does not define the status of the processes represented on the current control diagram Process behavior is defined by: Operating modes Transitions : from an operating mode to an other Events : switch on transitions and/or actions Actions : activities associated to events 3 (exclusive) representations types may be used : State/Transition diagrams : State/Transition tables State/Events matrices

CSPEC 0: STATE TRANSITION DIAGRAM Waiting for a coin for selection Dispensing of product initial accept new coin product dispensed coin detected accept customer request sufficient payment dispense product coin return request return payment product available=no Waiting for selection OPERATING MODE TRANSITION ARC Event EVENT/ACTION Action

ACTION LOGIC Is defined in a logic table When a CSPEC result is only made of activators, no ”control out” part is necessary It is a good idea to group processes of the same activity type (pulse or permanent) in adjacent columns

CSPEC 0: PROCESS ACTIVATION MATRIX

CSPEC1: PROCESS ACTIVATION MATRIX Deposit coins 1.4p Accumulate 1.2p Clear payment 1.3p 1.1p Validate coins_parameters sufficient coin detected

CSPEC 5 - PROCESS ACTIVATION MATRIX Get change coin 5.2p payment return request product available

BEHAVIOUR REPRESENTATION

EXAMPLE OF REQUIREMENTS DICTIONARY (PARTLY) Name Composed of Type ……… ……… …... object [coin | slug] data product [soda | gum | candy] data coin 0{[quarter | nickel | dime]}8 data product available [“yes” | “no”] control ……… ……… …… quarter * 25 cents US currency*