Demand collection: proper process
Granville Miller (RMiller@together@together@togethersoft.com) consultant and developers, Together, Together, October 2001
Granville Miller continues his discussion on the development of sub-software and summarizes demand collection concepts. Let's take a look at the four most common demand collection process - functional features, user scenarios, use cases, and traditional software demand specifications - how to adapt to a broader environment in which flexible software development processes. please at
Discussions Forum share your ideas about this article with author and other readers.
In the previous column, I started to discuss the overall software development, which is a development method that focuses on the process of innovation. This is my belief. As I mentioned in the declaration of last month, the overall software development has potential to make developers to achieve extraordinary achievements. However, this does not mean that I advocate fully exclude processes. The philosophy of my life can be summarized as follows:
There is too little process, and extraordinary people can do ordinary things; there are too many processes, even extraordinary people can't do extraordinary things.
This month, I will discuss the application of sub-integral software development and process. In particular, we will talk about the demand collection - the basis of any software development cycle, will also talk about the overall method - a means of dynamically implement a large number of processes and methods in the development cycle - how to enhance your needs collection process.
Software invisibility issues new software applications conceptualization is different from different projects. Although certain projects are very intuitive - perhaps like a new technology to be applied to a famous field - but other project requirements may be more complicated. When we continue to use software technology for unknown areas, the behavior of creating demand for software systems is a conceptual innovation. This innovation is not just a complex mental work of individuals, and the difficulty is also to communicate with larger development groups.
Frederick Brooks calls the properties of new software applications that are difficult to conceptual and described as software invisible. Although there are other fields such as hardware, there is no in the field of software. We can see or evaluate the effect of software applications, but its system is in essence. This is one of the reasons we created and rely on software models. The model gives the software physical dimension to make us better understand and express its direction.
Any software modeling work is designed to collect. The choice of implementation of the demand collection process relies on the largest environment for development projects. This environment can be found in the demand collection process, or it can be found in another model. In some cases, this environment can even be found during delivery. We can always discern where the needs of the system will reside will be discovered by the different needs of our discussion. The demand environment is the area we are in invisible with software.
The choice of appropriate working process is greatly affecting the success of the selected demand collection process. Because the demand collection is the basis of the development cycle, an invalid or selecting a demand analysis process greatly increases the possibility of project failure. This possibility leads us that we are in a known process, usually related to a separate, preferred software development method.
The demand collection process will be discussed here, abstract from three first-class software development methods: "Rational Unified Process (RUP)," Feature-Driven Development (FDD)) and "Extreme Programming" EXTreme Programming (XP)). Each method provides a large number of tools to assist in demand collection. In order to comply with the overall development method, we will focus on the necessary part - collecting the demand collection process - rather than the entire method itself. In addition, we will also see if it is organized a more dynamic and more variable demand collection process. Before continuing to discuss, use some time to read this supplementary article "Ten guidelines for sub-integral software development", see how the monolithic method is theory how we know what we know. Four most common demand collection processes are traditional Software Requirements Specification, SRSs, Use Cases, Features, and User Siters. In the subsequent subsequent section, we will consider each process, please pay special attention to the needs environment - means that each process is provided for the proper situation of maximizing value and each process to the development project. For more information on the application of each process summarized, see the reference.
Software demand standard Software demand norms (SRS) are one of the oldest demand collection processes. Its informal name is "Shall Statements), traditional SRS has a variety of forms, and today's contracting projects still need to be used. SRS has been a demand collection method in dominance for many years.
The thinking behind the SRS is to create a solution space - that is, such a space, where the development team has set a target, but the order and essence of action to achieve these goals can be very free. Therefore, SRS usually does not attempt to specify a single solution, but specify a series of possible solutions. Then, the development team has sufficient flexibility to innovate for an effective way to solve the problem being created.
Flexibility is a disadvantage for SRS, it is also an advantage. If a software development team is proficient in this area of the creation of systems, this group can easily use SRS to maximize innovation. However, in the development team, the traditional SRS as a demand collection process may be lacking in the era of daily work in the field they are not familiar. Typical users attempt to process normal conditions in a given domain, the steps they take are probably that group members don't know. Therefore, the system identified and created by the group may not be optimal for the user community.
Traditional SRS is most suitable for areas that have been fully understood and very well-understood in the development team in our work. - It is easy to understand the development environment. SRS allows for almost no techniques to adjust the solution space to manage changes in the system.
The use case describes the action sequence that the user is interactive with the system as compared with the solution spatial method supported by conventional SRS. In a sense, the use case is based on the route or purpose. It conveys a range of users who must start when using the system to solve the problem. For example, in a "video tape rent" case, we describe the case where the user interacts with the video tape rental system.
Use an example reaction We try to use the software system to achieve all events that may appear when the purpose is achieved. Because most software systems support multiple purposes, most of the modes of use are composed of multiple use cases. For example, "Pay Late Fee" describes what happens when the user who has a video rental system encounters the case of overdue payment. The correct level of information in use is the necessary conditions for successful establishment of the application. It is different depending on the environment. If an expert in the field is involved in the development process, use the case only to select the system's route. If the domain experts do not participate in the project, use the case to provide more information. The use case is the best process for communication. However, just like traditional SRS, use cases more suitable for areas that have been well understood. The use case can withstand a certain degree of changes, but other processes can adapt to changes.
Tribo Rental Availability The following use case is used to define the customer's best route in the automated (web) tape rental plan. Usage: The only use case ID: VS-01 is the only example ID: VS-01 Main Participants: N / A Conference: This use example describes the interaction behavior that occurs when the customer is based on a web-based recording tape. Trigger event: Customer Selects the title from the tabletist directory. Prerequisites:
Customers must have an event account. The customer satisfies the age requirements of the video tape hierarchical accompanying tablet directory. The tablet name is available with the tablet. Event stream:
Customer browsing the film name directory and selects a piece name. If this is present, the system is added to the shopping cart in the system, and the media is in the standard. After the customer completes the media selection, he will order it. To set orders, you need to let our customers validate and ensure that the account is valid. Media costs from user accounts into the debit (system). The media in the shopping cart and the order-related media turned into "lease". The system confirms the order. Subsequent conditions:
Create a new order for this account. Modify inventory to react to a recorded tape. The system has been credited to the debit (system) and records the transaction into the loan (customer) by the recording with rent. Optional event flow and exception:
The tablet name does not exist: customers must make additional choices. If the account is invalid because the overdue fee is not paid: see "Payment overdue fee" use case. The account is invalid because the invalid credit card is invalid: the system prompts the user to enter a valid credit card account.
Features Features Features are a brief statement of system expectation. The format of functional characteristics is:
One example functionality can be:
Forecast The Total of Quarterly Sales.
When each functional characteristics remain in the minimum state, the method based on functional characteristics is best. A group of features that can be implemented in two weeks or less time is the ideal feature.
The functionality characteristics will be organized using the group named function set. The function set contains the functional characteristics describing the given destination or domain. Functional sets and its functional features are only overview of the needs. As a mechanism, functional characteristics, the functional characteristics, and additional environments.
In the "Function Drive Development" method, the environment is carefully designed to be between the functional set and a color tag class chart called "domain neutral component". The field neutral component is a semantic template describing the cross-domain common relationship. The domain neutral component consists of moment-interval, a role, a Subject (Party, location or transaction), and Description. Instantaneous intervals are short-time elements in those areas, such as one order in order execution system. The role is a user, the system interacts with him and must recognize him. The theme is the formation of a field. The description is an abstraction that combines the meta information of these objects. Figure 1 is a domain neutral component for a tape rent. Figure 1. Area neutral components of the tape rent plan
As a demand collection process, "function drive development" is very flexible, which helps to change management in the development cycle. This process allows you to easily check and record new, changed, and remove the number of functional features in the process. Because typically is small, changing existing feature or add new features or add new feature, a large number of reworks on project levels. Functional features also help to challenge software invisibleity because new functional characteristics of interactive results between system entities in the area of tracking areas may be revealed.
Features can be used to familiarize yourself with demand exchange between individuals in a given field. In this way, the method based on functional characteristics is likely to be the most demand collection process. However, these functional features may be too dependent on the field of expertise, which is a luxury goods that many developed groups.
User Scenario User Scenario is a short description written on an index card, as shown in Figure 2.
Figure 2. Main points of sales user
The information contained in the user's situation is often more information contained in functional characteristics, although this is not a need for conditions. In the "Extreme Programming" method, the user's scenario requires a site-free customer. Field customers describe the ideal system to the development team. Then, this group is a little bit of building a system to give a full chance to see the results regularly. The customer "supervises" This can be delivered, and the system's modification recommendations are proposed in the new user scenario. The entire environment is combined by the feedback and increment process and delivery of the on-site customer.
User scenarios is the best way for projects that handle software invisible risks. Like functional characteristics, they are small enough and can be easily changed. Because their environment is based on operational systems and customers, it will be discarded until it is implemented or no longer effective. However, not every project can introduce a site customer, so the user's scenario does not apply to each project. This approach has lost its advantages due to its lack of customer interaction.
Conclusion This paper has its advantage in the appropriate environment. However, as shown in this discussion, for each environment, it is not an ideal for each environment, and they are not even necessary. The center of Sub-integral software development is to recognize that a single process or activity is incomplete, and expands these scope of this incomplete solution as much as possible.
Supplementary article "Ten Best Criteria for Sub-integrated Software Development" discusses the modularity. Modules allows the same activities as the same can be replaced with each other. When replacing the other with a demand collection activity, it is important to take into account the needs environment. The development cycle change event is likely to introduce a set of new power to the project. This action may become a disaster if it is not taken into account. However, after careful planning and execution, introducing new activities can help create new motivation, which promotes the success of the project.
Next month, we will talk about the modeling of the Web service infrastructure. With our investigation of this software development, I will provide more specific technical examples and the best criteria that have been discussing in the two columns, so please don't leave!
Reference
