| 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 | | ||= За =|| Сите луѓе || |
| 20 | | ||= Кои =|| Сакаат лесно да се навигираат низ некоја институција || |
| 21 | | ||= FINKI Maps =|| Е веб апликација за навигирање низ институции || |
| 22 | | ||= Кој овозможува =|| Лесно пребарување и навигирање до простории || |
| 23 | | ||= За разлика од =|| Физички знаци и ознаки || |
| 24 | | ||= Нашиот продукт =|| Можност за креирање на интерактивна мапа за секоја институција || |
| 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: 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 approves funding and so forth]|| |
| 32 | | || || || || |
| 33 | | || || || || |
| 34 | | || || || || |
| 35 | | || || || || |
| 36 | | |
| 37 | | === 3.2 Корисничка околина |
| 38 | | |
| 39 | | [Detail the working environment of the target user. Here are some suggestions: |
| 40 | | Number of people involved in completing the task? Is this changing? |
| 41 | | How long is a task cycle? Amount of time spent in each activity? Is this changing? |
| 42 | | Any unique environmental constraints: mobile, outdoors, in-flight, and so on? |
| 43 | | Which system platforms are in use today? Future platforms? |
| 44 | | What other applications are in use? Does your application need to integrate with them? |
| 45 | | This is where extracts from the Business Model could be included to outline the task and roles involved, and so on.] |
| 46 | | |
| 47 | | == 4. Преглед на производот |
| 48 | | |
| 49 | | === 4.1 Барања |
| 50 | | |
| 51 | | 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.] |
| 52 | | |
| 53 | | ||= Потреба =||= Приоритет =||= Карактеристики =|| |
| 54 | | || Dummy text || || || |
| 55 | | || || || || |
| 56 | | || || || || |
| 57 | | || || || || |
| 58 | | || || || || |
| 59 | | |
| 60 | | |
| 61 | | |
| 62 | | == 5. Други барања |
| 63 | | |
| 64 | | [At a high level, list applicable standards, hardware, or platform requirements; performance requirements; and environmental requirements. |
| 65 | | Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the Feature Set. |
| 66 | | 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. |
| 67 | | Define any specific documentation requirements, including user manuals, online help, installation, labeling, and packaging requirements. |
| 68 | | Define the priority of these other product requirements. Include, if useful, attributes such as stability, benefit, effort, and risk.] |
| 69 | | |
| 70 | | ||= Барање =||= Приоритет=|| |
| 71 | | || Dummy text || || |
| 72 | | || || || |
| 73 | | || || || |
| 74 | | || || || |
