CMM practice-use requisitepro for requirement Management
Problems in Demand Management
The key process domain of requirement Management (RM) in cm3. In our company's practice at the level 3 of CMMS, demand management is often a very costly task, for example, in demand analysis, building a demand tracking matrix, and other activities, if a team or several groups collaborate, a large number of Word and Excel files need to be transferred among different personnel, and tools such as VSS are used, there is still no way to avoid tedious and inefficient work methods, which may lead to problems such as the poor delivery of documents, overlapping requirements and Use Cases of collaborators, and missing expansion requirements. During the implementation of cm3, this step increases the company's operating costs.
For example, when multiple people collaborate to complete requirement analysis and manage all requirement cases, the requirement personnel can only use the same word document template according to the previous requirement survey report, analyze and describe the use cases of your tasks in detail, and then merge the Word documents written by the owner. This merge is a manual merge. At the same time, when analyzing the requirements of each person, you can only read all the documents to check for any omissions and other serious problems.
For another example, when a company uses the most primitive method to create a demand tracking matrix, it usually uses an Excel table to list a two-dimensional table and uses several stages of software survival as several columns, for example, "requirement", "design", "code", "test", and "release". Then, the requirement analysis personnel first put the "requirement case" in the first column, list all the requirements, and then hand over the Excel worksheet to the designer. Then, the designer will list the design items corresponding to each requirement on the "design" in the second column, this will continue to be passed on. In the meantime, I do not know how many people have gone through this table. Once one of them has been modified, it is difficult to ensure that the security is correctly traced forward.
If the company develops some management tools on its own to solve the above problems, it still needs to spend a lot of money.
Rational requisitepro features
- The IBM Rational requisitepro solution is a requirement and case management tool that helps the project team improve communication between project objectives, enhance collaborative development, and reduce project risks, and Improve the Quality of applications before deployment.
- Provides a familiar environment for the definition and organization of requirements through advanced integration with Microsoft Word
- Provides real-time synchronization between databases and Word documents to facilitate the organization, integration, and analysis of requirements.
- Supports customization and filtering of detailed demand attributes to maximize the information value of each requirement.
- A detailed trackable view is provided. These views can display the parent-child relationship between requirements and the relationship between requirements.
- Project baselines in XML format can be exported to compare the differences between projects.
- It can be integrated with many tools in IBM software development platform to improve the accessibility and communication of requirements.
Flexible application of rational requisitepro in CMM practice
The features listed above show that this software is a powerful demand management tool, we can use some of its features to flexibly handle operational and difficult activities related to requirements in level 3 of CMMs.
When multiple users use word for requirement analysis, the tool can be used to synchronize data with databases and Word documents in real time and collaborate with others to organize and integrate requirements.
To create a demand tracking matrix, we can use its rich trackable view features, according to our original method, set the stage items of each column in the Excel worksheet table to one type. For example, "Use Case requirement", "design", "encoding", and "test" are added to four columns respectively. Then, connect these requirements to the word text segment. For example, "design items" can be associated with use case items in Rose or related paragraphs in design documents.
At this time, the project team's requirement personnel can use requisitepro to add the "Use Case requirement" in the first column. all the requirements have been added, designers can also use it to add items in the "design" column. These operations do not need to pass an Excel document any more. You only need to use requisitepro to open the same project. Similarly, when the project team enters different stages, relevant personnel can use this tool to add and modify the project.
In this way, we can perform requirement coverage analysis. Through the method of creating a view, we analyze the coverage between the "Use Case requirements", "design", "encoding", and "test" and other requirements defined by us, that is, whether the records of a stage can be traced to a use case requirement item, that is, the result-> cause.
In particular, backtracing matrices can also be generated from the phase item to the use case requirement item. Arrows with red lines indicate suspect (suspicious) tracking, that is, if either of the two items with a trace relationship is modified independently, requisitepro will automatically mark it as a suspicious trace to remind you.
The above is just an example of rational requisitepro. In short, flexible use of tools can solve some problems that are difficult to operate during the implementation of cm3. this reduces implementation costs.
Be good at using tools during implementation of CMM
I personally think that in the process of implementing CMM, it cannot be self-written. Otherwise, the implementation cost will be huge. How to use tools to better solve problems in practice is the most important thing. Of course, different tools can be used in different situations, so we must give full play to the capabilities of implementers. From this point, CMM only tells us what to do, but it makes sense not to tell us how to do it. For the same purpose, there will be a lot of ways to achieve it. For a CMM implementer, he is equivalent to a innovator, just like the reform of our country, there is no Western method that is the best. It is the key to success to find the method that best suits us through our own practices.
Introduction to rational requisitepro
- Rational requisitepro is a good requirement building and management tool. Here we take the Learning Project-usecases example provided by requisitepro as an example to briefly describe how to use it.
- 1. Open project mode
- When you need to modify certain project attributes (this is determined by requisitepro), you need to select this mode. At this time, the current user is the only user of the project. However, in general, you do not need to make any choice on "open project option". When requisitepro detects that you can modify a certain project attribute only in exclusive mode, the requisitepro dialog box is provided for you to determine the "exclusive" mode.
- 2. interface elements
- The corresponding concepts can be determined through visual icons.
- Here, only the package, document (Word document), requirement (requirement), and view (View) are described:
- 1) package: it is the requirement organization mechanism. It is similar to the UML Package concept. A package can also contain sub-packages, documents, requirement, and view.
- 2) Document: this is an important way to present the printed version of the requirement document and write the requirements. Generally, you can create a Word document in the shortcut menu on the package icon and select the text in the Word document to create an automatically numbered UC event, term item, and feat item. Document is a required container. The document is typed in requisitepro.
- 3) Requirement: mainly refers to UC events, term items, and feat items.
- 4) view: After creating an automatically numbered UC event and feat item, you can analyze the two requirements, and the visual graph of the analysis is implemented through view, view is basically the result of a query. In requisitepro, you can set the query requirement type and its attributes to get a specific view, for example, sort the view based on the demand priority.
- 3. Organize the requirement documents through the package
- When building a demand management project based on use-case template, the first-level package name is as follows:
- 1) coverage analysis package: requirement coverage analysis. The method of creating a view is often used to analyze the coverage between UC events and feat items, that is, whether a UC event can be traced back (Traceable) to a feat item, that is, result-> reason.
- 2) features and vision package: Features and prospects. This is a high-level requirement, which is equivalent to the System Overview In the use case document. It has the main features, the needs of key risk owners, and key services.
- 3) Glossary package: term. Terms in this field. For example, role in the application field. It is basically a concept unrelated to computers.
- 4) Impact Analysis Package: Impact Analysis. Display the relationship between requirements (such as UC events and feat items) in a view. Unlike the coverage analysis package, this package stores the forward tracking matrix of requirements to express the impact chain of requirements, that is, the result of the result.
- 5) Supplementary requirements package: supplement the requirement. This word is not very accurate, because the package is not stored by a single use case specification document, that is, non-functional requirements, such: portability, reusability, security, scalability, etc. These requirements generally express constraints on multiple use cases.
- 6) Use Case package: Use Case. Store the use case specification document, which describes functional requirements.
- 4. Document Type
- Requirement documents are typed to identify different requirements and document formats (this is done through the document template corresponding to the document type ).
- Three types of documents are used:
- 1) Glossary document type: the term document type.
- Note: Double-underline paragraphs are stored in the DB corresponding to the requisitepro project, and other paragraphs are only stored in the Word Document (but the extension is GLS ), therefore, requisitepro will maintain bidirectional synchronization between double-underline sections and DB.
- 2) Use Case specification document type: Use Case specification document type, used to state a use case.
- In the use case specification document directory, you can see the basic process, optional process, special requirements (generally non-functional requirements), front and back parts. This type of document expresses the details of an elliptic (a use case) in the use case diagram. The details are mainly the Interaction Events (UC items) involved in the use case) the front and back parts executed in this use case. A use case diagram can be attached to this document to briefly describe the relationship between the use case and other use cases.
- Is an example of this type of document, which states the availability, easy-to-use interfaces, training, and other non-functional requirements. As a link to the use case specification document package, one of which is functional.
- 5. Requirement type
- The requirement type here is the type of paragraphs that can be saved to DB in Word documents. Note: These types Use prefixes to express their meanings:
- Feat item: identifies a special section, which is generally stored in vision. vis document (word.
- (The section with double dashes will be saved in dB ).
- Other requirement items are similar to feat items.
- 6. Attributes of requirement items
- All requisitepro elements have properties, but only the requirement item has the attribute ).
- Feat item: feat: The requirement attribute of the product feature. You can set its priority, difficulty, status, and stability.
- You can create a View query to list all the requirements in a package.
- 7. view type
- There are three view types: different view types can be separated from their icons.
- 1) attribute matrix: attribute matrix.
- 2) traceability matrix: trace Matrix
- From the UC item to the feat item backtracking trace matrix, the arrow with a red line indicates the suspect (suspicious) trace, that is, if either of the two items with a trace relationship is modified independently, requisitepro automatically marks a suspicious trail to remind the demand analyst.
- 3) traceability tree: trace tree: basically the Tree Representation of the trace matrix.
- 8. Create a requirement item in Word
- Take the establishment of UC items as an example to create UC items in word. Although you can also create a UC item on the requisitepre interface, the UC item is not automatically displayed in the Word document. Therefore, we recommend that you create a UC item in word.
- 1) Select the word section of the UC item to be created.
- 2) open new requirement and set
- A) set the UC Item Name
- B) set hierarchy
- Set the parent UC item of the UC item for requisitepro to automatically calculate the number of the UC item:
- C) set other attributes and save the document
- You can see this UC item in requisitepro.
- 9. Support for team development.
