Chapter 3 Requirements Analysis
• The basic task is to correctly answer: "What must the system do?."
Raised the target system complete, accurate, clear, specific requirements.
• Systems analysts should write software requirements specification.
Needs analysis should comply with the following guidelines:
(1) must understand and description of the problem domain, establish a data model.
(2) must be defined software functions should be done to establish functional model.
(3) must describe the behavior of software as a result of an external event, establish behavioral models.
(4) must be decomposed model description information, function and behavior, showing details of a hierarchical manner.
Task 3.1 Requirements Analysis
3.1.1 to determine the overall system requirements
1. Functional Requirements
The system must provide specified services, divided all functions of the system must be completed.
2. Performance requirements
System must meet specified timing constraints or capacity constraint, typically including the speed (response time), the information rate demand, a main memory capacity, disk capacity, safety and the like.
3. The reliability and availability requirements
4. Error handling requirements
When the system finds application actions they have committed a mistake when it adopted. However, only the key parts of the system to selectively raise demand for this type of error handling.
5. Interface Requirements
Description application format with its communication environment.
Common Interface Requirements are: user interface requirements; hardware interface requirements; software interface requirements; communication interface requirements.
6. Constraints
Description restrictions should be implemented or design application system compliance.
Common constraints are: precision; tools and language constraints; design constraints; criteria that should be used; you should use hardware platform.
7. Reverse Demand
Description software system should not do.
To clarify the real needs, eliminate misunderstanding reverse demand that may occur.
8. future requirements may be submitted
For possible future expansion and modification of the system pre-preparation.
3.1.2 Data Analysis System Requirements
This is an important task for software requirements analysis.
The method commonly used to establish a data model (ER FIG).
display method:
Data structure (represented by logical relationships between data elements)
Data Dictionary (enough visual image)
And level block diagram of FIG Warnier (described in Section 3.7)
Storage:
Database or file.
3.1.3 Export logical model system
• Logical model The above two steps to export the results of the system
• described by the tool
Data flow diagram
Entity Relationship diagram
State transition diagram
Data Dictionary
The main processing algorithms
3.1.4 correction system development plan
• Correct development plans developed in the feasibility analysis
• more accurate estimate of system cost and schedule
3.2 communicate with the needs of users to access methods
• 3.2.1 Interview
• Formal
• Informal
• Questionnaire
• Scenario analysis
3.2.2 Data stream oriented top-down refinement seek
Structured Analysis approach is a data-oriented method of stepwise refinement down requirement analysis flowing from the top.
• Feasibility research is that high-level data flow diagram of the target system
• One of the goals is to demand analysis of data flow and data storage elements to define the class.
• proceed with an analysis from the output data flow diagram, the output data determines the system must have the most basic constituent elements.
The output data is not difficult to find out the constituent elements of the investigation access.
Each data element is output come from?
Or input to the system from outside or is generated by the system by calculating out.
• back to the input from the output terminal, may be determined for each source data element, and related algorithms.
However, high-level data flow graph does not include many details, so often encounter the following problems back:
A data element need to use data elements currently no data flow diagram,
Or derived data elements need to use this algorithm is not fully understood.
• data elements included in the data dictionary
• Algorithm recorded in the IPO figure
• Added data flow diagram
• Please review the user
Review process to verify the known elements, complements the unknown elements, fill in the blank document.
• more detailed tracking data flow, data flow diagrams extended to a lower level. By thinning functional decomposition complete data flow graph.
New problems may arise in the analysis of trace, answers to these questions may well add some new entries in the data dictionary, or develop new or refined description of the algorithm.
Ultimately be satisfied with the knowledge of the system data and functional requirements.
FIG roughly 3.1 on the next page summarizes the above analysis.
Figure 3.1 the data stream oriented top-down request during spermatogenesis
3.2.3 Simple application specification techniques
To solve this problem, people have developed a team-oriented requirements gathering process, called simple application specification techniques.
This approach calls for the user to work closely with developers to discuss different scenarios and specify the basic needs.
• initial interviews, identify problems and solutions
• developers and users, respectively, to write "demand"
• Before the meeting, the "demand" distribution
• Everyone review "demand", lists the system objects
• meeting merge objects (eliminating redundancy) to obtain a consensus list
• sub-group discussion, to develop small-scale specifications
• Comprehensive discussion, drafting software specifications
3.2.4 software to quickly build prototype
• Rapid Prototyping is the rapid build up operable program designed to demonstrate the main function of the target system. Its features:
fast
Easy to modify
• In order to build a prototype and modified quickly, typically using the following three methods and tools:
The fourth-generation technology (such software engineers to quickly generate executable code, is an ideal tool for rapid prototyping)
Software components may be reusable (using a set of software components is assembled existing prototype)
Formal specification and prototyping environment (based on the specifications tool to automatically call the formal language of instructions translated into executable program code)
3.3 Analysis Modeling and Specification
3.3.1 Analysis Modeling
To better understand the complexity of things, things that people often use the method to establish the model.
The so-called model, a written description in order to understand things and to make an abstract thing, is a unambiguous.
Model consists of a set of graphical symbols and rules of organization of these symbols composition.
The structured analysis criteria, requirements analysis process should build three models, which are data model, functional model and behavior model.
Data Model
Entity - Relationship diagram depicting the relationship between data objects and data objects used to create the data model.
Functional Model
Data flow diagram depicting the logic process when the data is transformed, indicating that the system has a function of moving data changes in the software system, is the basis for the establishment of the functional model.
Behavioral models
Section 3.6 state transition diagram (state diagram), indicated as the result of an external event system behavior. Depict various behavior patterns of the system (referred to as "state") and transitions between states ways. Is the basis for behavior modeling.
3.3.2 Software Requirements Specification
Is the most important document needs analysis phase derived.
• Use natural language complete, accurate, and specifically describe the system of data requirements, functional requirements, performance requirements, reliability and availability requirements, error handling requirements, interface requirements, constraints, reverse demand and future requirements may be raised.
• Natural language specification has easy to write, easy to understand the advantage, as most people welcomed and adopted.
3.4 Entity - Relationship diagram
3.5 Data standardization
Various software systems often use long-term preservation of information, usually organized and stored in a database or file in a certain way, in order to reduce data redundancy, to avoid abnormal insertion or deletion abnormalities usually required to standardized data structure.
3.6 State Transition Diagram
Used to model the behavior of software systems.
By rendering system status and event cause the system state transitions, to represent the behavior of the system.
In addition, also identified as a result of a particular event which the system operation (e.g., data processing) will do.
Therefore, the state diagram provides a mechanism for behavioral modeling.
3.6.1 state
status:
Is any system behavior can be observed, a state represents a pattern of behavior of the system.
Defined state in a state diagram are:
Initial state (i.e., initial state) final state (i.e., final state) and the intermediate state.
In a state diagram can have an initial state, the final state can be 0 to plural.
When depicts one way of life, you need to indicate
The initial state (the initial state entered when the system starts) and
Final state (final state is reached at the end of the system is running).
When the drawing process does not have to cycle run.
3.6.2 Event
Event is happening at a particular moment, it is an abstract system or cause of action to do (and) transitions from one state to another external events.
For example, the internal clock indicates that a specified time period has elapsed, the user moves the mouse or clicks are all events.
In short, the event is the cause of action or information systems as a control (and) the transition state.
3.6.3 Symbols
Initial state represented by a solid circle,
Final state by a pair of concentric circles (the circle is filled circles) Fig.
Intermediate state is represented by a rounded rectangle,
You can divide it into two on the horizontal level, middle and lower parts.
The upper part of the name of the state, this part must be some;
Middle part of the names and values of the state variables, this part is optional;
The following table is the active part, this part is optional.
Syntax active table: event name (parameter list) / action expression
• "event name" can be the name of any event.
Often using the following three standard events: entry, exit and do.
entry specify actions to this state,
exit to exit the designated state action,
It does specify actions in this state.
You can specify parameters for the event list when • needed.
• action expression describes the specific actions should be done.
• connection with an arrow between two states referred to as a state transition arrows indicate the direction of conversion.
The state transition is typically triggered by an event, the event expression indicated by arrow trigger a transition in the state transition lines; if the event is not indicated in the arrow line, then automatically trigger a transition after the internal state of the source activity executed.
Event expression syntax is as follows:
Event Description [guard condition] / action expression
• The syntax for the event description: Event name (parameter list).
• guard condition is a Boolean expression.
If you use an event description and guarded condition, if and only if the event occurs and the boolean expression is true, the only state transition occurs.
If the conditions are not only guarding the description of the event, as long as the condition is true guard state transition occurs.
• action expression is a process expression, the expression is executed when the state transition begins.
3.6.4 Examples
Figure 3.4 (see page 57)
No one to call when the phone is in an idle state;
After someone picks up the handset then enter the dial tone state to reach this state, the phone is ringing behavior dial tone and timing;
Then pick up the handset if people change their minds not want to fight, and he put the receiver down (hang up), the phone again return to the idle state;
If you pick up the handset for a long time without dialing (timeout), then enter the time-out state; .......
3.7 Other graphical tools
3.7.1 level block diagram
Data hierarchy depicted a series of multi-level tree structure of the rectangular frame.
Top rectangular frame tree structure, representing the complete data structure,
The layers below the rectangular box represents the subset of data,
The bottom of each box represents the actual composition of this data element data (element is not subdivided).
For example, a computer company rendering data structures of all products can represent hierarchical block diagram with 3.5.
A block diagram of an example of the level of Figure 3.5
3.7.1 level block diagram
Starting from the top of the classification information, refinement repeatedly along each path until it is determined that all the details of the data structure is reached.
3.7.2 Warnier 图
It represents another graphical tool hierarchy of information.
However, this tool provides a graphical depiction of the means richer than the level block diagram.
FIG Warnier may indicate a logical organization of information,
It may be noted that one type of information or an information element is recurring,
May also represent specific information in a certain type of information is conditionally appear.
图3.6中的Warnier图表示
一种软件产品要么是系统软件要么是应用软件。
系统软件中有P1种操作系统，P2种编译程序，此外还有软件工具。
软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，并标出了每种软件工具的数量。
图3.6 Warnier图的一个例子
3.7.3 IPO图
IPO图是输入、处理、输出图的简称，它是美国IBM公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。
IPO图使用的基本符号既少又简单，因此很容易学会使用这种图形工具。
在左边的框中列出有关的输入数据，
在中间的框内列出主要的处理，
在右边的框内列出产生的输出数据。
处理框中列出处理的次序暗示了执行的顺序。
在IPO图中还用粗大箭头指出数据通信的情况。
图3.7是一个主文件更新的例子，通过这个例子不难了解IPO图的用法。
图3.7 IPO图的一个例子图
建议使用一种改进的IPO图(也称为IPO表)，图中包含某些附加的信息，比原始的IPO图更有用。如图3.8所示。
在需求分析阶段可以使用IPO图简略地描述系统的主要算法(即数据流图中各个处理的基本算法)。
当许多附加信息暂时还不具备时，在软件设计阶段可以进一步补充修正这些图，作为设计阶段的文档。
这正是在需求分析阶段用IPO图作为描述算法的工具的重要优点。
图3.8 改进的IPO图的形式
3.8 验证软件需求
3.8.1 从哪些方面验证软件需求的正确性
软件系统中15%的错误起源于错误的需求。
一般说来，应该从下述4个方面进行验证：
(1) 一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。
(2) 完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。
(3) 现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。
(4) 有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。
3.8.2 验证软件需求的方法
1. 验证需求的一致性
•人工审查（正确性不能保证）
•形式化描述软件需求的方法：当软件需求规格说明书是用形式化的需求陈述语言书写时，可以用软件工具验证需求的一致性。
2. 验证需求的现实性
• 经验
• 应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。
3. 验证需求的完整性和有效性
• 用户是需求的权威，但是不能很好表达自己的需求
• 根据需求开发一个软件系统，用户试用，成本翻倍
• 建立快速原型系统，使用户提出更符合实际的要求
3.8.3 用于需求分析的软件工具
为了有效地保证软件需求的正确性，特别是一致性，需要有适当的软件工具支持需求分析工作。
这类软件工具应该满足下列要求：
(1) 必须有形式化的语法(或表)，使可以用计算机自动处理使用这种语法说明的内容；
(2) 使用这个软件工具能够导出详细的文档；
(3) 必须提供分析(测试)规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；
(4) 使用这个软件工具之后，应该能够改进通信状况。