UML System Analysis and Design 03-Software Requirement Analysis Specification

This article will work with UML System Analysis and Design 02-use case diagram and activity diagram (I)UML System Analysis and Design 02-use case diagram and activity diagram (below)Together to form a simple UML-basedAnalysis of software requirements of the technology and output the analysis results.The Software Design of the technology is summarized to give reference to others.

 

Although the software requirement analysis specification is not the content of the UML system, it is also necessary to briefly describe it as an important output for System Analysis and Design Using UML. As my company's document is marked as "confidential", it cannot be shared here for your reference.

But then again, my company did not have this document before, at least when I joined the company. Later, I should have referred to another person's template, some changes have been made based on their own characteristics, which is similar to the templates published on the Internet. If you are interested, refer to "system requirement analysis manual instance template" in Baidu Library ". (I did not carefully analyze the content, but simply read the following format)

[Note: if the file cannot be downloaded, you can use the tool "idocdown" to download documents from Baidu Library. Of course, I am not responsible for downloading the "System Requirement analysis manual instance template" document.]

For the purpose of study and communication, I will share the document directories I know with you. The directories are divided into three parts:

1): the previous section

Most of the content in the previous section can be obtained from the feasibility analysis report and Product Requirement Specification.

 

2): intermediate part

The intermediate part is the focus of this manual, mainly the output of documents after analysis of business/needs, and is the focus of this article.

 

3): Subsequent parts

The last part focuses on the overall requirements, such as integration and cooperation with external systems, and planning for subsequent product development and upgrade and expansion.

 

4): Special Instructions

In this document, there are many words such as "constraints", "restrictions", and "environment", which are generally verified by "non-functional requirements, in many cases, sales often make a promise in the early stage to sign a ticket. For example, response time, concurrent data, and data volume, but it cannot be careless for development. I have suffered a loss in concurrency.

[Note: The feasibility analysis and product specification are both product-based. The system requirement analysis manual is based on the current project. Product requirements may be divided into several projects in batches and in stages: you will be provided in the second phase. In fact, there is no money in the second phase ). Strictly speaking, the objectives of the two documents may be different from those of users. You can simply consider that the project requirements are less than or equal to the product requirements.]

From the directory, we will find that the first part and the last part have basically been mentioned in previous documents, so simply copy them and sort them out. The "use case description" in the middle section is the focus of our description. It is mainly used to describe functional requirements. That is, the document output of the results of Requirement Analysis described in previous articles, namely the software requirement analysis manual.

The format of the "software requirement analysis manual" takes the Word format as an example. There are two common formats. After searching on the Internet, it is basically similar to the following:

1): Table mode

Use Cases1	Case name
Description	Detailed explanation of this case
Prerequisites	To enable this use case to work, what conditions must the system be in? For example, a store must first open
Trigger Condition	What causes this use case to start working? If a customer needs a product and enters the store.
Successful	What is the status of the system after the use case is completed? If the customer has the desired product and feels happy, the currency is stored in the Cashier's machine, waiting for the next customer.
Abort	What happens if the use case is abandoned? For example, if a customer puts down the shopping basket and does not buy anything to leave, someone needs to see this and put the goods back to the original place.
Participants	Main	Who plays a leading role? Such as customers and cashiers?
	Subordinate	Who plays a secondary role? Like a clerk?
Process	Procedure	Activity name	Description
	1
	2
	3
Change	Procedure	Activity name	Description
Exception	Procedure	Activity name	Description

 

2): Number Method

1. Use Case name

1.1 prerequisites

1.2 post conditions

1.3 expansion point

1.4 event stream

1.4.1 base stream

1.4.2 branch stream

S-1:

S-2:

S-N:

1.4.3 substitute stream

E-1:

E-2:

E-N:

 

2. Use Case 2(Omitted)

 

I prefer the second indent method, because the steps of the activity diagram are not fixed, and I do not like to add or delete the mesh, Which is troublesome. Of course, the grid looks quite clear. Let's take an example for reference (* ^_^ *)

 

------------------------- Example -------------------------

1. Manage Recording Materials

1. use case diagram

 

 

2. use case description:

The management of recording data use cases is mainly used by the Administrator to "add", "modify", and "delete" operations on the recording data, so that the administrator can promptly create and update the recording data. (More details can be found here ).

This example is implemented by the Administrator in the basic data management module. It is mainly used to maintain basic information and inventory information of records.

This use case includes three specific use cases:

Create a record: the Administrator enters the basic information and inventory information of the record and creates data information.

Modify the record information: the Administrator modifies the basic information and inventory information of the record. Then save or cancel the restoration operation.

Delete records: the Administrator deletes the selected records.

3. Prerequisites:

Only users with the Administrator identity have operation permissions for this function.

4. Post conditions:

If the use case is successful, the recording information and associated information corresponding to the use case will be added to the system, modified, updated, or deleted. If the use case is unsuccessful, the system status will not change.

5. Participants:

Administrator

6. Basic event stream:

When the administrator needs to add, modify, or delete information about a record, use cases are started.

The system presents activities that the administrator can perform (add new records, modify records, and delete records.

If the selected activity is add record data, execute the branch stream S-1: Add record data.

If the selected activity is modify record data, execute the branch stream S-2: Modify record data.

If the selected activity is delete record data, execute the branch stream S-4: delete record data.

7. branch stream:

S-1: New Records

(1) Select the add operation

(2) The system provides an information editing interface for adding new records. Users are required to specify the recording name, Publishing House, publishing time, and existing inventory for input.

[Note: this information is only representative and not necessarily applicable to reality]

(3) submit after the user enters the recording information

(4) system verification user submitted information (E-1)

(5) The system stores information about new records.

S-2: modifying records

(1) user selection and Modification

(2) The system displays the record information list and requires the user to select the desired record information

(3) Select a record to be modified.

(4) The system provides an information editing interface for selected records

(5) Submit the user after editing the basic information of the Recording Materials

(6) system verification user submitted information (E-2)

(7) The system saves the modified records and materials.

S-3: deleting records

(1) Select the delete operation.

(2) The system displays the wafer data list and asks the user to select the data items to be deleted.

(3) Select the recording materials and confirm the deletion.

(4) system verification user submitted information (E-3)

(5) Information about the deleted records

8. Alternative stream:

E-1: records submitted by the user conflict with the data in the system, the system shows the failure information, the user can re-enter or terminate the use case.

E-2: After the user submits the edited records information and the data in the system conflict, the system shows the modification failed information, the user can refresh the records list shows re-start modification or termination of use cases.

E-3: The delete operation selected by the user is not available, the system displays Failure Information, returns and refreshes the record list. Or a warning message is prompted. You can confirm or cancel it.

9. Expansion point

None;

[Note: use cases used to describe "extend" here]

10. Activity diagram:

 

[Note: the advantages of good case decomposition are not only reflected in the technical aspects, but also helpful for project management. Especially when running the WBS taskSplitting and task scheduling are clearly displayed.]

 

------------------------- The example is completed -------------------------

 

So far, most of the jobs based on UML are to analyze the requirements, so as to filter and summarize them. The main targets are users and product managers. Throughout the process, technicians may be more interested in clarifying the feasibility of Use Cases and assisting in the transformation from product requirements to system requirements (for example, "The store manager can delete the recording materials, the clerk cannot "analyze and convert it into" Role-Based permission management ") to form this" software requirement analysis manual ".

An important role of the Software Requirement Analysis specification is to transform product or user requirements into system requirements and become a baseline for subsequent project development. According to "Project Management", the "Project Scope" of the Project is clarified ".

Of course, in many projects, "typical UI style of the system", "Operation documentation", and even "simple demo model" are provided as attachments together with this manual, provide more intuitive expressions for related "reviews" and more accurate guidance for subsequent development.

 

[Supplement: The Software Requirement Analysis specification is sometimes referred to as the System Requirement Analysis specification or System Software Requirement Analysis specification]