SRS Print
SRS Print
SRS Print
1. Preface …………………………………………………………………………………………… 02
2. Introduction………………………………………………………………………………………. 03
2.1. Purposes
2.2. Scope
2.3. Organization
2.4. References
3. Glossary …………………………………………………………………………………………. 04
4. User Requirements Definition …………………………………………………………...…... 05-06
4.1. External Interface Requirements
4.1.1. User Interfaces
4.1.2. Hardware and software Interfaces
4.2. Functional Requirements
4.3. Non Functional Requirements
5. System Architecture …………………………………………………………………..……….06-08
5.1. Product perspective and Functions
5.2. System Environment
5.3. User characteristics
5.4. Assumptions and dependencies
6. System Requirements Specification …………………………………………………..………08-11
6.1. External Interface Requirements
6.1.1. User Interfaces – GUI
6.1.2. Hardware and software Interfaces
6.1.3. Communications interfaces
6.2. Functional Requirements
6.3. Non Functional Requirements
6.3.1. performance Requirements
6.3.2. Safety Requirements
6.3.3. Software Quality Attribute
6.3.4. Reliability
6.3.5. Multilingual Support
7. System Models ………………………………………………………………………………...11-22
7.1. Use Cases
7.1.1. UC 1
7.1.2. UC 2
7.1.3. UC 3
7.1.4. UC 4
7.1.5. UC 5
7.1.6. UC 6
7.1.7. UC 7
7.1.8. UC 8
7.1.9. UC 9
7.2. Use Case Diagram
8. System Evolution ……………………………………………………………………………...23-24
Appendix-I ………………………………………….………………………………….………... 25
Alphabetical Index ………………...………………………………………………..…..……….. 26
Index of diagrams ………………………………………………………………………..……… 27
2
1. Preface
The software requirements specification (or SRS) is an official statement of what the system
developers should implement. Both the user requirements for our system and a detailed specification
of the system requirements is included in this document. Actually, in this SRS, the user requirements
are defined as an introduction to the system requirements specification. This document is essential as
we’re acting as outside contractor while developing the software system named Efficiency Monitor.
It is useful to write this supporting document that defines the technical/non-functional requirements
for the system; it is easy to forget the requirements that apply to the system as a whole when focusing
on the functional requirements for the system release.
In short, this Software requirements document will focus mainly on defining the user requirements
and high-level, non-functional system requirements.
Readership
This requirements document has a diverse set of readers, ranging from the senior management of our
organization to the engineers responsible for developing the software. It is primarily aimed that the
customer(s), System analyst, project manager, Designer, Coder, tester, in a word every actor related
to our project will be considered as readers of this document. This SRS document will be presented
to our customers to validate the requirements we discovered while interviewing users and listed in
this document. Designer will use this SRS document as a primary material of his/their designing
process. Coder and tester will use SRS document while working in their sectors to understand what
are they actually going to do. In short, every person related to development and maintenance process
need this document as a primary postulata.
Version History
As this is the introductory version of “Efficiency Monitor” application, there is no previous version
history of this product. In version-1.0 of Efficiency monitor, we’re going to try our best to satisfy all
user requirements we have discovered through our study and interviewing customer and likelier
users [ mentioned in chapter-4 of this document].
In case, user encounter any limitations or laggings while using our product and report us or request
any new appealing features, we’ll introduce an updated version of Efficiency Monitor solving all
limitations and adding requested features or adding features of our own.
2. Introduction
2.1. Purpose
The purpose of this document is to present a detailed description of the undertaken Android Project
named Efficiency Monitor. It will explain the purpose and features of the system, the interfaces of
the system, what the system will do, the constraints under which it must operate and how the system
will react to external stimuli. This document is intended for both stakeholders and the developers of
the system.
2.2. Scope
This Android Application will be designed to maximize the user’s productivity by providing tools to
assist him/her to categorize his/her daily tasks according to their perfect priority. Which would
otherwise have to be simply avoided or performed using analog and time-consuming ways such as
pen/paper. By maximizing the user’s work efficiency and productivity the system will meet the user's
needs while remaining easy to understand and use.
More specifically, this system will be designed to give a clear idea to the user about which of his/her
task is should be done at which time to make his/her day more efficient. The app will facilitate its
users by saving their valuable time and will ensure a perfect management of their tasks. It will also
help them decide which task can be eliminated from his to-do list which ensure that their afford
won’t go in vain.
2.3. Organization
This document covers 7 chapters. The next chapter, the glossary section, of this document represents
the general meaning of some technical terms used in this document to make this document customer
friendly. Third section names as User requirement definition describes the services provided for the
user. It also covers the non-functional system requirements. we’ll use natural language, diagrams, or
other notations that are understandable to customers for this description. 4 th chapter titled as system
architecture presents a high-level overview of the anticipated system architecture, showing the
distribution of functions across system modules. This section Also highlights the architectural
components that are reused. In the next chapter System Requirement specification we described the
functional and non-functional requirements in more detail. Graphical system models showing the
relationships between the system components, the system, and its environment is included in Sixth
chapter named System Models. Next chapter titled as System Evolution describes the fundamental
assumptions on which the system is based, and any anticipated changes due to hardware evolution,
changing user needs, and so on. Appendices with detailed, specific information that is related to the
application (Efficiency Monitor) is added after 7th section.
2.4. References
IEEE: IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications,
IEEE Computer Society, 1998.
3. Glossary
Android – An operating system designed for mobile devices (i.e. cell phones, tablet computers) by
Google, Inc.
Android device – Any device running Android. In this document, synonymous to “smart phone
running Android.”
DFD (Data Flow Diagram) - A graphical representation that refers the system using functions
performed in the system and data produced by these functions.
Interface - A specification of the attributes and operations associated with a software component.
The interface is used as the means of accessing the component’s functionality.
Maintenance prediction- The process in which project manager try to predict what system changes
might be proposed and what parts of the system are likely to be the most difficult to maintain.
Object Model - A model of a software system that is structured and organized as a set of object
classes and the relationships between these classes.
Object-Oriented (OO) Approach - An approach to software development where the fundamental
abstractions in the system are independent objects.
Reliability - The ability of a system to deliver services as specified. Reliability can be specified
quantitatively as a probability of failure on demand or as the rate of occurrence of failure.
Requirement, functional - A statement of some function or feature that should be implemented in a
system.
Requirement, non-functional - A statement of a constraint or expected behavior that applies to a
system. This constraint may refer to the emergent properties of the software that is being developed
or to the development process.
Sequence Diagram - A diagram that shows the sequence of interactions required to complete some
operation. In the UML, sequence diagrams may be associated with use cases.
Software Requirements Specification - A document that completely describes all of the functions
of a proposed system and the constraints under which it must operate. For example, this document.
Software Architecture - A model of the fundamental structure and organization of a software
system.
Stakeholder - Any person with an interest in the project who is not a developer.
User- Someone who interacts with the android device.
User Interface - The way in which information produced by the system is displayed and the way in
which system users can access system functionality and
Unified Modeling Language (UML) - A graphical language used in object-oriented development
that includes several types of system models that provide different views of a system.
Use Cases- Use cases are a requirements discovery technique that identifies the actors involved in an
interaction and names the type of interaction.
5. System Architecture
This section will give an overview of the whole system. The system will be explained in its context
to show how the system interacts with user and introduce the basic functionality of it. It will also
describe what functionality is available for stakeholders. At last, the constraints and assumptions for
the system will be presented.
5.1. Product perspective and functions
This system will be a mobile application. The mobile application will be used to add daily tasks
according to their urgency and importance and keep track of the amount of done tasks. This system
also includes a feature called priority game, a quiz game, to ease user boredom. This system have
some other minor functions that’ll be mentioned later in this report. In this subsection we will
develop a block diagram to represent what the main functionalities of our system. The block diagram
is illustrated in figure 5.1.
Imp/ Imp/
urgent notUrgent
progress
Q1
Q2 Award
Play priority game acheivements
points
Qn
Edit
photo
Edit
User’s details
Update Info Profile
Badges
Add Tasks
Task List
Priority Game
Achievements
User User
Notifications
Efficiency Monitor
After studying the requirements mentioned by user [ listed in section 4], we’ve figured out a basic
logic structure of Efficiency Monitor mobile application. [shown in figure-5.3]. That structure
basically shows the primary activities, actors, features and primary relationships between them. In
general language, logic diagram shows who is doing and what is doing.
Adds
Task
Views
plays Updates
Calender
Updates
Achivements
Game Profile
Tasklist
Gives
which drives user to ‘setting’ page that allows him/her to change app’s language and theme to
preferred one. Credits, which drives user to credits page that displays abstract information about the
developer team. And finally, Exit, by tapping on which user can exit the application.
5. Profile Page: Profile page contains three options. First one (view details) shows the personal
details, second one (Display Picture) shows profile image that user saved previously and contains
options to edit the details and update the avater. The last option ‘Badges’ let user see the badges
he/she already achieved. By tapping on ‘user’s image’ from app’s home page or from menu pane user
will be able to visit ‘profile’ page.
6. Priority game & achievements:The home page of Efficiency monitor app contains a
‘Achievement’ option as mentioned earlier. When user taps on that option a new page titled as
Achievements is open. That page let user see the total amount of collected award points, claim new
badges(Platinum, Golden or Silver) and view a statistical chart of the category wise amount of total
tasks.
When user taps on ‘Priority game’ option from the app’s home page a page titled as ‘priority game’ is
open. That contains a block list where every block is leveled with a story number. Every block drives
user to a new story and quiz list from where user selects the correct ans of the questions. Every
correct answer earn him/her award points.
8.3. User views his/her most important task from that window and taps on delete button
associated with that task.
8.5. The system marks that task as done and removes from the reminder list.
9. Scenario: View Credits
Initial Step-By-Step Description:
9.1. User opens menu pane.[Using senator-5]
9.2. User selects Credits option from the list.
9.3. The system shows a window displaying some brief informations about our developer
team.
7. System Models
In this chapter, we’ll develop abstract models of the system to represent different view or perspective
of the system. In another words, we’ll represent the system using some kind of predefined graphical
notation. UML(Unified Model language) will be used for system modeling.
System modeling of our system aims to explain the proposed requirements to other system
stakeholders. we’ll use these models to discuss design proposals and to document the system for
implementation.
The use cases and key diagrams of our system is added as subsection.
7.1. Use Cases
Use Cases help us to identify the actors involved in an interaction and names the type of interaction.
This subsection outlines the Use Cases for our system’s users. Use cases are determined following
the scenarios mentioned in section-6.
7.1.1. UC 1
Use Case: Add New Task
Diagram:
Brief Description:
User adds a new task in his task list according to its importance and urgency.
UC1 : Add new Task
Preconditions:
1. The phone is powered on.
2. ‘Efficiency Monitor’ app is installed.
Main Success Scenario:
1. User taps the ‘All App’ icon from the home screen.
2. System shows app list
3. User taps ‘Efficiency Monitor’ app’s icon from the list.
4. System opens the app.
5. System shows the app’s home page, where ‘+’ signed button indicates Add New Task
operation.
6. User clicks ‘Add New Task’ button from that home screen.
7. System displays ‘New Task’ page, which contains 4 areas that allows user to entry his/her
task in any of that 4 areas according to its priority.
8. User taps on his/her desired task listing area.
9. System shows three input option ‘text’, ‘image’, ‘pdf’.
10. User adds his/her task using any of that three input method.
11. User taps done button.
12. System Prompts whether user want to set notification or no.
13.User taps ‘set reminder’.
14. System Stores the task as the most prior task of today.
15. System prompts whether the user want to save the changes or he/she want to cancel.
16. User taps the ‘Save’ option.
Postcondition:
1. System displays ‘Your Task Has Been Added.’ message.
2. System shows the updated task list.
Alternative Courses:
10a. System is not showing the selected image or pdf.
10a.01. User leaves the application using back button.
10a.02.Resume @3.
13a. Use taps ‘Do not set reminder’ button
13a.01. Jump to @15
16a. User taps ‘cancel’ option.
16a.01. System returns to the previous page.
16a.02. Resume @10.
7.1.2. UC 2
Use Case: View Achievements
Diagram:
View
Achievements
Brief Description:
User views his/her achievements i.e. total collected award points, a chart of his/her category wise
task amount, and claim badges.
UC2 : View Achievements
Preconditions:
1. The phone is powered on
2. ‘Efficiency Monitor’ app is installed.
3. ‘Efficiency Monitor’ App is open.
Main Success Scenario:
1. System displays the home page of Efficiency Monitor App.
2. User taps on the button leveled as ‘Achievements’ from that home screen.
3. System displays ‘Achievement’ page.
4. User Views the chart indicating category wise total task amount and total amount of
collected award points from that page.
5. User taps on ‘platinum badge’ button.
6. System displays Congratulation message for achieving that badge.
7. User taps on ‘golden badge’ button.
8. System displays Congratulation message for achieving that badge.
9. User taps on ‘silver badge’ button.
10. System displays Congratulation message for achieving that badge.
11. User taps back button of his phone.
Postconditions:
1. Achieved badge is added to user’s profile details.
2. System displays the home page of efficiency monitor app.
Alternative Courses:
6a. User is not eligible for platinum badge.
6a.01. System displays a message saying ‘you’re not eligible for platinum badge
collect more award points’.
6a.02. Resume @7.
8a. User is not eligible for golden badge.
8a.01. System displays a message saying ‘you’re not eligible for golden badge collect
more award points’.
8a.02. Resume @9.
7.1.3. UC 3
Use Case: Play Priority Game
Diagram:
Play Priority
Game
User
Figure-7.3: UC3
Brief Description:
User plays a quiz game named ‘Priority Game’ in case of boredom or to spend his/her free time.
Priority Game earns him/her points that are added to his/her award point and help him/her achieve
badges.
UC3 : Play Priority Game
Preconditions:
1. The phone is powered on
2. ‘Efficiency Monitor’ app is installed.
3. ‘Efficiency Monitor’ app is open.
Main Success Scenario:
1. System displays the home page of Efficiency Monitor App.
2. User taps on the ‘Priority Game’ button from the display screen.
3. System displays ‘priority game’ page which contains many rectangular boxes leveled as
‘Story 1’, ‘story 2’…...’Story n’. Every boxes also contains few lines of it’s story.
4. User Taps any of the ‘n’ buttons leveled ‘Story X’. [x indicates the story number]
5. System displays that story in a new window. Below that story, there are few MCQ question
with multiple answer option. [Every question earns the user some points].
6. User reads that story and questions.
7. User selects an answer from the choice list.
8. System shows ‘Right answer’ message.
9. System adds the points to user’s award points.
Postconditions:
1. System displays ‘Congratulations! You earned ___ award point’ message.
Alternative Courses:
8a. The answer is wrong.
8a.01. System displays ‘Wrong answer! Try again’ message.
8a.02. Resume @7.
Exceptions:
1. The User may abandon playing at any time.
7.1.4. UC 4
Use Case: Update Profile
Diagram:
Update
Profile Upload profile image
User
Figure-7.4: UC4
Brief Description:
User views and updates his/her own profile details. Details includes- personal informations, his/her
images, and the badges he/she already earned.
1. System updates user’s profile image on ‘profile’ page, under ‘Menu’ option and ‘Home’
page.
2. System Updates user’s general information such as ‘name’ in ‘Menu’ pane as well as on
‘Profile’ page.
Alternative Courses:
4a. User taps ‘Display Picture’.
4a.01. Jump to @14
4b. User Taps ‘Badges’ option.
4b.01. Jump to @22
5a. There is no previously saved information [First time user]
5a.01. System displays ‘Update Profile’ page directly.
5a.02. Resume @8
12a. User needs few more changes and taps Edit button again.
12a.01. Return to @7.
15a. No previously set image. [First time user]
15a.01. System displays a window with an empty image area and ‘update’ option.
15a.02. Jump to @16
20a. Image is not updated
20a.01. Format is not supported
20a.01.01. Return to @16
20a.02. Image size is extra large or very small
20a.02.01. Return to @16
23a. No earned badge list available.
23a.01. System displays empty window with Play game to earn new badge’ and ‘ok’
options.
23a.02. Resume @24.
24a. User taps on ‘play game to earn new badge’ button.
24a.01. System automatically drives to UC3.
Exceptions:
1. The user may abandon the operation at any time.
7.1.5. UC 5
Use Case: View Menu
Diagram:
View
Menu
User
Figure-7.5: UC5
Brief Description:
User visits ‘Menu’ ambit to review ‘Settings’ / ‘Credits’, to view ‘Calender’, or simply to exit the
Application.
UC5 : View Menu
Preconditions:
1. The phone is powered on
2. ‘Efficiency Monitor’ app is installed.
3. ‘Efficiency Monitor’ app is open.
7.1.6. UC 6
Use Case: View Calender
Diagram:
View
View Menu Calender
User
Figure-7.6: UC6
Brief Description:
A monthly calender is shown to the user.
UC6 : View Calender
Preconditions:
1. The phone is powered on
2. ‘Efficiency Monitor’ app is installed.
3. ‘Efficiency Monitor’ app is open.
Main Success Scenario:
1. System displays the home page of ‘Efficiency Monitor’ App.
2. User taps on ‘Menu’ option from the left upper corner of the home screen. [ ( ≡ ) symbol
indicates menu option.]
3. System displays a side pane containing user’s image, name and four options - ‘Settings’,
‘Calender’, ‘Credits’ and Exit’.
4. User taps on ‘Calender’.
5. System displays a new window containing the calender of running month.
6. User taps back button or (x) sign.
Postconditions:
1. System displays the home page of the application.
Alternative Courses:
5a. ‘Credits’ window is not displayed
5a.01. User taps the back button.
5a.02. System displays the app list of his/her phone.
5a.02.01. System still stays in efficiency monitor app’s page.
5a.02.01.01. User taps menu icon
5a.02.01.02. System displays a side pane containing user’s image,
name and four options - ‘Settings’, ‘Calender’,‘Credits’
and ‘Exit’.
5a.02.01.03. User taps on ‘Exit’ option.
5a.02.01.04. Resume @5a.02.01
5a.03. User taps on ‘Efficiency Monitor’ app icon.
5a.04. Resume @1.
Exceptions:
1. The user may abandon the operation at any time.
7.1.7. UC 7
Use Case: Update Settings
Diagram:
Update
Settings
User
Figure-7.7: UC7
Brief Description:
In order to change his/her app’s language and theme user visits settings option from menu pane.
Alternative Courses:
8a. User taps on ‘Bengali’ leveled check-box.
8a.01. System displays ‘your app’s language successfully changed to Bengali’
message.
8a.02. Resume @10.
14a. User taps on ‘Dark’ leveled check-box.
14a.01. System displays ‘your app’s theme successfully changed to dark’ message.
14a.02. Resume @16.
Exceptions:
1. The user may abandon the operation at any time.
7.1.8. UC 8
Use Case: Notifications
Diagram:
Notifications
User
Figure-7.8: UC8
Brief Description:
User
UC8 : Notifications
Preconditions:
1. The phone is powered on
2. ‘Efficiency Monitor’ App is installed.
3. Efficiency Monitor App is pen.
Main Success Scenario:
1. System displays the home page of ‘Efficiency Monitor’ App.
2. User taps on ‘Notification’ option from the left upper corner of the home screen. [Bell icon
indicates notification option.]
3. System displays a pop up window showing a list of the most important tasks of the day.
4. User selects the task that he/she have completed.
7.1.9. UC 9
Use Case: View Credits
Diagram:
User
Figure-7.9: UC9
Brief Description:
System displays who were behind the successful development process.
UC 9 : View Credits
Preconditions:
1. The phone is powered on
2. ‘Efficiency Monitor’ app is installed.
3. ‘Efficiency Monitor’ app is open.
Main Success Scenario:
1. System displays the home page of ‘Efficiency Monitor’ App.
2. User taps on ‘Menu’ option from the left upper corner of the home screen. [ ( ≡ ) symbol
indicates menu option.]
3. System displays a side pane containing user’s image, name and four options - ‘Settings’,
‘Calender’, ‘Credits’ and Exit’.
4. User taps on ‘Credits’ option.
5. System displays a new window titled as ‘Credits’ which contains abstract information of
our developer team.
6. User taps back button or (x) sign.
Postconditions:
1. System displays the home page of the application.
Alternative Courses:
5a. ‘Credits’ window is not displayed
5a.01. User taps the back button.
5a.02. System displays the app list of his/her phone.
5a.02.01. System still stays in efficiency monitor app’s page.
5a.02.01.01. User taps menu icon
5a.02.01.02. System displays a side pane containing user’s image,
name and four options - ‘Settings’, ‘Calender’,‘Credits’
and ‘Exit’.
5a.02.01.03. User taps on ‘Exit’ option.
5a.02.01.04. Resume @5a.02.01
5a.03. User taps on ‘Efficiency Monitor’ app icon.
5a.04. Resume @1.
Exceptions:
1. The user may abandon the process at any time.
<<include>>
<<Extend>>
Change
language
Update profile info
<<Extend>>
As we are following object oriented approach (OOP) to develop our system, DFD(Data Flow
Diagram)s can be avoided easily. But for a better understanding DFDs may be proved essential in
some rare cases. Hence, we attached the DFDs of our Efficiency Monitor App in Appendix-I.
8. System Evolution
We made some fundamental assumptions to show this project the light of day. In this section we
describe those fundamental assumptions on which the system is based, and any anticipated changes
due to hardware/software evolution, changing user needs, and so on.
Our software development process does not stop when the system is delivered but continues
throughout the lifetime of the system. After we deploy our application, Parts of the app may have to
be modified to correct errors that are found in operation, to adapt it for changes to its hardware and
software platform, and to improve its performance or other non-functional characteristics. As our
product is completely our organization based, means software customer might not issuing another
contract for system support and evolution, we have really a big deal with evolution process. The
evolution process includes the fundamental activities of change analysis, release planning, system
implementation, and releasing a system to customers.
We figured out some of problems that can be arose after deployment and have to be tackled with
urgently. We also made some assumption that can be the reason behind that problems. Table-I shows
a list of those reasons.
Table-I : Potential reasons that can cause severe problems during evolution process
2. The system’s operating environment can be changed and that will surely disrupt normal operation.
[ For example: if a completely new android version is released our system may not work with that
system.]
3. The plan-driven approach we are following can be proved inappropriate while maintenance and
evolution time is running. Then, we’ll have to change our currently followed approach to agile-
approach. And start from scratch while planning the second version.
Program modularization- A manual process in which related parts of the program are grouped
together and, where appropriate, redundancy is removed, functions updated. In some cases, this stage
may involve architectural refactoring.]
In case, any of those situation arises, we need a perfect plan to tackle the situation. That planning
process is called Maintenance prediction in engineer’s tongue. Maintenance prediction of our system
is shown in Table-II.
As the process of software evolution is driven by customer’s request for change in deployed product
we are badly dependent on customer’s feedback for this process. This section gives a simple abstract
assumption of this process.
Appendix-I
DFD (Data Flow Diagram) helps us understand the how the data is flowing across the system and
what is the relation between the functions of the system.
Level 0 DFD and Level 1 DFD of Efficiency Monitor are shown in figure-9.1 and figure-9.2
respectively.
Play Game
User Efficiency Monitor User
Give Personal
Information Show Task list
Level-1 DFD:
3
Update Profile
Info
4
5 Show
1 Profile
Update
6
Add new Settings
Language
8 Task & View
Themes change Calender
Play Game Task
7
Notification
Task Completion
2 Push
Notification
Award points Show Task
list
Achivements
Alphabetical Index
A Maintenance- 2, 4, 23, 24
abstract- 4, 5, 7, 9, 11, 20, 24
add- 5, 6, 8, 9, 10, 11, 12, 13, 14 N
activity- 8 natural language- 3, 5
alternative- 12, 13, 14, 16, 17, 18, 19, 20, 21
android- 3, 4, 5, 8, 9, 24 O
app- 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 17, 18, 19, object – 4, 22
20, 22, 23, 25 object-oriented approach- 4, 22
architecture- 3, 4, 5, 6
P
B product- 2, 3, 6, 7, 23, 24
block diagram- 6 project- 2, 3, 4, 23
process- 2, 4, 6, 11, 20, 21, 23, 24
C
case- 3, 4, 6, 11, 19, 23, 24 Q
communication- 9 quality- 5, 11
context- 6
customer- 2, 3, 23, 24 R
reliability- 4, 11
D requirements- 2, 3, 4, 5, 7, 8, 11, 21, 23
development- 2, 4, 20, 23
deployment- 23 S
design- 2, 3, 4, 11, 21 safety- 11
document- 2, 3, 4, 11 software- 2, 4, 5, 9, 11, 23, 24
specification- 2, 3, 4, 8, 11
E stakeholders- 3, 6, 11
efficiency- 2, 3, 7, 8, 9, 11, 12, 13, 14, 15, 16, system- 2 , 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
17, 18, 19, 20, 21, 25 15, 16, 17, 18, 19, 20, 21, 22, 23, 24
exceptions- 13, 14, 16, 17, 18, 19, 20, 21 system evolution- 3, 23
F T
functional requirements- 2, 3, 5, 8, 9, 11 task- 3, 5, 6, 8, 9, 11, 12, 13, 20
G U
graphical- 3, 4, 5, 11 UML- 4, 11, 21
user- 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14,
I 15, 16, 17, 18, 19, 20, 21, 23
implementation- 11, 23 use cases- 4, 11, 12, 13, 14, 16, 17, 18, 19
input- 6, 9, 11, 12 20, 21
interaction- 4, 11, 21 use Case Diagram- 21, 22
interfaces- 3, 4, 5, 8, 9, 11, 23
V
M version- 2, 5, 9, 23
models- 3, 4, 11 view- 3, 4, 5, 6, 8, 9, 10, 11, 13, 15, 16, 17, 20
Index of diagrams