-
Notifications
You must be signed in to change notification settings - Fork 21
/
Copy pathrequirements_analysis.typ
79 lines (59 loc) · 3.79 KB
/
requirements_analysis.typ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
#import "/utils/todo.typ": TODO
= Requirements Analysis
#TODO[
This chapter follows the Requirements Analysis Document Template in @bruegge2004object. Important: Make sure that the whole chapter is independent of the chosen technology and development platform. The idea is that you illustrate concepts, taxonomies and relationships of the application domain independent of the solution domain! Cite @bruegge2004object several times in this chapter.
]
== Overview
#TODO[
Provide a short overview about the purpose, scope, objectives and success criteria of the system that you like to develop.
]
== Current System
#TODO[
This section is only required if the proposed system (i.e. the system that you develop in the thesis) should replace an existing system.
]
== Proposed System
#TODO[
If you leave out the section “Current system”, you can rename this section into “Requirements”.
]
=== Functional Requirements
#TODO[
List and describe all functional requirements of your system. Also mention requirements that you were not able to realize. The short title should be in the form “verb objective”
- FR1 Short Title: Short Description.
- FR2 Short Title: Short Description.
- FR3 Short Title: Short Description.
]
=== Nonfunctional Requirements
#TODO[
List and describe all nonfunctional requirements of your system. Also mention requirements that you were not able to realize. Categorize them using the FURPS+ model described in @bruegge2004object without the category functionality that was already covered with the functional requirements.
- NFR1 Category: Short Description.
- NFR2 Category: Short Description.
- NFR3 Category: Short Description.
]
== System Models
#TODO[
This section includes important system models for the requirements analysis.
]
=== Scenarios
#TODO[
If you do not distinguish between visionary and demo scenarios, you can remove the two subsubsections below and list all scenarios here.
*Visionary Scenarios*
Describe 1-2 visionary scenario here, i.e. a scenario that would perfectly solve your problem, even if it might not be realizable. Use free text description.
*Demo Scenarios*
Describe 1-2 demo scenario here, i.e. a scenario that you can implement and demonstrate until the end of your thesis. Use free text description.
]
=== Use Case Model
#TODO[
This subsection should contain a UML Use Case Diagram including roles and their use cases. You can use colors to indicate priorities. Think about splitting the diagram into multiple ones if you have more than 10 use cases. *Important:* Make sure to describe the most important use cases using the use case table template (./tex/use-case-table.tex). Also describe the rationale of the use case model, i.e. why you modeled it like you show it in the diagram.
]
=== Analysis Object Model
#TODO[
This subsection should contain a UML Class Diagram showing the most important objects, attributes, methods and relations of your application domain including taxonomies using specification inheritance (see @bruegge2004object). Do not insert objects, attributes or methods of the solution domain. *Important:* Make sure to describe the analysis object model thoroughly in the text so that readers are able to understand the diagram. Also write about the rationale how and why you modeled the concepts like this.
]
=== Dynamic Model
#TODO[
This subsection should contain dynamic UML diagrams. These can be a UML state diagrams, UML communication diagrams or UML activity diagrams.*Important:* Make sure to describe the diagram and its rationale in the text. *Do not use UML sequence diagrams.*
]
=== User Interface
#TODO[
Show mockups of the user interface of the software you develop and their connections / transitions. You can also create a storyboard. *Important:* Describe the mockups and their rationale in the text.
]