| 1 | |
| 2 | = Визија |
| 3 | |
| 4 | == 1. Вовед |
| 5 | |
| 6 | |
| 7 | |
| 8 | == 2. Позиционирање |
| 9 | |
| 10 | === 2.1 Дефиниција на проблем |
| 11 | |
| 12 | ||= Тема на проблем =|| [describe the problem] || |
| 13 | ||= Кого засега =|| [the stakeholders affected by the problem] || |
| 14 | ||= Со последици како =|| [what is the impact of the problem?] || |
| 15 | ||= Успешно решение би било =|| [list some key benefits of a successful solution] || |
| 16 | |
| 17 | === 2.2 Позиција на пазарот |
| 18 | |
| 19 | ||= За =|| [target customer] || |
| 20 | ||= Кои =|| [statement of the need or opportunity] || |
| 21 | ||= !FINKI Maps =|| is a [product category] || |
| 22 | ||= Кој овозможува =|| [statement of key benefit; that is, the compelling reason to buy] || |
| 23 | ||= За разлика од =|| [primary competitive alternative] || |
| 24 | ||= Нашиот продукт =|| [statement of primary differentiation] || |
| 25 | |
| 26 | == 3. Опис на засегнатите лица |
| 27 | |
| 28 | === 3.1 Преглед |
| 29 | |
| 30 | ||= Име =||= Опис =||= Одговорности =|| |
| 31 | || [Name the stakeholder type.] || [Briefly describe the stakeholder.] || Summarize the stakeholder’s key responsibilities with regard to the system being developed; that is, their interest as a stakeholder. For example, this stakeholder: |
| 32 | ensures that the system will be maintainable ensures that there will be a market demand for the product’s features monitors the project’s progress |
| 33 | approves funding and so forth]|| |
| 34 | || || || || |
| 35 | || || || || |
| 36 | || || || || |
| 37 | || || || || |
| 38 | |
| 39 | === 3.2 Корисничка околина |
| 40 | |
| 41 | [Detail the working environment of the target user. Here are some suggestions: |
| 42 | Number of people involved in completing the task? Is this changing? |
| 43 | How long is a task cycle? Amount of time spent in each activity? Is this changing? |
| 44 | Any unique environmental constraints: mobile, outdoors, in-flight, and so on? |
| 45 | Which system platforms are in use today? Future platforms? |
| 46 | What other applications are in use? Does your application need to integrate with them? |
| 47 | This is where extracts from the Business Model could be included to outline the task and roles involved, and so on.] |
| 48 | |
| 49 | == 4. Преглед на производот |
| 50 | |
| 51 | === 4.1 Барања |
| 52 | |
| 53 | Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how) they should be implemented. Capture the stakeholder priority and planned release for each feature.] |
| 54 | |
| 55 | ||= Потреба =||= Приоритет =||= Карактеристики =|| |
| 56 | || Dummy text || || || |
| 57 | || || || || |
| 58 | || || || || |
| 59 | || || || || |
| 60 | || || || || |
| 61 | |
| 62 | |
| 63 | |
| 64 | == 5. Други барања |
| 65 | |
| 66 | [At a high level, list applicable standards, hardware, or platform requirements; performance requirements; and environmental requirements. |
| 67 | Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the Feature Set. |
| 68 | Note any design constraints, external constraints, assumptions or other dependencies that, if changed, will alter the Vision document. For example, an assumption may state that a specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the Vision document will need to change. |
| 69 | Define any specific documentation requirements, including user manuals, online help, installation, labeling, and packaging requirements. |
| 70 | Define the priority of these other product requirements. Include, if useful, attributes such as stability, benefit, effort, and risk.] |
| 71 | |
| 72 | ||= Барање =||= Приоритет=|| |
| 73 | || Dummy text || || |
| 74 | || || || |
| 75 | || || || |
| 76 | || || || |