Rational Software White Paper
Dean Leffingwell
Senior Software Engineer, IBM 2004 November
Introduction As a follower and support for object-oriented technology as a BU (UML appearance), I must admit that the various methods and representations of the industry's ideological leaders have been have some kind of magic. In two to four years before UML appears, you can walk into a room that is crowded with an OO advocacy and ask questions:
I think this OO technology is very promising, but tells me that since the object sharing behavior and data, how do you call the object to achieve its behavior obligations?
You may get the following answer:
"It is a responsibility!" (Wirfs-BROCK) "It is an action" ("it is a service" (COAD / YOURDON) "It is a (virtual) function" (STOURSTRUP "it is a Method (other than many people)
If this is not enough to confuse, then don't ask how to use graphics to call it objects and classes. (It is a rectangle, a cloud, and so on.) Although this is very stupid, the actual situation is that some of our software engineering leaders (inheritance, relationship, packaging), due to terminology and representation The minimal difference cannot be shared, or at least become confusing. In other words, whether it is OO engineering science or the interests to be obtained, it cannot continue to develop forward, because there is no inventive language to describe the scientific language. Of course, to reach a small thing in these authors, methodologists and independent thinkers, but in the end UML, software engineering science has moved forward.
Although the demand management methodology may not be as bad as the Babi Tower formed by OO method before UML, it has experienced the same problem - especially the blur, inconsistent and excessive use of common vocabulary. These vocabulary (including "use cases", "feature", and "requirements" are the daily vocabulary of "everyone understands", but each person gives them its own meaning in a given context. The result is that communication is not smooth. This happens only in the field of consensus as a successful standard. Booch [BOOCH 1994] quoted Stepp's statement:
One problem in science is to construct meaningful classification for observing objects and situations. Such classifications can promote people's understanding of observation and subsequent scientific theories.
In order to promote the "scientific theory" of the demand, we have to face the problem of terminology.
The purpose of this article is to initially explore the principle of software engineering by defining and describing some of the most common terms and concepts for explaining system software requirements. To this end, we hope to provide a basis for reaching consensus of all people (users, managers, developers, etc.). Of course, if we communicate more effectively and thus gain a consistent view, it may develop and deliver higher quality systems faster.
This paper focuses on the principle of demand management - the author recommended a lot of reference books in this respect. The purpose of this article is to help employ practitioners in this area improve their basic understanding of the correct behavior of the system.
The comparison between the problem domain and the solution domain Before starting to describe the specific terms, we must first realize that the need to define terms from two completely different aspects: aspects and solutions. We call them as a problem domain and solution domain.
Problem Domain If we do "low-alone" on the problem domain, we will find things around many actual life. For example, when "gliding" has passed the human resources department, he will see employees, responsible for employees, and pay checks. When you have a heavy equipment factory, we will see welders, welding controllers, welding robots and electrodes. When "Sliding" over the World Wide Web, we will see the router and server cluster, and users with browsers, telephone and modems. In other words, in any issues, we can easily identify things (entities) we have seen and exposed. Sometimes we can even see the relationship between these things; such as a one-to-one relationship between web users and browsers. We may also see a message from one thing to another: "Welders seem to be prepared in the 'brain' of the welding robot." If we are a keen observers, you may find any problems to be solved: "Welding workers are unpleasant when they can not arrange the correct work order" or "notice that employees enter salary data and receipt of the check-free time delay ! " Some problems seem to just beg to be a solution. Perhaps we can build a system (better programmable controller, more efficient salary) to help those poor users solve these problems.
Based on user and related needs
However, before we build a new system, we need to ensure that the truly needs of users in this issue are understood. If we don't, we may find that the welders can only be frowning, because he is as painful as the feet, the result is that he and his manager will not be interested in purchasing our latest "smartbot" automatic welding control unit. We also notice that when we try to sell SmartBot, the manager is a key to the purchase decision. We don't remember to see her in "gliding". (Maybe she is smoking at the time, where there is a blind spot of our camera). In other words, not all the people are all users, and if we want to have a chance to sell SmartBot, we must understand the needs of two communities (involved in public and users). For the sake of simplicity, we call all these needs to be involved, but we have to constantly remind our system's potential users sometimes represent a very important type of public type.
We will be defined as:
A reflection of business, personal or operational issues (or opportunities), which must be resolved to enable users to believe that they consider that the choice of purchases or uses new systems is correct.
Those who are involved in crowds have become a representation of issues related to the problem domain. These national demand did not give a solution, but in an initial angle, let us understand which feasible solutions need to be implemented. For example, if we meet the manager managed to manage the welded workers in the heavy equipment manufacturing plant, it may be found that the welding of the solder is consumed to consume huge manufacturing time and cost. In addition, the welder does not seem to like these specific work because they have been in danger of being burnt. Worse, the physical aspects of the work (repetitive, difficult to ponder, handmade), and the harm of vision, etc.) bring personal security issues and long-term health hazards.
Fully understand these matters, we can begin to define some of these involvement requirements:
We need an automated approach to create a large number of repeated weldments without allowing the welder to control the electrodes. We are happy to have a welder, but we need to move it to a safe area other than solders and away from those moving machines. We need to easily use "training mode", so general welders can also "training" machines to do most of them. We need to make greater flexibility in training mode and realize that this may conflict with certain aspects of user friendliness.
After understanding these different aspects of the system, we will focus on these discovery "stack" in a small bunch called Zhu. The solution domain is fortunately, "gliding" for the problem domain will not spend a long time, and (usually) we found in the problem domain is not very complicated. When we complete the "gliding" and start building our observed issues and the needs of the solution, we will start to understand the problem. Yes, we have begun the hardest part: Building a solution solution. We consider the activity set (system definition, design, etc.) to solve the problem, "things" (computer, robot arm, etc.) found and constructed, and workpieces created in the processing section of the solution domain (such as source code, use cases, and test).
In the solution domain, we must successfully perform many steps and activities, which can be defined, build and finalize the successful solution for the issue. They include:
1) Understand user needs
2) Define the system
3) Management scope and manage changes
4) Refining system definition
5) Construct the correct system
Briefly, the above steps define a simplified process of demand management. This article does not intend to introduce these steps; about this content we will recommend some reference books, including textbook "Managing Software Requirements", [LeffingWell, 1999]. This article is consistent with the reference book, and most of the definitions provided here are from the reference book.
For example, in the reference book [Leffingwell, 1999], we will find that demand management is defined in this:
The systematic approach to obtain, organizational, and recording system needs, establish and maintain a process of consensus on system requirements change between customers and project teams.
Or let us continue to find and define the other more demand management terms used to describe the system to be built.
Frequent demand terms in solution domain
Product or System Features When we start considering solutions that have identified problems, it naturally will never write down the system's characteristics. Features possesses a very interesting position in the development of the system. They seem to be intermedial between the user's truly needed expression and the system implementation of these needs. In this way, they provide a convenient construction in accordance with the abstract manner, or if you prefer, provide a "shorthand method". Since there are many possible solutions that need to be resolved, the initial scope of a specific system solution is provided in a sense of significance; they describe what the system is intended to do and what is not planning.
We define properties as a system that provides services for implementing one or more related needs.
We can easily use user familiar terms to expose characteristics with natural language. E.g:
The system is used is a standard North American power supply. Tree browser provides a means of organizing defect information. The household lighting control system has an interface with standard household automation systems.
Since the characteristics are derived from the needs of all demand, we arrange them in the next layer of the pyramid, that is, the following. At the same time, we also transferred from the problem domain (required) to the first layer (characteristic) of the solution field.
One thing is important, it is necessary to pay attention, that is, the characteristic is more than just the refinement of the needs of the people (add details). Instead, they are the direct response to the problem provided by the user, and they provide us with a top-level solution for us.
Typically, we should be able to describe the system by defining the characteristics of the 25 to 50 engraving system behavior. If you find that there is more than 50 characteristics of the hand, it may be because you have not abstract the true characteristics of the system or is too large and difficult to understand, you need to consider dividing it into a smaller part.
Features are described in natural language, so any involvement of the list can immediately obtain basic understanding of system behavior. Features list will lack fine grain levels. it does not matter. We just try to exchange purposes, and because many of the people are non-technical, too many details may make them confused or even interference. Through examples, our SMARTBOT automatic welding robot's partial feature list may include: allowing welding workers to teach the "Lead THROUGH PATH" training mode of which the robot welding is supported to repeat the "Step-And-repeat" feature of the welding order.
Usage When we further consider the method of completing the user task, we may find that the use of use techniques will further describe system behavior. This technology has been well developed in many books [Jacobson 1992], and it is also a constituent technology of industry standard unified modeling languages [BOOCH 1999].
From the technical say, use case:
A series of actions performed by the system are described for the user.
In other words, the use examples describe a series of users and system interactions that help users achieve their expectations. In another way, use examples describe how users and systems work together to implement the identified features.
The use case also introduced the construct of participants. Participants are just a label of users using the system. In UML, use a simple ellipse to represent the use case, and the participant uses a line drawing with a name. So you can explain the two as follows.
Use Example Techniques specify how participants implement a simple step-by-step process of use cases. For example, the use case for Step and rebeat may be as follows:
Step 1: Welding workers press the STEP AND REPEAT button to start the sequence.
Step 2: The welding system is a power supply to drive the motor so that the machine arm moves can be controlled.
Step 3: Welding workers hold the trigger, move the machine arm to the welded portion, and press the "Weld Here" button to weld each line that needs to be welded.
Use example techniques provide many other useful structures, such as pre-pace description, available flow (Alternate Flow). We will discuss them when discussing them in detail later. But now, we only need to know that the use case provides an excellent method to describe how to implement system characteristics.
For the purpose of the plan, some methods other than the use case may be needed to describe how to achieve specific features. For each feature, you may only need to use only several use cases (maybe 3 to 10). During the description of the use case, we explained in detail the behavior of the system. With the acquisition of other features, the use case has also become more detailed.
Vision Documents In many development attempts, the problem, the key involvement, user needs, system feature list, may have an example case usa can be found in a document called a vision document. It also has many other names, such as Project Charter, Product Requirements Document, Marketing Requirements Document, and so on. Regardless of the name, the vision document emphasizes the overall intent and purpose of building a system, and therefore, it is a natural container that is indicative and illustrative use case. In other words, the vision document captures the full form of the system and exchanges the need for public demand, characteristics and use cases.
However, we cannot simply transfer these features and initial use cases to the development team, and expect them to quickly develop systems that really meet the needs of the people. We may need to be more clear in system functionality and may involve various new people, including developers, testers, etc. This is the need to solve the next layer (software requirements) defined by the system. Software demand software requirements provide the next layer specificity during the software definition. On this layer, we must specify enough requirements and use cases so that developers can write code and test whether these codes meet the requirements. From the graph, the software needs provide our pyramid tower.
What is software demand? Although there have been many definitions in the past years, we have found the definition of Dorfman and Thayer [Dorfmann 1990] of demand engineering:
User resolves the software features required to implement a target, or must be met or owned by a system or system component to meet the software functions of the contract, standard, specification, or other formal release document.
To apply this definition, the development team can develop a more specific set of demand to improve or refine the list of features discussed earlier. Each requirement is a certain feature and vice versa. Note the simplicity of this method. We have a list of features and then refine them by writing a demand for these characteristic services. We don't write any other needs. This avoids just sitting on the chair, holding the ceiling, and "fabricating some demand for the system".
This process is simple, but it is not easy. Each feature needs to be checked and then written to support this feature. Inevitably, writing requirements for a feature will trigger you to add new needs to have been checked, or revise them.
Of course, you know that writing needs is not easy and may need to specify a large number of needs. We have found that considering three types or types of software requirements (functional demand, non-functional demand and design constraints) are very helpful.
We have found that these three needs are very helpful in the way we consider demand and the tasks we expect to be achieved. Let's take a look at these different types of needs, and how you can use them to define all aspects of the expected system.
Functional demand
Functional demand expresses system behavior. More specifically, functional requirements describe what inputs and outputs are, and how to be converted to a specific output at different times. Most software applications that can work effectively have rich functional needs. When specifying these needs, we must weigh the blur ("After you press the ON button, the system will open")) and the relationship between the specificity, this is important. It is also important to give designers and implementors to choose from as much as possible. If we are too specific, it may be too limited to the development team. If it is too loose, the development team does not know which features should be implemented.
The correct way to specify the demand is not only one. One of the techniques simply adopt a declarative approach and write a detailed event that the system needs to do.
For example, when the "Weld Here" input is activated, the system reads the position of the electrode end through the primary optical encoder every 100 milliseconds.
Refining case
In many systems, through refining the previously defined use cases and develop other use cases, it is easy to organize specifications to fully refine the system. With this technique, you can refine the use case step into a more detailed system interaction. You also need to define pre-condition and post criteria (preceding system assumptions before and after use), and alternate motion required for abnormal conditions.
Since the use case is semantically a semantic structure, they provide a structure of an organization and capture system behavior. Here is a representative use case of SmartBot.
Non-functional demand
In addition to functional requirements such as input to output, most systems also need to define a group of non-functional requirements, such as performance requirements, throughput, availability, reliability, and supportability. These needs and functional requirements for input and output are equally important. Typically, the expression of non-functional demand is to declare, such as "The average fault interval of the system should be 2000 hours", "the average repair time of the system should be 0.5 hours", and "SmartBot should be able to store and retrieve 100 welding paths. Design constraint
Unlike definition system behavior, third types of demand usually limit system design or we have to build a system. We define the design constraint as:
System design restrictions, or restrictions on system development steps, it does not affect external behavior of the system, but must be implemented to meet technology, business or contract requirements.
Typical design constraints may be expressed: "Programming with Java is Welder Control Unit". In general, we regard rationally design constraints as other needs, although these restrictions can require different technologies. As the functionality and non-functional demand, these constraints play an indispensable role in the design and testing of the system.
Hierarchical demand
Many projects benefit by expressing these needs by using a hierarchical or parent structure. Parental Structure Demand is an expansion of the specificity of parent demand expression. Prediracy needs to provide you with a flexible approach to enhance and expand specifications while organizing the level of detail. Just look at the father's needs, it is easy to provide top specifications according to methods that are easy to understand by users. At the same time, the implement persons can quickly check the detailed "sub-needs" specification to ensure that they can understand all the implementation details.
Note that hierarchical structures consist of three standard types of demand - functionality, non-functionality, and design constraints. This refinement relationship between these demands is defined here.
Traceability In addition to terms defined for those we use to illustrate system requirements, we will now transfer to key relationships, which is tracked, which may have a relationship between these matters.
An important factor in developing high quality software is to understand or track demand in specifications, architecture, design, implementation, and testing phases. Historical data indicates that the impact of changes is usually missing, and the small changes in the system may bring significant reliability issues. Therefore, tracking relationships and associates these relationships at the time of change, forming a number of modern software quality assurance processes, especially in mission-critical activities such as safety key systems (medical and transport products), and failure economic costs A high system (online transaction) forms a critical thread.
Let's take a look at how we define the need to track:
Traceability is a dependency, with entity (fault, use cases, and requirements) "traced to" depends to some extent on its entity of its "traced from".
For example, we have described how to create one or more software requirements to support a given feature or use case in the vision document. Therefore, we can say that these software needs have a trackable relationship with one or more characteristics.
Impact analysis and suspect
In addition, trackability is exceeding the scope of simple dependencies, as it provides the ability to affect analysis using the concept we call "suspected". When the change occurs in the "traced from" demand, the traceability begins "doubt", so it is necessary to check "traced to" (dependency requirements) to ensure that it is consistent with the source requirements.
For example, if we use traceability to associate requirements with a specific test, and if "SmartBot should be able to store and retrieve up to 100 welding paths", "SMARTBOT should be able to store and retrieve up to 200 welding paths", Then the test from this demand track is worthy of doubt, because the test designed to test the first demand is unlikely to test the second demand. Change requests and change management systems Finally, changes are inevitable. The process of managing changes is essential for projects with hopeful success. Regardless of what their source is and how many sources are numerous, all modifications including influencing characteristics and demand need to be introduced and managed in an orderly manner. Any key element of any change management system is a change request itself.
We define the change request as:
A formal request for amend or adding a systematic characteristics and / or demand. Change requests require structuralization and formal statements that are proposed to change, as well as any detail around the change. In order to manage these changes, each change must have its own identity in the system, which is important. The simplified form of change requests may be:
In most items, you will find no missing changes! In fact, your problem is to manage, integrate, and (as needed) in an orderly manner to reject unnecessary changes. In other words, you need a management change process. Your change management system should be used to capture all inputs and submit them to the Change Control Committee (CCB) to resolve. The CCB consists of no more than 3 to 5 representative projects (customer, market, and project management), it manages and controls system changes, thus playing key roles in helping project success.
In the end, we pointed out that the purpose of this article is to help practitioners in the field to increase their ability to answer the following basic questions: "What behavior should be implemented?"
As a first step in achieving this goal, we define and describe some common terms used to express the needs of the expected solutions (such as involving other people responsible for analyzing analytics) and other people responsible for describing issues in the problem domain. The needs, characteristics, use cases, software requirements, etc.). In this process, we also expound some key concepts for effective demand management. By using the terms and methods provided herein, you can more efficiently understand the needs of users, and developers, testers, and other technical team members exchange proposed solutions for other technical team members who meet the needs of customers and users.
An important technique for further defining and exchange of software solutions is the standard modeling language. Unified Modeling Language (UML) is a language for workpiece for visualization, designation, and documentation software intensive systems, and provides means of expressing these technical constructs more accurate in semantics. Sisters, Modeling The Requirements Artifacts With UML (Utilize UML Modeling Requirements), the UML construction and extension necessary to perform more efficient implementation requirements management tasks.
Recommended Reading [Leffingwell 1999] Leffingwell, Dean and Don Widrig. Managing Software Requirements: a Unified Approach. Reading, MA: Addison Wesley Longman, 1999.
[Weigers 1999] Weigers, Karl. Software Requirements, Redmond Washington: Microsoft Press, 1999.
Reference
[Booch 1994] Booch, Grady. Object-Oriented Analysis and Design with Applications, 2nd ed. Redwood City, CA. Benjamin Cummings, 1994. [Booch 1999] Booch, Grady, James Rumbaugh, Ivar Jacobson. The Unified Modeling Language User Guide . Reading, MA: Addison Wesley Longman, 1999 [Dorfmann 1990] Dorfmann, Merlin, and Richard H. Thayer Standards, Guidelines, and Examples of System and Software Requirements Engineering Los Alamitos, CA:... IEEE Computer Society Press, 1990. [Jacobson 1992] Jacobson, Ivar, Magnus Christerson, Patrik Jonsson, and Gunnar vergaard Object-Oriented Software Engineering:?. A Use Case Driven Approach Harlow, Essex, England:. Addison Wesley Longman, 1992. [Rumbaugh 1999] Rumbaugh, James , Ivar Jacobson, Grady Booch. The Unified Modeling Language Reference Manual. Reading, MA: Addison Wesley Longman, 1999. Please take the discussion of the Rational China Forum on this article. With regard to the author in Rational Software, I am honored to work with some of the industry's senior rigmators (Jim Rumbaugh, Philippe Kruchten, Bran Selic et al.). Although this is a part of my career, I am obsessed with it, but this is not that I can recommend it to everyone. In other words, please don't try to do this at home.
