Requirement Analysis of Software Engineering (I)

ArticleDirectory

• Requirement Analysis of Software Engineering (I)

Requirement Analysis of Software Engineering (I)

(Source: http://www.yesky.com)

[Editor's note:]Nowadays, people are increasingly aware of the important role of Software Engineering in software development. At present, the domestic software development process has not been clearly defined, and the documentation is incomplete and not standardized, the success of software projects is often attributed to the efforts of outstanding individuals or groups in the software development group. This success relying on individual personnel cannot lay an effective foundation for improving the software productivity and quality throughout the Organization. Only by establishing the whole process of improvement and adopting strict software engineering methods and management, and persistently put it into practice, in order to continuously improve the software process capability across the Organization, so that software development is more standardized and reasonable.
We are about to enter the WTO, so software development must be in line with international standards. Only in this way can we improve our project management level and ultimately develop high-quality software.

Summary

Software Engineering includes four stages: requirement, design, coding and testing. Demand engineering is the first and most important stage of software engineering, this paper takes the hospital management system as an example to describe the construction and method of the demand project.

I. Demand Development

Requirement development is divided into requirement acquisition, requirement analysis, specification writing, and requirement verification. The following lists and explains the common Analysis Steps. Of course, we should determine the appropriate steps based on actual conditions such as the project size and characteristics.

1. requirement acquisition

Determine the steps for collecting, analyzing, refining, and verifying requirements in the requirement development process, and compile them into documents.

2. Demand Analysis

Draw Association diagrams, create development prototypes, analyze feasibility, determine requirements priority, create models for requirements, write data dictionaries, and allocate Application quality functions.

3. Prepare Specification

Project views and scope documents contain business requirements, while instance documents contain user requirements.

4. Requirement Verification

Reviews Requirement documents, prepares test cases based on requirements, prepares user manuals, and determines qualified standards

Ii. Demand Management

The results of requirement development should include the project view and scope documents, use instance documents, Software Requirement Specifications and related analysis models. With review approval, these documents define a baseline for development requirements.

I. Summary

Software Engineering includes four stages: requirement, design, coding and testing. Demand engineering is the first and most important stage of software engineering, this paper takes the hospital management system as an example to describe the construction and method of the demand project.

First, we must understand the relationship between the demand project and other project processes:

Figure 1 Relationship between requirements and other project processes

Software requirements include three different layers-business requirements, user requirements, and functional requirements-and non-functional requirements: the business needs describe the initial benefits of the new system provided to customers and product developers, it reflects the high-level target requirements of organizations or customers on systems and products. They are described in the project view and scope documents. The user requirement documents describe the tasks that must be completed when users use products, this is described in the instance documentation or solution script description. Functional requirements define the software functions that developers must implement so that users can complete their tasks and meet business needs.

Figure 2 Relationship between components of software requirements

The demand project is divided into two phases: demand development and demand management. The following describes the two phases:

I. Requirement Development

Requirement development is divided into requirement acquisition, requirement analysis, specification writing, and requirement verification. The following lists and explains the common Analysis Steps. Of course, we should determine the appropriate steps based on actual conditions such as the project size and characteristics.

1. requirement acquisition:

1) determine the requirement development process: Determine how to organize the collection, analysis, refinement and verification steps of the requirement development process, and compile it into a document. Guidance should be given on important steps, which will help analysts and make it easier to collect demand activities and schedules.

2) compile the project view and scope document: the project view and scope document should include high-level product business goals. All instance and function usage requirements must comply with the business requirements that can be fulfilled. The project view description allows all project participants to reach consensus on the project objectives. The scope is used as a reference for evaluating requirements or potential characteristics.

	1	2	3	4	5	6
Business Requirement A	background	Business Opportunities	business objectives	customer or market demand	value provided to customers	business risk
solution of Project B	project view statement	main features	hypothesis and dependent environment
scope and limitations of C	scope of the first release	subsequent release scope	limitations and specialization
d Business Environment	customer profile	Project Priority
factors for product e success

Table 1 templates for project views and scope documents

A. 1 Background This section summarizes the theoretical basis of new products and provides a general description of the historical background or situation of product development.

A.2 Business Opportunities describe existing market opportunities or business problems being solved. Describe the environment in which the competitive market and information system of commodities will be applied. This includes a brief relative evaluation and solution for existing products, and points out why the proposed products are attractive and why they can bring about competitive advantages.

A.3 The business objective is to summarize the important commercial profits brought by products in a quantitative and measurable and rational way, focusing on the value of the business.

A.4 customer or market requirements describe the needs of some typical customers, including those that do not meet the needs of products or information systems in the existing market. This article introduces the possible (or impossible) problems encountered by the customer in the new product, and provides an example of how the customer uses the product. Determine the software and hardware platforms that can run the product.

A.5 determine the value of the product provided to the customer and specify how the product meets the customer's needs.

A.6 summarize the main business risks related to the product during development (or not development, such as market competition, time issues, user acceptance, implementation issues, or potential negative impact on the business. Predict the severity of the risk and specify the measures you can take to mitigate the risk.

B .1 project view statement: A Brief project view statement that summarizes the long-term goal and the purpose of developing new products. The project view statement will consider balancing the views of customers with different requirements. It may be a bit idealistic, but it must be based on the existing or expected customer market, enterprise framework, strategic direction of the organization, and resource limitations.

B .2 main features include the list of main features and user performance that new products will provide. It emphasizes the characteristics different from those of previous products and competing products. You can obtain these features from user requirements and functional requirements.

B .3 assumptions and dependency environments record any assumptions made when creating a project and compiling a project view and scope document. Generally, the assumptions held by one party should be different from those held by the other.

C.1 scope of the first release summarizes the performance of the first release. Describes the quality features of the product. These features allow the product to deliver expected results to different customer groups.

C.2 scope of subsequent releases if you imagine a periodic product evolution process, you need to specify which major feature development will be extended and look forward to the date of subsequent releases.

C.3 limitations and specialization defining the boundaries of features and functions that are included and excluded is a way to deal with scope setting and customer expectations. List the features and functions that risk owners expect, but you do not plan to include them in the product.

D.1 customer profile the customer overview clarifies some essential characteristics of different types of customers of this product, as well as the characteristics of target market departments and different customers in these departments.

D.2 once the priority of a project is clearly set up, risk owners and project participants can focus on a series of common goals. One way to achieve this is to consider five aspects of a software project: performance, quality, planning, costs, and personnel.

E. Factors of product success determine how product success is defined and measured, and specify several factors that have a huge impact on product success. It should include not only transactions within the scope directly controlled by the Organization, but also external factors. If possible, measurement criteria can be set up to evaluate whether the business objectives are met.

3) user group classification: there are many differences between product users, for example: the frequency of products used by users, their application fields and computer system knowledge, product features they use, their business processes, their geographical layout, and their access priorities. Based on these differences, you can divide these different users into groups. User classes do not necessarily refer to people. You can put other applicationsProgramOr the hardware components used by the system interface are also considered as members of the additional user class. Looking at application interfaces in this way can help you determine the requirements related to external applications or components in the product. Classify user groups and summarize their respective characteristics. To avoid the need for a user group to be neglected, it may be different. A detailed description of their individual characteristics and task status will help the product design.

4) Select Product representatives: Select Product representatives for each type of users to select at least one person who can really represent their needs as representatives of that type of users and make decisions. This is the easiest way to develop internal information systems, because users are employees around them. For commercial development, we need to establish a good cooperative relationship with major customers or testers and determine appropriate product representatives. They must always participate in project development and have the right to make decisions. Each product representative represents a specific user class and acts as the main interface between that user class and the developer.

5) Build a core team: Build a core team of typical users to bring together representatives of similar products or previous versions of your products, collect the functional and non-functional requirements of current products from them. Such a core team is especially useful for business development because you have a large and diverse customer base. The difference with product representatives is that core team members usually have no right to decide.

6) confirm the use of instances: Ask the user representative to determine the use of instances from the user representative office to collect the descriptions of the tasks they need to complete using the software-use instances to discuss the user-system interaction and dialogue requirements. You can use a standard template when writing documents for using instances to meet your functional requirements.

A single use instance may include many logic-related tasks and interaction sequence for completing a task. Therefore, an instance is a collection of related usage instructions and an example of using an instance. Lists the interaction or dialog sequence between the performer and the system in the description. When such a conversation ends, the performer also achieves the expected goal.

For some complex examples, it is helpful to draw graphic analysis models, including data flowcharts, object relationship graphs, state conversion graphs, object classes, and contact graphs.

The instance description does not provide developers with details about the features they want to develop. To reduce this uncertainty, You need to describe each use instance as a detailed functional requirement. Each instance can extend Multiple Functional requirements, which enables the executor to execute related tasks. In addition, multiple instances may need the same functional requirements. The benefit of using the instance method to obtain requirements comes from the task-centric and user-centric perspective. Compared with the function-centric approach, the instance approach allows users to better understand what the new system allows them to do.

Each instance describes a method. You can use this method to interact with the system to achieve a specific goal. Instances can effectively capture most of the expected system behaviors, but you may have some requirements that do not have a specific relationship with the interaction between user tasks or other executors. In this case, you need an independent Requirement Specification Description.

7) Hold the application development contact meeting: Hold the application development contact meeting, which is a wide range of and simple seminars, it is also a good way of cooperation between analysts and customer representatives, and the requirement document can be prepared accordingly. Through close and concentrated discussions, the meeting was able to put the partnership between customers and developers into practice.

8) analyze the user's workflow: analyze the user's workflow to observe the process of the user performing business tasks. Draw a simple diagram (preferably using a data flow diagram) to describe when the user obtains the data and how to use the data. The preparation of Business Process documents will help to clarify the use cases and functional requirements of products. You may even find that customers do not really need a completely new software system to achieve their business goals.

9) determine quality attributes: determine the quality attributes and other non-functional requirements. Consider the quality characteristics of non-functional features in addition to functional requirements. This will make your product meet and exceed the customer's expectations. The statement on how the system can perform certain behaviors well or allow users to take certain measures is the quality attribute, which is a non-functional requirement. Listen to the opinions that describe reasonable features: fast, simple, intuitive, user-friendly, robust, reliable, secure and efficient. You are going to discuss with users how to precisely define the true meanings of their vague and subjective words.

10) Check problem report: by checking the problem report of the current system, we can further improve the problem report of the requesting customers and supplement the requirements. This provides a large number of rich ideas for improving and adding features for new products or new versions, persons responsible for providing user support and help can provide valuable information for the collection of demand processes.

11) Demand reuse: Cross-Project reuse requirements if the features required by the customer are similar to existing products, you can check whether the requirements are flexible enough to allow reuse of some existing software components.