CHAPTER
2.2 General view of the system
The activities related to the definition of the scope of a project should usually take a relatively small fraction of the time of the whole project, although variations may exist depending on the 9 2.2 General view of the system
kind of the project: projects with simple and well-defined requirements may demand no more than a couple of days of business modeling while complex and large projects may demand weeks or months. At the time of scope definition, all information about the company business must be explored by interviewing users, clients, and domain specialists, as well as by the exami- nation of documents, reports, existing systems, and related bibliography.
For most projects, the first question the analyst should answer is the following: What is the vision of the company for the project? In other words, what does the company want with the project? Why is it being proposed, and why is the company going to spend money with it?
At that moment, another question, often forgotten, may be raised: Buying or developing?
Sometimes, the product the client wants is available for purchase.
These questions must be answered in a relatively short time. That is why it is suggested that the Inception phase proceed relatively quickly. Why? Because, at this time, the client and the develop- ment team usually do not have an idea of the real extension of the project and it is, from the point of view of both, an investment on the future, and, therefore, a risk.
The general view of the system or executive summary is a free format document, where the analyst may report the relevant items she discovered about the system after the initial interviews with the stakeholders. The document usually includes the scope declaration for the project.
We do not intend to propose rules for writing that document. But it is suggested that it should not be too long. A few pages of text and some diagrams seem to be sufficient to describe in a sum- marized way the scope of most systems. More than that could mean that too much detail was included in the summary. These details could be alternatively addressed in other documents such as the list of risks, requirements, or use cases.
The scope declaration in the general view must present, in general lines, the product that must be developed: what must be included, and whatcouldbe included but should not. This information may be obtained initially by interviewing the stakeholders, and may be refined later with the use of the diagrams presented in this chapter.
If possible, the main deliverables of the project should be also defined in the general view as well as the time frame when the client is going to receive some kind of delivery from the development team. Normally, this list of deliverables consists of implemented versions of the software, but the list can also include other items, such as design, manuals, installation media, training, etc. It can be very difficult to establish deadlines for deliveries before doing the requirements analysis of the system, because estimation effort techniques such as function points (Albrecht and Gaffney Jr., 1983), use case points (Karner, 1993), or COCOMO II (Boehm, 2000) can only be applied after a good deal of the requirements is known. Thus, the information about deadlines at this early stage is more a guess than a formal strong commit- ment for development.
The general view document may also contain some acceptance criteria for the product, that is, quantifiable items that will be used to decide whether the project was a success or not. The product acceptance criteria must at least include metrics for deadlines, budget, and quality. If subjective cri- teria such as “customer satisfied,” “system easy to use,” or “state-of-the-art technology” are used, they must be quantified, that is, it must be defined how to measure “customer satisfaction,” “ease of use,” “state of the art,” and so on. Examples of quantifiable acceptance criteria are “the system must support up to 50,000 simultaneous accesses without degrading performance,” “the system 10 CHAPTER 2 Business Modeling
must eliminate the need to use paper for performing processes x and y,” and “the system must allow selling up to 100 books a minute on the Internet.”
More information may be added to the general view document if needed (for example, main risks, technologies to be used, etc.). The general view of the system is the base agreement document for the client and the developer. It will be taken as a basis for planning the rest of the project.
It is important to mention that when the general view is being built, the requirements analysis has not yet been completed, and therefore the information mentioned in the general view consists of early commitments. It is expected that the requirements analysis will detail the scope in depth, but not augment its extension. For example, in requirements analysis the process of selling books may be detailed with discounts, sales, delivery, and so on (considering that “selling books” is men- tioned in the scope declaration), but if the payment roll of the company was not mentioned in the scope declaration, then the inclusion of that item in the project would require a renegotiation of the scope declaration.
Pressman (2008) proposes a number of techniques to communicate with stakeholders in order to discover business goals, for example:
• Traditional focus groups, where a trained analyst meets with a group of end-users or people representing their roles.
• Electronic focus groups, where the meetings are conducted by the use of electronic media.
• Iterative surveys, where a number of surveys are conducted among end-users, presenting them some questions and asking for clarification.
• Exploratory surveys, where an exploratory research is conducted among end-users that use a similar existing product.
• Scenario building, where a group of end users is led to produce a description of a number of scenarios for using the system.
The last option seems to be very popular among agile method practitioners, where scenarios are sometimes identified asuser stories.
Figure 2.1 presents a general view withverypreliminary scope declaration for a fictional virtual bookstore Livir,3which will be used to illustrate the modeling techniques within this book. This text would have been obtained after a quick preliminary meeting with the client. Using this as a basis, a deeper study may be conducted with business use cases and other diagrams, so that the information contained in it is refined, as shown below in this chapter. The document is divided into two parts:
• A simple vision statement of what the project will offer to customers and the business that’s creating it.
• The constraints for version 1.0.
3Why a virtual bookstore? Because it is a typical commercial information system, and because most readers should already have experience with that kind of system, and also because it is sufficiently simple, although rich, to illustrate the modeling techniques of this book. Such systems are already available for acquisition and customization, and it might not make sense to develop a new one from scratch, but the purpose here is just didactic.
11 2.2 General view of the system
To allow for the presentation of this project in a book, a series of simplifications were considered.
The description and modeling of a real project would be much more extensive. Furthermore, the models presented would sometimes only be partial at a given time, being refined or changed later.
It can be seen that the general view is a nonstructured view of the project. It includes business information for managers, and operational information for developers. Sometimes, even details about the technology to be used can be described if necessary. What the analyst must consider is that the general view describes the main concerns of the clients and those concerns will be better structured later during analysis and design.
A good analyst must act like a psychoanalyst, that is, she must avoid speaking in the place of the client. The analyst must help the client to speak; when the client starts to report some of her
General View for the Livir Project Version 1.0
Vision:
A new business will be initiated: a virtual bookstore. The system to support it must manage the acquisition and selling processes of the company. Access for customers and management people must be accomplished through a Web site.
When a book is ordered, it is delivered immediately if available in stock, or else, the book is ordered to a publisher, and a compatible deadline is informed to the customer.
The system must calculate taxes and delivery fee as well as applying discounts to the sale when applicable.
The system must allow a manager to generate reports on bestselling books, and on most profitable customers, as well as suggest books for buying based on past customer’s interests.
Constraints:
a) Customers would only pay by credit card.
b) The bookstore will deal only with new books, not used ones.
c) Access to the system will be available through a web site only.
FIGURE 2.1
General view for the Livir project.
12 CHAPTER 2 Business Modeling
needs, the analyst must hear, instead of presenting fast prebuilt (and often mistaken) solutions. The analyst must motivate the client to detail her requirements and must question those requirements so that the client can decide which are urgent and which are not.