Seven Weapons of software engineering requirement analysis (I)

Background

Character: "I"

Role: IT department System Analyst

Company Profile: Qin yuan Electronic Trading Company (not his real name), with an annual turnover of 0.2 billion, mainly composed of the sales department, materials department and IT department. The sales department is responsible for business, the materials department is responsible for supplier development and procurement of electronic component products, and the IT department is responsible for the development and implementation of the company's order management system.

System objective: the company will include business opportunity management on its agenda this year. The so-called "Business Opportunity" refers to the customer demand information that can bring performance and profit to the company. Once a business opportunity is submitted, the company's sales department, materials department, and so on will need to complete some business tasks for this business opportunity. The purpose of this system is to manage and track this business opportunity and its tasks.

Status quo Description: some time ago, after business interviews, the system needs were captured and the scope and objectives of business opportunity management were determined.

Task Description: Business Opportunity Tracking System Requirement Analysis.

The first weapon: the modeling method 

Demand analysis often starts from modeling. The main reason for modeling is that complexity is reduced through abstraction, which helps to recall all the details and facilitate communication with developers and system stakeholders. The model itself can also be used as a system maintenance document.

Graphical models are schematic representations of charts and systems. They use symbols to represent abstract objects, such as entities, processing processes, data, objects, information, and connections. The focus of the demand analysis stage is on the issue of high abstraction of system requirements.

Before creating a model, we must understand two key concepts: Events and things. "Event" refers to something that can be described and recorded at a specific time and place. "Things" are similar to external entities or participants that interact with the system. At the same time, things constitute the data related to system storage information.

With reference to the task described above, we have created an event list, an entity-contact diagram, a class diagram, and other model data flow diagrams for business opportunity management in the analysis phase. In the design phase, the models we created include the interface design, flowchart, database design, and structure diagram.

The business opportunity tracking system events are as follows:

• When receiving business opportunity Information
• Release business opportunities
• When receiving task information
• Task tracking
• When the task is completed
• When business opportunities are closed
• Business Opportunity fulfillment

Our understanding of events in the real world helps us to understand the concept of events in modern programming languages, and makes us realize that programming languages have produced many ideas and types during their development, the goal is to better solve practical problems.

Let's list part of the noun-based business opportunity tracking system, including: business Opportunity Task, BOM, owner, subject, content, operator, task inquiry, price negotiation, special offer application, evaluation, sample tracing, etc. What else? Maybe, if not, congratulations, your requirements have been refined.

We list the things as a symbolic system for requirement analysis. We can see that the natural relationship between things is clear. There is a one-to-multiple relationship between a business opportunity and a task, that is, a business opportunity can trigger at least one task or multiple tasks.

We can see that accurately defining system concepts, events, things, and processes is the cornerstone of building a model. It can even be said that it is the basis of all demand analysis methods.

The model graphs that need to be focused on are Entity class graphs and entity relationship graphs (ERD ). An object class diagram describes the relationship between an object and an object. It can be made using multiple CASE tools, such as Visio or rose. It is also a model in the abstract layer of UML for requirement analysis. An object relationship graph is a data model that helps us analyze and understand the data components of a business or system.

An object is named by a single name and represented by a rectangle in ERD. The object relationship diagram uses a diamond box to represent the relationship. It determines the logical and quantitative relationship between a pair of entities. The Link name must be able to describe the nature of the link. For example, the relationship between "Bom business opportunity" and "task" is "executed", which is expressed in words as "Bom business opportunity is executed by task" or "task execution BOM business opportunity ".

When reviewing ERD, ask the customer to check whether all the relationships shown in the figure are correct, appropriate, and comprehensive.

Provides an erdiagram of business opportunity tracking.

Figure 1 business opportunity tracking E-R

 

 Second weapon: peacock-Use Case Method

An important function of use cases is to identify and divide system functions using the function of drawing use case diagrams. It divides the system into roles and use cases ). A role represents a person, hardware, or software system that interacts with the system for a specific purpose.

The only criterion for determining roles is that they must be excluded from the system part of the case. They must be able to stimulate the system part and receive responses. Use Cases describe the activities of the system when a role gives a specific stimulus to the system. These activities are described in text, describing the nature of the responses that are stimulated when a use case is triggered, input and output to other actors, and the activities that convert input to output. The use case text usually also describes possible errors and remedial measures that the system should take during special activities. Use cases can also be represented by activity diagrams.

This may be very complicated. In fact, a use case describes the interaction sequence between the system and a role. The use case is defined as a series of actions performed by the system, and the execution result of the action can be noticed by the specified role.

The following table describes the goals that can be achieved by the use case:

• Use Cases capture the visible needs of some users to achieve a specific user goal.
• The use case is activated by the role and the exact value is provided to the role.
• The use case can be big or small, but it must be a complete description of the implementation of a specific user goal. In UML, the use case is represented as an elliptic.

From the perspective of demand development, the traditional demand analysis method is to study what users need to do with the system, but now it is to discuss what users need to implement. The purpose of the use case method is to describe.

We usually use the following method to determine the use case:

• First, define the executors and their roles, and then determine which business processes they are involved in.
• External events that can be reflected by the system, and then associate these events with participating executors and specific use cases.
• Describe the Business Process in a specific scenario, classify these scenarios as use cases, and determine the roles involved in each use case.

The business opportunity tracking system adopted the first method. I held a series of case acquisition and analysis seminars every Monday or twice, before each meeting, ask the user to think about what tasks they need to execute using the new system. I found that the name of the use case should indicate the target to be achieved by the user, and the verb must be used in the noun to describe the use case. In this way, you can describe your tasks, that is, the use case that the analyst needs to describe.

After requirement analysis, the e-company's business opportunity management role is as follows:

• Business Opportunity members: they are responsible for publishing business opportunities.
• Business Opportunity management: It is responsible for handling and allocating business opportunities. It often takes the following actions: Business Opportunity allocation, verification, inquiry, price negotiation, sample tracing, and confirmation.

The Use Case of the Business Opportunity Tracking System "Business Opportunity release" is described as follows:

Third weapon: Jasper knife-Prototype Method

Prototype refers to the meaning of models and samples. Obviously it draws on the experience of the manufacturing industry to require samples before undertaking batch orders. In the initial stage of the system, it uses a movable prototype to describe the requirements and analysis requirements, it gives people a sense of openness. The idea here is actually to acquire the demand by design, and the "brick" of the design prototype leads to the "Jade" of the real demand ". We should also see that the visualization of software tools is also the reason for the rapid generation of the original method. Prototype can be divided into several types: interface prototype, conceptual model, and data model. Psychology also shows that people have a much better understanding of the active interface prototype than static transactions, as if the visual impact of images is much greater than the text.

A rapid implementation prototype plays the following role in the entire demand development process:

• Clarify and improve requirements
• Research and Design Selection Scheme
• Final Product

There are many benefits of a prototype. I believe the following principles can be used to build a prototype to achieve better results:

• Tasks and resources that are scheduled to create prototypes in the Project Plan.
• Purpose should be stated before creation.
• Creating obsolete prototypes should be as fast and economical as possible, with minimal investment in developing prototypes for answering questions and solving demand uncertainty.
• Do not create prototypes for understood requirements, unless it is a research design selection scheme.
• Use seemingly real data in screen display and reports.
• You cannot expect a prototype to replace the Software Requirement Specification (SRS ).
• The design prototype can refer to the interface of the same type of software, but the design should not be separated from the actual needs and objectives.

Well, now let's take a look at the true nature of the business opportunity tracking system prototype interface.

Figure 2 new business opportunities

Figure 3 Task tracking

From the above prototype interface, it is a webpage in HTML format and looks very real. However, we will also find that the difference between the prototype method and agile development (XP) lies in the function: the prototype method focuses on the interface and concept definition, while agile development focuses on the iterative Implementation of functions.

 

Source: http://tech.it168.com/m/p/2007-03-22/200703221308636.shtml