COMMENTARY ON THE TERMS OF REFERENCE

The purpose - the purpose of application as a whole (rather than the objective of the program). Here are all of the requirements for the application.

Scope - what aspects of the program this document must cover. Under this section there will be comments on some of the specific features of the versions of the application. The purpose is to guide the design process at design time.

Definitions, terms and abbreviations – as table:

General description – sufficiently general part of the description..

User Interfaces – sketches, drawings of the key GUI to the overall presentation of the application. This is not a detailed description of the user interface.

Hardware interfaces – equipment on which the application will run, additional devices (eg, joystick, etc.).

Program interfaces – other programs with which the application must communicate, for example, a printer driver, use of the site. …

Communication interfaces – application will have an interface to connect to the Internet via modem from a minimum speed of 56 KB/sec.

Requirements for Adaptation – requirements on implementation on a particular PC, version on a concrete language, such as English, Kazakh, etc.

3.1 Functional requirements are the requirements that express the functions to be performed by the application.

To express the concept of the customer, you can use the following technologies of requirements organization:

А) requirements organization by use cases – as a typical interaction between the operating person and an application such technique is useful in the requirements formulation and the design and testing.

The unified software development process (USDP) uses the observation that many of the requirements occur naturally in the sequences of operations - case scenarios. Unified Process, providing software development process, favors the organization of the requirements by use cases. With technologies of detailed requirements it is meaningful to develop larger use cases from small, using the relationship "generalization". For example, the use case "A" summarizes use case "B" if the "B" contains all the steps of the "A" (usually additional steps too - options).

B) Organization of requirements by use cases can be applied both at the structural as well as in the object-oriented approach.

B) Organization of requirements by classes – This technology uses an object-oriented style of requirements organization, in which, first of all it is necessary to determine the classification, ie equivalent to the choice of classes.

After the classification of the main (basic) domain concepts, specific requirements are distributed by the obtained categories or classes. There are two approaches to do this:

1) classes can be considered as ways of organizing requirements, but not to consider them as necessarily used in real design;

2) classes designed for the requirements of a real object-oriented design and implementation can be used.

The second approach supports a one-to-one traceability between detailed requirements and methods of creating correspondence between each functional detailed requirement and function of the target programming language.

The great advantage of the organization of the requirements for the classes, which will be further used in the design, is the support of the hard consistency between the requirements, design and implementation. In addition to classes, relevant to the concepts of the real world, it is much more likely to use them again.

The disadvantages of the second approach include:

- the possibility of changes in the design of classes that violates the correspondence between the requirements and classes;

- Choice of classes occurs early enough, which leads to a combination of selection with the design process.

Thus, the use of domain classes is a way of the organization of thinking and tracking requirements! The goal is to determine the minimum, but sufficient set of domain classes, including all the detailed (specific) functional requirements!

The main source of domain classes are use cases.

Domain classes selection algorithm for the requirements classification:

1. Develop a complete set of non-overlapping use cases.

2. Create a sequence diagram for each use case. Do not forget to identify the classes and objects.

3. Collect all the classes used in the sequence diagrams.

4. Identify important additional classes.

5. Distribute detailed functional requirements by these classes. Moreover:

- Specify each attribute as a separate requirement.

- Identify each specific object of a class, which must exist.

- Identify each function necessary for the objects in this classification.

- List the events that have to react all the objects of the class.

After receiving classes from use cases an effective way to complete the definition of key domain classes is to use the process of "list and trim". It consists, firstly, of enumeration of all possible candidate classes which can come up with, and secondly of the aggressive removal of unnecessary candidates, after which only a few most important ones must remain.

C) Organization of the requirements by data flow diagrams (DFD)

Requirements can be naturally described by flow of data between the processing elements. In DFD units are processing units; arrows between nodes signed by the data types represent data flows; Data Warehouse - a place where data is stored; external objects, such as users and printers represented by rectangles. If DFD shows the desires and needs of the customer, and the customer understands this diagram, the use of the diagram is appropriate. If you need the program to track the flow of orders in the company, appropriate form of requirements is to use data flow diagrams showing the process at a high level, because DFD is required to display what you must do.

D) Organization of the requirements by the state transition diagram

The idea is to divide the application into the states, so that the application will always be in the same state. State of the application is its status or situation, phase or stage. For example, an online bookstore is always either in the viewing state (examine the information on the books), or in the state of purchase (with the provision of credit card information, etc.). For event-driven of appendices, state transition diagrams can sometimes be an effective means of reaching an agreement between the developer and the customer as to how the application should work.

After determining the states, transitions are added between them. Transitions are indicated by arrows, each of which is marked with the name of the event, resulting in a change of the state of the application.

Using the state transition model for the formulation of functional requirements depend on the particular application and on how it can help the customer.

Four alternative forms to express the customer's requirements:

Selection of form depends on customer and also on the type of the described requirements.

1. If the requirement is simple and stands by itself, express it by distinct proposals in the specification of software requirements.

2. If the requirement is the interaction of the user and application, express it with the use case. For this:

- Give names to the use cases;

- define the actors. The role of the external user is usually people;

- write down the sequence of user and application actions;

- minimize branching;

- use the general form;

- Avoid specific names and values, ​​for example, instead of the text "Nick puts $ 300" you should write "client enters the size of the deposit.".

3. If the requirement affects the processing elements, each of which receives and outputs the data, use the data flow diagram. For this:

- define the processing elements (usually high level), show them in circles or rectangles;

- define the data warehouse; show them as the names between the two horizontal lines.;

- show the data transmission path between processing elements. Specify the types of data transferred in each case.

4. If the requirement affects the states, which can contain a program (or part of the program), follow these steps:

- define the states (each state is usually defined by a verbal noun, such as "expectation"), display them in rectangles with rounded corners;

- specify the initial state with a special arrow;

- define events (occurring outside of the considered part of the system), leading to a state transitions, show them as labeled arrows.;

- define the nested states, show them as rectangles within rectangles.

3.2 Non-functional requirements

Non-functional requirements - requirements applied to the application, but not affected its functionality.

3.2.1 Performance - specifies time limits that must be met in the program. For example, limitations on computation time, the use of RAM, the use of auxiliary storage devices, etc.

3.2.2 Reliability and availability

Reliability requirements determine the reliability of the measured values. Requirements of this type assume the probability of non-ideal operation of the program and limit the scope of its imperfections.

Availability evaluates the extent to which the application must be available to users.

3.2.3 Error handling

This category of requirements explains how the program should respond to emerging mistakes, it does not apply to errors generated by the program.

Error checking in the program itself is only relevant for critical parts of the program.

3.2.4 Interface requirements

Interface requirements describe the format in which the program communicates with the environment, that is, either with users or with other programs.

Design of the user interface (GUI) can be considered as part of the requirements definition phase (except the design phase).

Interface specifications often consist of the names of called functions, the return type of the values ​​and types of arguments they require.

Interfaces can also consist of message formats or specifications generated or processed events.

Stages of the development of user interfaces.

1. Get to know your user

2. Understand the purpose of the system being designed

3. Apply the principles of good screen design

4. Choose the right type of windows

5. Develop a system menu

6. Select the appropriate hardware control devices

7. Select the appropriate onscreen controls

8. Organize and create the layout of windows

9. Select the appropriate colors

10. Create a meaningful icons

11. Provide effective communication, feedback and guidance.

3.2.5 Constraints

Limitation on the design or implementation describes the boundaries or conditions of how the application must be designed and developed. It is the conditions imposed on the project by the customer, as well as the environment or other circumstances.

- the accuracy of, for example, the output of the results and so on;

- restrictions on the tools and languages. These include historical traditions of the organization, compatibility and experience of the programmers;

- restrictions are imposed on the design due to the fact that persons financially interested in the project may require it, and they may limit the developers' freedom in design;

- adherence to a certain standard is often determined by the policy of the company or the customer;

- Projects are often limited to the platforms on which they will be used.

Appendix E

LIST OF REFERENCES

1. Baldwin, J. L, R. M. Bateman and C. L. Wheatley. Application of a neural network to the problem of mineral identification from well logs. //The Log Analyst. - 1990. - 3. - P. 279-293.

2. Benaouda B., Wadge G., Whitmark R.B., Rothwell R. G., MacLeod C. Inferring the lithology of borehole rocks by applying neural network classifiers to downhole logs - an example from the Ocean Drilling Program. //Geophysical Journal International. - 1999. — 136. - P. 477- 491.

3. Saggaf M. M., Nebrija Ed. L. Estimation of missing logs by regularized neural networks. //AAPG Bulletin. - 2003. - 87, № 8. - P. 1377-1389.

4. V. A. Tetenev, B. A. Yakimovich, M.A. Senilov, N.B. Paklin Mining systems of interpretation geophysical investigations of wells. «Штучний інтелект» 3’2002

5. Klaus Yelbig and Sven Treitel. Computational Neural Networks For Geophysical Data Processing. Editor: Mary M. Poulton 2001, 335 р

6. M. Borsaru,, B. Zhou, T. Aizawa, H. Karashima, T. Hashimoto. Automated lithology prediction from PGNAA and other geophysical logs. Applied Radiation and Isotopes 64 (2006) p.272–282

7. Kapur L., Lake L., Sepehrnoori K., Herrick D., Kalkomey C. Facies prediction from core and log data using artificial neural network technology. //Transactions of the 39th Society of Professional Well Log Analysts Annual Logging Symposium. - 1998. — 11 pОписание платформы «1С: Предприятие» http://v8.1c.ru/overview/

8. Aleshin S.P., Lyahov A.L. Neural network estimation of mineral and raw material source of a region by the data of geophysical monitoring. Нові технології № 1 (31) – 2011, Науковий вісник КУЕІТУ http://www.nbuv.gov.ua/portal/natural/newtech/2011_1/articles/2-3.pdf

9. A.N. Karpenko, O.V. Bulmasov. Use of neuronet technology to interpretation data of well logging. http://oil-gas.platinov-s.com/index.php?name=articles&op=view&id=11&pag=3&num=1

10. Rogers S J, Fang J H, Karr C L, and Stanley D A. Determination of lithology from well logs using a neural network. AAPG Bulletin. 1992. 76(5): 731–739.

Appendix F

Дата добавления: 2014-11-24; просмотров: 406; Нарушение авторских прав

Мы поможем в написании ваших работ!